Understanding Kubernetes Pods, Services, and Load Balancing Basics

1. Review of Core Pod Structures

1.1 Pod Structure

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

A pod can encapsulate 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 Expose Services Externally

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, a physical host port must be bound to the pod’s port, enabling packet forwarding from the host 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 traffic efficiently.

One naive idea is to deploy an Nginx inside a pod, but this approach fails because pods are transient—IP addresses 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 own IP address.

NODE IP : the physical host’s IP address.

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

3.2 How Service Implements Load Balancing

When a group of identical service replicas (e.g., order service) needs to be accessed, a Service presents a single virtual IP and port. Requests hit 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; a Service alone cannot be reached from the external network.

Service and Pod can communicate directly within the cluster’s LAN.

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

iptables

or

ipvs

to distribute packets to the target pods.

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

Thought 1: How Does a Service Associate with Pods?

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

Example:

selector: app=x

selects order‑service pods, while

selector: app=y

selects payment‑service pods. The Service stores the selected pod IPs in an

endpoints

object.

Thought 2: How Does a Service Detect Pod Changes?

Kubernetes uses the kube-proxy component on each node to monitor pods. When a pod is added, removed, or updated, kube-proxy updates the Service’s endpoint list accordingly.

The endpoint mappings are stored in

etcd

, and kube-proxy ensures they stay current.