As the complexity of software applications and infrastructure continues to grow, containerization has become a popular solution for managing and deploying software. However, as the number of containers increases, it can become difficult to manage them all manually. That's where Kubernetes comes in - a powerful container orchestration platform that automates the deployment, scaling, and management of containerized applications.

In this blog post, we'll dive into the world of Kubernetes and explore its various components and architecture. We'll cover the basics of pods and nodes, which are the building blocks of Kubernetes, and how they work together to create a scalable and resilient platform. We'll also discuss the role of container orchestration in the DevOps process and how Kubernetes can help developers and engineers streamline their workflows.

Whether you're new to Kubernetes or looking to improve your understanding of its inner workings, this post is for you. So let's get started and learn how Kubernetes can transform the way you manage your containerized applications!

Kubernetes Object Management

There are various methods to create and manage Kubernetes objects. The kubectl command-line tool (CLI) of kubernetes, can be leveraged for creation, deletion and modification of various objects in the cluster. It can be used to deploy and manage applications on Kubernetes.

Let us see few categories of operations by kubectl:

Type	Used For	Description
Declarative Resource Management	Deployment and Operations	Declaratively manage Kubernetes Workloads using Resource Config
Imperative Resource Management	Development Only	Run commands to manage Kubernetes Workloads using Command Line arguments and flags
Printing Workload State	Debugging	Print information about Workloads
Interacting with Containers	Debugging	Exec, Attach, Logs
Cluster Management	Cluster Operations	Drain and Cordon Nodes

These different approaches can be used to manage resources in the Kubernetes cluster.

The management Techniques are broadly classified into three:

Imperative commands - operates on live objects. This management technique is recommended to use on development project environments. Example,
```
 kubectl create deployment nginx --image nginx
```
This command creates a nginx deployment object which manages an nginx container. This is the simplest way to get started or to run a one-off task in a cluster. Since his technique operates directly on live objects, and hence it does not provide history of previous configurations.
Imperative object configuration - In imperative object configuration, the kubectl command specifies the operation (create, replace, etc.), optional flags and at least one file name. The file specified must contain a full definition of the object in YAML or JSON format. For Example,
```
 kubectl create -f nginx.yaml
```
Here we are creating the objects specified in the configuration file, nginx.yaml. Similar to kubectl create, operations like delete or replace can be performed. Delete is used to delete the objects specified in the configuration file and replace is used to update the objects defined in a configuration file by overwriting the live configuration. It is recommended to use on production project environments since it can be used for overwriting the live configuration.
```
 kubectl delete -f nginx.yamlkubectl replace -f nginx.yaml
```
Declarative object configuration - operate on directories of object configuration files stored locally. If you want to list all the configuration files in a directory, view the changes and then perform action on it, this is best suited way. Example,
```
 kubectl diff -R -f configs/kubectl apply -R -f configs/
```

Note: It is best practice to manage a kubernetes object using any one of the method. Managing same object with multiple management technique might result in undefined behaviour of the object.

Pod

A pod is the basic unit of deployment in Kubernetes. It has different phases associated with its states. The value of phases can be:

Pending – Pod is accepted in kubernetes, but one or more container image is not yet available.
Running – All containers in pod got created and atleast one container is running/starting/restarting.
Succeeded – All containers in pod have succeeded in its termination.
Failed – All containers in pod have terminated, and atleast one container has exited with non-zero status or was terminated by the system.
Unknown – The state of the pod is not available.

A pod has different pod conditions associated with pod status. The values of PodConditions can be:

lastProbeTime
lastTransitionTime
message
reason
status - True, False, Unknown
type - PodScheduled, Ready, Initialized, ContainersReady

Container Probes

A Probe is a diagnostic performed periodically by the kubelet on a Container. The kubelet can optionally perform and react to three kinds of probes on running Containers:

livenessProbe
readinessProbe
startupProbe

Each probe has one of three results:

Success
Failure
Unknown

Container states

Three possible container states are:

Waiting
Running
Terminated

Restart policy

A PodSpec has a restartPolicy field with possible values:

Always
OnFailure
Never

