Application Observability and Maintenance
Here you diagnose workloads and keep them healthy after they ship.
Probes
Three probe types: livenessProbe restarts a wedged container, readinessProbe removes a Pod from Service endpoints, startupProbe suspends the other two until it succeeds. Trap: a readiness probe aimed at the wrong port or path leaves the Pod Running but never Ready; the Service then has empty endpoints and clients see connection failures. For slow-booting apps, size failureThreshold × periodSeconds on the startup probe to comfortably exceed boot time. Probes support httpGet, tcpSocket, exec, and grpc.
Logs, events, metrics
kubectl logs pod -c container is mandatory for multi-container Pods. --previous reads logs from the last crashed instance; -f follows, --tail=N trims. Events: kubectl get events --sort-by=.metadata.creationTimestamp reveals scheduling, pulling, and probe failures that describe summarizes. kubectl top pod requires metrics-server and may be unavailable.
Diagnosing states
Pending means unschedulable (resources, nodeSelector, taints); ImagePullBackOff means registry auth or tag; CrashLoopBackOff means the process exits; CreateContainerConfigError usually means a missing ConfigMap/Secret key. Exit code 137 is SIGKILL (often OOMKilled against a memory limit); 143 is SIGTERM.
Live debugging
kubectl debug -it pod --image=busybox --target=app injects an ephemeral container sharing the target's process namespace. Trap: ephemeral containers cannot declare ports or resources and cannot be removed once added. kubectl debug node/x creates a privileged Pod with host access.
Worked example: a Pod cycling with no logs points to a bad command; run kubectl get pod -o yaml, check lastState.terminated.exitCode and reason, then fix command/args.
Rule of thumb: liveness restarts, readiness routes, startup protects the other two.