Introduction
In Kubernetes, managing application configurations dynamically is essential for scalability, security, and zero-downtime deployments. Traditionally, configurations were hardcoded inside applications, requiring a restart to apply changes. However, Kubernetes ConfigMaps and Secrets allow us to separate configurations from application code, enabling real-time updates without affecting running pods.
In this guide, we will:
Use ConfigMaps for non-sensitive configuration data. Use Secrets for storing sensitive credentials securely. Mount configurations as volumes for dynamic updates without pod restarts.
Step 1: Creating a ConfigMap
A ConfigMap stores application settings like environment variables, log levels, and external API URLs.
ConfigMap YAML (configmap.yaml)
apiVersion: v1
kind: ConfigMap
metadata:
name: app-config
data:
APP_ENV: "production"
LOG_LEVEL: "info"
Apply the ConfigMap:
kubectl apply -f configmap.yaml
Step 2: Creating a Secret
A Secret securely stores sensitive data, such as database credentials and API keys.
Secret YAML (secret.yaml)
apiVersion: v1
kind: Secret
metadata:
name: app-secret
type: Opaque
data:
DB_PASSWORD: Ym9zcw==
To encode a password in base64:
echo -n "boss" | base64
Apply the Secret:
kubectl apply -f secret.yaml
Step 3: Injecting ConfigMap and Secret into a Deployment
Now, let’s inject these values into a Kubernetes Deployment.
Deployment YAML (deployment.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 2
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app
image: nginx:latest
env:
- name: APP_ENV
valueFrom:
configMapKeyRef:
name: app-config
key: APP_ENV
- name: LOG_LEVEL
valueFrom:
configMapKeyRef:
name: app-config
key: LOG_LEVEL
- name: DB_PASSWORD
valueFrom:
secretKeyRef:
name: app-secret
key: DB_PASSWORD
Apply the Deployment:
kubectl apply -f deployment.yaml
Step 4: Enabling Automatic Updates for ConfigMaps
By default, ConfigMaps do not update dynamically inside a running pod when changed. To enable automatic updates, we can mount the ConfigMap as a volume.
Modify Deployment to Use ConfigMap as a Volume
spec:
volumes:
- name: config-volume
configMap:
name: app-config
containers:
- name: my-app
image: nginx:latest
volumeMounts:
- name: config-volume
mountPath: "/etc/config"
readOnly: true
Apply the Updated Deployment:
kubectl apply -f deployment.yaml
Now, whenever the ConfigMap is updated, the mounted file inside the pod will automatically reflect the changes without requiring a pod restart.
Step 5: Verifying ConfigMap and Secret Usage
Check ConfigMap Values in a Running Pod
kubectl exec -it <pod-name> -- printenv | grep APP_ENV
Verify Secret Values (Base64 Encoded)
kubectl get secret app-secret -o yaml
Important: Kubernetes does not allow printing Secrets in plaintext for security reasons.
Conclusion
With ConfigMaps and Secrets, we have achieved: Separation of application and configuration for better maintainability. Dynamic configuration updates without pod restarts. Secure handling of sensitive data with Secrets.
This approach ensures zero downtime, scalable deployments, and strong security for your Kubernetes applications.
Have you implemented ConfigMaps and Secrets in your Kubernetes projects? Share your experiences in the comments!
