Improving Kubernetes Latency with External Traffic Policy and Session Affinity

Improving Kubernetes Latency with External Traffic Policy and Session Affinity

When dealing with Kubernetes Services, achieving optimal performance often requires fine-tuning configurations.

In the basket of Kubernetes service configurations, you should know:

External Traffic Policy: Controls whether client IP is kept when traffic reaches your service.

Session Affinity: Keeps a client connected to the same pod each time.

And you can lower the latency with these settings.

1. externalTrafficPolicy: Local

By default, it is set to Cluster, meaning traffic can be forwarded to any node, even if the pod doesn't exist on that node.

This behavior introduces an additional network hop, increasing latency and losing the original client IP.

By setting externalTrafficPolicy to Local, only nodes that host the service’s pods will receive external traffic.

2. sessionAffinity: ClientIP

By default, it is set to None, meaning that requests from a single client may be distributed randomly across all pods.

This behavior is ideal for stateless applications but can create challenges for the applications that depend on maintaining user sessions.

By configuring sessionAffinity as ClientIP, all requests from the same client IP address are directed to the same pod.

When to Avoid

externalTrafficPolicy: Local

📌 When cluster wide load balancing across all nodes is more important than latency.

📌 When the pods for your service are sparsely distributed across a subset of nodes, causing uneven load.

sessionAffinity: ClientIP

📌 When you’re running stateless applications that don’t depend on session persistence.

📌 When a small number of clients generate a high volume of traffic, risking overloading a single pod.

📌 When your application relies on dynamic scaling, as session affinity can complicate traffic distribution.

Additional Considerations

While configuring externalTrafficPolicy: Local and sessionAffinity: ClientIP improves service performance and user experience, a broader optimization strategy is needed to address stability and scalability.

1. Node Placement Matters

affinity:

podAntiAffinity:

requiredDuringSchedulingIgnoredDuringExecution:

- labelSelector:

matchLabels:

app: frontend

topologyKey: kubernetes.io/hostname

This setup ensures pods are spread across nodes, especially useful in high traffic applications like content delivery systems, where traffic must be evenly distributed to reduce load imbalances.

2. Resource Requests and Limits

Prevent resource contention by setting resource requests and limits in your deployment.

resources:

requests:

cpu: "500m"

memory: "256Mi"

limits:

cpu: "1"

memory: "512Mi"

This is particularly valuable for applications like payment gateways, where individual user sessions may generate significant resource load.

3. Combine Network Policies for Security

Sample Network Policy to Allow Traffic from Specific IPs:

ingress:

- from:

- ipBlock:

cidr: 192.168.1.0/24

ports:

- protocol: TCP

port: 80

This is critical for applications like admin portals or private APIs where access needs to be restricted to specific IP ranges.

The attempt here is to know the options and understand the implications, but not a generalization.

It’s all about trade offs - what makes sense for one system need not be for the other