Kubernetes Availability Model

Kubernetes Availability Model ensures system reliability through automated failover, redundancy, and self-healing mechanisms across containerized workloads.

Kubernetes Availability Model is the framework for defining, measuring, and composing availability as a quantitative property of a Kubernetes-hosted system, covering the service-level indicator, objective, and agreement hierarchy, the mathematics of composing availability across dependent components, and how control-plane and data-plane availability are architected and measured separately within a cluster.

The SLI, SLO, SLA Hierarchy

Service Level Indicators as the Raw Measurement

sum(rate(http_requests_total{status!~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

A service level indicator (SLI) is a directly measured quantity, the ratio of successful to total requests over a window, the fraction of time a /healthz endpoint returned success, forming the raw data every higher-level availability statement is built from.

Service Level Objectives as Internal Targets

# conceptual SLO definition
slo:
  target: 99.9%
  window: 30d
  indicator: successful_request_ratio

A service level objective (SLO) is an internally set target for an SLI over a defined window, used to drive engineering and operational decisions, error budget consumption, alerting thresholds, without necessarily being a contractual promise to any external party.

Service Level Agreements as External Commitments

An SLA is a contractual commitment, typically less strict than the internal SLO to leave margin for error, with defined consequences (credits, penalties) if not met; the availability model treats SLA as a business-layer artifact built on top of, but distinct from, the SLO an engineering team actually operates against.

SLA \leq SLO \leq Measured SLI

Availability Expressed as "Nines"

The Nines Convention

99%      -> 3.65 days downtime/year
99.9%    -> 8.77 hours downtime/year
99.99%   -> 52.6 minutes downtime/year
99.999%  -> 5.26 minutes downtime/year

Each additional "nine" of availability reduces tolerable annual downtime by roughly a factor of ten, and the availability model uses this convention to translate an abstract percentage target into a concrete, comparable downtime budget that stakeholders can reason about directly.

Downtime = (1 - Availability) \times Window

Composing Availability Across Dependent Components

Serial Dependencies Multiply Availability Down

A depends on B depends on C
Availability(A) <= Availability(B) x Availability(C)

When a service's own availability strictly depends on every one of several other services being simultaneously available, in a serial dependency chain, the composed availability is the product of each component's individual availability, meaning a system built from several 99.9%-available dependencies in series cannot itself exceed roughly 99.7% availability, regardless of how reliable its own code is.

A {serial}_{} = \prod_{i}^{n} A_{i}

Redundant Dependencies Compose Multiplicatively on Failure

A depends on either B or B' (redundant)
Unavailability(A due to B) = Unavailability(B) x Unavailability(B')

When redundant, independent instances of a dependency exist and any one being available is sufficient, the composed unavailability (not availability) multiplies instead, which is the mathematical justification for why redundancy at every dependency layer, not just the primary workload, is necessary to achieve high composed availability across an entire request path.

U {redundant}_{} = \prod_{i}^{n} U_{i}

Control Plane vs. Data Plane Availability

Two Separately Measured Availability Domains

The availability model distinguishes control plane availability, whether the API server, scheduler, and etcd remain able to accept and process management requests, from data plane availability, whether already-running workload pods continue serving traffic; a control plane outage does not necessarily interrupt already-scheduled, already-running pods, meaning the two must be measured and targeted independently rather than conflated into a single cluster-wide number.

kubectl get componentstatuses
kubectl get --raw /healthz

High-Availability Control Plane Architecture

etcd:
  members: 3
apiServer:
  replicas: 3

Running an odd number of etcd members (commonly three or five) to maintain quorum, and multiple API server replicas behind a load balancer, is the standard architecture for control plane availability, tolerating the loss of a minority of members or replicas without losing the ability to serve management requests or persist cluster state changes.

Quorum = \frac{n}{2} + 1

Availability From the Client's Perspective

Endpoint-Based Definition of Available

A pod is considered available to a client only once it is both running and passing its readiness probe, added to a Service's endpoint list; availability from the client's perspective is therefore defined at the Service endpoint layer, not merely at the pod-existence layer, which is why readiness probing is as central to the availability model as it is to the broader reliability model.

Relationship to Reliability Model and Reliability and Availability Areas

The availability model provides the quantitative measurement and composition framework that complements the reliability model's qualitative failure-and-recovery philosophy: where the reliability model explains why probes, redundancy, and spread reduce recovery time and correlated failure, the availability model provides the SLI/SLO vocabulary and composition mathematics used to set concrete targets for, and verify the actual effectiveness of, every mechanism enumerated under reliability and availability areas.