Calculate pod co-location outcomes when podAffinity rules are applied to a cluster.
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.
latencySavedPerRequest = (crossNodeLatency - sameNodeLatency) × callsPerRequest
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.
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.
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.