I'm doing some network diagramming for my Kubernetes cluster and noticed something interesting in my Ingress logs. They show direct calls to the pod CIDR (10.244.0.0/16) for traffic steering. I thought Ingress was supposed to refer to a service, which means I should be seeing the service CIDR (192.168.0.0/16) instead. Can someone explain if this behavior is normal? Is KubeDNS resolving something on its own that leads to using the direct Pod IP when referencing a service?
3 Answers
It really depends on the ingress controller and its setup. For example, the old nginx ingress controller typically only uses Kubernetes services for discovering the pod IPs behind those services. This means it can directly connect the Ingress to the pods, offering benefits like alternative load balancing. You can modify the nginx settings for different behaviors.
Service IPs are essentially virtual IPs. The kube-proxy (which uses iptables) handles the destination network address translation (NAT) to send traffic to the actual pod IPs. So this behavior aligns with how Kubernetes manages traffic.
Okay cool... operating as expected then and I was misunderstanding the purpose of service IPs. Thank you for clarification!
Actually, Ingress typically checks the service first, which then directs the requests to the endpoints tracking pod IPs. It ensures routing to the healthy pod IPs behind your services.
Okay cool... operating as expected then and I was misunderstanding the purpose of service IPs. Thank you for clarification!
This is what we are using currently. To be clear, this is on Azure Kubernetes Service, which is still supporting NGINX Ingress until November 2026 without a clear replacement plan yet. Appreciate your feedback!