What Is Kubernetes Architecture? – Components Overview

Kubernetes is an open-source container orchestrator that automates container deployment, scaling, and administration tasks. It provides helpful abstraction layers for running containerized workloads in production.

Kubernetes is a distributed system. It horizontally scales containers across multiple physical hosts termed Nodes. This produces fault-tolerant deployments which adapt to conditions such as Node resource pressure, instability, and elevated external traffic levels. If one Node suffers an outage, Kubernetes can reschedule your containers onto neighboring healthy Nodes.

The system provides auto-scaling functionality that changes deployment replica counts automatically as load grows. Managed Kubernetes services such as Google GKE and Amazon EKS support dynamic Node creation too. This helps you ride out traffic spikes by dynamically increasing your cluster’s capacity without requiring manual intervention.

All this functionality means the Kubernetes architecture is relatively complex. Several different components work together to create a functioning cluster. In this article, we’ll look at each major item in turn so you can better understand how Kubernetes works.

Kubernetes aims to lower the management overhead of running fleets of containers in production. It achieves this by pooling multiple compute Nodes into one logical platform termed a “cluster.” Deploying workloads to your Kubernetes cluster automatically starts containers on one or more of the Nodes.

1) Workloads

Kubernetes includes several abstraction layers that you use to define your application. Here are some of the most common workload objects you’ll encounter:

• Pod – Pods are the fundamental compute unit in Kubernetes. A Pod is a group of one or more containers that share the same specification. All the containers in the Pod are scheduled to the same host.
• Deployment – A Deployment wraps the lower-level ReplicaSet object. It guarantees a certain number of replicas of a Pod will be running in your cluster. Deployments also provide declarative updates for Pods; you describe the desired state, and the Deployment will automatically add, replace, and remove Pods to achieve it.
• Service – Services expose Pods as a network service. You use services to permit access to Pods, either within your cluster via automatic service discovery, or externally through an Ingress. (Read more: What is a Kubernetes Service?)
• Job – A Job starts one or more Pods and waits for them to successfully terminate. Kubernetes also provides CronJobs to automatically create Jobs on a recurring schedule.

There are other kinds of workload too, such as DaemonSets and StatefulSets. DaemonSets replicate a Pod to every Node in your cluster, while StatefulSets provide persistent replica identities.

See StatefulSet vs. Deployment.

2) Control Plane

The Kubernetes Control Plane is your cluster’s management surface. It stores the cluster’s state, monitors for changes, and applies any actions that are required. Actions could be initiated by users via the API or in response to Node events, such as increased memory pressure.

The control plane gets created automatically when you deploy a cluster. It often runs on a dedicated Node, ensuring it’s isolated from your workloads for maximum performance and security. This is not mandatory, though – the machine that runs the control plane can also be used as a regular Node.

The control plane is a collective term for many different components. Together they provide everything needed to administer your cluster but not actually start and run containers. Those functions are provided by Node-level software, which we’ll see in the next section.

API Server (kube-apiserver)

The API server is the control plane component that exposes the Kubernetes REST API. You’re using this API whenever you run a command with Kubectl. You’ll lose management access to your cluster when the API server fails, but your workloads won’t necessarily be affected.

Controller Manager (kube-controller-manager)

Much of Kubernetes is built upon the controller pattern. A controller is a loop that continually monitors your cluster and performs actions when certain events occur. The Deployment controller launches new Pods when you create a Deployment object, for example.

The controller manager oversees all the controllers in your cluster. It starts their processes and ensures they’re operational the whole time that your cluster’s running.

Scheduler (kube-scheduler)

The scheduler is responsible for placing newly created Pods onto the Nodes in your cluster. The scheduling process works by first filtering out Nodes that can’t host the Pod, then scoring each eligible Node to identify the most suitable placement.

Nodes could be filtered out because of insufficient CPU or memory, inability to satisfy the Pod’s affinity rules, or other factors such as being cordoned for maintenance. The scoring process prioritizes Pods that satisfy non-mandatory conditions like preferred affinities. If several Nodes appear to be equally suitable, Kubernetes will try to evenly distribute your Pods across them.

Etcd

Etcd is a distributed key-value storage system. Kubernetes stores your cluster’s state within etcd. It holds every API object, including config values and sensitive data you store in ConfigMaps and Secrets.

Etcd is the most security-critical control plane component. Successfully compromising it would permit full access to your Kubernetes data. It’s important that etcd receives adequate hardware resources, too, as any starvation can affect the performance and stability of your entire cluster.

Cloud Controller Manager

The Cloud Controller Manager integrates Kubernetes with your cloud provider’s platform. It facilitates interactions between your cluster and its outside environment. This component is involved whenever Kubernetes objects change your cloud account, such as by provisioning a load balancer, adding a block storage volume, or creating a virtual machine to act as a Node.

3) Nodes

