Kubernetes architecture simply means what makes up a Kubernetes cluster. A Kubernetes cluster by default, consists of a master-worker node architecture. But based on the cluster setup and high availability needs of the cluster, it is possible to have a single or multiple master or single or multiple worker nodes in one Kubernetes cluster. With Minikube, there can be a single node setup that serves as both master and worker nodes within a local/dev environment.

The worker node is also referred to as the slave node while the master node is just the Kubernetes master node.

Cluster

A cluster is a central and overall space where nodes are set up to carry out the orchestration of containers and automated deployment of applications. In simpler terms, a cluster is like a house while the nodes - master and worker nodes are like different rooms that make up the house. What this implies is that for you to have a node, it must be within the cluster.

Within the nodes, there are other Kubernetes components such as pods, replicaSets, deployments, namespaces, services, etc.

Master node

The master node is like the chief manager that is responsible for the management of Kubernetes clusters. The master node is in charge of all administrative tasks so long as Kubernetes is concerned. Once there is a request made to the cluster, the master is the node to receive this request, process it, and assign it to a worker node based on the type of request or task. The master node is made up of several components that enable the cluster to receive user requests, process the request, serve the request, schedule containers, manage the execution of the application running in the container, and ensure the cluster maintains a good state at all times.

Components of A Master Node

• Kube API Server

This is the entry point within the Kubernetes cluster and it is a single destination for all REST APIs. The Kube API server is the cluster's gateway that receives any requests made by users or other applications into the cluster and processes these requests.

For example, when a user requests data from an application that is deployed and managed in Kubernetes, the Kube API server is responsible for handling this request as it allows users and admins to create, update, and delete objects within the cluster. It also checks for secure communication since it is an instrument for authentication to ensure that only authenticated and authorized requests get through the cluster.

• Etcd

This is a distributed database in a Kubernetes cluster that stores its information in a key-value form, storing every cluster state. It is like the cluster brain at the backend of the master node.

It provides high-availability services to the cluster. The complete state of the Kubernetes cluster and every change made is saved in the Etcd database. The data provided by this Etcd component is used by the other components within the master node.

Lost clusters can be recovered in the Etcd database. On production machines, it is essential to have an external backup or outrightly externalize the Etcd database from the master node. This will make data recovery possible and faster in any event of loss or downtime from the master node.

If the Etcd is attached to the master node without any proper backup, if the node crashes, the Etcd database will also crash with the master node and the contents of this component cannot be recovered if there is no external backup.

• Kube Scheduler

The kube scheduler just as the name suggests is charged with scheduling and regulating the pods that should run on the worker/slave node.

The scheduler gets the resources or objects that are on the master node and schedules them on a suitable or free worker node. After the API Server validates the request to schedule a new pod, the scheduler looks at the worker node and decides on which of the nodes to start the application based on the specifications made in the pod.

• Kube Controller

Controllers manage a bunch of tasks by running multiple controller utilities in a single process.

The controller is charged with automating tasks in the cluster. Also, when pods die or crash in any node, the controller manager detects these changes and recovers the cluster state, requests the scheduler to schedule the crashed pod. Based on the available resources, the scheduler decides which node should restart the crashed pod.

Slave/Worker Node

The worker node is a server or machine where the containers are run. This is the node that does the actual work. There are processes installed on every worker node and each worker node can run multiple pods.

The worker node contains all the services that are needed to manage the networking of containers, communications with the master node, and assigning resources to scheduled containers.

Components of A Worker Node

• Container Runtime

The first of the three processes that run on Kubernetes is the process that runs on the worker node and that is the container runtime. The container runtime is the application that is running on a container. An abstraction of this container runtime in Kubernetes is called the pod.

• Kublet

On each worker node, there is a utility called kublet. Kublet is a Kubernetes agent that directly communicates with the Kube API server on the master node to manage the state of the worker nodes.

The execution of services on the worker node is the responsibility of the Kublet. Kublet gets the configuration of a pod from the API server and ensures the containers are up and running. This component interfaces with the container runtime and the node itself. It takes whatever configuration that has been defined and starts a pod with the container inside it.

• Kube-Proxy

