Pod Affinity Calculator
Estimate the latency benefit and scheduling constraint tightening from co-locating pods on the same node or zone via podAffinity.
Inputs
Typical network latency between pods on different nodes.
Typical latency between pods co-located on the same node (localhost/loopback-like).
Number of calls per request made to the co-located dependency.
Estimated percent of nodes still eligible once podAffinity is applied (nodes already running the target pod).
Latency Saved per Request
9.50ms
Per-Call Latency Reduction
95.0%
Scheduling Flexibility Lost
40%
Step by step
Latency saved per call
2ms − 0.1ms
= 1.90ms
Latency saved per request
1.90ms × 5
= 9.50ms
Scheduling flexibility lost
100% − 60%
= 40%
How it works
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
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.