In this lesson, we’ll be going through the concepts and terminologies of kubernetes, but, before that, there are some pre-requisites to kubernetes on how we come to this technology to further optimize our production workloads and save us some lifelines.
Pre-requisite to kubernetes
Before deep diving into kubernetes, let’s take a step back and understand why we need kuberenetes in the first place.
Why do you think kubernetes and containers play such an important role in DevOps? Think about it…
Let’s go back to Virtual Machines, In VMs, we deploy our application as a monolithic architecture, means, our application is in a single binary file and is deployed onto a Virtual Machine. Let’s say the VM size is 2vCPU and 4GB of memory. Your application is running fine without any challenges, but guess what? The application is experiencing traffic more than you anticipated and unfortunately our 2vCPU/4GB VM is unable to handle that much load.
What would be the next step? Think and try to answer…
We need to spin up more VMs to handle that much load but spinning up VMs takes time. Let’s say, about 5 mins, now, you’re experiencing an unexpected downtime which you didn’t anticipate for either! This downtime is bad for our application as well as our business. Spinning up new instances of VMs takes time because it’s heavy, it’s virtualizes hardware and all the other dependencies that your application needs in order to run safe and sound. but, what if we can improve this workflow?
What could be the possible solution to this?
Containers came into the picture! VMs virualizes hardware and takes time to boot up but on the other hand, containres virtualizes operating system and doesn’t need that much time to boot. Docker plays an important role in managing and spinning up the containers. Let’s learn more about it.
Is Docker a container or something else? this is a crucial topic here…
Docker is just a runtime which is being used heavily by developers and architects around the world. It’s not a container but rather it’s a tool to spin up containers.
## for help
docker -h
## a command to show all containers in the system
docker ps -a
Let’s run some containers using docker and expose a nginx server on port 8080
docker run --name nginx-alpine -p 8080:80 nginx:alpine
The above command will spin up a docker container for nginx server and expose it to port 8080 on local machine
--name: Name a docker container-p: Port mapping for a container to run [host-port]:[container-port].nginx:alpine: Name of the Image to run [Image-name]:[tag]Now, we’ve come to a point where we’re able to run our applications in a docker container. Now, let’s see, why we want to use kubernetes on the top of it.
Let’s assume we’ve our application docker container is up and running. Out of sudden, docker container stopped working so, we get into the server and spinned up another container. Container hardly takes 15 seconds to get up and running.
So, if a container stopped working? What would be the next step?
Spinning up another instances of container manually. Suppose, we have 100 docker container running in the system. If 10 stopped working, would this be an ideal approach to go and spin up another instance manually one by one? This would be tiring, and a manual overhead. We need to make this automated process. Containers are a good way to bundle and run your applications. In a production environment, you need to manage the containers that run the applications and ensure that there is no downtime. For example, if a container goes down, another container needs to start. Wouldn’t it be easier if this behavior was handled by a system? This is where kubernetes comes into the picture of orchestrating containers.
Features of Kubernetes:
This is it for this lesson. Let’s get into more details on kubernetes in the next lesson.
In this lesson, we’re going to cover the core fundamentals of kubernetes and where should we use it and where not to.
Kubernetes, as we explained in the last post, is a container orchestration tool able to simplify the management of containers and, simultaneously, to make it more efficient. The main aim of Kubernetes, as the other orchestration systems, is to simplify the work of technical teams, by automating many processes of applications and services deployment that before were carried out manually. Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.
The name Kubernetes originates from Greek, meaning helmsman or pilot. K8s as an abbreviation results from counting the eight letters between the “K” and the “s”. Google open-sourced the Kubernetes project in 2014. Kubernetes combines over 15 years of Google’s experience running production workloads at scale with best-of-breed ideas and practices from the community.
So, this is container deployment era which states the benefits of containers and how it makes the application management efficiently. Containers have become popular because they provide extra benefits, such as:
Not all application are desgined for container architecture and some performs better on monolithic architecture then microservices. It’s crucial to understand the importance of when not to use kubernetes. Kubernetes provides the building blocks for building developer platforms, but preserves user choice and flexibility where it is important.
What kubernetes is not:
Let do a deeper dive on the operations of kubernetes and take a look at the components of kuberentes which makes it possible driving millions of applications around the world.
In this lesson, we’re going to be discussing about the components which drives the kubernetes orchestration tool.
Before we go any deeper, let’s take a step back and look at the monolith architecture. The monolith applications runs on a Virtual Machines whether it would be on any Cloud Provider such as AWS, Azure, GCP and many more, or, we’re running it on an on-prem enviornment. These virtual machines are runs your on the host itself. Kubernetes on the other hand, also uses virtual machines to run applications but in a different way.
Like we talked about containers how it virtualizes the operating system and can seprate application into a logical units which can be spinned up in seconds and brought back down in an instant.
Kuberentes also host your applications on Virtual machines to be precise but with the integration of containers things are much easier. Now, applications are deployed as a container workload and be placed onto the Nodes. These Nodes are the Virtual Machines what we’ve just talked about.
A Kubernetes cluster consists of a set of worker machines(VMs), called nodes, that run containerized applications. Every cluster has at least one worker node. These worker nodes host the pods that are the components of the application workloads. We’ve been introduced to a new term pods.
What are Pods in kuberentes ecosystem?
Pods are the fundamental unit in kuberentes which consists of one or more containers to host your application. Assume, we’ve created an application and containerized it. Whenever we deploy application onto the kubernetes, the fundamental unit that get’s deployed is Pods. So, application would be inside of the Pods and pods can consists one or more container inside of it. However, it’s recommended to run one container per pod.
We’ll do hands-on lab on pods in kubernetes in later lessons.
Now, we’ve been introduced to Pods and Nodes but who’s driving all this? Who’s giving them instructions on what operations needs to be done? That is Master Server or it can be called as Control Plane
Image here for control and data plane
Control plane consists of multiple kubernetes components. Which are responsible for keeping an application alive.
Components of Control Plane
The control plane’s components make global decisions about the cluster (for example, scheduling), as well as detecting and responding to cluster events
API Server – This API server is the master of all. It handles the requests and grants the required permissions to access the application inside the cluster. The Kubernetes API server validates and configures data for the api objects which include pods, services, replicationcontrollers, and others. The API Server services REST operations and provides the frontend to the cluster’s shared state through which all other components interact.
Scheduler – Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on. Whenever we do a deployment onto the kubernetes, the kube-scheduler watches for the upcoming workloads that needs to assigned onto the Nodes.
Etcd – Consistent and highly-available key value store used as Kubernetes’ backing store for all cluster data. If your Kubernetes cluster uses etcd as its backing store, make sure you have a back up plan for those data.
Controller Manager Control Plane component that runs controller processes.
Logically, each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
Some types of these controllers are:
Node controller: Responsible for noticing and responding when nodes go down. Job controller: Watches for Job objects that represent one-off tasks, then creates Pods to run those tasks to completion. Endpoints controller: Populates the Endpoints object (that is, joins Services & Pods). Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
Kubelet An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod.
The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers which were not created by Kubernetes.
Kube-proxy kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept.
kube-proxy maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster.
kube-proxy uses the operating system packet filtering layer if there is one and it’s available. Otherwise, kube-proxy forwards the traffic itself.
Take a pause here, and let’s talk a bit more about kubelet and kube-proxy