What is Kubernetes ?

Kubernetes is a "Container Orchestration System" which was Open Source by Google in 2014. It makes it easy for us to manage container by automating various tasks.

Kubernetes is a portable, extensible, Open Source platform for managing containerized workloads & Services, that facilitates both declarative configuration and automation.

Why use Kubernetes?

Kubernetes provide an easy way to scale application, Automate deploying & Managing Containerized application on a group of server, Compare to Virtual Machine.

Kubernetes Architecture

A Kubernetes cluster consist of Master node which manages other worker node. Worker nodes are virtual Machine / Physical Server running within a data centre.They expose the underlying network and storage resources to the application.

All these nodes join together to form a cluster with providing fault tolerance and replication. These nodes were previously called minions.

Control Plane (Master Node

It it Responsible for managing the whole cluster. The Control Plane manages the Worker nodes & Podes in the Cluster. It monitor the health check of Worker node & shows the information of about the member of the Cluster as well as their Configuration.

If a Worker node fails, the master node moves the load to another healthy worker node. Kubernetes master is responsible for scheduling, Controlling &
Exposing API to the clients.

Components of the master node

API server

The API ( Application programming Interface ) Sever determines if a request
Is valid and then processes it.

Gate keeper for the Entire Cluster. CRUD Operation for Server go through the API. API server configures the API Object such as Pods, Services, Replication Controllers () And deployement. It Exposes API Almost Every Operation. How to Interact with this API ? Using a tool Called KubeControl. It Talks to the API Server to perform any Operation that we issue from cmd. In most cases, the Master node does not contain containers. It just Manages Worker Nodes, And Also makes sure that the cluster of worker nodes are running healthy & Successfully.

Scheduler

The Kubernetes scheduler is a control plane process which assigns Pods to Nodes. The Scheduler determines which nodes are valid placements for each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node.

It is Responsible for physically scheduling pods across multiple nodes. Depending upon the Constraints mentioned in the configuration file, Scheduler these Pods Accordingly.

For Ex. If you mention CPU has 6 Core, memory is 16 GB, etc. Once this artifact is passed to API Server. the Scheduler will look for the appropriate nodes that meet these criteria & will schedule the Pods.

Control Manager

The Kubernetes Controller manager is Daemon that embeds the core Control loops shipped with Kubernetes.

There are 4 Controllers behind the Control manager.

• Node Controller

It is responsible for Onboarding new nodes to the cluster Handling situation where nodes become unavailable or get destroyed to keep our application running.

• Replication Controller

It is Responsible for monitoring the status of replica sets and ensuring that the desired number of Pod are available at all times within the set. If a POD dies it will create another POD. It makes sure that desired number of PODs or at least one POD is in running state. It has the capability to bring up or down the specified no of PODs.

• EndPoint Controller

  Populates the Endpoints object (that is, joins Services & Pods). Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.

• Services Accountant Token Controller

These Controller are responsible for the Overall health of the Entire Cluster. It Ensure that nodes are up And Running all the time as well as the Correct number of pods are running as mentioned in the Spec File.

etcd

Consist and highly-available key value store used as Kubernetes backing store for all cluster data.

Distributed key-Value lightweight database. Central database to store current cluster at any point of time. Any Component of Kubernetes can Query etcd to Understand the state of the Cluster so this is going be the Single Source of truth for all the nodes, Components and the Master that are forming kubernetes cluster.

Worker Node

It is basically ant VM or Physical server while Containers are Deployed. Every Node in Kubernetes cluster must run a runtime such as Docker Or Rocket.

Components of the Worker Node

kubelet

The Kubelet is the primary "node agent" that runs on each node.

Primary Node agent that runs on each worker node inside the cluster. The Primary Objective is that it looks at the Pod Spec that was Submitted to the API Server on the Kubernetes master And Ensure that Containers described in that Spec are running and Healthy. Incase Kubelet notices any issue with the Pods running on the worker nodes, it tries to restart the Pod on the Same Node. If the fault is with the worker Node, it tries to restart the Pod on the Same Node. If the Fault is with the Worker Node itself, then Kubernetes Master detects a Node failure and it Decides to recreate the Pod on Another Healthy Node. This also depends on if the Pod is Controlled by replica set or Replication Controller ( Ensure that the Specified number of Pods are Running at any time ). If none of them are behind this Pod then Pod dies & Cannot be Recreated anywhere. So it is advised to use Pods as Deployment or Replica Set.

Kube-Proxy

Responsible for Maintaining the Entire Network Confriguration, It Maintains the Distributed network across all the Nodes, Across All the Pods, And All Containers. Also exposes Services to the Outside World. It is the Core Networking Component inside Kubernetes. The Kube-Proxy will feed it's information about what pods are on this Node to Iptables. Iptables is a firewall in Linux And can Route traffic. So when a new Pod is Launched, Kube-Proxy isgoing to change the iptables rules to makes sure that this pod is Routable within the Cluster.

Pods

A Pod is a collection of one or more Linux® containers, and is the smallest unit of a Kubernetes application. A Scheduling unit in Kubernetes. Like a virtual machine in the Virtualization world. Each Pod consists of one or more containers. There are scenarios where you need to run two or more dependent containers together within a pod where one Container will be helping another Container. with the help of Pods, we can deploy multiple dependent container together. Pod acts as a Wrapper around these Container. we interact and Manage Containers through Pods.

Containers

A Container image is a Ready to run Software Package, containing everything needed to run an application: the code and any runtime it requires, application and system libraries, and default values for any essential settings.

Container are Runtime Environment for Containerized application. we run Container application inside the Containers. These Container reside inside Pods. Container are designed to run Micro-Service.

Complete Architecture

More about Pods

Every node inside a Kubernetes cluster has its unique IP address known as Node IP Address. In Kubernetes, there is an additional IP Address called Pod IP address. So once we deploy a Pod on the worker node, it will get it’s own IP Address. Containers in pods communicate with the outside world by network namespace. All the containers inside a pod operate within that same network namespace as the pod. Means all the containers in a pod will have the same IP Address as their worker node. There is a unique way to identify each container. It can be done by using ports. Note: Containers within the same pod, not only just share the same IP Address, but will also share the access to the same volumes, c-group limits, and even same IPC names.

Pod Networking

How do Pods communicate with one another?

• Inter-Pod communication: All the Pod IP addresses are fully routable on the Pod Network inside the Kubernetes cluster.

How do containers communicate in the same pod?

• Intra-Pod Communication: Containers use shared Local Host interface. All the containers can communicate with each other’s port on local host.

Pod Lifecycle

• Define the pod configuration inside manifest file (explained ahead) in yaml/json. Submit the manifest file on the api server of the Kubernetes master.

• It will then get scheduled on a worker node inside the cluster. Once it is scheduled, it goes in the pending state. - During this pending state, the node will download all container images and start running the containers. It stays in the pending state until all containers are up and running.

• Now it goes in the running state. When the purpose is achieved, it gets shutdown & state is changed to succeeded.

• Failed state: It happens when the pod is in the pending state and fails due to some particular reason. If a pod dies, you cannot bring it back. You can replace it with a new pod.

API Version

It defines the version of the Kubernetes API you’re using to create this object.

• v1: It means that the Kubernetes object is part of first stable release of the Kubernetes API. So it consists of core objects such as Pods, ReplicationController and Service.
• apps/v1: Includes functionality related to running apps in Kubernetes.
• batch/v1: Consists of objects related to bash processes and jobs like tasks.

kind

It defines the type of object being created.

metadata

Data that helps uniquely identify the object, including a name string, UID, and optional namespace.

spec

The precise format of the object spec is different for every Kubernetes object, and contains nested fields specific to that object.