Introduction to Kubernetes architecture

Highlights

• Kubernetes architecture is based on a control plane / worker node model.
• A Kubernetes cluster should be secure, easy-to-use, and extendable.
• A cluster has two parts: the control plane that makes global decisions and the nodes which run applications.
• Out of the box, Kubernetes doesn't include a method for pods on different nodes to talk to each other, a way to route internet traffic inside, or a way to easily view logs.
• Kubernetes offers the tools to orchestrate a large and complex containerized application, but it also leaves many decisions up to you.

What is Kubernetes architecture?

Kubernetes architecture is based on a control plane / worker node model. It splits a cluster into two primary layers: the control plane, which makes global decisions and manages the cluster, and the worker nodes, which physically run your applications inside containers.

If you know only the basics of Kubernetes, you know it’s an open source container orchestration platform designed for running distributed applications and services at scale. But you might not understand its components and how they interact.

Let’s take a brief look at the design principles that underpin Kubernetes, then explore how the different components of Kubernetes work together.

The design of a Kubernetes cluster is based on 3 principles, as explained in the Kubernetes implementation details.

A Kubernetes cluster should be:

• Secure. It should follow the latest security best-practices.
• Easy to use. It should be operable using a few simple commands.
• Extendable. It shouldn’t favor one provider and should be customizable from a configuration file.

A working Kubernetes deployment is called a cluster. You can visualize a Kubernetes cluster as two parts: the control plane and the compute machines, or nodes. Each node is its own Linux® environment, and could be either a physical or virtual machine. Each node runs pods, which are made up of containers.

This diagram shows how the parts of a Kubernetes cluster relate to one another:

The Kubernetes control plane is the "brain" of your cluster. It makes global decisions (like scheduling applications), detects and responds to cluster events, and ensures that the actual state of your cluster matches the desired state you've declared.

Within the Kubernetes control plane are the components that control the cluster, along with data about the cluster’s state and configuration. These core Kubernetes components handle the important work of making sure your containers are running in sufficient numbers and with the necessary resources. 

The control plane is in constant contact with your compute machines. You’ve configured your cluster to run a certain way. The control plane makes sure it does.

kube-apiserver

The Kubernetes API is the front end of the Kubernetes control plane, handling internal and external requests. The API server determines if a request is valid and, if it is, processes it. You can access the API through REST calls, through the kubectl command-line interface, or through other command-line tools such as kubeadm.

kube-scheduler

The scheduler considers the resource needs of a pod, such as CPU or memory, along with the health of the cluster. Then it schedules the pod to an appropriate compute node.

kube-controller-manager

Controllers take care of actually running the cluster, and the Kubernetes controller-manager contains several controller functions in one. One controller consults the scheduler and makes sure the correct number of pods is running. If a pod goes down, another controller notices and responds. A controller connects services to pods, so requests go to the right endpoints. And there are controllers for creating accounts and API access tokens.

etcd

Configuration data and information about the state of the cluster lives in etcd, a key-value store database. Fault-tolerant and distributed, etcd is designed to be the ultimate source of truth about your cluster.

While the control plane acts as the brain, the Kubernetes worker nodes are the muscle—they do the actual heavy lifting of running your applications.

A Kubernetes node can be a physical machine or a virtual machine (VM). What happens inside a node is a continuous cycle of receiving instructions from the control plane, running containers, managing networking, and reporting health status back.

A Kubernetes cluster needs at least one compute node, but will normally have many. Pods are scheduled and orchestrated to run on nodes. Need to scale up the capacity of your cluster? Add more nodes.

Pods

A pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of an application. Each pod is made up of a container or a series of tightly coupled containers, along with options that govern how the containers are run. Pods can be connected to persistent storage in order to run stateful applications.

Container runtime engine

To run the containers, each compute node has a container runtime engine. Docker is one example, but Kubernetes supports other Open Container Initiative-compliant runtimes as well, such as rkt and CRI-O.

kubelet

Each compute node contains a kubelet, a tiny application that communicates with the control plane. The kublet makes sure containers are running in a pod. When the control plane needs something to happen in a node, the kubelet executes the action.

kube-proxy

Each compute node also contains kube-proxy, a network proxy for facilitating Kubernetes networking services. The kube-proxy handles network communications inside or outside of your cluster—relying either on your operating system’s packet filtering layer, or forwarding the traffic itself.

Once you have the control plane and the worker nodes, you technically have a Kubernetes cluster. However, it’s completely naked. Out of the box, Kubernetes doesn't actually include a way for pods on different nodes to talk to each other, a way to route internet traffic inside, or a way to easily view logs.

To make a cluster production-ready, you need to install add-ons and supporting infrastructure.

1. Networking: Kubernetes requires a virtual network overlay so pods can seamlessly communicate across different nodes. A Container Network Interface (CNI) plugin like Cilium or Calico must be installed to create this network layer and assign unique IP addresses to every pod.
2. Ingress controller: Internal traffic is handled automatically but you must have a gateway to let external traffic in. An Ingress Controller, such as NGINX or Traefik, acts as a reverse proxy and load balancer that securely routes external internet traffic to the correct services inside your cluster.
3. Cluster DNS: Because pods constantly change IP addresses when they restart, you cannot hardcode network paths. A cluster DNS provider (typically CoreDNS) automatically maps permanent domain names to your services, ensuring your applications can always locate one another.
4. Storage provisioner: Containers are stateless by nature, meaning any data they hold is wiped out if they crash. A Container Storage Interface (CSI) links your cluster to external physical storage (like cloud disks or NFS), automatically provisioning and attaching permanent hard drives so your data survives restarts.
5. Observability stack: With applications scattered across multiple machines, troubleshooting requires centralized insights. Tools like Prometheus and Grafana monitor cluster metrics, alongside logging agents like FluentBit to aggregate container logs into a single, searchable dashboard.

This simplified overview of Kubernetes architecture just scratches the surface. As you consider how these components communicate with each other—and with external resources and infrastructure—you can appreciate the challenges of configuring and securing a Kubernetes cluster.

Kubernetes offers the tools to orchestrate a large and complex containerized application, but it also leaves many decisions up to you. You choose the operating system, container runtime, continuous integration/continuous delivery (CI/CD) tooling, application services, storage, and most other components. There’s also the work of managing roles, access control, multitenancy, and secure default settings. Additionally, you can choose to run Kubernetes on your own or work with a vendor who can provide a supported version.

This freedom of choice is part of the flexible nature of Kubernetes. While it can be complex to implement, Kubernetes gives you tremendous power to run containerized applications on your own terms, and to react to changes in your organization with agility.

Build cloud-native applications with Kubernetes

Watch this webinar series to get expert perspectives to help you establish the data platform on enterprise Kubernetes you need to build, run, deploy, and modernize applications. 

Watch the web series on demand

Red Hat is a leader and active builder of open source container technology, including Kubernetes, and creates essential tools for securing, simplifying, and automatically updating your container infrastructure. 

Red Hat® OpenShift® is an enterprise-grade Kubernetes distribution. With Red Hat OpenShift, teams gain a single, integrated platform for DevOps. Red Hat OpenShift offers developers their choice of languages, frameworks, middleware, and databases, along with build and deploy automation through CI/CD to supercharge productivity. Also available is a data and storage services platform engineered for containers, Red Hat OpenShift Data Foundation.

Learn more