Kubernetes Reliability and Availability Areas

Kubernetes Reliability and Availability Areas are the distinct mechanism families Kubernetes provides for keeping workloads healthy and continuously available, spanning health probing and restart behavior, controlled disruption budgets, failure-domain spread and anti-affinity, graceful shutdown handling, and priority-based scheduling under resource contention.

Health Probing and Restart Behavior

Liveness, Readiness, and Startup Probes

livenessProbe:
  httpGet: { path: /healthz, port: 8080 }
  periodSeconds: 10
readinessProbe:
  httpGet: { path: /ready, port: 8080 }
  periodSeconds: 5
startupProbe:
  httpGet: { path: /healthz, port: 8080 }
  failureThreshold: 30
  periodSeconds: 2

Liveness probes detect a container that must be restarted to recover; readiness probes detect a container that should temporarily stop receiving traffic without being restarted; startup probes give slow-starting applications a grace period before liveness checking begins, preventing a legitimately slow boot from being mistaken for a hang.

restartPolicy

spec:
  restartPolicy: Always

The pod-level restartPolicy (Always, OnFailure, Never) determines whether the kubelet restarts a container after it exits, forming the baseline self-healing behavior beneath the more sophisticated probe-driven signals layered on top of it.

Controlled Disruption

Pod Disruption Budgets

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels: { app: web }

A PodDisruptionBudget constrains how many replicas of a workload can be voluntarily evicted at once (during a node drain or cluster upgrade), blocking the eviction API from removing more pods than the budget allows, protecting availability specifically during planned, Kubernetes-initiated disruptions.

Failure-Domain Spread

Topology Spread Constraints

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

Topology spread constraints instruct the scheduler to distribute replicas evenly across a given topology dimension, zones, nodes, racks, bounding the maximum imbalance (maxSkew) and choosing whether an unsatisfiable constraint should block scheduling entirely or merely be treated as a soft preference.

Pod Anti-Affinity

affinity:
  podAntiAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchLabels: { app: web }
        topologyKey: kubernetes.io/hostname

Pod anti-affinity rules prevent replicas of the same workload from being co-located on the same node (or other topology domain), a more targeted alternative to topology spread constraints for the specific case of avoiding same-node placement of otherwise identical pods.

Graceful Shutdown

terminationGracePeriodSeconds and preStop Hooks

spec:
  terminationGracePeriodSeconds: 30
  containers:
    - name: web
      lifecycle:
        preStop:
          exec:
            command: ["sh", "-c", "sleep 5"]

A preStop hook runs before the container receives SIGTERM, commonly used to deregister from a load balancer or drain in-flight requests, while terminationGracePeriodSeconds bounds how long the kubelet waits after SIGTERM before issuing SIGKILL, together determining whether a pod termination is disruptive to active requests or transparent to clients.

Node-Level Resilience

Taints, Tolerations, and Eviction

tolerations:
  - key: node.kubernetes.io/not-ready
    operator: Exists
    effect: NoExecute
    tolerationSeconds: 300

The node lifecycle controller automatically taints a node detected as unreachable or not-ready, and pods without a matching toleration (or whose toleration's tolerationSeconds expires) are evicted and rescheduled elsewhere, providing automatic recovery from node-level failures without requiring an operator to manually identify and reschedule affected workloads.

Priority and Preemption

PriorityClass for Contention Scenarios

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000

spec:
  priorityClassName: high-priority

Under resource contention, higher-priority pods can preempt (evict) lower-priority ones to obtain scheduling capacity, ensuring critical workloads remain schedulable even when a cluster is under pressure, at the deliberate cost of potentially disrupting lower-priority workloads.

Replica Redundancy as the Foundation

Multiple Replicas as a Prerequisite

Every mechanism above assumes and builds upon a foundational redundancy decision, running more than one replica of a workload, since a single-replica workload has no spare capacity for a PodDisruptionBudget to protect, no alternative placement for anti-affinity to diversify, and no standby instance to absorb a liveness-triggered restart without a service interruption.

Relationship to Reliability and Availability Scope

These areas are the concrete mechanism families operating within the boundary established by reliability and availability scope: probing and restart behavior address individual pod health, disruption budgets and topology spread address planned and unplanned disruption at the workload level, node-level taints and tolerations address infrastructure failure, and priority and preemption address resource contention, together forming the layered toolkit that keeps a workload correctly running and available despite the many independent ways a distributed system can partially fail.