Kubernetes Deployment Reliability Basics

Kubernetes Deployment Reliability Basics is the practice of configuring the resource requests and limits, Quality of Service classification, and structural composition of a Deployment so that its pods remain schedulable and survive node-level resource pressure, distinct from the rollout-time availability mechanics covered separately, focusing instead on steady-state reliability under normal operation and resource contention.

The Deployment-ReplicaSet-Pod Hierarchy

Layered Ownership and the pod-template-hash Label

metadata:
  labels:
    pod-template-hash: 7d8f9c9b8c

A Deployment never manages pods directly; it manages ReplicaSet objects, each stamped with a hash of its pod template, and each ReplicaSet in turn manages the actual pods, a layered structure that is what allows multiple ReplicaSet generations (old and new versions) to coexist safely during a rollout without their respective pods being confused with each other, since the hash uniquely distinguishes which generation a given pod belongs to.

Quality of Service Classes

Guaranteed, Burstable, and BestEffort

resources:
  requests: { cpu: 500m, memory: 512Mi }
  limits: { cpu: 500m, memory: 512Mi }

A pod is classified Guaranteed when every container's requests equal its limits for both CPU and memory; Burstable when at least one container has requests set but they do not equal limits; BestEffort when no requests or limits are set at all, and this classification directly determines eviction priority under node memory pressure.

Why QoS Class Matters for Reliability

Under node memory pressure, the kubelet evicts BestEffort pods first, then Burstable pods exceeding their requests, and only evicts Guaranteed pods as an absolute last resort; a workload whose reliability depends on not being evicted during contention should be explicitly configured as Guaranteed, rather than leaving requests and limits unset and unintentionally accepting BestEffort classification's much higher eviction risk.

kubectl get pod web-abc123 -o jsonpath='{.status.qosClass}'

Requests as the Scheduling Reliability Signal

Requests Determine Schedulability, Not Just Fairness

resources:
  requests: { cpu: 250m, memory: 256Mi }

The scheduler places a pod only on a node with enough unreserved capacity to satisfy its requests, meaning requests set too low relative to actual usage risk overcommitting a node (many pods scheduled based on optimistic requests, then contending for real resources under actual load), while requests set unrealistically high waste capacity and can make a pod unschedulable in a smaller cluster despite having room to run under its true usage.

Sizing Requests From Observed Usage

quantile_over_time(0.95, container_memory_working_set_bytes{pod=~"web-.*"}[7d])

Setting requests based on observed p95 or higher usage over a representative historical window, rather than an arbitrary guess, is the standard practice for balancing reliable scheduling against efficient cluster utilization, revisited periodically as the workload's actual resource profile evolves.

Limits and OOM Risk

Memory Limits Are Hard, CPU Limits Are Throttled

resources:
  limits: { memory: 512Mi, cpu: 1000m }

Exceeding a memory limit causes the container to be OOM-killed immediately, an abrupt, unrecoverable-in-place failure, while exceeding a CPU limit merely throttles the container's CPU time without killing it; this asymmetry means memory limits require more conservative headroom than CPU limits, since a memory limit set too tight against real peak usage produces outright restarts rather than merely degraded performance.

Combining Spread and Anti-Affinity Within the Deployment Spec

Structural Placement as Part of Steady-State Reliability

spec:
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule
          labelSelector:
            matchLabels: { app: web }

Because topology spread constraints and anti-affinity rules are declared within the Deployment's pod template, they apply consistently to every replica the ReplicaSet creates, including replacement replicas created after a failure, meaning the reliability benefit of spread is maintained automatically across the workload's entire operational lifetime, not merely at initial deployment.

Relationship to Replica Reliability, Rollout Availability, and the Reliability Model

Deployment reliability basics address the steady-state resource and placement configuration that determines whether a Deployment's replicas remain schedulable and survive contention, complementing replica reliability's count-maintenance focus and rollout availability's update-time focus: together these three areas cover a Deployment's full reliability surface, whether it can maintain its declared replica count, whether updating it preserves availability, and whether each individual replica is correctly sized and classified to survive the resource pressure a real cluster inevitably experiences.