Cluster architecture and a local setup

What the control plane and the nodes actually do, why the API server is the only door in, and how to stand up a real cluster on a laptop.

Two halves of every cluster

A Kubernetes cluster is a set of machines split into a control plane that holds the desired state and makes decisions, and worker nodes that run your containers. Nothing on a node is smart: the node reports what it sees to the control plane, and the control plane tells it what to do.

Component	Where	Job
`kube-apiserver`	Control plane	The only entry point. Authenticates, authorises, runs admission, then writes to etcd
`etcd`	Control plane	The key-value store holding every object. Lose it and you lose the cluster
`kube-scheduler`	Control plane	Picks a node for each new pod by filtering and scoring candidates
`kube-controller-manager`	Control plane	Runs the reconcile loops: Deployments, ReplicaSets, Jobs, endpoints
`kubelet`	Every node	Starts and monitors containers, reports pod status back
`kube-proxy`	Every node	Programs the routing rules that make Service IPs work
Container runtime	Every node	containerd or CRI-O, the thing that actually spawns processes
CNI plugin	Every node	Assigns pod IPs and wires pod-to-pod networking

The whole system is a reconciliation loop. Controllers watch objects, compare the observed state with the declared state, and take action. You never run a command that "makes" three pods exist; you declare three and the control unit converges.

Everything talks to the API server

kubectl, the kubelet, the schedulers and every operator are all clients of the same REST API. Only the API server speaks to etcd. That single choke point is where authentication, authorisation and admission live, which is why RBAC and audit logs are the core of cluster security.

kubectl cluster-info                 # which cluster am I even talking to
kubectl version                      # client and server versions
kubectl config current-context
kubectl get nodes -o wide            # kubelet version, IPs, runtime
kubectl get --raw='/readyz?verbose'  # control plane component health
kubectl api-resources                # every kind the server knows, and its scope

Objects are addressed as group/version, kind. kubectl explain reads the schema the server itself publishes.
Controllers use a list-watch: they stream changes instead of polling, so the loop reacts in milliseconds.
A node showing NotReady is usually a kubelet or CNI problem, not a control plane problem — check describe node events.
On a managed cluster you cannot see most of these components. The API stays identical, so nothing you learn changes.

A real cluster on your laptop

You do not need a cloud account to learn Kubernetes. The main options differ in how many virtual machines and features they give you.

Tool	How it runs	Pick it when
`kind`	Each node is a Docker container	Fastest to create and delete; supports multi-node and CI
`minikube`	One VM or container, optional addons	You want ingress, storage and dashboard addons for free
Docker Desktop	One node inside its VM	You already run it and want a cluster with a checkbox
`k3s` / `k3d`	Lightweight single binary	Small machines, or a realistic remote node

kind create cluster --name dev
kubectl config current-context          # kind-dev
kubectl config get-contexts             # every cluster your kubeconfig knows
kubectl get nodes

kind get clusters
kind create cluster --name dev --config - <<'EOF'
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
  - role: control-plane
  - role: worker
  - role: worker
EOF

kubectl config use-context kind-dev
kind delete cluster --name dev

# kubeconfig lives at $KUBECONFIG or ~/.kube/config
export KUBECONFIG=~/.kube/config:~/.kube/kind-dev
kubectl config set-context --current --namespace=dev
kubectl config view --minify          # just the context you are using

💡

The most common self-inflicted outage while learning is applying manifests to the wrong cluster. Put the context in your shell prompt, or run kubectl config current-context before anything destructive.

FAQ

Do I need more than one node locally?

No, and one node is much faster to create. Use a multi-node kind cluster only when you are testing something node-specific: DaemonSets, taints, topology spread or pod anti-affinity.

Is a local cluster the same as production?

The API, the manifests and most behaviour are identical. What differs is the storage driver, the load balancer (there is none, so LoadBalancer services stay pending), the CNI, and the absence of real failure domains.

kubectl fundamentals and writing manifests Labels, selectors, namespaces and annotations

Last refreshed 2026-09-18.

Cluster architecture and a local setup

Two halves of every cluster

Everything talks to the API server

A real cluster on your laptop

FAQ

Related