Config, Secrets & Scaling
The production essentials: configuration, health checks, and automatic scaling.
Your app needs configuration (URLs, feature flags) and secrets (passwords, API keys) — and it should never bake these into the image. It also needs to stay healthy and scale with demand. This lesson covers the production essentials that make a Deployment truly robust.
🎯 Learning Objectives
By the end of this lesson you will:
- Store configuration in ConfigMaps and secrets in Secrets
- Inject them into Pods as environment variables or files
- Add liveness and readiness probes
- Autoscale a Deployment with the Horizontal Pod Autoscaler
ConfigMaps — Configuration Outside the Image
A ConfigMap holds non-sensitive configuration as key-value pairs:
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
LOG_LEVEL: "info"
FEATURE_NEW_UI: "true"Inject it into a Pod as environment variables:
spec:
containers:
- name: app
image: myapp:1.0
envFrom:
- configMapRef:
name: app-config💡 Why separate config from code?
The same image should run in dev, staging, and production — only the config changes. Keeping config out of the image means one build promotes cleanly through every environment.
Secrets — Sensitive Values
A Secret works like a ConfigMap but is meant for sensitive data (passwords, tokens, keys):
kubectl create secret generic db-secret \
--from-literal=DB_PASSWORD='s3cr3t'⚠ Secrets are base64, not encrypted by default
Kubernetes Secrets are only base64-encoded in etcd, not truly encrypted out of the box. For real security, enable encryption at rest for etcd and restrict access with RBAC, or use an external secrets manager (Vault, cloud KMS).
Inject a Secret the same way you inject config:
env:
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: db-secret
key: DB_PASSWORDHealth Probes
Kubernetes needs to know if your app is alive and ready. Two probes tell it:
| Probe | Question it answers | On failure |
|---|---|---|
| livenessProbe | Is the app still alive? | Restart the container |
| readinessProbe | Is the app ready for traffic? | Remove it from the Service until ready |
livenessProbe:
httpGet:
path: /healthz
port: 3000
initialDelaySeconds: 10
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 3000
periodSeconds: 5💡 Readiness enables zero-downtime deploys
During a rolling update, traffic is only sent to Pods that pass their readiness probe. A new Pod that’s still starting up won’t receive requests until it’s genuinely ready.
Autoscaling with the HPA
The Horizontal Pod Autoscaler adds or removes Pods automatically based on metrics like CPU usage:
kubectl autoscale deployment web \
--cpu-percent=70 --min=2 --max=10When average CPU crosses 70%, the HPA scales up toward 10 Pods; when load drops, it scales back down toward 2. This requires resource requests to be set on the containers so the HPA has a baseline to measure against.
🧪 Hands-on Lab
Configure, Secure, and Autoscale
- Create a ConfigMap with a
LOG_LEVELand inject it into your Deployment - Create a Secret for a database password and mount it as an env var
- Add an HPA that scales between 2 and 8 Pods at 70% CPU
🧠 Knowledge Check
Where should a database password be stored for a Pod?
What does a readiness probe control?
💼 Interview Preparation
How would you make a Kubernetes app production-ready?
Summary
You’ve completed the Kubernetes track: architecture, Pods and Deployments, Services and Ingress, and now config, secrets, probes, and autoscaling. You can deploy and operate a resilient app on a cluster. Next, we provision the infrastructure itself as code with Terraform.