Nodes are the physical or virtual machines that host the Pods in your cluster. Although it’s possible to run a cluster with a single Node, production environments should include several so you can horizontally scale your resources and achieve high availability.

Nodes join the cluster using a token that’s issued by the control plane. Once the Node’s been admitted, the control plane will start scheduling new Pods to it. Each Node runs several software components to start containers and maintain communication with the control plane.

Learn how to delete Pods from a Kubernetes Node.

Kubelet

Kubelet is the Node-level process that acts as the control plane’s agent. It periodically checks in with the control plane to report the state of the Node’s workloads. The control plane can reach out to Kubelet when it wants to schedule a new Pod onto the Node.

Kubelet’s also responsible for running Pod containers. It will pull the images required by newly scheduled Pods, then start containers to produce the desired state. Once the containers are up, Kubelet monitors them to ensure they remain healthy.

Read more about Kubernetes Image Pull Policy.

Kube-Proxy

The kube-proxy component facilitates network communications between the Nodes in your cluster. It automatically applies and maintains networking rules so that Pods exposed by Services are able to reach each other. If kube-proxy fails, Pods on that Node won’t be reachable over the network.

Container Runtime

Each Node requires a CRI-compatible runtime so it can start your containers. The containerd runtime is the most popular option, but alternatives such as CRI-O and Docker Engine can be used instead. The runtime uses operating system features such as cgroups to achieve containerization.

Below you can find an example of the Kubernetes architecture diagram:

Kubernetes is highly extensible, so you can customize it to suit your environment. Although the control plane and Node-level software stacks are the most important, several other aspects of the architecture are significant too.

Networking

Kubernetes networking uses a plugin-based approach. A CNI-compatible networking plugin must be installed to allow Pods to reach each other. Most popular Kubernetes distributions include a plugin for you, but you’ll have to manually install a solution such as Calico or Flannel when you deploy a cluster from scratch.

Storage

Storage provisioning can work very differently depending on your cloud provider. Storage Classes provide a consistent interface for accessing different types of storage in your workloads. You can add storage classes to save data to different platforms, such as a local volume on a Node’s filesystem or your cloud platform’s block storage volumes.

Kubernetes also has an external dependency on a container registry. You’ll need somewhere central to store your container images. You can run a registry inside your cluster, but this is not included with the default Kubernetes distribution.

Custom Functionality

You can add your own Kubernetes abstractions with custom resource definitions (CRDs). CRDs extend the API with support for your own data structures.

You can build the functionality around your CRDs by writing controllers and operators. These facilitate advanced automated workflows, such as automatically provisioning a database when you add a PostgresDatabaseConnection object to your cluster. They use the same fundamental concepts as built-in functionality: you author a control loop that watches for new objects and performs tasks when they occur.

Complexity and many moving parts create the potential for security problems. Hardening Kubernetes is a substantial topic: while the system purports to be production-ready, in practice, you need to take several manual actions to fully protect yourself.

Enabling etcd encryption is one essential step. Your cluster’s data isn’t encrypted by default so passwords and certificates in secrets are stored in plain text. It’s also important to secure the API server, avoid running other software on your Nodes, and ensure you use features like networking policies to fully isolate your workloads from each other. You can learn how to strengthen your cluster in our Kubernetes security guide.

Kubernetes requires the control plane components to remain available at all times. While the system is naturally resilient to Node failures, a problem in the control plane will affect the whole system. Its central role makes it a potential weak point in the architecture.

You can mitigate this risk by running multiple replicas of each component. This produces a highly available control plane that’s distributed across several Nodes, similarly to your Pods. It takes more time to set up but provides additional safety for production clusters. If you’re using a managed Kubernetes service, check with your provider to see if a high-availability control plane option is available.

If you need more help managing the complexities and compliance challenges of using Kubernetes check out Spacelift. It brings with it a GitOps flow, so your Kubernetes Deployments are synced with your Kubernetes Stacks, and pull requests show you a preview of what they’re planning to change. It also has an extensive selection of policies, which lets you automate compliance checks and build complex multi-stack workflows. You can also use Spacelift to mix and match Terraform, Pulumi, AWS CloudFormation, and Kubernetes Stacks and have them talk to one another. Find out more about how Spacelift works with Kubernetes.

Kubernetes is a complete platform for deploying, scaling, and managing distributed systems using containers. With powerful functionality comes to a complex and potentially confusing architecture. Kubernetes clusters are formed from several pieces, each assigned its own vital role.

In this article, you’ve learned how the fundamental components, such as Kubelet, kube-scheduler, etcd, and the API server combine to create an operational cluster. You can now continue your Kubernetes journey by deploying your own environment, either from scratch with Kubeadm or using a managed cloud service such as Amazon EKS, Google GKE, or DigitalOcean DOKS. You can get all the information you need to use Kubernetes in our beginners guide, or try some of the advanced topics elsewhere on our blog.