Kubernetes Core Concepts: Pods, Nodes, Services, & Ingress

Kubernetes is an open-source, declarative container orchestration platform originally designed by Google (Borg) and maintained by the Cloud Native Computing Foundation (CNCF). It automates the provisioning, scheduling, horizontal scaling, networking, and self-healing of containerized applications across clusters of physical or virtual machines.

A production Kubernetes cluster is bifurcated into two primary planes:

1. The Control Plane (Master Nodes): Makes global decisions about the cluster (e.g., scheduling pods, detecting node failures).
2. Worker Nodes: Provide compute, memory, disk, and network resources to execute user container workloads.

The Control Plane maintains the declarative truth of the entire cluster:

• kube-apiserver (The Hub): The single stateless entrypoint for all cluster management. It exposes the Kubernetes REST API, handles authentication (X.509 certs, OIDC tokens), authorization (RBAC), and runs Admission Webhooks (Validating and Mutating). No component touches etcd directly except kube-apiserver.
• etcd (Distributed Consensus Store): A strongly consistent, distributed key-value store implementing the Raft consensus algorithm. It persists the desired and actual state of all cluster resources. A standard HA deployment runs 3 or 5 etcd replicas to tolerate 1 or 2 node failures.
• kube-scheduler: Watches for newly created pods without an assigned node. It evaluates candidates through two phases:
  1. Filtering (Predicates): Eliminates nodes lacking sufficient CPU/RAM requests, lacking required node labels, or matching node taints.
  2. Scoring (Priorities): Ranks qualifying nodes based on topology spread (spreading pods across Availability Zones) and resource balance, assigning the pod to the highest-scoring node.
• kube-controller-manager: Runs continuous reconciliation control loops (e.g., NodeController, ReplicaSetController, EndpointSliceController, ServiceAccountController). It continuously drives the actual cluster state toward the declared desired state.

Worker nodes execute container workloads and report health back to the control plane:

• kubelet: The primary node agent running as a system daemon. It registers the node with the API server, watches for PodSpecs assigned to its node, and instructs the container runtime via the CRI (Container Runtime Interface) (e.g., containerd, CRI-O) to launch or stop containers. It also executes periodic liveness, readiness, and startup health probes.
• kube-proxy: A network proxy running on each node that implements the Kubernetes Service abstraction:
  • iptables mode: Generates Linux netfilter NAT rules to randomly distribute traffic arriving at a Service Virtual IP (VIP) to healthy backend Pod IPs.
  • IPVS mode (IP Virtual Server): Utilizes Linux kernel IPVS hash tables for O(1) lookups, scaling cleanly to clusters with tens of thousands of services where iptables O(N) rule evaluation causes CPU latency.
• CNI (Container Network Interface): Implements flat, non-NAT pod-to-pod networking (e.g., AWS VPC CNI, Calico, Cilium with eBPF). Every pod receives a unique, routable IP address in the cluster CIDR.

A Pod is the smallest deployable compute unit in Kubernetes. A pod represents a single instance of a running process:

• A pod encapsulates one or more closely coupled containers sharing the same Network Namespace (same IP address, port space, and reachable via localhost) and shared Storage Volumes.
• The Sidecar Pattern: Running a helper container alongside the main application container within the same pod (e.g., an Envoy proxy for service mesh mTLS, a FluentBit agent for log shipping, or an OpenTelemetry collector).
• Init Containers: Specialized containers that execute sequentially to completion before the application containers start (e.g., executing database schema migrations or waiting for a cache to become reachable).

Pods are ephemeral; when a pod crashes or scales, it is replaced with a new pod with a completely new IP address. Kubernetes Services provide a permanent, stable network identity:

1. ClusterIP (Default): Assigns a permanent internal Virtual IP (VIP) and internal cluster DNS name (my-service.my-namespace.svc.cluster.local). Traffic sent to this VIP is load-balanced across healthy pods tracked by EndpointSlices.
2. NodePort: Exposes the service on a dedicated static port (range 30000-32767) across every worker node's physical IP address.
3. LoadBalancer: Integrates with cloud providers (AWS NLB, GCP Cloud LB) to automatically provision an external hardware/cloud load balancer that forwards public internet traffic to the cluster NodePorts.
4. Ingress & Ingress Controllers (Layer 7): An API object that manages external HTTP/HTTPS routing rules (Host-based api.example.com and Path-based /orders vs /users), TLS termination via cert-manager (Let's Encrypt), and rate limiting before routing traffic to internal ClusterIP Services.