Mastering Kubernetes: Core Concepts from Container Ops to Network Isolation

Container Operations

Kubernetes (k8s) is an open‑source platform for automated container operations, including deployment, scaling, and scheduling across node clusters.

Key capabilities:

Automated container deployment and replication.

Real‑time elastic scaling of container workloads.

Orchestrated grouping of containers with built‑in load balancing.

Core components: kubectl: command‑line client for interacting with the cluster. kube-apiserver: REST API entry point for control operations. kube-controller-manager: runs background control loops (node health, pod counts, service‑pod bindings, etc.). kube-scheduler: assigns newly created pods to suitable nodes. etcd: distributed key‑value store for configuration sharing and service discovery. kube-proxy: runs on each node to implement pod‑level network proxying, syncing service info from etcd. kubelet: node‑level agent that receives pod assignments, manages containers, and reports status.

Optional DNS service for creating DNS records for each Service object.

Two‑Site Three‑Center Model

The model consists of a local production center, a local disaster‑recovery center, and a remote disaster‑recovery center. Data consistency is achieved with etcd, which provides a highly available, strongly consistent store for configuration sharing and service discovery.

etcd characteristics:

Simple: HTTP + JSON API usable with curl.

Secure: optional SSL client authentication.

Fast: supports ~1,000 writes per second per instance.

Trustworthy: Raft consensus algorithm ensures distributed reliability.

Four‑Layer Service Discovery

Kubernetes offers two native service‑discovery methods, both operating at layer 4:

Environment variables : When a pod is created, kubelet injects environment variables for all existing services. This method requires the service to be created before the pod, limiting its practicality.

DNS : Deploying the kube-dns add‑on creates DNS records for services, enabling pods to resolve service names via standard DNS queries.

Five Shared Resources Within a Pod

A pod is the smallest deployable unit in Kubernetes, grouping one or more tightly coupled containers. Containers in the same pod share the following resources:

PID namespace – processes can see each other's IDs.

Network namespace – shared IP address and port range.

IPC namespace – shared System V IPC or POSIX message queues.

UTS namespace – shared hostname.

Volumes – shared storage volumes defined at the pod level.

Pod lifecycle is managed by a Replication Controller (or newer ReplicaSet/Deployment). Each pod receives a unique IP address (IP‑per‑Pod model) and can communicate via localhost between its containers.

Six Common CNI Plugins

The Container Network Interface (CNI) defines a standard library and specifications for container networking. Kubernetes can use a variety of CNI plugins to implement different network models; the six most frequently used plugins are illustrated in the accompanying diagram.

Seven‑Layer Load Balancing

Load balancing in data‑center environments spans multiple OSI layers:

L2 – MAC‑address based balancing.

L3 – IP‑address based balancing.

L4 – IP + port (TCP/UDP) based balancing.

L7 – Application‑level balancing using URL, headers, etc.

Kubernetes traditionally exposes services via NodePort, binding a port on each node. This approach suffers from port‑exhaustion and limited firewall rule applicability. The preferred solution is an external load balancer (e.g., Nginx) combined with an Ingress controller, which provides L7 routing based on hostnames or paths.

Eight Isolation Dimensions

Kubernetes scheduling must respect isolation requirements ranging from coarse‑grained to fine‑grained dimensions (CPU, memory, network, security, etc.). The diagram outlines these eight dimensions.

Nine Network Model Principles

Kubernetes networking adheres to a set of principles:

Four basic principles (e.g., flat network, all pods reachable).

Three network‑requirement principles.

One architectural principle.

One IP‑address principle.

Key points of the IP‑per‑Pod model:

Each pod receives a unique IP address, assumed to be reachable from any other pod without NAT.

Pod IPs are the smallest address granularity; containers share the pod’s network stack.

Containers within the same pod communicate via localhost, similar to processes on a single VM.

No NAT is required for inter‑container communication.

The pod’s IP is visible both inside and outside the cluster.

The following diagrams illustrate the architecture, IP hierarchy, and network topology discussed above.