Injection Methods
Injection Methods
Four mechanisms, increasingly indirect:
- Literal env —
env: [{name: PORT, value: "8080"}]baked into the manifest. - valueFrom — pull one key:
configMapKeyReforsecretKeyRef(withoptional: trueif absence is acceptable). - envFrom — ingest every key of a ConfigMap or Secret as a variable;
prefix:namespaces the names to avoid collisions. - Downward API — expose pod metadata itself: namespace, name, labels, node name.
envFrom:
- configMapRef: { name: app-config, prefix: CFG_ }
- secretRef: { name: db-creds }
Keys must be valid environment names — ConfigMap keys matching the identifier rules translate directly; anything else is skipped or rejected depending on the path.
Env Vars Versus Files
Env Vars Versus Files
Environment variables suit small, scalar values the app reads once at boot: ports, log levels, feature flags. They are visible in kubectl describe, inherited by child processes, and never updated after start.
Files suit structured or rotating content: JSON blobs, certificates, whole nginx configs. Mounted from ConfigMaps or Secrets they refresh (non-subPath) and keep sensitive values out of process listings.
volumeMounts:
- { name: config, mountPath: /etc/app/config.json, subPath: config.json }
volumes:
- name: config
configMap: { name: app-config, items: [{ key: config.json, path: config.json }] }
A projected volume can combine both sources plus a service-account token in a single mount path.
Pitfalls and Interview Angles
Pitfalls and Interview Angles
Pitfall 1 — required refs that are missing. A secretKeyRef without optional: true blocks container start in CreateContainerConfigError when the key is absent — a classic "pod stuck waiting" trace in kubectl describe.
Pitfall 2 — envFrom collisions and timing. If a ConfigMap and Secret define the same key, later sources win silently; environment changes never reach running containers.
Interview-ready: describe your rule of thumb — env for scalars the app needs at boot, files for structured or rotated data — then the debug path for a stuck pod: describe shows CreateContainerConfigError, kubectl get secret confirms existence, key name is checked against the manifest, and the fix is a correct key reference or optional: true.
Quiz
1. What does envFrom with a prefix do?
2. A pod shows CreateContainerConfigError. Most likely cause?
3. Which method exposes pod metadata like namespace and labels as variables?
Flashcards
Question
envFrom vs valueFrom
Click to reveal answer
Answer
envFrom loads every key at once (with optional prefix); valueFrom selects one specific key.
Question
optional: true
Click to reveal answer
Answer
Lets a missing ConfigMap/Secret key fall back to absence instead of blocking container creation.
Question
Downward API
Click to reveal answer
Answer
Injects pod metadata (name, namespace, labels, node) via fieldRef/resourceFieldRef.
Question
Projected volume
Click to reveal answer
Answer
Combines ConfigMaps, Secrets, and service account tokens into one mount.
Revision Notes
Key Takeaways
- 1. Env for boot-time scalars; files for structured or rotating data
- 2. Missing keys block startup unless marked optional
- 3. Injection is start-time for env; sync-time for mounted files
Interview Tips
- • Give your env-vs-file decision rule with one example each
- • Trace CreateContainerConfigError from symptom to missing key reference
Cheat Sheet
Literal/valueFrom/envFrom/Downward API for env; files for structured data. secretKeyRef/configMapKeyRef block start unless optional:true; env never refreshes.