kube-proxy is a service that runs on each node to deal with individual host subnetting and ensures that the services are available to external parties. Kube-proxy provides connectivity between the containers and third parties by forwarding requests to their services and ports. Kube-Proxy has to be installed on every node, to make sure the communication also works in a performant way at the lowest costs.

Kubernetes Objects

Objects are the various resources that can be deployed or configured in Kubernetes. Most of these objects are executed in the worker node while some of the objects like services, and namespaces are executed in the master node.

Below are the different kinds of objects that can be deployed or configured in a Kubernetes cluster -

• Pods

In Kubernetes, a pod is the abstraction of a container. By abstraction, it means that a pod is a container with all of its features but this time, it is in a form that is more manageable and lightweight for proper orchestration. You can also say that a pod is a basic unit or object that has a single container or multiple containers that have a shared storage or network, with a good specification of how the containers can run.

Pod is a single unit in Kubernetes which is meant to have a single container running within it. It is also possible to run more than a single container in one pod. These multiple containers that can be run on a pod must have similar configurations - one main application and perhaps other side service containers that have the same configuration as the main application. It is not practicable to execute containers that are configured differently within one pod. What this means is that only a single container which is the application itself. Or a single container which is the application itself and other applications which could be the main application's dependencies or artefacts that are needed for the smooth running of the main application.

A pod creates a running environment or an additional layer on top of the container to enable Kubernetes to abstract the container to interact with its layer.

The shared containers within the pods use the same IP which is assigned to the pod regardless of the number of containers within it. The containers that are within a single pod can communicate with each other via the localhost. Single pods can run on multiple nodes and a single node can also execute multiple pods. The pod uses the IP address to communicate with other pods. Lastly, pods are ephemeral and when they die, they get replaced by a new pod which is assigned a new IP address.

• Deployment

Deployment is a blueprint or abstraction layer of a pod where pods are replicated in one or numbers. Deployments are used in place of pods in real-time and with pods, you can specify, and scale up or down the number of replicas you will need. Deployment makes it easier to interact with the pods, replicate them, and configure them. This is highly advantageous when a pod dies, the service will route the application to one of the replicated pods so that the application can still be running.

• ReplicaSet

A ReplicaSet manages the replicas of pods within it while the pod contains an abstraction of a container. When a pod dies, the kube scheduler from the master node schedules another pod from the replicas of the pod created through the ReplicaSet. Both the pods and the ReplicaSet are managed and created automatically from the deployment.

• Service

A service is an object in the Kubernetes cluster that is used to manage communication and networking within and outside the cluster. With the service, you can assign a permanent IP address with a Domain name that can be assigned to a Kubernetes pod.

Due to the ephemeral nature of pods, the lifecycle of the pod and services are not connected so even if a pod dies, its service and its IP address will stay so you don’t have to change that endpoint anymore. Pods also communicate with each other using a service.

The service is also a load balancer that catches requests and forwards them to whichever pod is free or less busy.

There are two classes of services:

1. External services

These are services that open communication from external sources. With this, every component of your service is visible to the public.

1. Internal services

These are the types of services that you specify the properties you want to use when creating one.

• Volumes

Volumes are external storage attached to a node or a pod. It could be a physical hard drive or a cloud storage service such as an Amazon S3 bucket. The volume is usually not within the Kubernetes cluster because Kubernetes clusters cannot manage data persistence hence an external backup(volume) outside the cluster should be most handy.

• Config Map

The is a file that contains the configuration of an object or resource deployable in a cluster. Config map will usually contain the configuration data like the API version, container name and image, the number of replicas for the deployment or pod, and the service or other services like load balancers to be used.

The config map is to be connected to a pod so that the pod can get the data that the config map contains. Once there is a change in the service, instead of creating an object, the config map can be modified and reapplied so that the change can take effect.

• Secrets

Secrets are like config maps but they are used to store and manage credentials that should be kept secret. The secret does not store passwords, certificates, and other credentials in plain text but in an encoded base64 format. To further strengthen the secrecy of the credentials stored within the Kubernetes secret, some third-party encryption tools can be employed. The credentials kept in these secrets are to be connected to the pod so that pods can use them when there is a need to use an environmental variable or properties files.

• statefulSet

This component is designed for the creation of stateful applications such as the database. Just like deployment which replicates the pods, statefulSet replicates the database. Scaling them up and down and making sure that the database synchronizes so that there will be no inconsistencies.