Kubernetes (often abbreviated as K8s) is an open-source system for managing containerized applications. At a high level, a Kubernetes Cluster is made up of:

Each Node has a kubelet process running on it. Kubelet communicates with the API server to register the node and manage pods assigned to it.

Control Plane Node

Control Plane Node runs several necessary kubernetes processes that allow to run and manage the cluster. Some processes running on the master node:

Worker Nodes

Worker nodes run your application workloads. Each node has:

Virtual Network

Kubernetes provides a flat network — every pod gets its own IP, and pods can communicate with each other without NAT, regardless of the node they’re on.

A Virtual Network essentially turns all the cluster’s nodes into one big machine for communication.

Kubernetes Components

Node and Pod

A Pod is the smallest deployable unit in Kubernetes and can contain one or more containers. It is an abstraction over a container. Pod allows you to create a layer over the container so you can replace the container technology (i.e. you don’t have to use Docker for your containers, you can use any other container service).

Each Pod gets its own IP address. Pods are ephemeral (can die very easily). So if a pod dies, a new pod is created in its place and gets assigned a new IP address. This sounds rather inconvenient because it seems you’ll have to change the IP address in other services to communicate with this pod if gets recreated. To overcome this inconvenience, we use a component called Service

Service and Ingress

Each group of pods is assigned its own Service (usually replica pods). Lifecycles of a pod and service and decoupled. If a pods dies, the service stays alive and vice-versa.

Service has 4 types:

Ingress forwards external requests to internal services.

A Service is like a persistant static IP address and DNS name.

ConfigMap and Secret

ConfigMap is a component that allows you to assign and modify environment variables to each pod without having to rebuild the pod image. Traditionally, if you were to, lets say, change the db url, you would then have to rebuild the db image, push it to the repo and then deploy it to the pod. However with ConfigMap, all you have to do is modify the key value in ConfigMap and your db url will change accordingly.

Secret is another component that allows you to store sensitive variables. These could include username, passwords, API keys, tokens, certificates etc. Secret is just like ConfigMap but instead of storing as plain text, Secret stores data as base64 encoded format. This is still insecure so we use third party tools to encrypt the secrets and then store them as base64.

Volume

A Volume attaches a physical storage to your pod. The storage could be on your local machine or a remote storage such as cloud storage which is an external reference to your storage. K8 cluster does not manage data persistance. So its our job to manage data outside of a k8 cluster.

Deployment and StatefulSet

Deployment is a component which acts like a blueprint for setting up replicas for pods. In practice, we work with Deployments rather than pods directly. Each replica is connected to the same service. For example, if we have a node with an app pod and database pod. We create two replicas of the node. Now for both the nods, both app pods are connected to the same service and database pods are connected to the same service.

However, there is a flaw in this approach. App pods are stateless and hence accessing and performing an action on any app pod is fine. For the database pods, that is not the case. Database pods are stateful pods. Clones of database are accessing shared volumes for data. We’ll have to manage how which pods are writing to the storage or reading from the storage to prevent data inconsistencies. For this we have StatefulSet component

StatefulSet components should be used for stateful pods. We would ideally use StatefulSets for databases rather than Deployments. A point to consider, deploying databases using StatefulSets is cumbersome and we usually practice hosting database outside of our cluster for simplicity.

DaemonSet

Kubernetes Configuration

All configuration goes through the master node via the API Server Container. This request is in the form of yaml or json format.

3 Parts of a K8 configuration file

apiVersion: apps/v1
kind: Deployment
metadata:
 name: backend-deployment
 labels: ...
spec:
 replicas: 2
 selector: ...
 template: ...

YAML files are strict indentation. Indentations in the yaml file matter and not having proper indentation can lead to incorrect configuration.

We usually store the config file with our code in the code repo.

Summary