Node Placement and Locality Tuning

Node Placement and Locality Tuning An architecture diagram generated by Archify. Web server pod · Node 1 · Availability Zone 1 (us-west-2a) Web server pod Node 1 Cache pod · Node 2 · Availability Zone 1 (us-west-2a) Cache pod Node 2 DB pod (primary) · Node 2 · Availability Zone 1 (us-west-2a) DB pod (primary) Node 2 Web server pod · Node 3 · Availability Zone 2 (us-west-2b) Web server pod Node 3 Cache pod · Node 4 · Availability Zone 2 (us-west-2b) Cache pod Node 4 DB pod (replica) · Node 4 · Availability Zone 2 (us-west-2b) DB pod (replica) Node 4 High-frequency (intra-AZ) High-frequency (intra-AZ) DB replication (cross-AZ) Availability Zone 1 (us-west-2a) Availability Zone 2 (us-west-2b) Legend Frontend Database

Pod affinity

  • • Use podAffinity to co-locate chatty pairs such as web server and cache in one zone
  • • preferredDuringSchedulingIgnoredDuringExecution + topologyKey: topology.kubernetes.io/zone
  • • Intra-AZ traffic has lower latency than cross-AZ and no data transfer charge

Node affinity

  • • nodeAffinity on node.kubernetes.io/instance-type pins workloads to the instance types they need
  • • Use requiredDuringScheduling for hard constraints and preferredDuringScheduling for soft ones

Topology spread

  • • topologySpreadConstraints with maxSkew: 1 spreads pods evenly across zones and nodes
  • • whenUnsatisfiable: DoNotSchedule is strict; ScheduleAnyway is permissive
  • • Keep only durability-driven traffic, such as DB replication, deliberately cross-AZ