What Is Kubernetes? A Beginner’s Guide to Core Concepts and Components

Kubernetes Overview

Kubernetes is an open‑source container‑cluster management system originally developed by Google, providing deployment, maintenance, and scaling mechanisms for containerized applications across machines. It runs on platforms such as GCE, vSphere, CoreOS, OpenShift, Azure, or directly on physical hosts.

Example:

OpenStack manages virtual machines (KVM, Xen, VMware, etc.).

Kubernetes manages containers (Docker).

Kubernetes Concepts (Roles)

Pod A Pod is the smallest operational unit in Kubernetes, consisting of one or more containers that share the same volumes and network namespace, and must run on the same host.

ReplicationController (RC) RC manages Pods, ensuring the number of available Pods matches the desired count. It creates Pods from a template, can modify Pod attributes dynamically, and uses labels to associate or delete Pods.

Label Labels are key/value pairs used to distinguish Pods, Services, and RCs; multiple labels can be attached, but each key is unique.

Service A Service abstracts a set of Pods, providing a stable IP address and load‑balancing across the Pods. It presents a single access point to external clients without exposing the underlying Pod details.

Kubernetes Components

Kubernetes components are similar to OpenStack, consisting of various roles that together support the system. Main components include kubectl, kube-apiserver, kube-controller-manager, kube-scheduler, kube-proxy, kubelet , plus the data store etcd and optional network service Flannel .

Comparison with OpenStack Components

kubectl ↔ nova/glance/neutron/cinder (client CLI tools)

kube-apiserver ↔ nova‑api (REST API service)

kube-controller-manager ↔ keystone (multiple controllers)

kube-scheduler ↔ nova‑scheduler (task scheduling)

kube-proxy ↔ iptables (network proxy/forwarding)

kubelet ↔ nova‑compute (container/VM management)

etcd ↔ MySQL (information storage)

flannel ↔ dnsmasq (IP address allocation)

Kubectl

A command‑line tool that formats received commands and sends them to kube‑apiserver, serving as the entry point for platform operations.

Kube‑apiserver

The control entry point of the system, exposing a REST API that can be horizontally scaled for high availability.

Kube‑controller‑manager

Executes background tasks and aggregates multiple controller processes, including:
- Node Controller: handles node up/down status.
- Replication Controller: maintains the desired number of Pods.
- Endpoints Controller: maintains Pod‑Service relationships.
- Service Account & Token Controllers: creates default accounts and API tokens for new namespaces.

Kube‑scheduler

Monitors newly created Pods and assigns them to suitable nodes for execution.

Kube‑proxy

Runs on each node, managing network rules and forwarding to make Services appear as abstracted entities.

Kubelet

Runs on each node as an agent, monitoring assigned Pods, mounting volumes, downloading secrets, running containers via Docker, and reporting status back to the REST system.

Diagram illustrating the architecture:

Pod

A group of applications sharing context, possibly isolated by cgroups, forming a logical host that can contain one or more containers. All containers in a Pod run on the same physical or virtual host.

Pod context combines Linux namespaces, including:

pod namespace (process visibility)
network namespace (shared IP and ports)
ipc namespace (SystemV IPC or POSIX message queues)
uts namespace (shared hostname)

Resource Sharing and Communication

All applications in a Pod share the same network namespace, allowing them to discover and communicate via localhost. Each Pod receives a unique IP address for inter‑node and cross‑network container communication.

Pods serve as the smallest deployable unit, supporting horizontal scaling and replication.