• TechOps Examples
  • Posts
  • Improving Kubernetes Latency with External Traffic Policy and Session Affinity

Improving Kubernetes Latency with External Traffic Policy and Session Affinity

Author

Govardhana M K
December 05, 2024

In partnership with

TechOps Examples

Hey — It's Govardhana MK 👋

Along with a use case deep dive, we identify the remote job opportunities, top news, tools, and articles in the TechOps industry.

👋 Before we begin... a big thank you to today's sponsor HUBSPOT

Ready to Level up your work with AI?

HubSpot’s free guide to using ChatGPT at work is your new cheat code to go from working hard to hardly working

HubSpot’s guide will teach you:

  • How to prompt like a pro

  • How to integrate AI in your personal workflow

  • Over 100+ useful prompt ideas

All in order to help you unleash the power of AI for a more efficient, impactful professional life.

IN TODAY'S EDITION

🧠 Use Case

  • Improving Kubernetes Latency with External Traffic Policy and Session Affinity

🚀 Top News

👀 Remote Jobs

📚️ Resources

🛠️ TOOL OF THE DAY

my badges - A GitHub Action that generates badges for your profile README.md

  • Badges will be updated automatically every day.

  • You will get new badges as you progress, or as community adds new badges.

🧠 USE CASE

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.

You may even like:

Looking to promote your company, product, service, or event to 24,000+ TechOps Professionals? Let's work together.