Kubernetes architecture: control plane, nodes, pods and services
In short: Kubernetes runs containers across a cluster by constantly matching the actual state to a desired state you declare. The control plane (API server, etcd, scheduler and controllers) decides; worker nodes run pods. Almost every security control passes through the API server, which makes it the centre of cluster security.
What Kubernetes does
Kubernetes (often written K8s) is an orchestrator: you describe what you want, such as "three copies of this web app, reachable on port 443", and it keeps the cluster in that state, restarting failed containers and moving work when nodes fail. You describe the desired state in YAML manifests and send them to the cluster with kubectl or a deployment tool.
Managed services such as Amazon EKS, Azure AKS and Google GKE run the control plane for you, but you are still responsible for workloads, access and most configuration under the shared responsibility model.
Control plane and nodes
| Component | Role | Security note |
|---|---|---|
| kube-apiserver | Front door; every change goes through it | Restrict network access; authenticate and authorise every call |
| etcd | Key-value store holding all cluster state, including Secrets | Encrypt, restrict to API server only, back up securely |
| kube-scheduler | Chooses which node runs each pod | Can be steered with node selectors and taints for isolation |
| controller-manager | Runs loops that reconcile desired and actual state | Uses powerful credentials; protect its configuration |
| kubelet | Agent on each node that starts pods | Disable anonymous access; its API must not be open |
| Container runtime | containerd or CRI-O runs the containers | Keep patched; apply runtime restrictions |
Workload objects
- Pod: the smallest unit, one or more containers sharing a network address and volumes.
- Deployment: keeps a set number of identical pods running and handles rolling updates.
- Service: a stable virtual IP and DNS name in front of a changing set of pods. Types include ClusterIP (internal), NodePort and LoadBalancer.
- Ingress or Gateway: routes external HTTP(S) traffic to services, often terminating TLS.
- Namespace: a logical grouping for teams or apps; RBAC, quotas and policies are often scoped by namespace.
- ConfigMap and Secret: configuration and sensitive values supplied to pods.
kubectl get nodes -o wide
kubectl get pods -A
kubectl describe deployment web -n shop
kubectl get svc -n shopWhere security fits
Every request to the API server passes three gates in order: authentication (who are you, using certificates, tokens or OIDC), authorisation (usually RBAC) and admission control (policy checks that can reject or modify objects, such as Pod Security admission). Requests that pass are written to etcd and recorded in audit logs.
Beyond the API server, you secure pod-to-pod traffic with network policies, protect stored secrets in etcd and harden nodes. Note that namespaces are an organisational boundary, not a strong security boundary on their own: pods in different namespaces can talk freely unless network policies say otherwise.
Tip: a good first lab is minikube on your own machine. Explore each component with kubectl get pods -n kube-system.
Practice
Which component stores all cluster state, and why is it sensitive?
What are the three checks an API request passes before it is stored?
Are namespaces enough to isolate two teams?
Key takeaways
- Kubernetes reconciles actual state to the desired state you declare.
- The control plane is the API server, etcd, scheduler and controllers.
- Nodes run pods using the kubelet and a container runtime.
- Every API request is authenticated, authorised and admission-checked.
- Namespaces organise; network policies and RBAC isolate.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.