Mastering EKS Container Network Observability for Inter-AZ Traffic
In a cloud-native world, visibility into network traffic is paramount. EKS Container Network Observability provides the tools you need to track inter-AZ and NAT gateway traffic, ensuring your applications run smoothly across availability zones. This capability is vital for diagnosing issues, optimizing performance, and maintaining high availability in your Kubernetes clusters.
At the core of this observability is the Network Flow Monitor Agent, an eBPF daemon that collects and monitors network traffic at the pod level. This allows you to see how traffic flows between your services, including insights on latency and throughput. You can also control traffic distribution using the trafficDistribution field in your Kubernetes Service spec, which guides kube-proxy on how to route traffic to service endpoints. For example, setting trafficDistribution: PreferSameZone helps keep traffic within the same availability zone, reducing latency and improving performance.
In production, you need to be aware of the Kubernetes version requirements—this feature is available from version 1.35 onward. Additionally, while using traffic distribution is beneficial, moving workloads to a single AZ is generally not recommended for critical applications that require fault tolerance. Always consider the implications of your architecture on availability and performance.
Key takeaways
- →Leverage the Network Flow Monitor Agent to gain pod-level insights into network traffic.
- →Use the `trafficDistribution` field to control how traffic is routed to service endpoints.
- →Ensure your EKS cluster runs Kubernetes version 1.35 or later to utilize these features.
- →Avoid moving workloads to a single AZ to maintain high availability and fault tolerance.
Why it matters
In production, understanding and optimizing network traffic can significantly enhance application performance and reliability, directly impacting user experience and operational efficiency.
Code examples
1apiVersion: v1
2kind: Service
3metadata:
4 name: receiver
5spec:
6 trafficDistribution: PreferSameZone
7 selector:
8 app: receiver
9 ports:
10 - port: 80kubectl get pods -l 'app in (sender,receiver)' -o custom-columns='NAME:.metadata.name,APP:.metadata.labels.app,NODE:.spec.nodeName,AZ:.metadata.labels.topology\.kubernetes\.io/zone' --sort-by='.metadata.labels.app'1apiVersion: v1
2kind: Service
3metadata:
4 name: my-service
5spec:
6 selector:
7 app: my-app
8 trafficDistribution: PreferSameZone
9 ports:
10 - protocol: TCP
11 port: 80
12 targetPort: 8080When NOT to use this
Move your workload to a single AZ: This is generally not recommended for critical workloads that require high availability and fault tolerance.
Want the complete reference?
Read official docs35% off the CKA and other certifications with code OCT26NONCYBER, or 40% off Kubernetes security certs (CKS, KCSA) with OCT26CYBER.
CiliumCon Returns: Scaling eBPF Networking at KubeCon 2026
CiliumCon is back, and it's crucial for anyone involved in Kubernetes networking. With Cilium as the de facto CNI, understanding its eBPF foundation is key to managing workloads at scale. Don't miss out on the insights that could elevate your cloud-native architecture.
OVHcloud Joins CNCF: What This Means for Kubernetes in Europe
The CNCF's new partnership with OVHcloud marks a significant shift for Kubernetes in Europe. With OVHcloud operating thousands of production Kubernetes clusters using Cilium, this collaboration promises enhanced networking and security for multi-tenant environments.
Migrating to ALB: Mastering oauth2-proxy in Kubernetes
Switching from NGINX Ingress to ALB can be tricky, especially when handling oauth2-proxy. Learn how to configure oauth2-proxy to work seamlessly with ALB's OIDC authentication capabilities.
Get the daily digest
One email. 5 articles. Every morning.
No spam. Unsubscribe anytime.