{"id":2175,"date":"2026-02-16T01:05:52","date_gmt":"2026-02-16T01:05:52","guid":{"rendered":"https:\/\/finopsschool.com\/blog\/topology-spread-constraints\/"},"modified":"2026-02-16T01:05:52","modified_gmt":"2026-02-16T01:05:52","slug":"topology-spread-constraints","status":"publish","type":"post","link":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/","title":{"rendered":"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"},"content":{"rendered":"\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Quick Definition (30\u201360 words)<\/h2>\n\n\n\n<p>Topology spread constraints are Kubernetes scheduling rules that ensure Pods are distributed across failure domains like nodes, zones, or regions to reduce correlated failures. Analogy: like seating guests at different tables so a single extinguisher won&#8217;t clear a whole party. Formal: a Kubernetes PodSpec field guiding the scheduler to maximize even Pod placement across a specified topologyKey.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">What is Topology spread constraints?<\/h2>\n\n\n\n<p>Topology spread constraints are scheduling policies in Kubernetes that guide how replicas of workloads are distributed across defined topology domains (node, zone, region, custom labels). They are not a replacement for higher-level resilience like global active-active architecture or multi-cluster control planes.<\/p>\n\n\n\n<p>What it is NOT:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Not a traffic load balancing mechanism.<\/li>\n<li>Not an automatic failover or state replication system.<\/li>\n<li>Not a guarantee against all correlated failures; it reduces probability.<\/li>\n<\/ul>\n\n\n\n<p>Key properties and constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Controlled via PodSpec fields: topologySpreadConstraints.<\/li>\n<li>Supports maxSkew, topologyKey, whenUnsatisfiable, and labelSelectors.<\/li>\n<li>Two whenUnsatisfiable modes: DoNotSchedule and ScheduleAnyway (best-effort).<\/li>\n<li>Works at scheduler time; reconciliation and evictions are separate concerns.<\/li>\n<li>Depends on node labeling and cluster topology awareness.<\/li>\n<li>Interacts with PodDisruptionBudgets, affinity\/anti-affinity, and taints\/tolerations.<\/li>\n<\/ul>\n\n\n\n<p>Where it fits in modern cloud\/SRE workflows:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Reliability engineering: reduce blast radius by distributing replicas.<\/li>\n<li>Capacity planning: informs placement choices alongside resource requests.<\/li>\n<li>CI\/CD: included in Pod specs during deployment pipelines.<\/li>\n<li>Observability: telemetry to show distribution, imbalance, and scheduling failures.<\/li>\n<li>Security: used to ensure workloads span availability boundaries for compliance.<\/li>\n<\/ul>\n\n\n\n<p>Diagram description (text-only):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Imagine a grid of clusters, each cluster has zones, zones have nodes.<\/li>\n<li>A Deployment with 12 replicas has a rule: maxSkew 1 across topologyKey zone.<\/li>\n<li>Scheduler maps Pods so no zone differs by more than 1 Pod.<\/li>\n<li>If a zone loses a node, pods in other zones remain within skew by rescheduling.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Topology spread constraints in one sentence<\/h3>\n\n\n\n<p>A Kubernetes scheduling construct that enforces spread of Pods across named topology domains to reduce correlated failures and improve availability.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Topology spread constraints vs related terms (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Term<\/th>\n<th>How it differs from Topology spread constraints<\/th>\n<th>Common confusion<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>T1<\/td>\n<td>Pod anti-affinity<\/td>\n<td>Anti-affinity restricts specific Pods from colocating on the same topology node or host<\/td>\n<td>People think both do same thing<\/td>\n<\/tr>\n<tr>\n<td>T2<\/td>\n<td>Node affinity<\/td>\n<td>Node affinity targets nodes by labels for placement, not spread balancing<\/td>\n<td>Often conflated with spread<\/td>\n<\/tr>\n<tr>\n<td>T3<\/td>\n<td>PodDisruptionBudget<\/td>\n<td>PDB limits voluntary disruptions, not placement distribution<\/td>\n<td>PDBs don&#8217;t schedule Pods<\/td>\n<\/tr>\n<tr>\n<td>T4<\/td>\n<td>DaemonSet<\/td>\n<td>DaemonSet schedules one Pod per node, not balancing replicas<\/td>\n<td>Developers confuse guaranteed per-node placement<\/td>\n<\/tr>\n<tr>\n<td>T5<\/td>\n<td>StatefulSet<\/td>\n<td>Controls stable identities; spread is scheduling concern<\/td>\n<td>StatefulSet has its own ordering semantics<\/td>\n<\/tr>\n<tr>\n<td>T6<\/td>\n<td>PriorityClass<\/td>\n<td>Priority affects preemption, not distribution across topologies<\/td>\n<td>High priority can still be uneven<\/td>\n<\/tr>\n<tr>\n<td>T7<\/td>\n<td>Taints\/Tolerations<\/td>\n<td>Taints block placement unless tolerated; spread needs label topology keys<\/td>\n<td>Taints are not distribution<\/td>\n<\/tr>\n<tr>\n<td>T8<\/td>\n<td>Scheduler Extender<\/td>\n<td>Extenders modify scheduling decisions beyond built-in spread<\/td>\n<td>People assume extenders are needed for spread<\/td>\n<\/tr>\n<tr>\n<td>T9<\/td>\n<td>ReplicaSet<\/td>\n<td>ReplicaSet ensures desired replica count not topology distribution<\/td>\n<td>ReplicaSet does not enforce skew<\/td>\n<\/tr>\n<tr>\n<td>T10<\/td>\n<td>Multi-cluster controllers<\/td>\n<td>Multi-cluster controls cross-cluster placement, while spread is intra-cluster<\/td>\n<td>Confused with global distribution<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if any cell says \u201cSee details below\u201d)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Why does Topology spread constraints matter?<\/h2>\n\n\n\n<p>Business impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Revenue: Proper distribution reduces outages from single-zone failures, avoiding revenue loss during incidents.<\/li>\n<li>Trust: Higher availability builds customer confidence.<\/li>\n<li>Risk: Limits single-point failures that cause regulatory or contractual violations.<\/li>\n<\/ul>\n\n\n\n<p>Engineering impact:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Incident reduction: Less correlated failures, fewer cascading incidents.<\/li>\n<li>Velocity: Teams can deploy safer defaults and focus on features instead of manual placement tuning.<\/li>\n<li>Complexity trade-off: Misconfiguration can impede scheduler efficiency and cause pod evictions.<\/li>\n<\/ul>\n\n\n\n<p>SRE framing:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>SLIs\/SLOs: A spread-related SLI could be &#8220;fraction of replicas within allowed skew per workload&#8221;.<\/li>\n<li>Error budgets: Violations tied to distribution can consume error budget and trigger remediation.<\/li>\n<li>Toil: Automating topology-aware deployments reduces manual interventions.<\/li>\n<li>On-call: Alerts surface topology imbalance and scheduling failures as high-severity issues.<\/li>\n<\/ul>\n\n\n\n<p>What breaks in production (realistic examples):<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Zone outage concentrates all replicas in remaining zones causing over-capacity and degraded latency.<\/li>\n<li>Autoscaler launches many Pods in one node due to cloud provider API lag, violating spread and causing hot nodes.<\/li>\n<li>Stateful workload scheduled unevenly leading to quorums lost in distributed databases.<\/li>\n<li>Misconfigured labels\/topologyKey lead to all replicas placed on control-plane nodes, increasing blast radius.<\/li>\n<li>Interaction with PDBs prevents rescheduling during voluntary maintenance, causing capacity shortfall.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Where is Topology spread constraints used? (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Layer\/Area<\/th>\n<th>How Topology spread constraints appears<\/th>\n<th>Typical telemetry<\/th>\n<th>Common tools<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>L1<\/td>\n<td>Edge<\/td>\n<td>Spread across edge nodes or POPs to avoid single POP failure<\/td>\n<td>Pod distribution by POP and latency variance<\/td>\n<td>Kubernetes scheduler Prometheus<\/td>\n<\/tr>\n<tr>\n<td>L2<\/td>\n<td>Network<\/td>\n<td>Avoid colocating critical network proxies on same switch<\/td>\n<td>Pod-to-switch mapping and packet loss<\/td>\n<td>CNI metrics and node exporter<\/td>\n<\/tr>\n<tr>\n<td>L3<\/td>\n<td>Service<\/td>\n<td>Spread replicas of a microservice across AZs<\/td>\n<td>Replica skew and request error rates<\/td>\n<td>Service metrics and traces<\/td>\n<\/tr>\n<tr>\n<td>L4<\/td>\n<td>App<\/td>\n<td>App-level replicas distributed across nodes for resilience<\/td>\n<td>Instance health and restart counts<\/td>\n<td>App logs and Prometheus<\/td>\n<\/tr>\n<tr>\n<td>L5<\/td>\n<td>Data<\/td>\n<td>Distribute stateless cache frontends across zones<\/td>\n<td>Cache hit ratio and evictions<\/td>\n<td>Observability tools and Redis metrics<\/td>\n<\/tr>\n<tr>\n<td>L6<\/td>\n<td>IaaS<\/td>\n<td>Uses provider availability zones or host aggregates as topologyKey<\/td>\n<td>Cloud zone health and node labels<\/td>\n<td>Cloud provider telemetry<\/td>\n<\/tr>\n<tr>\n<td>L7<\/td>\n<td>PaaS\/Kubernetes<\/td>\n<td>Native Kubernetes PodSpec topologySpreadConstraints<\/td>\n<td>Scheduler events and pod scheduling failures<\/td>\n<td>kubectl, kube-state-metrics, Prometheus<\/td>\n<\/tr>\n<tr>\n<td>L8<\/td>\n<td>Serverless<\/td>\n<td>Managed runtime may expose placement controls or none<\/td>\n<td>Invocation latency skew and cold starts<\/td>\n<td>Provider metrics (varies)<\/td>\n<\/tr>\n<tr>\n<td>L9<\/td>\n<td>CI\/CD<\/td>\n<td>Deployment manifests include topology rules in pipelines<\/td>\n<td>Deployment validation and lint results<\/td>\n<td>GitOps pipelines and test suites<\/td>\n<\/tr>\n<tr>\n<td>L10<\/td>\n<td>Incident Response<\/td>\n<td>Used as mitigation to reduce impact scope during incidents<\/td>\n<td>Distribution imbalance alerts and PDBs<\/td>\n<td>On-call tools and runbooks<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">When should you use Topology spread constraints?<\/h2>\n\n\n\n<p>When necessary:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Critical services with multiple replicas that must survive zone\/node loss.<\/li>\n<li>Stateful systems requiring quorum distribution.<\/li>\n<li>Compliance or contractual needs to distribute across failure domains.<\/li>\n<\/ul>\n\n\n\n<p>When optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Burst workloads that are cheap to recreate and have short lifetimes.<\/li>\n<li>Development or test namespaces where availability is not critical.<\/li>\n<\/ul>\n\n\n\n<p>When NOT to use \/ overuse it:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Small clusters where topology domains are too limited; constraints will block scheduling.<\/li>\n<li>Highly dynamic, ephemeral jobs that add overhead to scheduler decisions.<\/li>\n<li>When underlying cloud provider topology is unreliable or unlabeled.<\/li>\n<\/ul>\n\n\n\n<p>Decision checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you need high availability across zones and you have &gt;1 zone -&gt; use topologySpreadConstraints.<\/li>\n<li>If pods are stateful requiring unique identities -&gt; consider StatefulSet + spread rules.<\/li>\n<li>If cluster has limited nodes per topology domain -&gt; prefer ScheduleAnyway and add capacity planning.<\/li>\n<li>If Pod disruption budgets block rescheduling during maintenance -&gt; coordinate PDBs and spread.<\/li>\n<\/ul>\n\n\n\n<p>Maturity ladder:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Beginner: Use simple evenPodSpread with topologyKey=zone and whenUnsatisfiable=ScheduleAnyway.<\/li>\n<li>Intermediate: Combine spread with anti-affinity and PDBs; add scheduler metrics.<\/li>\n<li>Advanced: Automated placement controllers, cross-cluster distribution, chaos testing and automated remediation.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How does Topology spread constraints work?<\/h2>\n\n\n\n<p>Components and workflow:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>PodSpec contains topologySpreadConstraints list per workload.<\/li>\n<li>Scheduler evaluates available nodes using constraints in score and filter phases.<\/li>\n<li>maxSkew defines acceptable difference between most and least populated topology domains.<\/li>\n<li>topologyKey is a node label key e.g., topology.kubernetes.io\/zone or custom key.<\/li>\n<li>whenUnsatisfiable decides strictness: DoNotSchedule blocks scheduling if constraint violated; ScheduleAnyway allows best-effort.<\/li>\n<li>Label selector restricts set of Pods considered when computing skew.<\/li>\n<\/ul>\n\n\n\n<p>Data flow and lifecycle:<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Deployment creates ReplicaSet which creates Pods with spread constraints.<\/li>\n<li>Scheduler checks nodes, gathers counts of matching Pods per topology domain.<\/li>\n<li>Scheduler filters nodes that would violate DoNotSchedule; otherwise ranks nodes by evenness.<\/li>\n<li>Pod is bound to node; kubelet starts container.<\/li>\n<li>Rescheduler, eviction, or node failure triggers new scheduling decisions recalculating spread.<\/li>\n<\/ol>\n\n\n\n<p>Edge cases and failure modes:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Insufficient nodes in a topology domain cause DoNotSchedule rejections.<\/li>\n<li>Missing or inconsistent node labels break domain grouping leading to uneven distribution.<\/li>\n<li>Interaction with pod anti-affinity and taints can create unsatisfiable conflict.<\/li>\n<li>Scale-up latency from cluster autoscaler may produce temporary imbalance.<\/li>\n<li>Admission controllers or mutating webhooks that change labels can affect computed skew.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Typical architecture patterns for Topology spread constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Pattern: Zone-based even spread<\/li>\n<li>Use when: Multi-AZ clusters requiring resilience to AZ failure.<\/li>\n<li>Pattern: Node-group balancing<\/li>\n<li>Use when: Need to avoid localized hot-spots on instance groups.<\/li>\n<li>Pattern: Rack-aware spread<\/li>\n<li>Use when: On-prem or bare-metal clusters with rack labels.<\/li>\n<li>Pattern: Service-role spread<\/li>\n<li>Use when: Spread across nodes with distinct hardware or NICs.<\/li>\n<li>Pattern: Multi-cluster-aware spread controller<\/li>\n<li>Use when: Global distribution across clusters; often combined with higher orchestration.<\/li>\n<li>Pattern: Canary with spread override<\/li>\n<li>Use when: Canary rollout should target specific topologies first.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Failure modes &amp; mitigation (TABLE REQUIRED)<\/h3>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Failure mode<\/th>\n<th>Symptom<\/th>\n<th>Likely cause<\/th>\n<th>Mitigation<\/th>\n<th>Observability signal<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>F1<\/td>\n<td>Scheduling blocked<\/td>\n<td>Pods Pending indefinitely<\/td>\n<td>DoNotSchedule with insufficient nodes<\/td>\n<td>Use ScheduleAnyway or add capacity<\/td>\n<td>Pending pod age and events<\/td>\n<\/tr>\n<tr>\n<td>F2<\/td>\n<td>Uneven distribution<\/td>\n<td>One zone has many replicas<\/td>\n<td>Missing node labels or scheduler issue<\/td>\n<td>Fix labels or adjust selectors<\/td>\n<td>Replica skew metric by zone<\/td>\n<\/tr>\n<tr>\n<td>F3<\/td>\n<td>Thrash after node loss<\/td>\n<td>Frequent reschedules and restarts<\/td>\n<td>PDBs prevent evictions or capacity shortage<\/td>\n<td>Adjust PDBs and autoscaler<\/td>\n<td>Restart counts and eviction rate<\/td>\n<\/tr>\n<tr>\n<td>F4<\/td>\n<td>Quorum loss<\/td>\n<td>Distributed DB loses quorum<\/td>\n<td>Replica placement clustered on few nodes<\/td>\n<td>Enforce stronger spread and anti-affinity<\/td>\n<td>Error spikes and DB leader changes<\/td>\n<\/tr>\n<tr>\n<td>F5<\/td>\n<td>Performance hotspot<\/td>\n<td>High CPU on nodes hosting many pods<\/td>\n<td>Scheduler scored incorrectly or affinities override<\/td>\n<td>Tune scheduler weights and affinity<\/td>\n<td>Node CPU and request latency<\/td>\n<\/tr>\n<tr>\n<td>F6<\/td>\n<td>Interference with anti-affinity<\/td>\n<td>Unschedulable pods due to conflicting rules<\/td>\n<td>Conflicting pod affinity rules<\/td>\n<td>Reconcile rules or create exceptions<\/td>\n<td>Scheduler events and filtering reasons<\/td>\n<\/tr>\n<tr>\n<td>F7<\/td>\n<td>Over-constraining during scale<\/td>\n<td>New replicas force scheduler failures<\/td>\n<td>Too strict maxSkew or DoNotSchedule<\/td>\n<td>Relax skew or provide more capacity<\/td>\n<td>Deployment scaling failures<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Key Concepts, Keywords &amp; Terminology for Topology spread constraints<\/h2>\n\n\n\n<p>(40+ glossary entries)<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Topology spread constraints \u2014 Scheduler rules in PodSpec to spread Pods across topology domains \u2014 Ensures replica distribution \u2014 Pitfall: over-constraining can block scheduling.<\/li>\n<li>topologyKey \u2014 Node label key used as domain, e.g., zone \u2014 Determines grouping for spread \u2014 Pitfall: unlabeled nodes ignored.<\/li>\n<li>maxSkew \u2014 Maximum allowed difference between counts in domains \u2014 Controls evenness \u2014 Pitfall: low value prevents scaling.<\/li>\n<li>whenUnsatisfiable \u2014 Behavior when constraint cannot be met (DoNotSchedule or ScheduleAnyway) \u2014 Dictates strictness \u2014 Pitfall: DoNotSchedule can block pods.<\/li>\n<li>labelSelector \u2014 Selects which Pods are counted for skew \u2014 Targets specific sets \u2014 Pitfall: wrong selector miscomputes skew.<\/li>\n<li>Scheduler \u2014 Kubernetes component that binds Pods to nodes \u2014 Implements spread logic \u2014 Pitfall: custom extenders may override behavior.<\/li>\n<li>PodSpec \u2014 Pod definition in Kubernetes \u2014 Hosts topologySpreadConstraints \u2014 Pitfall: forgetting to add constraints in templates.<\/li>\n<li>Node labels \u2014 Key\/value metadata on nodes used as keys \u2014 Used as topology domains \u2014 Pitfall: inconsistent labeling across nodes.<\/li>\n<li>Zone \u2014 Cloud availability zone concept used as a topology layer \u2014 Common topologyKey \u2014 Pitfall: provider zones vary in naming.<\/li>\n<li>Region \u2014 Higher-level topology domain above zones \u2014 Useful for multi-region clusters \u2014 Pitfall: cross-region latency.<\/li>\n<li>Anti-affinity \u2014 Constraint to avoid colocating specific Pods \u2014 Related to spread but targets affinity between Pods \u2014 Pitfall: conflicts with spread constraints.<\/li>\n<li>Affinity \u2014 Rules to prefer or require co-location \u2014 Opposite of anti-affinity \u2014 Pitfall: affinity can override spread preferences.<\/li>\n<li>PDB (PodDisruptionBudget) \u2014 Limits voluntary disruptions \u2014 Ensures minimum available replicas \u2014 Pitfall: can block maintenances.<\/li>\n<li>ReplicaSet \u2014 Controller ensuring replica count \u2014 Works with spread but doesn&#8217;t enforce it \u2014 Pitfall: scale spikes may affect skew.<\/li>\n<li>StatefulSet \u2014 Controller for stateful apps with stable identities \u2014 Works with spread but ordering matters \u2014 Pitfall: startup order can delay distribution.<\/li>\n<li>DaemonSet \u2014 Ensures Pods on each node \u2014 Not used for spread but used for per-node services \u2014 Pitfall: conflicts with capacity.<\/li>\n<li>Taints \u2014 Node-level markers preventing placement unless tolerated \u2014 Affects where Pods can land \u2014 Pitfall: missing tolerations cause scheduling failures.<\/li>\n<li>Tolerations \u2014 Pod settings to tolerate taints \u2014 Needed when using taints \u2014 Pitfall: over-tolerating can increase blast radius.<\/li>\n<li>Scheduler Extender \u2014 External component to influence scheduling \u2014 Rarely needed for basic spread \u2014 Pitfall: complexity and maintenance.<\/li>\n<li>kube-scheduler-policy \u2014 Deprecated approach for scheduler behavior \u2014 Historical context \u2014 Pitfall: version mismatch.<\/li>\n<li>kube-state-metrics \u2014 Emits Kubernetes object metrics \u2014 Useful for counting Pod distribution \u2014 Pitfall: cardinality explosion if misused.<\/li>\n<li>Prometheus \u2014 Monitoring system to record distribution metrics \u2014 Enables alerts \u2014 Pitfall: incomplete instrumentation.<\/li>\n<li>Cluster Autoscaler \u2014 Scales node pools based on pending pods \u2014 Helps satisfy DoNotSchedule constraints \u2014 Pitfall: slow scale-up can leave pods pending.<\/li>\n<li>NodePool \u2014 Group of nodes with similar properties \u2014 Often corresponds to topology unit \u2014 Pitfall: single nodepool in multiple zones causes misleading labels.<\/li>\n<li>Quorum \u2014 Minimum nodes\/replicas required for consistency \u2014 Important for stateful systems \u2014 Pitfall: poor distribution risks quorum loss.<\/li>\n<li>Reachability \u2014 Network connectivity between nodes\/zones \u2014 Underpins effective spread \u2014 Pitfall: network partitions invalidate benefit.<\/li>\n<li>Scheduling Score \u2014 Numeric value the scheduler uses to prefer nodes \u2014 Spread contributes to scoring \u2014 Pitfall: scoring weights might not be tuned.<\/li>\n<li>Scheduler Predicates \u2014 Pre-filter checks to allow candidate nodes \u2014 Spread can be enforced here for DoNotSchedule \u2014 Pitfall: predicates conflict can block scheduling.<\/li>\n<li>Eviction \u2014 Forcing Pod removal from node \u2014 Interacts with spread during node failures \u2014 Pitfall: mass evictions cause reschedule storms.<\/li>\n<li>Rescheduler \u2014 Component or controller that may attempt to rebalance \u2014 Not always present by default \u2014 Pitfall: absence means imbalance persists.<\/li>\n<li>Best-effort scheduling \u2014 whenUnsatisfiable=ScheduleAnyway \u2014 Allows placement disregarding strictness \u2014 Pitfall: temporary imbalance.<\/li>\n<li>Admission controller \u2014 Validates or mutates Pod objects \u2014 Can inject topology defaults \u2014 Pitfall: misconfiguration mutates constraints unexpectedly.<\/li>\n<li>GitOps \u2014 Declarative deployment patterns \u2014 Distributes constraints via manifests \u2014 Pitfall: drift between clusters.<\/li>\n<li>Canary \u2014 Gradual rollout pattern \u2014 Spread ensures canary isn&#8217;t isolated \u2014 Pitfall: canary may not represent full topology.<\/li>\n<li>Chaos engineering \u2014 Failure injection to validate spread resilience \u2014 Tests constraint effectiveness \u2014 Pitfall: risk if not scoped.<\/li>\n<li>Observability signal \u2014 Telemetry that indicates spread health \u2014 Crucial for alerts \u2014 Pitfall: missing signals hide issues.<\/li>\n<li>SLI \u2014 Service Level Indicator relevant to spread such as replica skew fraction \u2014 Measurement basis \u2014 Pitfall: wrong SLI leads to meaningless alerts.<\/li>\n<li>SLO \u2014 Service Level Objective based on SLI \u2014 Drives error budget for spread violations \u2014 Pitfall: unrealistic SLO.<\/li>\n<li>Error budget \u2014 Allowance for SLO violation \u2014 Used to guide remediation \u2014 Pitfall: exhaustion causes operational limits.<\/li>\n<li>Load balancing \u2014 Distributes traffic across replicas \u2014 Complementary to spread \u2014 Pitfall: spread does not change LB behavior.<\/li>\n<li>Multi-cluster \u2014 Managing workloads across clusters \u2014 Spread is intra-cluster; multi-cluster expands scope \u2014 Pitfall: relying solely on spread for global resilience.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">How to Measure Topology spread constraints (Metrics, SLIs, SLOs) (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Metric\/SLI<\/th>\n<th>What it tells you<\/th>\n<th>How to measure<\/th>\n<th>Starting target<\/th>\n<th>Gotchas<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>M1<\/td>\n<td>Replica skew per topology domain<\/td>\n<td>Degree of imbalance across domains<\/td>\n<td>Count matching pods grouped by topology label<\/td>\n<td>&lt;=1 difference for critical services<\/td>\n<td>Label mismatches hide pods<\/td>\n<\/tr>\n<tr>\n<td>M2<\/td>\n<td>Pending pods due to DoNotSchedule<\/td>\n<td>Pods blocked by strict rules<\/td>\n<td>Count pending pods with scheduling reason Unschedulable<\/td>\n<td>0 sustained pending<\/td>\n<td>Transient spikes possible<\/td>\n<\/tr>\n<tr>\n<td>M3<\/td>\n<td>Scheduling failure rate<\/td>\n<td>Frequency of scheduling errors<\/td>\n<td>Count failed schedule events per minute<\/td>\n<td>&lt;1% of scheduling ops<\/td>\n<td>Events sampling can miss issues<\/td>\n<\/tr>\n<tr>\n<td>M4<\/td>\n<td>Reschedule frequency per pod<\/td>\n<td>Pod churn due to evictions<\/td>\n<td>Count restarts and reschedules per pod per hour<\/td>\n<td>&lt;1 per day for stable services<\/td>\n<td>Autoscaler churn inflates metric<\/td>\n<\/tr>\n<tr>\n<td>M5<\/td>\n<td>PDB violation incidents<\/td>\n<td>Number of times PDB blocked eviction<\/td>\n<td>PDB violations and voluntary disruption failures<\/td>\n<td>0 for critical services<\/td>\n<td>Necessary maintenance may trigger<\/td>\n<\/tr>\n<tr>\n<td>M6<\/td>\n<td>Node distribution variance<\/td>\n<td>Statistical variance of pods per domain<\/td>\n<td>Compute variance across domain counts<\/td>\n<td>Low variance per service<\/td>\n<td>Small sample sizes distort variance<\/td>\n<\/tr>\n<tr>\n<td>M7<\/td>\n<td>Time to restore skew<\/td>\n<td>Time to return to allowed skew after failure<\/td>\n<td>Time from imbalance detected to restored<\/td>\n<td>&lt; 10 minutes for autoscaling setups<\/td>\n<td>Slow autoscale or manual steps increase time<\/td>\n<\/tr>\n<tr>\n<td>M8<\/td>\n<td>Error rate correlated to skew<\/td>\n<td>Application errors related to imbalance<\/td>\n<td>Error rate during high skew windows<\/td>\n<td>SLO-based, e.g., &lt;1% increase<\/td>\n<td>Correlation requires traceability<\/td>\n<\/tr>\n<tr>\n<td>M9<\/td>\n<td>Capacity shortfall events<\/td>\n<td>When schedulable capacity insufficient<\/td>\n<td>Count events where scale-up requested<\/td>\n<td>0 frequent events<\/td>\n<td>Spot instance interruptions can cause bursts<\/td>\n<\/tr>\n<tr>\n<td>M10<\/td>\n<td>Scheduler latency impacted by constraints<\/td>\n<td>Effect of constraints on scheduling time<\/td>\n<td>Measure scheduler decision latency per pod<\/td>\n<td>Minimal impact target &lt;200ms<\/td>\n<td>High cluster size increases latency<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Best tools to measure Topology spread constraints<\/h3>\n\n\n\n<h3 class=\"wp-block-heading\">H4: Tool \u2014 Prometheus<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Topology spread constraints:<\/li>\n<li>Pod counts per topology domain and scheduling events.<\/li>\n<li>Best-fit environment:<\/li>\n<li>Kubernetes clusters with kube-state-metrics.<\/li>\n<li>Setup outline:<\/li>\n<li>Install kube-state-metrics.<\/li>\n<li>Scrape metrics from kube-state-metrics and kube-scheduler.<\/li>\n<li>Create recording rules for replica skew.<\/li>\n<li>Build dashboards and alerts.<\/li>\n<li>Strengths:<\/li>\n<li>Query language for flexible metrics and alerts.<\/li>\n<li>Widely adopted in cloud-native stacks.<\/li>\n<li>Limitations:<\/li>\n<li>High cardinality can increase storage cost.<\/li>\n<li>Needs proper instrumentation for scheduler internals.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">H4: Tool \u2014 kube-state-metrics<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Topology spread constraints:<\/li>\n<li>Kubernetes object state including Pod labels and counts.<\/li>\n<li>Best-fit environment:<\/li>\n<li>Any Kubernetes cluster feeding Prometheus.<\/li>\n<li>Setup outline:<\/li>\n<li>Deploy in cluster.<\/li>\n<li>Ensure RBAC allows reading pods and nodes.<\/li>\n<li>Map metrics to topology label aggregations.<\/li>\n<li>Strengths:<\/li>\n<li>Exposes native object metrics.<\/li>\n<li>Low-level visibility.<\/li>\n<li>Limitations:<\/li>\n<li>Not a complete telemetry solution on its own.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">H4: Tool \u2014 kube-scheduler metrics \/ logs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Topology spread constraints:<\/li>\n<li>Scheduler decisions, filtering reasons, and latencies.<\/li>\n<li>Best-fit environment:<\/li>\n<li>Clusters where you can access control plane metrics.<\/li>\n<li>Setup outline:<\/li>\n<li>Enable scheduler metrics.<\/li>\n<li>Collect logs and metric endpoints securely.<\/li>\n<li>Create alerts for high filter rates.<\/li>\n<li>Strengths:<\/li>\n<li>Direct insight into scheduling decisions.<\/li>\n<li>Limitations:<\/li>\n<li>Access restricted in managed clusters.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">H4: Tool \u2014 Grafana<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Topology spread constraints:<\/li>\n<li>Visualization and dashboards for spread metrics.<\/li>\n<li>Best-fit environment:<\/li>\n<li>Any environment with Prometheus.<\/li>\n<li>Setup outline:<\/li>\n<li>Create dashboards with panels for skew, pending pods, scheduler latency.<\/li>\n<li>Provide templates for services and topology keys.<\/li>\n<li>Strengths:<\/li>\n<li>Flexible dashboards and annotations.<\/li>\n<li>Limitations:<\/li>\n<li>Needs backing data source; not a collector.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">H4: Tool \u2014 Cluster Autoscaler<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Topology spread constraints:<\/li>\n<li>Scale-up requests triggered by pending pods and unschedulable conditions.<\/li>\n<li>Best-fit environment:<\/li>\n<li>Cloud-managed or self-hosted autoscaler-enabled clusters.<\/li>\n<li>Setup outline:<\/li>\n<li>Configure node pools and scale settings.<\/li>\n<li>Monitor pending pods and scale events.<\/li>\n<li>Strengths:<\/li>\n<li>Automated capacity reactions to satisfy DoNotSchedule.<\/li>\n<li>Limitations:<\/li>\n<li>Scale-up latency; cost implications.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">H4: Tool \u2014 Observability\/tracing (Jaeger\/Tempo)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>What it measures for Topology spread constraints:<\/li>\n<li>Correlate user-facing errors to deployment topology imbalances.<\/li>\n<li>Best-fit environment:<\/li>\n<li>Microservice architectures with tracing.<\/li>\n<li>Setup outline:<\/li>\n<li>Instrument services with tracing.<\/li>\n<li>Tag traces with node\/zone metadata.<\/li>\n<li>Analyze error spikes relative to skew events.<\/li>\n<li>Strengths:<\/li>\n<li>Deep root cause correlation across systems.<\/li>\n<li>Limitations:<\/li>\n<li>Instrumentation overhead and sampling limits.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Recommended dashboards &amp; alerts for Topology spread constraints<\/h3>\n\n\n\n<p>Executive dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Overall percent of workloads within allowed skew \u2014 executive-friendly availability metric.<\/li>\n<li>Number of critical services impacted by imbalance \u2014 business impact view.<\/li>\n<li>Recent severe scheduling incidents and time to restore.<\/li>\n<li>Why:<\/li>\n<li>High-level health and business exposure.<\/li>\n<\/ul>\n\n\n\n<p>On-call dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Replica skew per topologyKey for the service in question.<\/li>\n<li>Pending pods with scheduling reasons and age.<\/li>\n<li>Node CPU\/memory across topology domains.<\/li>\n<li>Scheduler filter\/failure logs for recent events.<\/li>\n<li>Why:<\/li>\n<li>Rapid triage and root-cause identification.<\/li>\n<\/ul>\n\n\n\n<p>Debug dashboard:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Panels:<\/li>\n<li>Pod distribution heatmap by node and label.<\/li>\n<li>Scheduler decision trace for sample pods.<\/li>\n<li>PDB status and eviction history.<\/li>\n<li>Autoscaler scale events and pending pod queue.<\/li>\n<li>Why:<\/li>\n<li>Deep troubleshooting during incidents.<\/li>\n<\/ul>\n\n\n\n<p>Alerting guidance:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Page vs ticket:<\/li>\n<li>Page: sustained pending pods due to DoNotSchedule for production critical services; time to restore exceeds threshold; quorum loss events.<\/li>\n<li>Ticket: transient imbalance below severity thresholds, minor skew that auto-corrects within short windows.<\/li>\n<li>Burn-rate guidance:<\/li>\n<li>Tie spread-related SLOs to error budget; increased burn-rate due to distribution violations should trigger escalations and remediation playbooks.<\/li>\n<li>Noise reduction tactics:<\/li>\n<li>Dedupe by topologyKey and service.<\/li>\n<li>Group alerts for a service rather than individual pods.<\/li>\n<li>Suppress alerts during planned maintenance windows and autoscaler correction windows.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Implementation Guide (Step-by-step)<\/h2>\n\n\n\n<p>1) Prerequisites\n&#8211; Kubernetes cluster with multiple topology domains labeled.\n&#8211; RBAC to allow kube-state-metrics and observability tools.\n&#8211; CI\/CD pipeline that deploys manifests.\n&#8211; Monitoring and alerting system (Prometheus + Grafana or equivalent).<\/p>\n\n\n\n<p>2) Instrumentation plan\n&#8211; Add topologySpreadConstraints to Pod templates in manifests.\n&#8211; Ensure node labels exist and are consistent.\n&#8211; Emit custom metrics for replica skew and pending pods.<\/p>\n\n\n\n<p>3) Data collection\n&#8211; Deploy kube-state-metrics and scrape with Prometheus.\n&#8211; Collect kube-scheduler metrics and events.\n&#8211; Gather node exporter or cloud provider telemetry for topology health.<\/p>\n\n\n\n<p>4) SLO design\n&#8211; Define SLI: fraction of critical services within allowed skew.\n&#8211; Set SLO: e.g., 99.9% of time replicas within allowed skew over 30 days (example starting point).\n&#8211; Define alert thresholds for sustained imbalance.<\/p>\n\n\n\n<p>5) Dashboards\n&#8211; Build executive, on-call, and debug dashboards described above.\n&#8211; Add templating to select service, namespace, and topologyKey.<\/p>\n\n\n\n<p>6) Alerts &amp; routing\n&#8211; Create alerts for pending pods, skew breaches, and scheduling failures.\n&#8211; Route critical pages to SRE on-call; minor tickets to application owners.<\/p>\n\n\n\n<p>7) Runbooks &amp; automation\n&#8211; Create runbooks for common faults: pending pods, imbalance, label drift.\n&#8211; Automate remediation: trigger autoscaler, add node labels, or recreate failing nodes.<\/p>\n\n\n\n<p>8) Validation (load\/chaos\/game days)\n&#8211; Run chaos experiments to simulate zone\/node failures.\n&#8211; Test autoscaler response and restoration time.\n&#8211; Verify PDB interactions and failover behavior.<\/p>\n\n\n\n<p>9) Continuous improvement\n&#8211; Weekly reviews of skew incidents and root causes.\n&#8211; Iterate constraints per workload maturity.\n&#8211; Automate recommended changes via GitOps.<\/p>\n\n\n\n<p>Pre-production checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Node labels present and consistent across nodes.<\/li>\n<li>Metrics and dashboards show expected baseline.<\/li>\n<li>CI\/CD pipelines include topologySpreadConstraints linting.<\/li>\n<li>PDBs and other constraints reviewed for conflicts.<\/li>\n<li>Autoscaler behavior validated for pending pods.<\/li>\n<\/ul>\n\n\n\n<p>Production readiness checklist:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Alerts configured and tested to page on real conditions.<\/li>\n<li>Runbooks available and practiced.<\/li>\n<li>Capacity buffer exists for expected failovers.<\/li>\n<li>Chaos tests passed at least once in staging.<\/li>\n<\/ul>\n\n\n\n<p>Incident checklist specific to Topology spread constraints:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Check pending pods and scheduling reasons.<\/li>\n<li>Inspect node labels and topologyKeys.<\/li>\n<li>Verify PDBs are not blocking evictions.<\/li>\n<li>Check cluster autoscaler logs and scale events.<\/li>\n<li>If necessary, relax whenUnsatisfiable or adjust maxSkew temporarily.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Use Cases of Topology spread constraints<\/h2>\n\n\n\n<p>Provide 8\u201312 use cases:<\/p>\n\n\n\n<p>1) Highly available frontend service\n&#8211; Context: Public API served from multi-AZ cluster.\n&#8211; Problem: Zone failure should not take down all replicas.\n&#8211; Why it helps: Ensures replicas distributed across AZs.\n&#8211; What to measure: Replica skew by zone, error rate.\n&#8211; Typical tools: Prometheus, kube-state-metrics, Grafana.<\/p>\n\n\n\n<p>2) Distributed database coordinator placement\n&#8211; Context: Small controller nodes managing DB shards.\n&#8211; Problem: Concentrated placement triggers quorum loss.\n&#8211; Why it helps: Keeps coordinators in different topologies to maintain quorum.\n&#8211; What to measure: Leader changes, skew, latency.\n&#8211; Typical tools: Database metrics, scheduler logs.<\/p>\n\n\n\n<p>3) Edge POP service distribution\n&#8211; Context: Edge compute across POPs or racks.\n&#8211; Problem: Single POP outage degrades regional service.\n&#8211; Why it helps: Ensures at least one replica in each POP.\n&#8211; What to measure: POP-level availability and latency.\n&#8211; Typical tools: Edge monitoring, node labels.<\/p>\n\n\n\n<p>4) Stateful cache frontends\n&#8211; Context: Cache layer in front of DB.\n&#8211; Problem: Co-located instances on one node cause CPU contention.\n&#8211; Why it helps: Spreads cache replicas to reduce hotspots.\n&#8211; What to measure: Node CPU, cache hit ratio.\n&#8211; Typical tools: Prometheus, node exporter.<\/p>\n\n\n\n<p>5) Canary rollouts sensitive to topology\n&#8211; Context: Feature rollout in stages.\n&#8211; Problem: Canary all in one zone may not reveal cross-zone issues.\n&#8211; Why it helps: Place canary across topologies for better validation.\n&#8211; What to measure: Error flux across zones.\n&#8211; Typical tools: CI\/CD pipeline, metrics.<\/p>\n\n\n\n<p>6) Multi-tenant isolation\n&#8211; Context: Tenants with SLA requirements.\n&#8211; Problem: Tenant pods collocated causing noisy neighbor issues.\n&#8211; Why it helps: Use topology keys to direct tenant replicas across host groups.\n&#8211; What to measure: Tenant latency and node contention.\n&#8211; Typical tools: Kubernetes labels and scheduler constraints.<\/p>\n\n\n\n<p>7) Compliance-driven distribution\n&#8211; Context: Data residency and redundancy requirements.\n&#8211; Problem: Regulatory needs replicas across regions or racks.\n&#8211; Why it helps: Enforces placement across specific topology labels.\n&#8211; What to measure: Placement compliance and audit logs.\n&#8211; Typical tools: Policy-as-code and admission controls.<\/p>\n\n\n\n<p>8) Autoscaling resilience\n&#8211; Context: Rapid traffic increases causing autoscaling.\n&#8211; Problem: New replicas placed unevenly, burdening nodes.\n&#8211; Why it helps: Distributes newly created pods across nodes to avoid hotspots.\n&#8211; What to measure: New pod distribution and node utilization.\n&#8211; Typical tools: Cluster Autoscaler and scheduler metrics.<\/p>\n\n\n\n<p>9) Security isolation for critical workloads\n&#8211; Context: Critical microservices must avoid colocating with others.\n&#8211; Problem: Co-location increases attack surface.\n&#8211; Why it helps: Spread constraints combined with taints isolate critical services.\n&#8211; What to measure: Security incidents and placement adherence.\n&#8211; Typical tools: Admission controllers and policy engines.<\/p>\n\n\n\n<p>10) Legacy workload modernization\n&#8211; Context: Migrating monolith into microservices across zones.\n&#8211; Problem: Initial deployments concentrated in one topology.\n&#8211; Why it helps: Gradually enforce spread for safe migration.\n&#8211; What to measure: Service availability and skew during cutover.\n&#8211; Typical tools: GitOps and observability.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Scenario Examples (Realistic, End-to-End)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #1 \u2014 Kubernetes multi-AZ web service<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A customer-facing web service in a 3-AZ cluster.<br\/>\n<strong>Goal:<\/strong> Ensure at least one replica per AZ and limit skew to 1.<br\/>\n<strong>Why Topology spread constraints matters here:<\/strong> Prevents all replicas landing in single AZ during AZ failure.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Deployment with replicas: 9, topologySpreadConstraints with topologyKey=topology.kubernetes.io\/zone, maxSkew=1, whenUnsatisfiable=DoNotSchedule. PDB ensures minimal availability during maintenance.<br\/>\n<strong>Step-by-step implementation:<\/strong> <\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Label nodes with zone labels correctly.<\/li>\n<li>Add topologySpreadConstraints to Deployment Pod template.<\/li>\n<li>Configure PDB to allow safe maintenance.<\/li>\n<li>Monitor replica counts per zone and pending pods.<\/li>\n<li>Test with simulated AZ failure via chaos test.\n<strong>What to measure:<\/strong> Replica skew per zone, pending pods due to DoNotSchedule, time to restore.<br\/>\n<strong>Tools to use and why:<\/strong> Prometheus, kube-state-metrics, Grafana, chaos tool for failover.<br\/>\n<strong>Common pitfalls:<\/strong> DoNotSchedule blocks pods if capacity limited; autoscaler latency causes pending pods.<br\/>\n<strong>Validation:<\/strong> Run zone failure simulation and confirm no service downtime and skew restored within target time.<br\/>\n<strong>Outcome:<\/strong> Service remains available across AZs and recovers automatically.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #2 \u2014 Serverless managed PaaS with placement controls<\/h3>\n\n\n\n<p><strong>Context:<\/strong> Managed PaaS offering allows specifying placement affinity via annotations.<br\/>\n<strong>Goal:<\/strong> Reduce correlated failures by allocating function instances across edge clusters or zones.<br\/>\n<strong>Why Topology spread constraints matters here:<\/strong> Even in managed environments, placement across domains reduces single-domain outages.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Platform maps annotations into underlying Kubernetes topologySpreadConstraints or provider placement policies. The provider exposes a config to request spread across regions.<br\/>\n<strong>Step-by-step implementation:<\/strong> <\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Request placement profile in application manifest.<\/li>\n<li>Platform validates and translates to topology keys.<\/li>\n<li>Operator reviews mapping to provider topologies.<\/li>\n<li>Deploy and measure instance distribution.\n<strong>What to measure:<\/strong> Instance skew across domains, invocation latency variance.<br\/>\n<strong>Tools to use and why:<\/strong> Provider metrics, platform logs, Prometheus if available.<br\/>\n<strong>Common pitfalls:<\/strong> Provider limitations may ignore hints; lack of direct control.<br\/>\n<strong>Validation:<\/strong> Trigger region outage test and observe failover.<br\/>\n<strong>Outcome:<\/strong> Functions continue to operate with reduced correlated failure risk.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #3 \u2014 Incident response and postmortem for quorum loss<\/h3>\n\n\n\n<p><strong>Context:<\/strong> A distributed DB loses quorum unexpectedly.<br\/>\n<strong>Goal:<\/strong> Identify placement causes and fix distribution to prevent recurrence.<br\/>\n<strong>Why Topology spread constraints matters here:<\/strong> Misplacement caused too many replicas on same node group leading to correlated failure.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Examine deployment topologySpreadConstraints, PDB, and node labels. Use tracing to correlate DB leader changes with node events.<br\/>\n<strong>Step-by-step implementation:<\/strong> <\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Run queries for pod placement at incident time.<\/li>\n<li>Check scheduler events and pending pods.<\/li>\n<li>Verify node failures or preemptions occurred.<\/li>\n<li>Update topologySpreadConstraints and PDBs as corrective action.<\/li>\n<li>Run postmortem and test changes in staging with chaos tests.\n<strong>What to measure:<\/strong> Time to quorum loss, number of replicas per topology at failure.<br\/>\n<strong>Tools to use and why:<\/strong> Scheduler logs, Prometheus, tracing, DB logs.<br\/>\n<strong>Common pitfalls:<\/strong> Missing historical metrics to correlate sequence of events.<br\/>\n<strong>Validation:<\/strong> Confirm new placement prevents quorum loss under same failure scenario.<br\/>\n<strong>Outcome:<\/strong> Root cause attributed to uneven placement; constraints updated and verified.<\/li>\n<\/ol>\n\n\n\n<h3 class=\"wp-block-heading\">Scenario #4 \u2014 Cost vs performance trade-off for spread constraints<\/h3>\n\n\n\n<p><strong>Context:<\/strong> High-cost multi-AZ deployment with expensive cross-AZ networking.<br\/>\n<strong>Goal:<\/strong> Balance cost and resilience by selectively applying spread to critical services.<br\/>\n<strong>Why Topology spread constraints matters here:<\/strong> Spreading every workload across AZs inflates cross-AZ costs; selective use optimizes trade-off.<br\/>\n<strong>Architecture \/ workflow:<\/strong> Tier services into critical and non-critical. Apply strict spread to critical; use ScheduleAnyway for non-critical. Monitor costs and performance.<br\/>\n<strong>Step-by-step implementation:<\/strong> <\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Classify services by criticality and cost impact.<\/li>\n<li>Update manifests appropriately.<\/li>\n<li>Run load tests to measure cross-AZ traffic and latency.<\/li>\n<li>Monitor cost telemetry and performance metrics.\n<strong>What to measure:<\/strong> Cross-AZ network egress, replica skew, user latency.<br\/>\n<strong>Tools to use and why:<\/strong> Cost reporting tools, Prometheus, tracing.<br\/>\n<strong>Common pitfalls:<\/strong> Over-optimization reduces resilience unintentionally.<br\/>\n<strong>Validation:<\/strong> Validate failover for critical services and acceptable degradation for non-critical ones.<br\/>\n<strong>Outcome:<\/strong> Cost optimized while maintaining SLOs for critical services.<\/li>\n<\/ol>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Common Mistakes, Anti-patterns, and Troubleshooting<\/h2>\n\n\n\n<p>List of mistakes with Symptom -&gt; Root cause -&gt; Fix (15\u201325 items)<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>Symptom: Pods Pending with Unschedulable reason -&gt; Root cause: DoNotSchedule with not enough capacity -&gt; Fix: Temporarily set ScheduleAnyway or add capacity.<\/li>\n<li>Symptom: All replicas on one node -&gt; Root cause: Missing topology node labels -&gt; Fix: Apply consistent labels to nodes.<\/li>\n<li>Symptom: High scheduler latency -&gt; Root cause: Excessive constraints and high cluster size -&gt; Fix: Simplify constraints or tune scheduler performance.<\/li>\n<li>Symptom: PDB blocks maintenance -&gt; Root cause: Strict PDB plus DoNotSchedule -&gt; Fix: Adjust PDBs or maintenance windows.<\/li>\n<li>Symptom: Quorum loss in DB -&gt; Root cause: Replicas collocated on same topology -&gt; Fix: Enforce stronger spread with anti-affinity.<\/li>\n<li>Symptom: Excessive pod restarts after failure -&gt; Root cause: Eviction storms due to mass rescheduling -&gt; Fix: Stagger reschedules or add graceful draining.<\/li>\n<li>Symptom: Canary not representative -&gt; Root cause: Canary instances in a single topology -&gt; Fix: Spread canary across domains.<\/li>\n<li>Symptom: Unexpected placement in cloud provider -&gt; Root cause: Provider overrides or mapping differences -&gt; Fix: Validate provider topology mapping and labels.<\/li>\n<li>Symptom: Observability gaps during incidents -&gt; Root cause: No embed of topology metadata in traces -&gt; Fix: Tag traces\/metrics with node\/zone metadata.<\/li>\n<li>Symptom: Alerts too noisy -&gt; Root cause: Too-sensitive thresholds or no suppression during autoscale -&gt; Fix: Add grouping, suppression windows, and dedupe.<\/li>\n<li>Symptom: Conflict between anti-affinity and spread -&gt; Root cause: Contradictory Pod rules -&gt; Fix: Reconcile rules or create exceptions.<\/li>\n<li>Symptom: Scale-up creates uneven nodes -&gt; Root cause: Autoscaler adds nodes in one pool only -&gt; Fix: Configure autoscaler with balanced node pools and scale policies.<\/li>\n<li>Symptom: Label drift over time -&gt; Root cause: Automation or manual changes altering node labels -&gt; Fix: Enforce labels via daemon or policy controller.<\/li>\n<li>Symptom: Metrics cardinality explosion -&gt; Root cause: Metrics per pod with high label set -&gt; Fix: Aggregate metrics by topology key, drop high-cardinality labels.<\/li>\n<li>Symptom: Misapplied constraints in CI -&gt; Root cause: Incomplete manifests or templating issues -&gt; Fix: Add linting and manifest validation to pipeline.<\/li>\n<li>Symptom: Timing-sensitive imbalance -&gt; Root cause: Slow autoscaler reaction -&gt; Fix: Pre-warm capacity or predictive scaling.<\/li>\n<li>Symptom: Rogue mutating webhook alters constraints -&gt; Root cause: Webhook changing PodSpec labels -&gt; Fix: Audit and restrict webhooks.<\/li>\n<li>Symptom: Inconsistent behavior across clusters -&gt; Root cause: Cluster version differences and scheduler flags -&gt; Fix: Standardize cluster configurations.<\/li>\n<li>Symptom: High network cost after spreading -&gt; Root cause: Cross-AZ traffic increased by spreading stateful caches -&gt; Fix: Selective spread and data locality considerations.<\/li>\n<li>Symptom: Insufficient telemetry for postmortem -&gt; Root cause: Lack of historical scheduler metrics -&gt; Fix: Retain scheduler and pod placement metrics for relevant retention period.<\/li>\n<li>Symptom: Overly complex policies -&gt; Root cause: Mix of affinity, anti-affinity, taints and spread -&gt; Fix: Simplify and document policy interactions.<\/li>\n<li>Symptom: Security boundary breach due to placement -&gt; Root cause: Over-tolerating taints and wide spread -&gt; Fix: Combine spread with strict taints and node isolation.<\/li>\n<li>Symptom: Unexpected cost spikes -&gt; Root cause: Autoscaler scaling up to satisfy DoNotSchedule -&gt; Fix: Monitor cost and tune autoscaler limits.<\/li>\n<\/ol>\n\n\n\n<p>Observability pitfalls (at least 5 included above):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Missing topology metadata in traces prevents root cause correlation.<\/li>\n<li>No historical scheduler metrics blocks incident analysis.<\/li>\n<li>High metric cardinality hides useful aggregates.<\/li>\n<li>Alerts fire without topology context causing noisy paging.<\/li>\n<li>Lack of per-topology dashboards slows triage.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Best Practices &amp; Operating Model<\/h2>\n\n\n\n<p>Ownership and on-call:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>App teams own topologySpreadConstraints for their workloads.<\/li>\n<li>SRE maintains cluster-level defaults and guidance.<\/li>\n<li>On-call rotation should include SRE members with permissions to change cluster-level responses.<\/li>\n<\/ul>\n\n\n\n<p>Runbooks vs playbooks:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Runbooks: step-by-step remediation for common symptoms.<\/li>\n<li>Playbooks: higher-level decision flow for more complex, multi-service incidents.<\/li>\n<\/ul>\n\n\n\n<p>Safe deployments:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use canary or incremental rollouts combined with spread to minimize impact.<\/li>\n<li>Always include PDBs reviewed against spread constraints.<\/li>\n<\/ul>\n\n\n\n<p>Toil reduction and automation:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Automate label consistency with controllers.<\/li>\n<li>Use admission controllers to inject standard spread constraints for critical namespaces.<\/li>\n<li>Automate remediation: scale up node pools or toggle ScheduleAnyway through safe API paths.<\/li>\n<\/ul>\n\n\n\n<p>Security basics:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Restrict who can mutate node labels or topology constraints.<\/li>\n<li>Use taints for critical nodes and combine with spread to avoid accidental colocations.<\/li>\n<li>Audit changes to PodSpec templates via GitOps.<\/li>\n<\/ul>\n\n\n\n<p>Weekly\/monthly routines:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Weekly: Review incidents and any skew alerts; validate runbook accuracy.<\/li>\n<li>Monthly: Audit node labels and topology mappings; test autoscaler behavior.<\/li>\n<li>Quarterly: Chaos game days and compliance checks on distribution.<\/li>\n<\/ul>\n\n\n\n<p>Postmortem reviews:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm whether placement or topology contributed to outage.<\/li>\n<li>Review metrics like time to restore skew and pending pod counts.<\/li>\n<li>Update runbooks, dashboards, and constraints based on findings.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Tooling &amp; Integration Map for Topology spread constraints (TABLE REQUIRED)<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>ID<\/th>\n<th>Category<\/th>\n<th>What it does<\/th>\n<th>Key integrations<\/th>\n<th>Notes<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>I1<\/td>\n<td>Monitoring<\/td>\n<td>Collects cluster and scheduler metrics<\/td>\n<td>Prometheus, kube-state-metrics<\/td>\n<td>Core for measurement<\/td>\n<\/tr>\n<tr>\n<td>I2<\/td>\n<td>Visualization<\/td>\n<td>Dashboards for skew and scheduling<\/td>\n<td>Grafana<\/td>\n<td>For executive and on-call views<\/td>\n<\/tr>\n<tr>\n<td>I3<\/td>\n<td>Autoscaling<\/td>\n<td>Adds node capacity to satisfy constraints<\/td>\n<td>Cluster Autoscaler<\/td>\n<td>Helps DoNotSchedule situations<\/td>\n<\/tr>\n<tr>\n<td>I4<\/td>\n<td>Chaos engineering<\/td>\n<td>Tests distribution resilience<\/td>\n<td>Chaos tool<\/td>\n<td>Validates spread under failure<\/td>\n<\/tr>\n<tr>\n<td>I5<\/td>\n<td>CI\/CD<\/td>\n<td>Injects and validates manifest constraints<\/td>\n<td>GitOps pipelines<\/td>\n<td>Prevents misconfigurations<\/td>\n<\/tr>\n<tr>\n<td>I6<\/td>\n<td>Policy enforcement<\/td>\n<td>Enforces labels and constraints via policies<\/td>\n<td>OPA\/Admission controllers<\/td>\n<td>Ensures consistency<\/td>\n<\/tr>\n<tr>\n<td>I7<\/td>\n<td>Tracing<\/td>\n<td>Correlates errors with placement<\/td>\n<td>Tracing systems<\/td>\n<td>Adds topology metadata to traces<\/td>\n<\/tr>\n<tr>\n<td>I8<\/td>\n<td>Logging<\/td>\n<td>Centralizes scheduler and node logs<\/td>\n<td>Aggregated logging<\/td>\n<td>Useful for incident analysis<\/td>\n<\/tr>\n<tr>\n<td>I9<\/td>\n<td>State metrics<\/td>\n<td>Exposes Kubernetes object state<\/td>\n<td>kube-state-metrics<\/td>\n<td>Enables domain counts<\/td>\n<\/tr>\n<tr>\n<td>I10<\/td>\n<td>Cloud provider telemetry<\/td>\n<td>Provides zone and host-level health<\/td>\n<td>Provider metrics<\/td>\n<td>Necessary for mapping and capacity<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h4 class=\"wp-block-heading\">Row Details (only if needed)<\/h4>\n\n\n\n<ul class=\"wp-block-list\">\n<li>None required.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Frequently Asked Questions (FAQs)<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What is the default behavior if topologyKey is missing on nodes?<\/h3>\n\n\n\n<p>If nodes lack the label for topologyKey, they are treated as a single domain and skew calculation will not be meaningful; ensure label consistency.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can topology spread constraints ensure strict equal distribution?<\/h3>\n\n\n\n<p>maxSkew controls strictness; DoNotSchedule can block scheduling to enforce it but may lead to Pending pods if capacity insufficient.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do managed Kubernetes offerings support topology spread constraints?<\/h3>\n\n\n\n<p>Varies \/ depends on provider; many support native Kubernetes features but access to scheduler metrics may be limited.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How do topology spread constraints interact with PodDisruptionBudgets?<\/h3>\n\n\n\n<p>They are complementary; PDBs limit voluntary evictions while spread controls placement. Conflicts can prevent rescheduling.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Is topology spread constraints sufficient for stateful databases?<\/h3>\n\n\n\n<p>Not alone; stateful workloads often need StatefulSet semantics and explicit quorum placement in addition to spread.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What happens during horizontal scaling?<\/h3>\n\n\n\n<p>Scheduler recalculates domain counts and places new pods to respect maxSkew; autoscaler may be required for sufficient capacity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can topologyKey be a custom label?<\/h3>\n\n\n\n<p>Yes; any node label can be used as topologyKey, but labels must be consistent and present across nodes.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Should all workloads have topology spread constraints?<\/h3>\n\n\n\n<p>Not necessarily; apply to services requiring availability guarantees or low blast radius.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to debug pods Pending due to spread constraints?<\/h3>\n\n\n\n<p>Inspect events for scheduling reasons, check node labels, PDBs, and cluster autoscaler activity.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Does spread affect performance or latency?<\/h3>\n\n\n\n<p>Potentially: spreading across regions or AZs may increase latency; measure cross-domain latency before broad application.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to test spread policy before production?<\/h3>\n\n\n\n<p>Use staging clusters, simulate failures with chaos engineering, and run autoscaling scenarios.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to automate enforcement of spread defaults?<\/h3>\n\n\n\n<p>Use admission controllers or GitOps policies to inject or validate topologySpreadConstraints in manifests.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">What are reasonable starting targets for SLOs?<\/h3>\n\n\n\n<p>Varies \/ depends; pick conservative targets based on workload criticality and test restoration windows via chaos experiments.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Can anti-affinity be used instead of spread?<\/h3>\n\n\n\n<p>They are different; anti-affinity prevents co-location of Pods while spread enforces balance; use both when needed.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to avoid metric cardinality explosion when measuring skew?<\/h3>\n\n\n\n<p>Aggregate by topologyKey and service rather than per-pod labels; use recording rules.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Do nodes in different AZs always have correct topology labels?<\/h3>\n\n\n\n<p>Not always; label mappings can vary by provider and cluster setup\u2014verify label presence.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">How to handle legacy workloads without Pod templates that support spread?<\/h3>\n\n\n\n<p>Wrap with higher-level controller or recreate workloads with updated manifests; use admission controller to detect and flag.<\/p>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Conclusion<\/h2>\n\n\n\n<p>Topology spread constraints are a practical scheduling tool to reduce correlated failures by distributing Pods across defined topology domains. They integrate into broader SRE practices\u2014monitoring, autoscaling, PDBs, and runbooks\u2014and require careful measurement and testing to avoid over-constraining clusters.<\/p>\n\n\n\n<p>Next 7 days plan (5 bullets):<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Day 1: Inventory critical services and current pod distribution by topology.<\/li>\n<li>Day 2: Add or validate node topology labels and deploy kube-state-metrics.<\/li>\n<li>Day 3: Apply topologySpreadConstraints to one critical service in staging and monitor.<\/li>\n<li>Day 4: Create dashboards and record replica skew metrics; set alerts.<\/li>\n<li>Day 5\u20137: Run a scoped chaos test simulating a topology failure; iterate config and update runbooks.<\/li>\n<\/ul>\n\n\n\n<hr class=\"wp-block-separator\" \/>\n\n\n\n<h2 class=\"wp-block-heading\">Appendix \u2014 Topology spread constraints Keyword Cluster (SEO)<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Primary keywords<\/li>\n<li>Topology spread constraints<\/li>\n<li>topologySpreadConstraints Kubernetes<\/li>\n<li>Kubernetes spread pods<\/li>\n<li>pod scheduling spread<\/li>\n<li>\n<p>distribute pods across zones<\/p>\n<\/li>\n<li>\n<p>Secondary keywords<\/p>\n<\/li>\n<li>maxSkew Kubernetes<\/li>\n<li>whenUnsatisfiable DoNotSchedule ScheduleAnyway<\/li>\n<li>topologyKey node labels<\/li>\n<li>replica skew metric<\/li>\n<li>\n<p>pod distribution monitoring<\/p>\n<\/li>\n<li>\n<p>Long-tail questions<\/p>\n<\/li>\n<li>How do topology spread constraints work in Kubernetes<\/li>\n<li>What is maxSkew in topology spread constraints<\/li>\n<li>How to prevent all pods in one availability zone<\/li>\n<li>Why are my pods pending due to topology spread constraints<\/li>\n<li>How to measure pod skew across zones<\/li>\n<li>Can topology spread constraints cause scheduling delays<\/li>\n<li>How do PDBs interact with topology spread constraints<\/li>\n<li>Best practices for topologySpreadConstraints in production<\/li>\n<li>How to test topology spread constraints with chaos engineering<\/li>\n<li>How to visualize replica skew in Grafana<\/li>\n<li>How to label nodes for topology spread constraints<\/li>\n<li>How does cluster autoscaler affect topology spread constraints<\/li>\n<li>How to design SLOs for pod distribution<\/li>\n<li>How to balance cost and availability with spread constraints<\/li>\n<li>How to handle topologyKey differences across cloud providers<\/li>\n<li>How to debug unschedulable pods due to spread<\/li>\n<li>How to use topology spread constraints with StatefulSet<\/li>\n<li>How to inject default topology spread constraints with admission controller<\/li>\n<li>How to log scheduler decisions for topology spread<\/li>\n<li>\n<p>How to design canary rollouts with topology spread<\/p>\n<\/li>\n<li>\n<p>Related terminology<\/p>\n<\/li>\n<li>Pod anti-affinity<\/li>\n<li>Node affinity<\/li>\n<li>PodDisruptionBudget<\/li>\n<li>Cluster Autoscaler<\/li>\n<li>kube-state-metrics<\/li>\n<li>Prometheus monitoring<\/li>\n<li>Grafana dashboards<\/li>\n<li>Scheduler events<\/li>\n<li>Eviction storms<\/li>\n<li>Scheduler latency<\/li>\n<li>ReplicaSet vs StatefulSet<\/li>\n<li>Taints and tolerations<\/li>\n<li>Node labels and topologyKey<\/li>\n<li>Cloud availability zones<\/li>\n<li>Region-aware scheduling<\/li>\n<li>Quorum placement<\/li>\n<li>Chaos engineering tests<\/li>\n<li>GitOps manifest validation<\/li>\n<li>Admission controllers<\/li>\n<li>Policy-as-code<\/li>\n<li>Observability signals<\/li>\n<li>SLIs and SLOs for placement<\/li>\n<li>Error budget for distribution violations<\/li>\n<li>Pod scheduling predicates<\/li>\n<li>Scheduler extenders<\/li>\n<li>Placement constraints<\/li>\n<li>Rack-aware scheduling<\/li>\n<li>Edge POP distribution<\/li>\n<li>Cross-AZ network cost<\/li>\n<li>Best-effort scheduling<\/li>\n<li>DoNotSchedule impact<\/li>\n<li>ScheduleAnyway behavior<\/li>\n<li>Label selector for skew<\/li>\n<li>Replica skew detection<\/li>\n<li>Historical scheduler metrics<\/li>\n<li>Postmortem for placement incidents<\/li>\n<li>Runbooks for scheduling faults<\/li>\n<li>Admission webhooks for placement<\/li>\n<\/ul>\n","protected":false},"excerpt":{"rendered":"<p>&#8212;<\/p>\n","protected":false},"author":7,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-2175","post","type-post","status-publish","format-standard","hentry"],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v25.3 - https:\/\/yoast.com\/wordpress\/plugins\/seo\/ -->\n<title>What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - FinOps School<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - FinOps School\" \/>\n<meta property=\"og:description\" content=\"---\" \/>\n<meta property=\"og:url\" content=\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/\" \/>\n<meta property=\"og:site_name\" content=\"FinOps School\" \/>\n<meta property=\"article:published_time\" content=\"2026-02-16T01:05:52+00:00\" \/>\n<meta name=\"author\" content=\"rajeshkumar\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"rajeshkumar\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"32 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"WebPage\",\"@id\":\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/\",\"url\":\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/\",\"name\":\"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - FinOps School\",\"isPartOf\":{\"@id\":\"http:\/\/finopsschool.com\/blog\/#website\"},\"datePublished\":\"2026-02-16T01:05:52+00:00\",\"author\":{\"@id\":\"http:\/\/finopsschool.com\/blog\/#\/schema\/person\/0cc0bd5373147ea66317868865cda1b8\"},\"breadcrumb\":{\"@id\":\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"http:\/\/finopsschool.com\/blog\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)\"}]},{\"@type\":\"WebSite\",\"@id\":\"http:\/\/finopsschool.com\/blog\/#website\",\"url\":\"http:\/\/finopsschool.com\/blog\/\",\"name\":\"FinOps School\",\"description\":\"FinOps NoOps Certifications\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"http:\/\/finopsschool.com\/blog\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"http:\/\/finopsschool.com\/blog\/#\/schema\/person\/0cc0bd5373147ea66317868865cda1b8\",\"name\":\"rajeshkumar\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"http:\/\/finopsschool.com\/blog\/#\/schema\/person\/image\/\",\"url\":\"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"contentUrl\":\"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g\",\"caption\":\"rajeshkumar\"},\"url\":\"http:\/\/finopsschool.com\/blog\/author\/rajeshkumar\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - FinOps School","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/","og_locale":"en_US","og_type":"article","og_title":"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - FinOps School","og_description":"---","og_url":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/","og_site_name":"FinOps School","article_published_time":"2026-02-16T01:05:52+00:00","author":"rajeshkumar","twitter_card":"summary_large_image","twitter_misc":{"Written by":"rajeshkumar","Est. reading time":"32 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"WebPage","@id":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/","url":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/","name":"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide) - FinOps School","isPartOf":{"@id":"http:\/\/finopsschool.com\/blog\/#website"},"datePublished":"2026-02-16T01:05:52+00:00","author":{"@id":"http:\/\/finopsschool.com\/blog\/#\/schema\/person\/0cc0bd5373147ea66317868865cda1b8"},"breadcrumb":{"@id":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/"]}]},{"@type":"BreadcrumbList","@id":"http:\/\/finopsschool.com\/blog\/topology-spread-constraints\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"http:\/\/finopsschool.com\/blog\/"},{"@type":"ListItem","position":2,"name":"What is Topology spread constraints? Meaning, Architecture, Examples, Use Cases, and How to Measure It (2026 Guide)"}]},{"@type":"WebSite","@id":"http:\/\/finopsschool.com\/blog\/#website","url":"http:\/\/finopsschool.com\/blog\/","name":"FinOps School","description":"FinOps NoOps Certifications","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"http:\/\/finopsschool.com\/blog\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"http:\/\/finopsschool.com\/blog\/#\/schema\/person\/0cc0bd5373147ea66317868865cda1b8","name":"rajeshkumar","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"http:\/\/finopsschool.com\/blog\/#\/schema\/person\/image\/","url":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/787e4927bf816b550f1dea2682554cf787002e61c81a79a6803a804a6dd37d9a?s=96&d=mm&r=g","caption":"rajeshkumar"},"url":"http:\/\/finopsschool.com\/blog\/author\/rajeshkumar\/"}]}},"_links":{"self":[{"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/2175","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/users\/7"}],"replies":[{"embeddable":true,"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/comments?post=2175"}],"version-history":[{"count":0,"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/posts\/2175\/revisions"}],"wp:attachment":[{"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/media?parent=2175"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/categories?post=2175"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/finopsschool.com\/blog\/wp-json\/wp\/v2\/tags?post=2175"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}