Kubernetes Fundamentals · Module 01 of 14

Why Kubernetes? Architecture and the control loop

Understand why orchestration exists and how the API server, etcd, scheduler, controllers and kubelets cooperate to reconcile desired state.

Learning objectives

By the end of this module, you should be able to:

Explain the problem Kubernetes solves beyond running a single container.
Identify the major control-plane and node components.
Describe declarative desired state and reconciliation.

From containers to orchestration

Docker makes it practical to package and run containers on one host. Production systems then need placement, replacement, service discovery, configuration, rollout and scaling across many machines. Kubernetes provides an API-driven control plane for those concerns.

Kubernetes does not replace the container runtime. It coordinates workloads that a compatible runtime executes on cluster nodes.

The control plane

The API server is the front door to cluster state. etcd stores Kubernetes API data. The scheduler chooses nodes for unscheduled Pods, and controller managers run reconciliation loops that move actual state toward desired state.

kube-apiserver: validates and serves the Kubernetes API.
etcd: consistent key-value store for cluster API data.
kube-scheduler: selects a node for a Pod that has no node assignment.
kube-controller-manager: runs built-in controllers that reconcile resources.

The node

Each worker node runs kubelet, which watches Pod assignments and works with the container runtime to make containers run. kube-proxy or alternative dataplane implementations help realize Service networking depending on the cluster design.

Worked examples

See the idea in practice.

See the cluster from the API

kubectl cluster-info
kubectl get nodes -o wide
kubectl -n kube-system get pods

cluster-info shows control-plane endpoints exposed to your client.
Nodes report readiness and version information.
System Pods reveal the concrete implementation used by the lab cluster.

Hands-on lab

Lab — Map a real cluster

Goal: Identify the cluster, nodes and system workloads without changing anything.

Before you start

A working Kubernetes cluster is required. The included validation script can create an isolated kind v1.37 cluster for testing.

STEP 1

Check client and server versions

kubectl version

STEP 2

Inspect cluster endpoints

kubectl cluster-info

STEP 3

Inspect nodes

kubectl get nodes -o wide

STEP 4

Inspect system workloads

kubectl -n kube-system get pods -o wide

Verify

At least one node reports Ready.
kubectl can query the API server.
System workloads are visible in kube-system.

Expected outcome

Client and server information is returned.
The control-plane node in a local kind cluster normally carries the control-plane role label.

If it fails

If kubectl cannot connect, inspect kubectl config current-context and kubeconfig.
If a node is NotReady, inspect kubectl describe node and system Pods before continuing.

Real-world connection

Operators begin incidents by establishing cluster reachability and node/control-plane health before debugging an application.

Avoid these traps

Common mistakes

Thinking Kubernetes directly runs application binaries without a container runtime.
Editing etcd directly instead of using the Kubernetes API.
Treating desired state as a one-time script rather than continuously reconciled state.

Knowledge check

Can you explain it without looking back?

Open each answer only after you have tried to answer the question yourself.

1What component is the normal API entry point?

kube-apiserver.

2What chooses a node for a newly created unscheduled Pod?

kube-scheduler.

3What does reconciliation mean?

Controllers repeatedly compare desired and observed state and act to reduce the difference.