Understanding Kubernetes Pods, Services, and Load Balancing Basics

1. Review Core Pod Structures

1.1 Pod Structure

Pod is like a container; it has its own IP address and hostname, isolated by namespace, acting as an independent sandbox.

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

1.2 Pod Network

Pod has its own independent IP address.

Containers inside a pod communicate via

localhost

.

2. How Pods Expose External Access

Although a pod has its own IP and hostname, it is a virtual resource (represented as a process) without a physical machine or 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, enabling the host to forward packets to the pod.

For example, on a Linux machine running Logstash for log collection:

3. Pod Load Balancing

A key question is how a group of related pod replicas achieve load-balanced access, i.e., which pod should handle an incoming request.

One idea is to deploy an Nginx inside a pod, but this approach has drawbacks because pods are transient—IP addresses and hostnames change when pods restart or are updated, and Nginx cannot automatically detect these changes.

The proper solution is to use a Service resource object.

3.1 What Is a Service Resource Object

POD IP : the IP address of a pod.

NODE IP : the IP address of the physical host.

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

3.2 How Service Implements Load Balancing

When a set of identical service replicas (e.g., order service) needs load-balanced access, a Service is created with a virtual IP (VIP) and port. Clients request the Service, which then distributes traffic to the appropriate pod replicas.

3.3 Deep Dive into Service VIP

Both Service and Pod are virtual processes; a Service alone cannot directly provide external network access.

Service and Pod can communicate directly within the local network.

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

iptables

or

ipvs

to distribute packets.

To expose the Service externally, a host port must also be bound on the physical machine; the host forwards incoming traffic to the Service, which then forwards packets to the appropriate 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 require separate Services.

Example: a selector

app=x

selects order service pods, while

app=y

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

endpoints

object, establishing the mapping.

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

Kubernetes uses the kube-proxy component (mentioned in part 1). Each node runs kube-proxy, which monitors pods and updates the Service’s IP mapping when changes occur.

Service discovery works because kube-proxy updates the

endpoints

stored in

etcd

whenever pod status changes.

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