Kubernetes Reliability and Availability Scope

Kubernetes Reliability and Availability Scope is the definition of what falls within the discipline of keeping workloads running correctly and continuously despite individual component failures, covering self-healing mechanisms, redundancy and spread across failure domains, graceful degradation under partial failure, and the boundary separating this discipline from observability, disaster recovery, and pure performance scaling.

What Reliability and Availability Covers

Self-Healing Through Continuous Health Assessment

At its core, this scope covers the mechanisms that let Kubernetes detect an unhealthy workload instance and automatically take corrective action, restarting a crashed container, removing an unready pod from service traffic, without requiring human intervention for routine, individually recoverable failures.

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /ready
    port: 8080

Redundancy Across Failure Domains

This scope also covers the deliberate placement of workload replicas so that a single point of failure, a node, a rack, an availability zone, cannot take down every replica of a service simultaneously.

topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: DoNotSchedule

Controlled Disruption During Voluntary Changes

Reliability and availability scope extends to protecting a service's minimum available capacity during voluntary disruptions, node drains, cluster upgrades, that Kubernetes itself initiates, distinct from involuntary failures like a node crashing unexpectedly.

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

The Boundary With Observability

Reliability Acts, Observability Measures

Reliability and availability mechanisms take corrective action directly, restarting a container, rescheduling a pod, blocking a disruptive drain, while observability, covered as its own knowledge area, is concerned with measuring and reporting on system state without itself taking corrective action; a liveness probe restarting an unhealthy container is a reliability mechanism, while a dashboard showing elevated restart counts is an observability concern reporting on the same underlying event.

The Boundary With Disaster Recovery and Backup

Availability Within a Cluster vs. Recovery Across Clusters

This scope is concerned with keeping a workload available within the failure domains a single cluster spans, individual pods, nodes, and zones; recovering from a catastrophic event that destroys an entire cluster or region, restoring from backups, failing over to an entirely separate cluster, is a distinct discipline (disaster recovery) that builds on, but is not the same as, in-cluster reliability mechanisms.

# in scope: surviving the loss of one node out of ten
# out of scope: restoring the cluster after a full regional outage

The Boundary With Performance and Autoscaling

Reliability Under Failure vs. Capacity Under Load

Reliability and availability scope addresses correctness and continuity of service when components fail; it is related to, but distinct from, capacity management under increasing load, covered separately as autoscaling and performance tuning, though the two frequently interact, since an autoscaler's minimum replica count is itself a reliability-relevant parameter.

Layers Within Scope

Pod-Level, Node-Level, and Cluster-Level Mechanisms

Reliability mechanisms operate at several layers: pod-level (probes, restart policies), node-level (taints, evictions, node problem detection), and cluster-level (multi-zone spread, control plane redundancy), each addressing a different scale of failure domain, with a complete reliability posture requiring attention at every layer rather than any single one alone.

Relationship to the Broader Reliability and Availability Area

This scope statement establishes the working boundary for every subsequent topic in Kubernetes Reliability and Availability Basics: probes, restart policies, pod disruption budgets, topology spread, and node-level resilience mechanisms all operate within the space defined here, keeping workloads correctly running and continuously available despite individual component failure, explicitly distinct from the measurement concerns of observability, the catastrophic-scale concerns of disaster recovery, and the load-driven concerns of autoscaling.