Kubernetes Service Network Mechanisms: Overview, Access Methods, Container Networking, Service Types, DNS, kube-proxy Modes, Source IP Preservation, and Ingress

Kubernetes treats a group of tightly related containers as a Pod, sharing a network namespace; therefore, container networking discussions can be expressed in terms of Pod communication.

1. Network Access Methods – Access is classified into four scenarios: same‑node pod access, cross‑node pod access, pod accessing external services, and external clients accessing cluster pods.

2. Container Network Mechanism – On a node, the container runtime creates a default bridge (cbr0) and uses CNI bridge plugins to create a veth‑pair for each Pod (eth0 inside the Pod, the peer in the host namespace). Same‑node pod traffic is switched via cbr0; cross‑node traffic traverses the host’s eth0 and follows the routing table to the destination node.

Example of the bridge setup:

cbr0 (bridge) <-- veth‑pair --> eth0 (Pod)

3. Service‑Pod Relationship – A Service selects Pods via label selectors, creating an Endpoints object that lists the target Pod IPs. This enables load‑balancing across multiple Pod replicas.

Endpoint controller snippet:

// kubernetes/pkg/controller/endpoint/endpoints_controller.go
func NewEndpointController(ctx context.Context, podInformer coreinformers.PodInformer, serviceInformer coreinformers.ServiceInformer,
    endpointsInformer coreinformers.EndpointsInformer, client clientset.Interface, endpointUpdatesBatchPeriod time.Duration) *Controller {
    // Add event handlers for Service, Pod, and Endpoints
    serviceInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{AddFunc: e.onServiceUpdate, UpdateFunc: func(old, cur interface{}) {e.onServiceUpdate(cur)}, DeleteFunc: e.onServiceDelete})
    podInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{AddFunc: e.addPod, UpdateFunc: e.updatePod, DeleteFunc: e.deletePod})
    endpointsInformer.Informer().AddEventHandler(cache.ResourceEventHandlerFuncs{DeleteFunc: e.onEndpointsDelete})
    return e
}

4. Service Types

ClusterIP – internal access via a virtual IP.

NodePort – exposes a port on each node for external access.

LoadBalancer – provisions an external IP (often via cloud provider) and forwards to node ports.

ExternalName – maps a Service name to an external DNS name.

Headless Service example (ClusterIP: None):

apiVersion: v1
kind: Service
metadata:
  name: headless-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP
  clusterIP: None
  publishNotReadyAddresses: true

5. DNS Resolution – CoreDNS runs as a Pod, watches Service objects, and creates DNS records. A typical lookup:

nslookup my-svc.my-namespace.svc.cluster.local
Server: 10.4.7.51
Address: 10.4.7.51:53
Name: my-svc.my-namespace.svc.cluster.local
Address: 10.4.7.201

6. kube‑proxy Modes – Supports userspace, iptables (default), ipvs, nftables, and kernelspace (Windows). iptables mode creates NAT PREROUTING chains that map Service IP/port to Endpoint IPs using probabilistic rules.

iptables rule example:

iptables -t nat -nvL KUBE-SVC-RY7QXPUTX5YFBMZE
Chain KUBE-SVC-RY7QXPUTX5YFBMZE (1 references)
 pkts bytes target prot opt in out source destination
 0 0 KUBE-SEP-BHJRQ3WTIY7ZLGKU all -- * * 0.0.0.0/0 0.0.0.0/0 /* default/demo */ statistic mode random probability 0.33333333349

ipvs mode inserts services into the kernel IPVS table, e.g.:

ipvsadm -ln | grep 30180 -A 5
TCP  HostIP/VIP:30180 rr
  -> 10.5.0.87:18080 Masq 1 0 0
  -> 10.5.0.88:18080 Masq 1 0 0
  -> 10.5.0.89:18080 Masq 1 0 0

7. Source IP Preservation – Setting service.spec.externalTrafficPolicy=Local keeps the client’s source IP by avoiding SNAT when the target Pod resides on the same node.

iptables snippet for local‑only traffic:

Chain KUBE-XLB-AANU2CJXJILSCCKL (1 references)
 pkts bytes target prot opt in out source destination
 0 0 KUBE-MARK-MASQ all -- * * 0.0.0.0/0 0.0.0.0/0 /* masquerade LOCAL traffic */
 0 0 KUBE-SVC-AANU2CJXJILSCCKL all -- * * 0.0.0.0/0 0.0.0.0/0 /* route LOCAL traffic */
 0 0 KUBE-MARK-DROP all -- * * 0.0.0.0/0 0.0.0.0/0 /* no local endpoints */

8. Ingress – Provides HTTP/HTTPS routing based on host and path rules, translating them to ClusterIP Services. The newer Gateway API supersedes Ingress for richer protocol support.

Conclusion – Understanding the interplay of container networking, Service types, DNS, kube‑proxy modes, source‑IP handling, and Ingress is essential for designing reliable, scalable workloads on Kubernetes.