Kubernetes is the most popular open-source container orchestration platform. It came into limelight because of its seamless deployment, scaling, and management capabilities. Talking a bit about history, Kubernetes(also written as k8s) was originally open-sourced by Google in 2014 and is now maintained by Cloud Native Foundation, which is itself under the Linux Foundation. The term Kubernetes originates from Greek, meaning a helmsman or pilot (very much justifying its features)
Traveling back in time
Ever wondered how were things before the release of Kubernetes? Let’s call this traditional deployment era. So in this traditional deployment era, organizations ran applications on physical servers. So, why is that a problem, right? The problem lied in resource allocation. There was no way to define resource limits for applications in physical servers and this caused resource allocation issues. To understand this better, let’s consider a scenario in which two applications, Application A and Application B, which are deployed on a physical server. Now, for some unanticipated reason, Application A starts consuming most of the resources of the server, resulting in Application B to underperform. Of course, the most straight forward solution to this problem could have been to run the two applications on different servers, but there were two major problems associated with this approach — First, scaling would still be a problem and may also lead to underutilization of resources. Second, it would be an expensive affair for organizations to maintain different physical servers for every application. So, these problems gave birth to the virtualized deployment era. In this era, virtualization was introduced. It allowed running different virtual machines on a single physical server. Virtualization allowed applications to be isolated between VMs. Virtualization allowed better scalability and resource utilization in a physical server. Also, most importantly it pulled down the hardware cost drastically. Now let’s talk about the Container deployment era. This is the era we are in. Containers are similar to VMs but they are lightweight and have relaxed isolation properties to share the OS among the applications, which was not the case with VMs (every VM is a full machine running all the components, including its own operating system). No doubt, containers have become more popular because of the agility, resource utilization, and other necessary capabilities associated with it.
Why Kubernetes?
Containers have become the popular and preferred way to run anything from a small microservice to a large application, especially since the Docker containerization project launched in 2013. In fact, containers are the easiest way to bundle and run any application. But why do you need Kubernetes for this right? Large, distributed containerized applications can become increasingly difficult to manage and co-ordinate. Also, a lot of time can be wasted in orchestrating the containers which could have otherwise been utilized improving the existing ones or developing new ones. Consider a situation — In your production environment, several containers are running and you need to make sure that there is no downtime. Suddenly a container goes down and another needs to start. Wouldn’t this be easier if this behavior was handled by a system? Here is where Kubernetes comes to the rescue. Kubernetes provides a framework to run distributed systems resiliently. It takes care of scaling and failover. Kubernetes provides many useful features like Service discovery and load balancing, storage orchestration, automated rollouts and rollbacks, self-healing, secrets management, and many more. So it's evident that Kubernetes has placed its foot strong in container revolution.
Kubernetes and Docker
I have seen a lot of confusion in this area. The general misconception people hold is — Kubernetes replaces Docker. But no, that’s not the case. Kubernetes doesn’t replace Docker, rather it augments and supports Docker. Although Kubernetes does replace some technologies that were born from docker, like Docker Swarm. Docker Swarm is a container orchestrator just like Kubernetes, but it comes bundled up with Docker. It is very much possible to user Docker Swarm instead of Kubernetes (if you want), but lately Docker inc. has chosen to make Kubernetes a part of the Docker community and Docker Enterprise Edition. More details here.
While it has become a general practice to use Kubernetes with Docker but it can be used with any container system which conforms to Open Container Initiative(OCI) standards.
Kubernetes Architecture
Curious about how Kubernetes works? What are the different concepts and abstractions in Kubernetes? Here's an answer to all your questions.
Talking about the architecture of Kubernetes, a lot of words cross my mind. Let’s take it one by one.
Clusters
In simple words, the cluster is a collection of machines running Kubernetes. Every Kubernetes cluster has a master, which is the control plane (responsible for maintaining the desired state of the cluster, such as which applications are running and which container images they use) and one or more compute machines or nodes. In a way, cluster in the heart of Kubernetes’ key advantage — ability to schedule and run containers across a group of machines, be it physical or virtual, on-prem or in the cloud.
Node and Pod
A Kubernetes cluster consists of a set of worker machines which is called Node. Every cluster has at least one worker node. It is the node that runs containerized applications. To be specific, Kubernetes runs the workload by placing containers into Pods to run on Nodes. A node may be a virtual machine or a physical machine depending on the cluster. Each node contains services necessary to run Pods, managed by the control plane. The components of a node include the kubelet, a container runtime, and the kube-proxy. Kubelet is an agent that runs on each node in a cluster and makes sure that containers are running in a pod. Container runtime is software that is responsible for running containers, for example, Docker, containerd, CRI-O, and many more. Kube-proxy is a network proxy that runs on each node in the cluster. It maintains network rules on nodes. These network rules allow network communication to pods from network sessions, inside or outside the cluster.
Conclusion
Kubernetes is not a traditional, all-inclusive PaaS(Platform as a Service) system. Since Kubernetes operates at the container level rather than at the hardware level it provides some generally applicable features common to PaaS. Kubernetes has been designed with 15 years on running containerized applications at a scale at Google. It has already been adopted by many organizations now.
- SAP Managed Tags:
2 Comments