The default value is Always. The restartPolicy is applied to all Containers specified in the Pod. It only refers to restarts of the Containers by the kubelet on the same node. Exited Containers that are restarted by the kubelet are restarted with an exponential back-off delay (10s, 20s, 40s ...) capped at five minutes, and is reset after ten minutes of successful execution. Once bound to a node, a Pod will never be rebound to another node.

Pod lifetime

In general, Pods remain in the cluster until it is explicitly removed. The control plane cleans up terminated Pods when the number of Pods exceeds the configured threshold determined by kube-controller-manager.

There are different kinds of resources for creating Pods:

Use a Deployment, ReplicaSet or StatefulSet for Pods that are not expected to terminate, for example, web servers.
Use a Job for Pods that are expected to terminate once their work is complete; for example, batch computations. Jobs are appropriate only for Pods with restartPolicy equal to OnFailure or Never.
Use a DaemonSet for Pods that need to run on every node.

All workload resources contain a PodSpec - specification of pod. It is recommended to create the appropriate workload resource and let the resource's controller create Pods, rather than directly create Pods. If a pod is created without any management object, kubectl delete will remove it. If a node dies or is disconnected from the rest of the cluster, Kubernetes applies a policy for setting the phase of all Pods on the lost node to Failed.

For more details you can visit https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/

Kubernetes Architecture Diagram

kubernetes architecture diagram

1) In the AWS Kubernetes architecture diagram above you can see, there is one or more master and multiple nodes. One or masters used to provide high-availability.

2) The Master node communicates with Worker nodes using Kube API-server to kubelet communication.

3) In the Worker node, there can be one or more pods and pods can contain one or more containers.

4) Containers can be deployed using the image also can be deployed externally by the user.

Read more about Kubernetes Network Policy here.

Kubernetes Architecture Components

Kubernetes Component

Read more about Container Orchestration and Management Options

Kubernetes Master Node

Master Node is a collection of components like Storage, Controller, Scheduler, API-server that makes up the control plan of the Kubernetes. When you interact with Kubernetes by using CLI you are communicating with the Kubernetes cluster’s master node. All the processes run on a single node in the cluster, and this node is also referred to as the master.

Master Node Components:

1) Kube API-server performs all the administrative tasks on the master node. A user sends the rest commands as YAML/JSON format to the API server, then it processes and executes them. The Kube API-server is the front end of the Kubernetes control plane.

2) etcd is a distributed key-value store that is used to store the cluster state. Kubernetes stores the file in a database called the etcd. Besides storing the cluster state, etcd is also used to store the configuration details such as the subnets and the config maps.

Read More: Kubernetes for Testers.

3) Kube-scheduler is used to schedule the work to different worker nodes. It also manages the new requests coming from the API Server and assigns them to healthy nodes.

4) Kube Controller Manager task is to obtain the desired state from the API Server. If the desired state does not meet the current state of the object, then the corrective steps are taken by the control loop to bring the current state the same as the desired state.

There are different types of control manager in Kubernetes architecture:

Node Manager, it manages the nodes. It creates new nodes if any node is unavailable or destroyed.
Replication Controller, it manages if the desired number of containers is running in the replication group.
Endpoints controller, it populates the endpoints object that is, joins Services & Pods.

Also read: Difference between Kubernetes vs Docker.

Kubernetes Worker Node

The worker nodes in a cluster are the machines or physical servers that run your applications. The Kubernetes master controls each node. there are multiple nodes connected to the master node. On the node, there are multiple pods running and there are multiple containers running in pods.

Worker Node Components

1) Kubelet is an agent that runs on each worker node and communicates with the master node. It also makes sure that the containers which are part of the pods are always healthy. It watches for tasks sent from the API Server, executes the task like deploy or destroy the container, and then reports back to the Master.

2) Kube-proxy is used to communicate between the multiple worker nodes. It maintains network rules on nodes and also make sure there are necessary rules define on the worker node so the container can communicate to each in different nodes.

3) Kubernetes pod is a group of one or more containers that are deployed together on the same host. Pod is deployed with a shared storage/network, and a specification for how to run the containers. Containers can easily communicate with other containers in the same pod as though they were on the same machine.

4) Container Runtime is the software that is responsible for running containers. Kubernetes supports several container runtimes: Docker, containers.

you can refer https://kubernetes.io/ for more updates and featres.

Shubham Londhe

Kubernetes for DevOps