DNS Resolution Phase

When a client attempts to reach a domain like app.example.com, it first queries a DNS server. The resolution yields different results based on the service exposure strategy:

• External IP (e.g., 198.51.100.10): Returned when the application is exposed externally via a LoadBalancer or an Ingress resource.
• Cluster-internal IP (e.g., 10.100.50.50): Returned for internal-only access using a ClusterIP type service.
• Kubernetes Internal FQDN (e.g., api-svc.production.svc.cluster.local): Resolves directly to the virtual IP assigned to the service.

Traffic Entry into the Cluster

External Traffic Path (LoadBalancer / Ingress)

The request arrives at the cloud provider's load balancer public IP. From here:

• LoadBalancer: Forwards traffic directly to the Service's NodePort or to the pods themselves, depending on the cloud controller configuration.
• Ingress: The Ingress controller (such as Traefik or Nginx) evaluates the host header and path against its defined rules. Once a match is found, traffic is proxied to the corresponding backend Service's ClusterIP.

Internal Traffic Path (Direct Service Access)

If the client is already within the cluster, it typically uses the Service's ClusterIP or its internal FQDN. The request bypasses external load balancers and directly enters the cluster's service discovery mechanism.

Service Discovery and Routing

Once the request reaches the Service's virtual IP (ClusterIP), kube-proxy intercepts it. Operating on the node, kube-proxy uses iptables or IPVS rules to distribute the traffic across healthy backend pods.

Example of iptables NAT rules handling the routing:

# Routing traffic destined for the service VIP to available endpoints
-A KUBE-SERVICES -d 10.100.50.50/32 -p tcp --dport 80 -j KUBE-SVC-WEBAPP
-A KUBE-SVC-WEBAPP -m statistic --mode random --probability 0.33 -j KUBE-SEP-WEBPOD1
-A KUBE-SVC-WEBAPP -m statistic --mode random --probability 0.5 -j KUBE-SEP-WEBPOD2
-A KUBE-SVC-WEBAPP -j KUBE-SEP-WEBPOD3

The list of active pod IPs backing the service is maintained dynamically by the EndpointSlice API, which updates based on pod readiness probes.

Pod Processing

The routed request arrives at a specific pod IP (e.g., 10.244.1.5:8080). The containerized application processes the incoming data and formulates a response.

Response Traversal

The reply travels back through the established network path:

Pod -> Service -> Ingress/LoadBalancer -> Client

During the return journey, especially when passing through an Ingress controller, headers like X-Forwarded-For are often appended or modified to preserve the original client IP address.

Traffic Paths by Service Type

ClusterIP

Path: Internal Client -> ClusterIP -> kube-proxy -> Pod
Used strictly for inter-cluster communication.

NodePort

Path: Client -> NodeIP:NodePort -> Service -> kube-proxy -> Pod
Exposes the service on a static port across all nodes, requiring external firewall management.

LoadBalancer

Path: Client -> Cloud LB External IP -> Service -> kube-proxy -> Pod
The standard approach for provisioning an external entry point in cloud environments.

Ingress (Layer 7)

Path: Client -> Ingress Controller -> Service -> Pod
Provides advanced HTTP routing, host/path matching, and TLS termination capabilities.

End-to-End External Request Walkthrough

1. A user navigates to https://app.example.com.
2. DNS resolves the domain to the external IP of the cloud load balancer (e.g., 198.51.100.10).
3. The cloud LB routes the traffic to the Ingress Controller pods.
4. The Ingress controller matches the Host: app.example.com header and proxies the request to frontend-svc:80.
5. kube-proxy translates the ClusterIP destination to a pod IP (e.g., 10.244.1.5:8080) via NAT.
6. The pod generates the response, which retraces the exact path back to the user.