TL;DR: Kubernetes is driven entirely by its API in every component communicates through it to manage the cluster.

This post focuses on Kubernetes internal communication. Key technical terms will be highlighted in code blocks as we go.

What is Kubernetes?

In short, Kubernetes is an orchestrator for containerized workloads.

Before diving into orchestration, we need to clarify what containerized systems actually are. Unlike virtual machines (which virtualize full hardware), containers isolate processes at the OS level. They package an application and its dependencies together so it runs consistently across almost any Linux environment.

Kubernetes is separated into two parts: the control side and the work side.

Think of it like a busy seaport, where the harbor administrator acts as the Control Plane to direct all operations, while cranes schedule and move cargo containers onto the correct ships based on available space. At the same time, the loading docks and trucks handle the local transport, ensuring each cargo container lands on the right ship and receives traffic through the correct destination port.

With the analogy out of the way, let’s focus on the Control Plane first, followed by the components that power the Worker Nodes.

Control Plane

Kubenetes has 6 components.

  1. kubectl
  2. Controller
  3. Scheduler
  4. kubelet
  5. etcd
  6. API Server

kubectl is a client-side command-line tool that runs on your local computer or laptop. It makes HTTP/REST requests to the API Server.

kubelet is an agent that runs on every Worker Node to manage local containers.

This two are not in Control Plane.

For the Control Plane Components.

API Server (or kube-apiserver): Everything (including kubectl, controllers, and worker nodes) communicates exclusively through the API Server.

etcd (et cetera daemon named after the Unix /etc folder to reflect its role as a configuration store) is the cluster’s key-value database and single source of truth. It stores:

  • Cluster State & Configuration: Every object created in the cluster, including Pods, Services, and Deployments.
  • Kubernetes Secrets & ConfigMaps: Your application configuration and native Kubernetes Secret resources. For security reasons, native etcd secrets should be protected using a Key Management Service (KMS) or managed externally by syncing with a dedicated secret server.

Scheduler (kube-scheduler): Decides which worker node should run each newly created container/pod based on available resources.

Controller (kube-controller-manager): Runs background controller loops to continuously monitor the cluster and adjust actual state to match your desired state.

Option cloud-controller-manager: Connects your cluster to cloud provider APIs (like AWS, GCP, or Azure) to manage load balancers, storage volumes, and routing

Every piece of a Kubernetes ecosystem operates around one rule: all communication flows exclusively through the API Server (kube-apiserver). Components never talk directly to one another, nor do they touch etcd on their own. When you run a command using kubectl on your local machine, it sends a request to the API Server. The Control Plane components; such as the Scheduler and Controller Manager. Then watch the API Server to detect changes and update the cluster state accordingly. Down on the worker nodes, the kubelet constantly polls the API Server to fetch new pod assignments and report node health.

The only real exception to this central hub model happens at the application level on the worker nodes, where running containers send and receive network data directly to handle end-user traffic.

Back up and restore

etcd is the only Control Plane component that needs to be backed up, though persistent volume data for your applications must be backed up separatel.

In a production environment, you must run at least 3 Control Plane nodes to establish High Availability and maintain the etcd Raft consensus quorum if a node fails.

The API Server is the gatekeeper for everything. Whether you’re logging in, running a command, or asking for persistent storage. It checks etcd to verify your RBAC permissions, encrypts the payload, and saves the new state into etcd. From there, background controllers pick up the request and spin up external resources like storage.

The API Server relies on Role-Based Access Control (RBAC) to decide who can do what. While the RBAC security logic runs entirely inside the API Server, the actual permission rules (the Role and RoleBinding definitions) are stored as data inside etcd. When a request comes in, the API Server reads those rules from etcd, evaluates the permission, and approves or denies the action.

Back to Certified Cloud Native Platform Engineering Associate Preparation