A Kuber­netes cluster is a system con­sist­ing of at least one control node (master) and multiple worker nodes where con­tain­er­ised ap­plic­a­tions are executed. The cluster auto­mat­ic­ally manages the de­ploy­ment, scaling, and re­si­li­ence of the con­tain­ers. This structure enables ap­plic­a­tions to be run reliably and ef­fi­ciently in dis­trib­uted en­vir­on­ments.

IONOS Cloud Managed Kuber­netes
Container workloads in expert hands

The ideal platform for demanding, highly scalable container ap­plic­a­tions. Managed Kuber­netes works with many cloud-native solutions and includes 24/7 expert support.

What is a Kuber­netes cluster?

In general, clusters are a group of computers that appear as a single unified system from the outside. In the case of Kuber­netes, several nodes are combined into clusters instead of physical computers. The nodes can be either physical or virtual machines.

The in­di­vidu­al ap­plic­a­tions run on the Kuber­netes clusters. Therefore, Kuber­netes clusters represent the highest level in the Kuber­netes hierarchy.

What are use cases for Kuber­netes clusters?

Clusters are an essential part of lever­aging the benefits of Kuber­netes. Only clusters allow you to deploy your ap­plic­a­tions without binding them to specific machines. They primarily help abstract your con­tain­ers for cross-computer execution. They are not tied to a specific operating system and are therefore highly portable.

Typical ap­plic­a­tion areas include:

  • De­ploy­ment of complete ap­plic­a­tions: These span across con­tain­ers and are in­de­pend­ent of the un­der­ly­ing hardware. This allows updates or new features to be rolled out quickly without requiring changes to in­di­vidu­al servers. As a result, your ap­plic­a­tions run con­sist­ently in every en­vir­on­ment.
  • Operation in mi­croservice ar­chi­tec­tures: In this setup, ap­plic­a­tions can com­mu­nic­ate with each other and remain highly scalable. In­di­vidu­al mi­croservices can be developed, updated, and scaled in­de­pend­ently, sig­ni­fic­antly in­creas­ing the agility and fault tolerance of the overall ap­plic­a­tion.
  • Con­tinu­ous in­teg­ra­tion (CI) / con­tinu­ous delivery (CD): Con­tinu­ous in­teg­ra­tion or con­tinu­ous delivery jobs enable the auto­ma­tion of build, test, and de­ploy­ment processes. This shortens de­vel­op­ment cycles, reduces manual sources of error, and ensures that new features or patches reach pro­duc­tion faster.

What is a Kuber­netes cluster made of?

A Kuber­netes cluster consists of a control unit, also known as the master node, and one or more worker nodes.

Master Node

The master node forms the found­a­tion of the entire Kuber­netes cluster. It is re­spons­ible for managing the entire cluster, primarily over­see­ing the state of the cluster by de­term­in­ing which ap­plic­a­tion runs and when. The control unit is divided into different com­pon­ents:

  • API server: The API server acts as the frontend of the master node and manages com­mu­nic­a­tion with the Kuber­netes cluster. It defines the cluster’s state and provides the main access point to the Kuber­netes API, which can be used via the command line or the graphical user interface in the Google Cloud Console.
  • Scheduler: The scheduler assigns con­tain­ers to nodes based on available resources. It ensures that all Kuber­netes pods (groups of con­tain­ers) are properly scheduled on a node and can run as intended.
  • Con­trol­ler manager: The con­trol­ler manager oversees different con­trol­lers, which are es­sen­tially back­ground processes. It triggers the necessary actions if in­di­vidu­al nodes fail and con­stantly works to align the cluster’s current state with the desired state.
  • etcd: etcd is the key-value database that stores all critical cluster data. As part of the control plane, it serves as Kuber­netes’ backup storage, keeping con­fig­ur­a­tion and state in­form­a­tion con­sist­ent across the system. It is organised as a key-value store.

Worker nodes

Each Kuber­netes cluster has at least one, but in most cases, several worker nodes. These nodes execute the tasks and ap­plic­a­tions assigned to them by the control unit. The worker nodes consist of two com­pon­ents:

  • Kubelet: Kubelet is a component of worker nodes that ensures each container in a pod is running. To achieve this, Kubelet interacts with the utilised container engine, a program for container creation and man­age­ment.
  • Kube-Proxy: Kube-Proxy ensures that network rules are adhered to. Ad­di­tion­ally, this component is re­spons­ible for per­form­ing con­nec­tion for­ward­ing.

How to create a Kuber­netes cluster

A Kuber­netes cluster can be deployed on either virtual or physical machines. There are various ways to create your own clusters.

Setting up Kuber­netes Cluster with Minikube

To create a simple cluster with one worker node, Minikube can be used. It is a tool that allows Kuber­netes to run locally on your own computer. Minikube can be installed on all common operating systems and is ex­tens­ively described by many Kuber­netes tutorials. To check if your in­stall­a­tion was suc­cess­ful, you can enter the following command in the terminal:

minikube version
bash

You start Minikube with the following command:

minikube start
bash

After executing this command, Minikube starts a virtual machine. A cluster runs auto­mat­ic­ally within it. To interact with Kuber­netes, you can use the Kuber­netes command line. To check if it’s installed, use the following terminal command:

kubectl version
bash

You can view the details of your cluster with the following command:

kubectl cluster-info
bash

You can also view the in­di­vidu­al nodes where your ap­plic­a­tions can run directly in the terminal:

kubectl get nodes
bash

Creating Kuber­netes cluster with kind

If you want to create a Kuber­netes cluster with more than one node, you can use the tool kind. Kind is also available for all common operating systems. The in­stall­a­tion is easiest through a package manager. In the examples shown here, choco is used for Windows:

choco install kind
bash

For a cluster with multiple worker nodes, you now create a YAML-con­fig­ur­a­tion file in any directory. In this file, you define the structure of your cluster. A con­fig­ur­a­tion file for a Kuber­netes cluster with one master and two worker nodes might look like this:

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
- role: worker

You can then create the Kuber­netes cluster according to the con­fig­ur­a­tion you selected with the following command:

kind create cluster --config example-file.yaml
Go to Main Menu