How can you create and use a Ku­ber­netes cluster?

A Ku­ber­netes cluster is a system con­sist­ing of at least one control node (master) and multiple worker nodes where con­tainer­ized ap­pli­ca­tions are executed. The cluster au­to­mat­i­cal­ly manages the de­ploy­ment, scaling, and re­silience of the con­tain­ers. This structure enables ap­pli­ca­tions to be run reliably and ef­fi­cient­ly in dis­trib­uted en­vi­ron­ments.

What is a Ku­ber­netes cluster?

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

The in­di­vid­ual ap­pli­ca­tions run on the Ku­ber­netes clusters. Therefore, Ku­ber­netes clusters represent the highest level in the Ku­ber­netes hierarchy.

What are use cases for Ku­ber­netes clusters?

Clusters are an essential part of lever­ag­ing the benefits of Ku­ber­netes. Only clusters allow you to deploy your ap­pli­ca­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­pli­ca­tion areas include:

• De­ploy­ment of complete ap­pli­ca­tions: These span across con­tain­ers and are in­de­pen­dent of the un­der­ly­ing hardware. This allows updates or new features to be rolled out quickly without requiring changes to in­di­vid­ual servers. As a result, your ap­pli­ca­tions run con­sis­tent­ly in every en­vi­ron­ment.
• Operation in mi­croser­vice ar­chi­tec­tures: In this setup, ap­pli­ca­tions can com­mu­ni­cate with each other and remain highly scalable. In­di­vid­ual mi­croser­vices can be developed, updated, and scaled in­de­pen­dent­ly, sig­nif­i­cant­ly in­creas­ing the agility and fault tolerance of the overall ap­pli­ca­tion.
• Con­tin­u­ous in­te­gra­tion (CI) / con­tin­u­ous delivery (CD): Con­tin­u­ous in­te­gra­tion or con­tin­u­ous delivery jobs enable the au­toma­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 Ku­ber­netes cluster made of?

A Ku­ber­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 foun­da­tion of the entire Ku­ber­netes cluster. It is re­spon­si­ble for managing the entire cluster, primarily over­see­ing the state of the cluster by de­ter­min­ing which ap­pli­ca­tion runs and when. The control unit is divided into different com­po­nents:

• API server: The API server acts as the frontend of the master node and manages com­mu­ni­ca­tion with the Ku­ber­netes cluster. It defines the cluster’s state and provides the main access point to the Ku­ber­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 Ku­ber­netes pods (groups of con­tain­ers) are properly scheduled on a node and can run as intended.
• Con­troller manager: The con­troller manager oversees different con­trollers, which are es­sen­tial­ly back­ground processes. It triggers the necessary actions if in­di­vid­ual nodes fail and con­stant­ly 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 Ku­ber­netes’ backup storage, keeping con­fig­u­ra­tion and state in­for­ma­tion con­sis­tent across the system. It is organized as a key-value store.

Worker nodes

Each Ku­ber­netes cluster has at least one, but in most cases, several worker nodes. These nodes execute the tasks and ap­pli­ca­tions assigned to them by the control unit. The worker nodes consist of two com­po­nents:

• Kubelet: Kubelet is a component of worker nodes that ensures each container in a pod is running. To achieve this, Kubelet interacts with the utilized 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­al­ly, this component is re­spon­si­ble for per­form­ing con­nec­tion for­ward­ing.

How to create a Ku­ber­netes cluster

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

Setting up Ku­ber­netes Cluster with Minikube

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

minikube version

You start Minikube with the following command:

minikube start

After executing this command, Minikube starts a virtual machine. A cluster runs au­to­mat­i­cal­ly within it. To interact with Ku­ber­netes, you can use the Ku­ber­netes command line. To check if it’s installed, use the following terminal command:

kubectl version

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

kubectl cluster-info

You can also view the in­di­vid­ual nodes where your ap­pli­ca­tions can run directly in the terminal:

kubectl get nodes

Creating Ku­ber­netes cluster with kind

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

choco install kind

For a cluster with multiple worker nodes, you now create a YAML-con­fig­u­ra­tion file in any directory. In this file, you define the structure of your cluster. A con­fig­u­ra­tion file for a Ku­ber­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 Ku­ber­netes cluster according to the con­fig­u­ra­tion you selected with the following command:

kind create cluster --config example-file.yaml