Kubernetes Architecture,Hands On!

You need to learn Kubernetes right now!!!! But Why??? Well Kubernetes can deploy hundreds of containers with just one command and it is almost present in every DevOps pipeline. So it is important!!!

In this article we are going to walk through the Kubernetes Architecture and it’s various components and how they work together.

The Master and Worker

Let’s take a look at the cluster architecture and what are the components and what their purpose is. So the two basic roles in Kubernetes are the master role and the worker role. You can have one or many master nodes, and you can have zero or many worker nodes. A node,is just a machine in which you can install Kubernetes and a container runtime on. You can use your cloud servers, or you can use Raspberry Pis or you can even use the machine you work on.

Within a node is a pod, which contains one or many containers running your application. Kubernetes allows you to run your application on potentially thousands of machines, but to you it seems as if they’re just running on one giant machine. Deploying your application is the same no matter if you have a single node cluster or a 5,000 node cluster.Which node the application components reside on shouldn’t matter because it operates in the same fashion. They can talk to each other in the same way, no matter where they are within the Kubernetes cluster.Kubernetes can also relocate the app components at any time to another node, and you wouldn’t even notice or care. This abstraction layer eliminates the need to worry about the underlying infrastructure and focus more on deploying and scaling your application. Kubernetes takes care of the service discovery, scaling, load balancing, self healing, and even leader election. Therefore, developers no longer have to build these services inside of their application. That’s a long paragraph……let’s get into the components real quick.

So let’s get into the components of both the master node and the worker node, shall we? The four basic components of the master node, “the control plane” are the API server, the scheduler, the controller manager, and etcd. The API server is the communication hub for all cluster components. As you see, all of the other components are pointing towards it trying to reach out to it to request information.

The API server exposes the Kubernetes API.The scheduler is responsible for assigning your application to a worker node. It will automatically detect which pod to place on which node based on the resource requirements, hardware constraints, and other factors.The controller manager maintains the cluster, it handles node failures, replicating components, maintaining the correct amount of pods and so on.And finally, etcd is a data store that stores the cluster configuration. It’s recommended to back this up, especially if your cluster configuration is very complex, as you won’t have to worry if your cluster crashes.The master node will never contain pods or be responsible for running the application components. The master node can be replicated for high availability, and that’s usually recommended. Overall, the master node initiates and follows the instructions according to a spec to deploy pods and the container or containers within.

Let’s move on to the worker node. The worker node is responsible for running your application, monitoring it, and providing the services it needs. The three basic components of the worker node are the kubelet, the kube-proxy, and the container runtime. The kubelet runs and manages the containers on the node, and it talks to the API server. As you’ll see in the first image, there’s an arrow going from the kubelet to the API server. It’s also pointed to container runtime because it will contact the container runtime, like Docker for example, to go out and pull images that it requires to run the pod. The kube-proxy also called the service proxy load balances traffic between application components and the third one the container run time, is the program that runs your containers like Docker, Rocket, or Container D.

Once you describe the image that contains your application, the scheduler on the master node schedules the specified groups of containers onto the nodes then the kubelet and instructs the container runtime to pull the images and then run the containers.

Here’s what a cluster looks like when running multiple application components and using Docker as the container runtime.There may be different images on those containers. There may be multiple containers running in the same pod because there are some dependencies and they’re also maybe multiple replicas of the same image.

At a very high level, you create the description of your app and its dependencies and replicas.The scheduler then notifies the nodes, as you see here the arrows are going from the master to the kueblet on the worker node. The kubelet will then tell Docker to pull the images from the image registry. So we have an arrow going from Docker to the image registry, and then Docker provisions that container and runs it on the worker node. The control plane will always make sure that the applications stays in the same state as specified in the description. And if it doesn’t stay in that state, Kubernetes will fix it automatically. This is called a declarative intent, instead of having to manually check the cluster and see if it’s in a desired state, Kubernetes does this automatically. You just tell it what state that it should be in.

Time to run some commands hands on !!!!!!

They’re all in the ready state, one of them master and two are workers. We can also see the pods running on those nodes by running the following command “kubectl get pods — all -namespaces”. This gives us all pods running in all namespaces.

If you notice from the output of above command, we aren’t able to see what nodes these pods are on. We can output more detail by adding “-o” and then “wide” and in this output we have the names of my nodes here.

Namespace is just a virtual cluster. Think of it as a virtual separation between different environments. For clusters with just a few users, you shouldn’t have to worry about namespaces at all. They come in handy when you want to divide cluster resources between many different users, as the concern is that one group or team will consume more resources than is available within the cluster.We can run a command to see all the namespaces in our Kubernetes cluster by running kubectl get namespaces. We see we have four namespaces here, the default namespace, the kube-public namespace, the kube-node-lease namespace and the kube-system namespace.

Let’s go ahead and run a simple deployment.

cat << EOF | kubectl create -f -
apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx
EOF

it’s basically just creating the YAML file and creating the deployment all in one. We have the kind of deployment as pod. We have the name of the deployment, which is nginx, the name of the container, which is also nginx and the name of the image to get from the container registry. Our deployment is ready.

Let’s go ahead and run the “kubectl get pods” and “kubectl describe pod nginx” commands to see our pod.

So we have the name, the namespace, which is just the default namespace. We have the IP address of the pod. We have the container ID of the container. We have the name of the image, which is nginx. We have the conditions and we have the events. This describe pod command is going to come in handy when troubleshooting problems with your pod. Let’s go ahead now and delete the pod by running the command “kubectl delete pod nginx”.

That’s it for the architecture of the Kubernetes cluster. Hope you Enjoyed!!!