Free tools Windows power users keep installed
One-click scans. No signup required.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Kubernetes is not automatically a new physical fault domain. A cluster runs on infrastructure that already has boundaries—such as nodes and zones—and its scheduler can distribute Pods across those boundaries. But spreading Pods does not by itself keep an application available: resilience also depends on control-plane and API endpoint design, capacity, storage, and how the application recovers.
What counts as a Kubernetes fault domain?
A fault domain is a group of resources that can be affected by the same failure. Depending on the infrastructure, that might mean a node, a rack, a zone, or a region. Kubernetes can use labels on nodes to represent those boundaries and apply Pod topology spread constraints to influence where workload Pods are placed. The Kubernetes documentation describes these constraints as a way to spread Pods across failure domains such as regions, zones, nodes, and user-defined domains (Pod Topology Spread Constraints).
Kubernetes does not create or distribute the underlying nodes by itself. The infrastructure provider or cluster operator determines where nodes exist and whether their labels accurately describe physical locations. If labels are missing or inconsistent, a scheduler rule may not reflect the real failure boundaries. A Deployment alone should not be treated as a promise of zone-level resilience; Kubernetes documentation notes that Pods are automatically spread across different nodes, while users who need control across zones should configure topology labels and constraints (Running in multiple zones).
How much protection does Pod spreading provide?
Topology spread constraints govern placement, not application availability. Their behavior depends on which nodes are eligible, how those nodes are labeled, the workload’s selectors, and the cluster’s available capacity. Constraints can express a preferred balance or prohibit a placement that would exceed the configured skew.
#1 Best Overall
whenUnsatisfiable: ScheduleAnyway: permits scheduling and prioritizes placements that reduce imbalance. It does not guarantee an even distribution if capacity or eligible domains are unavailable.whenUnsatisfiable: DoNotSchedule: prevents placement when it would violate the configured skew. This enforces the placement rule, but a Pod may remain Pending if the cluster cannot satisfy it.
For either setting, maxSkew defines the permitted difference in Pod counts across eligible domains. Multiple topology constraints are combined, so restrictive rules can leave Pods unscheduled even when the cluster has some free capacity. Check the current Kubernetes documentation for version-specific behavior before applying configuration; the page notes, for example, that nodeTaintsPolicy became generally available in Kubernetes v1.33 and describes feature-gate history for minDomains (Pod Topology Spread Constraints).
Which design fits the failure you need to tolerate?
| Design or boundary | What it can address | What it does not establish |
|---|---|---|
| Replicas on separate nodes | Reduces dependence on a single node when Pods are placed on distinct, eligible nodes. | Protection from a zone-wide failure, or application recovery if replicas share a dependency or cannot serve traffic. |
| Pods spread across zones | Reduces correlated exposure to a single zone failure when the infrastructure has correctly labeled zones and sufficient capacity. | Control-plane or API endpoint availability, nor guaranteed application availability after a zone loss. |
| Control-plane components replicated across zones | Can reduce dependence on one zone for control-plane components. Kubernetes recommends at least three failure zones, with each control-plane component replicated across them, when availability is important. | A healthy, cross-zone API server endpoint. Kubernetes explicitly states, “Kubernetes does not provide cross-zone resilience for the API server endpoints.” |
| Application replicas plus recovery planning | Can support continued service or recovery when Pods or infrastructure fail, depending on readiness, storage and data behavior, and application design. | Any guarantee based solely on replica count or Pod placement. |
For API endpoint availability, Kubernetes’ multi-zone guidance discusses options such as DNS round-robin, SRV records, or a third-party health-checking load balancer. These are separate from replicating control-plane components, and the guidance is not a claim that every managed Kubernetes service uses the same architecture (Running in multiple zones).
What happens during maintenance and unexpected failure?
Kubernetes distinguishes voluntary disruptions, such as an administrator draining a node, from involuntary disruptions, such as a VM disappearing because of an infrastructure failure. A PodDisruptionBudget (PDB) can limit voluntary evictions to help preserve a workload’s available replicas during operations. It cannot prevent an involuntary infrastructure failure or make an application recover by itself.
Recommended Free Tools
PDBs also do not limit rolling upgrades performed through workload resources such as Deployments or StatefulSets. For node drains, Kubernetes recommends considering the AlwaysAllow unhealthy Pod eviction policy so misbehaving applications do not block eviction. The disruption guidance also recommends spreading replicated applications across racks or zones for higher availability (Disruptions).
Rank #3
What to check before calling a cluster resilient
- Map the actual failure boundaries. Confirm which nodes belong to each zone or other domain and that the topology labels are present and consistent.
- Review placement rules against capacity. Check the workload’s selectors, eligible domains,
maxSkew, and unsatisfiable behavior. Decide whether an unscheduled Pod is preferable to a placement that weakens the intended separation. - Inspect control-plane and API endpoint design separately. Verify how control-plane components are replicated and how clients reach a healthy API endpoint; a multi-zone workload does not answer either question.
- Test application recovery assumptions. Confirm replicas can actually serve traffic, examine readiness and storage behavior, and determine how data and dependent services behave during node or zone loss.
- Account for operational costs. Cross-zone placement can reduce correlated failure exposure, but topology decisions affect network latency and cost. Maintaining accurate labels and enough capacity in eligible domains adds operational work.
AWS Prescriptive Guidance recommends spreading EKS workloads across nodes and Availability Zones with topology spread constraints. That is guidance for EKS configuration, not a Kubernetes-wide guarantee (Spread workloads across nodes and Availability Zones). For broader production planning, Kubernetes also provides a production environment guide and documentation on cluster architecture.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
