How Do Kubernetes Pods and Services Achieve Load Balancing?

1. Review of Core Pod Structures

1.1 Pod Structure

Pod acts as a container with its own IP address and hostname, isolated via namespaces, essentially a sandbox.

A pod encapsulates one or more containers, usually a group of related containers.

1.2 Pod Networking

Pod has its own independent IP address.

Containers inside a pod communicate via localhost.

2. How Pods Expose Services Externally

Although a pod has its own IP and hostname, it is a virtual resource (a process) without a physical counterpart, so it cannot directly provide external access.

To expose a service, the pod must bind a port on the host machine, mapping the host port to the pod’s port, allowing traffic forwarding through the physical host.

Example: a Linux machine running Logstash for log collection.

3. Pod Load Balancing

A key question is how a set of related pod replicas achieve load‑balanced access when requests arrive.

One idea is to deploy an Nginx inside a pod.

Example diagram shows two Node pods for payment services and different pods for order services; an Nginx could route requests, but this approach has limitations because pods are processes whose IPs and hostnames change on failure or updates, making Nginx unsuitable.

The proper solution is to use a Service resource.

3.1 What Is a Service Resource?

POD IP: the pod’s IP address.

NODE IP: the physical host’s IP address.

Cluster IP: a virtual IP abstracted by Kubernetes, representing the Service object (VIP).

3.2 How Service Implements Load Balancing

To load‑balance access to a set of identical service replicas (e.g., order service), a Service presents a virtual IP and port. Clients contact the Service, which then distributes traffic to the appropriate pods.

3.3 Deep Dive into Service VIP

Both Service and Pod are virtual processes; a Service alone cannot be directly accessed from the external network.

Service and Pod can communicate directly within the local network.

Load‑balancing strategy: Service uses iptables or ipvs to distribute packets.

To expose the Service externally, a host port must be bound as before, forwarding traffic to the Service, which then forwards packets to the corresponding pods. The flow is illustrated below.

Thought 1: How does a Service associate with pods?

The association uses label selectors; a Service can only target a set of identical replicas. Different business groups require separate Services.

Example: selector

app=x

selects order service pods; selector

app=y

selects payment service pods. Endpoints store the IPs of the selected pods, establishing the mapping.

Thought 2: How does a Service discover pod changes such as crashes or new versions?

Kubernetes component

kube-proxy

runs on each node, monitoring pods and updating the Service’s IP mapping when changes occur.

Service discovery works by

kube-proxy

updating the endpoints stored in etcd whenever pod status changes.