How Do Pods and Services Enable Load Balancing in Kubernetes?

1. Review core pod structures

1.1 Pod structure

A pod is a container-like sandbox with its own IP address and hostname, isolated by namespaces.

A pod can encapsulate one or multiple related containers.

1.2 Pod networking

Each pod has an independent IP address.

Containers inside the same pod communicate via

localhost

.

2. How a pod provides external access

Although a pod has its own IP and hostname, it is a virtual resource (a process) without a physical network interface, so it cannot be accessed directly from outside.

To expose a pod externally, a physical host port must be bound to the pod's port, allowing the host to forward traffic to the pod.

Example: a Linux machine running Logstash for log collection.

3. Pod load balancing

A key question is how a set of identical pod replicas can share incoming requests efficiently.

One naive idea is to deploy an Nginx inside a pod, but because pods have short lifecycles and their IPs change, Nginx cannot reliably track them.

The proper solution is to use a Service resource.

3.1 What is a Service?

POD IP : the IP address of a pod.

NODE IP : the IP address of the physical host.

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

3.2 How Service implements load balancing

A Service presents a virtual IP and port to clients; the Service then distributes traffic to the appropriate pod replicas (e.g., four identical pods in the diagram).

3.3 Deep dive into Service VIP

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

Service and Pod can communicate directly within the cluster (LAN communication).

Load‑balancing strategy: after a request reaches the Service, it uses

iptables

or

ipvs

to forward packets to the selected pods.

To expose the Service externally, a host port must be bound just like with a pod, and traffic is forwarded from the host to the Service, which then distributes it to the pods.

Thought 1: How does a Service associate with pods?

The association is achieved via label selectors. A Service can only target a single group of identical pod replicas; different business groups require separate Services.

Example: selector

app=x

selects order‑service pods, creating one Service; selector

app=y

selects payment‑service pods, creating another Service. The Service stores the pod IPs in an

endpoints

object.

Thought 2: How does Service discover pod changes?

Kubernetes uses the kube‑proxy component (running on each node) to monitor pods. When a pod is added, removed, or updated, kube‑proxy updates the Service’s endpoint list (stored in etcd) with the new IP addresses.

Source: CSDN article