Scenario
You have a Kubernetes cluster where the deployment webapp in namespace prod is stuck in CrashLoopBackOff.
The application exposes a health check endpoint at /healthz on port 8080. The container image already includes a config directory with the required files, but the deployment configuration has issues preventing the pod from starting correctly.
Because the config directory already exists and is used by the application, mounting a ConfigMap over the entire directory would overwrite it and cause the app to fail. The deployment needs to be fixed so configuration is injected without replacing the existing directory.
Task
Fix the pod so it reaches Running state with 1/1 Ready
Step 1: Check pod status
kubectl get pods -n prod
Observe the pod in CrashLoopBackOff state. Note the pod name for later use.
Step 2: Check pod logs
kubectl logs -n prod <pod-name>
Replace <pod-name> with actual pod name. Look for error about missing config file.
Step 3: Verify ConfigMap exists
kubectl get configmap webapp-config -n prod -o yaml
Confirms the ConfigMap exists and shows its data.
Step 4: Edit the deployment to fix both issues
kubectl edit deployment webapp -n prod
Fix two issues:
- ConfigMap mount - Add
subPath to mount the ConfigMap key as a file (not directory):
volumeMounts:
- name: config-volume
mountPath: /etc/webapp/config.yaml
subPath: config.yaml
- Readiness probe - Correct the path to match the application's health endpoint:
readinessProbe:
httpGet:
path: /healthz
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
Save and exit. Kubernetes will automatically roll out new pods with the fixes.
Step 5: Wait for new pod and verify status
kubectl get pods -n prod -w
Watch as old pod terminates and new pod becomes Running and Ready (1/1). Press Ctrl+C to stop.
Step 6: Verify config file is accessible
kubectl exec -n prod <pod-name> -- cat /etc/webapp/config.yaml
Replace <pod-name> with the new pod name. Should display ConfigMap content, confirming the subPath fix worked.