I use cookies in order to optimize my website and continually improve it. By continuing to use this site, you are agreeing to the use of cookies.
You can find an Opt-Out option and more details on the Privacy Page!

Kubernetes cluster architecture

A Kubernetes cluster consists of several components, with different functions:

ETCD

One part I already looked at in one of my previous posts is the etcd-cluster. Kubernetes stores his states inside the cluster and flannel a layer 3 network for communication inside of a kubernetes cluster also uses etcd to store the network configuration. It is very important, that the etcd is resillient against failures, to prevent cluster failures. Therefore, we set up an etcd cluster with at least 3 nodes. If you use AWS or other cloud providers it is recommendet to create an autoscaling group that runs health checks against the cluster to substitute failing etcd nodes.

Kubernetes Master

The master nodes receive the work via the api-server from the user, store their states in the etcd and coordinate the kubernetes worker nodes to run these tasks (run container). It is very important to secure these api-servers from beeing accessed from unauthorized users. In a high available cluster the master nodes are also replicated on more than one node. In our case we user 3 nodes. This also makes it easier to upgrade the master nodes to a new kubernetes version and in case of failure the nodes can connect to another master node. In the next post kubernetes master I show how to setup an kubernetes master cluster that is secured via x509 client certificate.

Kubernetes Worker

The kubernetes nodes do the work the kubernetes masters received. This components are very good to autoscale, if there is more work to do they can be scaled up and if there is less work to do they can be scaled down. The workers share together with the worker nodes a flannel network. This network is required for pod communication and communication to the api-server from inside the pods. On each worker there is a process called kubelet, this process handles the work assigned to the node and runs them on docker by creating or deleting containers. Additionally there is kube-proxy, this process receives requests and delegeates them to the correct node and to the correct pod. In another post, I’ll show how to setup kubernetes workers.

Kube-DNS

Björn Wenzel

Björn Wenzel

My name is Björn Wenzel. I’m a Platform Engineer working for Schenker with interests in Kubernetes, CI/CD, Spring and NodeJS.