How Do Kubernetes Pods Expose Services and Achieve Load Balancing?

1. Review pod core structures

1.1 Pod structure

Pod is like a container; it has its own IP address and hostname, using namespace for resource isolation, acting as an independent sandbox.

Inside a pod are one or more containers (usually a related group).

1.2 Pod networking

Pod has its own IP address.

Containers inside a pod communicate via localhost.

2. How pods provide external access

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

To expose a pod, a physical machine port must be bound (i.e., open a port on the host and map it to the pod's port), allowing traffic to be forwarded through the host.

Example using a Linux machine (logstash for log collection) is shown below.

3. Pod load balancing

A key issue 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.

However, because pods are processes with lifecycles—IP and hostname change on restart or version update—Nginx cannot automatically discover these changes, making it unsuitable for load balancing.

Instead, use a Service resource object.

3.1 What is a Service resource object

POD IP: the pod's IP address.

NODE IP: the physical machine's IP address.

Cluster IP: a virtual IP abstracted by Kubernetes; the Service object acts as a VIP (virtual IP).

3.2 How Service implements load balancing

To load‑balance access to a group of identical service replicas (e.g., order service), a Service is created that presents a virtual IP (VIP) and port. Requests reach the Service, which then load‑balances them to the appropriate pods.

3.3 Deep dive into Service VIP

Both Service and Pod are virtual processes, so Service cannot directly provide external network access.

Service and Pod can communicate directly within the LAN.

Load strategy: after receiving a request, Service uses iptables or ipvs to distribute packets.

To expose services externally, a host port must also be bound, forwarding external requests to the Service, which then distributes them to the pods.

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 need separate Services.

Example: selector app=x selects order service pods to create a Service; selector app=y selects payment service pods. The Service stores the pods' IPs in an endpoints attribute, establishing the mapping.

Thought 2: How does Service discover pod changes?

Kubernetes component kube-proxy runs on each node. It monitors pods and updates the Service's endpoints in etcd when pods change, ensuring the Service has up‑to‑date IP mappings.

Source: https://blog.csdn.net/qq_43280818/article/details/107164860