Understanding Kubernetes Pods, Services, and Load Balancing

1. Review of Core Pod Structures

1.1 Pod Structure

A pod acts like a container sandbox with its own IP address and hostname, isolated via namespaces.

It encapsulates one or multiple related containers.

1.2 Pod Network

Each pod has an independent 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 object (a process) without a physical network interface, so it cannot be accessed directly from outside.

To expose a service, the pod must bind a host machine port to the pod's port, allowing the host to forward traffic.

Example: a Linux machine running Logstash (log collection) illustrates this mapping.

3. Pod Load Balancing

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

Deploying an Nginx inside a pod is not ideal because pods are dynamic; their IPs and hostnames change on restart or upgrade, and Nginx cannot automatically discover these changes.

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 (VIP) abstracted by Kubernetes for the Service object.

3.2 Service Load Balancing

A Service presents a virtual IP and port to external clients. Requests hit the Service, which then load‑balances them to the appropriate pod replicas.

3.3 Deep Dive into Service VIP

Both Service and Pod are virtual processes; a Service cannot directly expose itself to the external network.

Service and Pod can communicate within the cluster LAN.

Load‑distribution is implemented by the Service using iptables or ipvs to forward packets.

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

Thought 1: How does a Service associate with pods?

Association is done via label selectors. A Service targets a set of identical pod replicas sharing the same labels; different business groups require separate Services.

Thought 2: How does a Service discover pod changes?

The kube-proxy component runs on each node, monitors pod lifecycle events, and updates the Service's endpoint list (stored in etcd) with new pod IPs.