Kubernetes Operations
Operating Kubernetes well means designing workloads that cooperate with the scheduler and controllers. The platform can restart, reschedule, and roll out Pods, but it needs accurate signals and resource declarations.
Probes and Resources
Readiness probes tell Kubernetes whether a Pod should receive traffic. Liveness probes tell Kubernetes whether a Pod should be restarted. Startup probes protect slow-starting applications from premature liveness failures. Misused probes create outages: a liveness check that depends on a flaky downstream service can restart healthy application processes.
CPU and memory requests help scheduling. Limits constrain usage. Missing requests make capacity planning vague; unrealistic limits cause throttling or out-of-memory kills.
Upgrades and Disruption
Rolling updates require enough capacity to run old and new versions temporarily. Pod disruption budgets express how much voluntary disruption a service can tolerate. Node upgrades, cluster autoscaling, and spot interruptions become safer when workloads declare these constraints.
Exercise
For a service deployment, define what readiness means without relying on a dependency that can fail independently. Then define what liveness means as a process-health check, not a full business transaction.
Capacity and Scheduling
Kubernetes operations begins with resource honesty. Requests tell the scheduler what the workload expects. Limits tell the runtime what it may consume. If requests are too low, nodes become overcommitted and latency spikes under load. If limits are too low, applications are throttled or killed even when the cluster has spare capacity.
Horizontal autoscaling depends on meaningful signals. CPU works for compute-bound services, but queue depth, request rate, or custom business metrics may represent demand better. Autoscaling a broken service can amplify downstream pressure if retries and concurrency are not controlled.
Rollout Debugging
A failed rollout should be diagnosable from Kubernetes events, Pod status, container logs, and deployment history. Common causes include image pull failures, bad configuration, failed startup probes, missing secrets, insufficient resources, and incompatible security policies. Good platform defaults surface these causes clearly.
Cluster Upgrades
Clusters are living systems. Node images, control-plane versions, CNI plugins, storage drivers, admission controllers, and API deprecations all change. Teams should test workloads against upcoming versions, avoid deprecated APIs, and define disruption budgets for critical services. A cluster upgrade is a production change even when application code is untouched.
Study Task
Choose one workload and simulate a node drain in a non-production environment. Observe whether replicas reschedule, readiness protects traffic, disruption budgets behave as expected, and logs show graceful shutdown. Record any assumption that turned out false.
Operational Review
Kubernetes operations should be reviewed from the workload outward. Start with the Pod: does it start, become ready, consume resources predictably, and shut down gracefully? Then review the controller: does rollout preserve capacity and stop on failure? Then review cluster dependencies: DNS, ingress, storage, networking, admission policy, and autoscaling.
The review should also ask whether the team can debug common states. ImagePullBackOff, CrashLoopBackOff, Pending, failed readiness, and out-of-memory kills each imply different causes. Operators should know which command, event, log, or metric distinguishes them.
Production Kubernetes skill is pattern recognition plus humility. The platform is powerful, but small manifest choices can create large operational effects. Every workload should have a declared owner and a tested recovery path.