Kubernetes from the Inside: Cluster Architecture Basics

Kubernetes is usually learned from the application side: Deployments, Services, ConfigMaps, Helm charts and YAML manifests. That is natural, because this is what developers work with most of the time.

This series goes the other way.

Instead of asking:

How do I deploy an application to Kubernetes?

we ask:

What actually makes a Kubernetes cluster work?

So we focus on the parts we usually don't create ourselves, but which keep working in the background all the time:

• kube-apiserver,
• etcd,
• kube-scheduler,
• kube-controller-manager,
• kubelet,
• container runtime,
• CNI,
• kube-proxy,
• CoreDNS.

On top of that come two very important splits:

• control plane vs data plane,
• managed vs self-managed Kubernetes.

At the end we will also look at where such a cluster can run: in the public cloud, on-premises, on virtual machines or directly on bare metal.

The goal of this series is not to describe the whole Kubernetes ecosystem. We won't go deep into application workloads, operators, observability or advanced storage.

The point is to build a solid mental model: what is part of the cluster, what each main component is responsible for and how these pieces work together.

If you use Kubernetes every day, but names like etcd, kubelet or kube-proxy are mostly something that "is just there", this series should put that picture in order.