Pod Affinity Calculator
Calculate pod co-location outcomes when podAffinity rules are applied to a cluster.
About Pod Affinity Calculator
podAffinity schedules a pod onto the same node or topology domain (zone) as another pod it depends on, cutting network hops for chatty inter-service calls at the cost of scheduling flexibility — the scheduler can now only place the pod where the target already runs. This calculator estimates the latency benefit from co-location and quantifies how much scheduling flexibility (percent of otherwise-eligible nodes) is given up in exchange.
Formula
latencySavedPerRequest = (crossNodeLatency - sameNodeLatency) × callsPerRequest
- L_{cross}
- Cross-node network latency in ms
- L_{same}
- Same-node (loopback) latency in ms
- C
- Number of dependent calls per request
- \Delta L
- Total latency saved per request in ms
Worked example
With the default values below, Pod Affinity Calculator returns Latency Saved per Request of 9.50. Change any input above and every figure here is recalculated in your browser.
Inputs used
- Cross-Node Latencyaccepts 0–1,000 ms
- 2 ms
- Same-Node Latencyaccepts 0–1,000 ms
- 0.1 ms
- Dependent Calls per Requestaccepts 0–10,000 calls
- 5 calls
- Nodes Eligible After Constraintaccepts 0–100 %
- 60 %
Results
- Latency Saved per Request
- 9.50 ms
- Per-Call Latency Reduction
- 95.0%
- Scheduling Flexibility Lost
- 40%
Step by step
- 1Latency saved per call= 1.90ms
- 2Latency saved per request= 9.50ms
- 3Scheduling flexibility lost= 40%
Assumptions and limits
- The result is derived only from the 4 inputs listed above. Anything not among them is not part of the calculation.
- In particular, this calculator does not take inflation, tax, fees or charges or compounding frequency into account.
- Figures are rounded for display to 2 decimal places, so totals built from several rounded parts can differ slightly from the unrounded arithmetic.
How these calculators are built and tested is described on the Methodology page. If a figure looks wrong, please report it.
Frequently Asked Questions
When is podAffinity worth the scheduling constraint?
When the co-located services are latency-sensitive and communicate frequently per request — e.g. an app container calling a local cache or sidecar many times. For infrequent or already-fast cross-node calls, the constraint often isn't worth the reduced bin-packing flexibility.
What's the difference between node-level and zone-level pod affinity?
Setting topologyKey to kubernetes.io/hostname enforces same-node co-location (tightest, lowest latency); setting it to a zone label like topology.kubernetes.io/zone only requires same-zone placement, giving the scheduler more nodes to choose from while still avoiding cross-zone latency and transfer costs.
Can pod affinity cause scheduling failures?
Yes — with requiredDuringScheduling affinity, if the target pod's node runs out of capacity for additional co-located pods, or the target pod is rescheduled elsewhere, dependent pods can get stuck Pending until a matching node is available.