Understanding Kubernetes: Core Concepts, Architecture, and Key Components

1. Introduction

Kubernetes is an open‑source container‑orchestration platform originated from Google’s large‑scale container management system. It provides a unified API for deploying, scaling, and operating containerized workloads on public, private, or hybrid clouds, and is widely adopted by vendors such as Microsoft, VMware, Red Hat, CoreOS, and Mesos.

2. What is Kubernetes

Kubernetes manages clusters of Docker containers, offering:

Packaging, instantiating, and running applications with Docker.

Coordinated execution of containers across multiple hosts.

Cross‑host networking for container communication.

Self‑healing mechanisms that keep the desired number of replicas running.

Supported environments include Google Compute Engine, vSphere, CoreOS, OpenShift, Azure, and bare‑metal servers.

3. Core Concepts

3.1 Pods

A Pod is the smallest deployable unit. It groups one or more tightly coupled containers that share the same network namespace, IP address, port space, and volumes, and are scheduled onto the same node.

3.2 Services

Services expose a stable virtual IP and DNS name that abstracts a set of Pods. Clients access the Service without needing to know the underlying Pod IPs, and the Service routes traffic to matching Pods via label selectors.

3.3 Replication Controllers (now Deployments)

Replication Controllers ensure that a specified number of Pod replicas are always running. They create new Pods when the count falls below the target and delete excess Pods when it exceeds the target. Key capabilities:

Rescheduling – maintains replica count after node failures.

Horizontal scaling – adjusts the replica count on demand.

Rolling updates – replaces Pods incrementally to achieve zero‑downtime upgrades.

Multiple release tracks – distinguishes versions using labels.

3.4 Labels

Labels are key/value pairs attached to Pods, Services, and Controllers. They enable selection, grouping, and routing of resources, forming the basis for Service discovery and controller management.

4. Kubernetes Components

The control plane consists of kubectl (client), the API Server, Scheduler, and a set of registries stored in etcd. Worker nodes run Kubelet and Kube‑proxy.

4.1 Master (Control Plane)

The Master hosts the API Server, Scheduler, and the following registries (all persisted in etcd):

Minion Registry – tracks node objects; supports Create, Get, List, Delete.

Pod Registry – tracks Pods and their node bindings; supports full CRUD and a watch interface.

Service Registry – tracks Service objects; supports CRUD and watch.

Controller Registry – tracks Replication Controllers (or Deployments); supports CRUD and watch.

Endpoints Registry – stores Service endpoint IP:port pairs; supports CRUD and watch.

Binding Registry – write‑only API used by the Scheduler to bind a Pod to a specific node.

The Scheduler continuously watches for unscheduled Pods, evaluates node resource availability (CPU, memory), and writes a binding object back to the API Server to assign the Pod to a suitable node.

4.2 Kubelet

Kubelet runs on every worker node and acts as the bridge between the API Server and the node. Its responsibilities include:

Fetching Pod specifications from the API Server.

Creating and starting containers via the Docker runtime.

Mounting declared volumes into containers.

Setting environment variables for containers.

Exposing container ports as defined in the Pod spec.

Monitoring container health using liveness and readiness probes.

Collecting resource usage metrics from cAdvisor.

Reporting Pod status back to the API Server.

Executing commands inside containers on demand.

4.3 Proxy

Kube‑proxy runs on each node to implement Service networking. For each Service, it reads the Service and Endpoint definitions from etcd (or a local file) and starts a proxy process that listens on the Service’s port. Incoming TCP/UDP traffic is load‑balanced across the backend Pods according to the Endpoint list.