Skip to main content
In this lesson we’ll cover the core concepts you need to get started with Kubernetes: how it differs from running a single Docker container, the control plane and node architecture, how containers are scheduled and run, and the primary CLI commands you’ll use day-to-day. Kubernetes is a powerful container orchestration system that manages containers at scale. While a full Kubernetes curriculum could span multiple courses, this introduction will equip you with the vocabulary and mental model to begin deploying and operating applications on a cluster.

​
From Docker to Kubernetes: single instance vs. many replicas

With Docker you can run a single instance of an application using docker run. Kubernetes extends that idea so you can declare the desired state (the container image, number of replicas, update strategy, etc.) in a Deployment, and Kubernetes automatically makes reality match that desired state across the cluster. Example: start one container with Docker:
Create a Deployment that schedules many replicas with kubectl:
Be mindful of cluster capacity and resource limits. Kubernetes will attempt to schedule the specified number of replicas and can fail or become unstable if the cluster lacks resources.
Kubernetes supports scaling (manual and automatic), rolling updates, rollbacks, and progressive deployment strategies (canary, A/B testing). For automatic scaling: the Horizontal Pod Autoscaler (HPA) scales pods based on metrics, while the Cluster Autoscaler adjusts node count to match scheduling needs.

​
Kubernetes cluster architecture — control plane and nodes

A Kubernetes cluster is a set of machines called nodes. Each node is a physical or virtual machine that runs containers. To tolerate node failures you run multiple nodes; together they form a cluster. The cluster is managed by the control plane (also called the master). The control plane components track cluster state, make scheduling decisions, and react to failures.
A diagram titled "Kubernetes Architecture" showing the Kubernetes control plane (master) at the top and three worker nodes (node-1, node-2, node-3) below, each containing container boxes.

​
Control plane components

The main control-plane components you’ll encounter are:
  • API server — the front end for the control plane; all clients and tools (including kubectl) interact with the cluster via the API server.
  • etcd — a distributed key-value store that persists cluster state (nodes, pods, configs) reliably.
  • Scheduler — assigns new Pods to nodes based on resource requests, constraints, and available capacity.
  • Controllers — reconciliation loops that observe the current state and take actions to reach the desired state (e.g., replacing failed Pods).
A diagram titled "Control Plane Components" showing four labeled boxes: api-server, etcd, scheduler, and controllers, each with a short description of their roles. It visually explains the Kubernetes control plane components and their responsibilities.

​
Node components

Each worker node runs:
  • kubelet — an agent that registers the node with the control plane and ensures containers described in Pods are running and healthy.
  • Container runtime — the software that actually runs containers (commonly containerd or CRI‑O).
  • Optionally: kube-proxy or other networking components to implement Services and network rules.
An infographic titled "Inside a Node" showing the kubelet agent that runs on each Kubernetes node and ensures containers are running. Below it the container runtime layer is shown with examples like containerd and CRI‑O.

​
How Kubernetes interacts with container runtimes (Docker and CRI)

Kubernetes communicates with container runtimes through the Container Runtime Interface (CRI). Historically, many nodes used Docker Engine, and Kubernetes relied on a shim (dockershim) or an external cri-dockerd bridge to talk to Docker. Since Kubernetes v1.24 (April 2022) dockershim was removed from the core codebase, so Kubernetes no longer includes native Docker Engine support; cri-dockerd can still be used where Docker compatibility is required. Important details:
  • Docker Engine itself delegates container execution to containerd (and containerd uses runc). Kubernetes can talk directly to containerd or other CRI-compliant runtimes, so the removal of dockerd did not stop workloads from running.
  • Common CRI runtimes: containerd, CRI‑O. If you need Docker Engine compatibility, use the external cri-dockerd adapter.
A diagram titled "Docker on Kubernetes" showing the kubelet connecting through the Container Runtime Interface (CRI) to runtimes like containerd and CRI-O, plus a cri-dockerd shim to Docker. A footer notes direct Docker support was removed in Kubernetes v1.24 (April 2022).

​
kubectl — the Kubernetes CLI

kubectl is the primary command-line tool used to interact with a cluster: deploy applications, inspect resources, and perform cluster administration tasks. Common kubectl commands: Example interactive session:
This shows how a single command can launch many instances of your application across the cluster and how kubectl surfaces the cluster state.

​
Quick summary

  • Kubernetes runs and manages containers at scale using a control plane (API server, etcd, scheduler, controllers) and multiple worker nodes.
  • Deployments declare the desired state (image, replicas, update policy); controllers reconcile actual state to match desired state.
  • Use kubectl to inspect and manage the cluster.
  • Kubernetes talks to container runtimes via the CRI; Docker Engine requires an adapter for compatibility in modern clusters.
Courses available on our platform:

Watch Video