Understanding Kubernetes Service Types and kube-proxy Load‑Balancing Mechanisms

Kubernetes Service is an abstraction that groups Pods with the same label and provides a stable virtual IP (ClusterIP) for intra‑cluster communication, while kube‑proxy watches Service and Endpoint objects and programs the underlying networking layer to enable load balancing.

The article first outlines the four main Service types: ClusterIP (default, internal only), NodePort (exposes a port on every node for external access), LoadBalancer (integrates with cloud provider load balancers), and Ingress (a logical entry point that can route to multiple Services).

Service discovery can be performed via environment variables or DNS; DNS (CoreDNS) is recommended because environment variables are only injected into Pods created after the Service exists.

For load balancing, kube‑proxy can operate in two modes:

Iptables mode : kube‑proxy creates custom iptables chains (e.g., KUBE‑SERVICE, KUBE‑SVC‑XXXXX, KUBE‑SEP‑XXXXX) that perform DNAT/SNAT and routing. The matching process traverses chains linearly (O(N)), leading to higher latency, slow rule updates, scalability limits, and temporary service disruption during updates.

IPVS mode : built on the Linux Virtual Server project, IPVS uses hash tables for O(1) lookups, supports multiple scheduling algorithms (rr, lc, dh, sh, sed, nq), and provides session affinity. It creates virtual servers on a dedicated interface (kube‑ipvs0) and maps Service IPs to IPVS virtual servers.

To enable IPVS, the following kube‑proxy flags are required:

--proxy-mode=ipvs               // set kube-proxy mode to IPVS
--ipvs-scheduler=rr            // choose the load‑balancing algorithm (default rr)
--ipvs-min-sync-period=5s      // minimum interval to sync IPVS rules
--ipvs-sync-period=30s         // maximum interval to sync IPVS rules

An example Service manifest that enables client‑IP session affinity is shown below:

kind: Service
apiVersion: v1
metadata:
  name: nginx-service
spec:
  type: ClusterIP
  selector:
    app: nginx
  sessionAffinity: ClientIP
  sessionAffinityConfig:
    clientIP:
      timeoutSeconds: 50
  ports:
  - name: http
    protocol: TCP
    port: 80
    targetPort: 80

After applying the manifest, ipvsadm -L can be used to verify that the session‑affinity rules are in effect. The article concludes that IPVS provides constant‑time connection handling independent of the number of Services, making it far more efficient than iptables for large clusters.