Kubernetes — Ohoyee Captain!

In the previous blog, we left at etcd. I hope you got the basics of each component discussed as of now, do not worry we shall go in-depth for each one of them. Let us start this blog with kube-scheduler.

Kube-Scheduler

So basically what we can get from the name scheduler is that it creates and manages pods as well as the nodes. Simple as that, whenever there is a request made from the user. If a pod is not assigned to a node then the scheduler decides which is the best node that pod can run on. It gets information from the configuration files and schedules the pod accordingly.

Controller-Manager

This makes sure that the actual state of the cluster matches its desired state. Suppose the desired state is 4 pods on the 2 nodes, but somehow the pods got destroyed due to some error, then the controller manager will check the actual state of the cluster and it will realize that the actual state doesn’t match with the desired state of the cluster, it will then send message to kube-scheduler to schedule 2 new pods on the node.

If this K8s cluster is hosted on the cloud then it is called cloud-controller-manager, if it is hosted in a non-cloud platform then it will be called kube-controller-manager. There are some components in the master node that help the controller-manager function properly, they are:

• Node-manager: For checking the cloud provider to determine if a node has been detected in the cloud after it stops responding.
• Route-controller- responsible for setting up the network routes on your cluster
• Service controller- responsible for load balancers on your cloud against services of type load balancer
• Volume controller: for creating, attaching, and mounting volumes and interacting with the cloud provider to orchestrate volume

Kubelet

Kubelet is a component of Kubernetes that runs on each node in the cluster. It is responsible for running containers on a node, as well as for managing the node’s state. It uses the port 10255.

Container Engine

There are many container engines that you can use with K8s, like Docker, Podman, ContainerD. Nowadays docker is not being used with K8s, you can use ContainerD with nerdctl to control containerD

Kube-Proxy

The kube-proxy job is to assign an IP to each pod. It is required to assign IP addresses dynamically to each pod. Kube proxy runs on each node & this makes sure that each pod will get its own unique IP and is able to establish a connection between them.

So with this we have completed the basics of K8s Architecture. Now the fun part…

We will start to deep dive into each of these components with practical. Now do not worry, I will be here with you to explain every step and every part of it so that you can say to your friends that Kubernetes? eeh! Not so hard after all.

K8s Pod

• The pod is the smallest unit in a K8s cluster
• A pod is a group of one or more containers that are deployed together on the same host
• In K8s the control unit is the pod, not the container
• The pod can contain one or more containers that are tightly coupled
• Pods run on nodes that are controlled by the master node
• K8s deals with the pods itself and not the container within. K8s cannot start the containers without the pods
• It is best practice to initiate one container in a single pod.
• We can specify K8s from where the image would be pulled, a public docker hub repo, or a private one

Kubectl run nginx --image nginx

Kubectl get pods

Multi-Container Pods

• When in a multi-container environment, pods share access to memory space
• Containers are connected to each other via localhost:port
• The entire pod is hosted on the same node, the scheduler will decide about which node that pod will be deployed

There are some limitations to pods like

• No auto-healing or scaling
• If the pod crashes the containers in the pod also go down

Pods with YAML

• K8s uses YAML files as inputs for the creation of objects such as pods, replicas, deployments, services, etc.
• All of these follow a similar structure, a k8s definition file always contains 4 top-level fields

apiVersion:

• This is the version of K8s API version we are using to create objects, it depends on what object you are trying to make, in this case for a POD we will use “v1”
• Other possible value for this API version is apps/v1 for replica set and deployment

kind:

• The type of object we are trying to create, which is in this case happens to be a pod. Other kinds could be, Service, ReplicaSet, Deployment, etc.

metadata:

• It is the data about the object like its name, labels, etc.

spec:

• Also known as specification. It depends on what we have to create, spec is where we provide additional information to K8s pertaining to that object. This is going to be different for different objects
• Since we are only creating a pod with a single container in it, it is easy.
• Spec is a dictionary so add a property under it called containers, now the containers is a list/array
• We add names and images under containers

all of this combined will look something like this

apiVersion: v1
kind: Pod
Metadata: 
  name: test-pod
spec:
  containers:
  - name: nginx
    image: nginx:1.14.2
    ports:
    - containerPort: 80

• Containers specify the specs for the container in the pod that is being deployed, that is nginx a basic web server
• Image specifies that this specific image is to be used to create the container that is to be deployed in the pod
• Ports here are used to mention the port that will be exposed out of the pod that will communicate with the user. Nginx runs by default runs on port 80 so we exposed that port of the container to Pod so that when the IP of the Pod is accessed it will show us the Nginx server that is running on the container.