Mastering Kubernetes: Core Concepts, Architecture, and Networking Essentials

Goal: Container Operations

Kubernetes (k8s) is an open‑source platform that automates container deployment, scheduling, and scaling across a cluster of nodes.

Key Functions

Automated container deployment and replication.

Real‑time elastic scaling of container workloads.

Container orchestration with built‑in load balancing.

Core Components

kubectl : Command‑line client that serves as the primary entry point for cluster operations.

kube‑apiserver : Exposes a RESTful API used by all control‑plane components and external tools.

kube‑controller‑manager : Runs background controllers (node controller, replication controller, endpoint controller, etc.) that maintain desired state.

kube‑scheduler : Assigns newly created Pods to nodes based on resource availability, taints/tolerations, and affinity rules.

etcd : Distributed, strongly consistent key‑value store that holds cluster configuration, service‑discovery data, and state.

kube‑proxy : Runs on each node, implements Service virtual IPs and load‑balances traffic to backend Pods using iptables or IPVS.

kubelet : Node‑level agent that receives Pod specifications, starts/stops containers via the container runtime, and reports node health to the apiserver.

DNS (optional) : Adds a cluster‑wide DNS service (CoreDNS/kube‑dns) that creates DNS records for Services, enabling name‑based discovery.

Two‑Location Three‑Center Architecture

This deployment model consists of a local production center, a local disaster‑recovery (DR) center, and a remote DR center. Data consistency across the three sites is achieved by using etcd as a highly available, strongly consistent service‑discovery store backed by the Raft consensus algorithm.

Simple: HTTP + JSON API usable with curl.

Secure: Optional mutual TLS client authentication.

Fast: Each etcd member can handle up to 1,000 writes per second.

Trusted: Raft ensures robust distributed consistency.

Four‑Layer Service Discovery

Kubernetes provides two native mechanisms for discovering Services:

Environment variables : When a Pod is created, kubelet injects environment variables for every Service that already exists. Example for a Service redis‑master with ClusterIP:Port 10.0.0.11:6379:

REDIS_MASTER_SERVICE_HOST=10.0.0.11
REDIS_MASTER_SERVICE_PORT=6379

DNS : Deploying the kube-dns (or CoreDNS) add‑on creates a DNS service that resolves <service-name>.<namespace>.svc.cluster.local to the Service’s ClusterIP.

Five Types of Pod Shared Resources

A Pod groups one or more tightly coupled containers that share Linux namespaces and a volume. The shared resources are:

PID namespace – containers see each other’s process IDs.

Network namespace – containers share the same IP address and port range.

IPC namespace – containers can use SystemV IPC or POSIX message queues.

UTS namespace – containers share a hostname.

Volumes – containers can access storage defined at the Pod level.

Pod lifecycle is managed by higher‑level controllers such as Deployments or ReplicaSets. When all containers in a Pod terminate, the Pod is removed.

Six Common CNI Plugins

The Container Network Interface (CNI) defines a standard for configuring container networking. Six widely used plugins are illustrated below (e.g., Calico, Flannel, Weave, Cilium, Contiv, and SR‑IOV). They provide different networking models such as overlay, underlay, and network policy enforcement.

Seven‑Layer Load Balancing

Kubernetes exposes Services at different OSI layers:

Layer 2 – MAC‑address based balancing (rare in k8s).

Layer 3 – IP‑address based balancing (e.g., external load balancers).

Layer 4 – IP + port balancing (NodePort, kube-proxy IPVS mode).

Layer 7 – HTTP/HTTPS URL‑based balancing using Ingress controllers (NGINX, HAProxy, Envoy).

Eight Isolation Dimensions

Kubernetes scheduling respects isolation policies ranging from coarse‑grained (node pools, zones) to fine‑grained (pod affinity/anti‑affinity, taints, tolerations, security contexts). These dimensions guide the placement of Pods across the cluster.

Nine Network Model Principles

Kubernetes networking follows a set of principles:

Every Pod receives a unique IP address; all Pods reside in a flat, routable network.

IP‑per‑Pod model: containers in the same Pod share a network stack, enabling localhost communication.

Pod IPs are visible both inside and outside the cluster, eliminating the need for NAT between Pods.

Service abstraction provides stable virtual IPs (ClusterIP) and optional external access via NodePort, LoadBalancer, or Ingress.

Ten Classes of IP Addresses

In addition to the traditional A‑E classes, there are five special‑purpose ranges used for private networking, loopback, multicast, and link‑local addressing.

A class: 1.0.0.0‑122.255.255.255, default mask /8 (255.0.0.0)
B class: 128.0.0.0‑191.255.255.255, default mask /16 (255.255.0.0)
C class: 192.0.0.0‑223.255.255.255, default mask /24 (255.255.255.0)
D class: 224.0.0.0‑239.255.255.255, used for multicast
E class: 240.0.0.0‑255.255.255.255, research use

0.0.0.0 – default route (unspecified address)
127.0.0.1 – loopback address
224.0.0.1 – multicast address (used with IRDP)
169.254.x.x – link‑local (APIPA) address when DHCP fails
10.x.x.x, 172.16‑31.x.x, 192.168.x.x – private address spaces