Kubernetes : A Container Management Tool
By: Niharika Dhanik
Tags: Tinder, Containers, Airbnb, Kubernetes, Pinterest

With day-to-day advancement in technology and in context with keeping up with the pace, there's a constant need for learning new tech stacks to solve modern day tech-problems. This blog will give an overview of the contents related to Containers and Kubernetes.

So let's hop on the track starting with the introduction to one of the most popular Devops tool in the market — Kubernetes, and its importance in today’s IT processes.

Kubernetes

Back To Beginning —

Early on, organizations ran applications on physical servers. If multiple applications were to run on a physical server, there will be instances where one application would take up most of the resources, and as a result, the other applications would underperform. A solution for this would be to run each application on a different physical server which is not feasible plus expensive.

Series of Deployment Era

As a solution, Virtualization was introduced which allows running multiple Virtual Machines (VMs) on a single physical server’s CPU. It llows better utilization of resources in a physical server and allows better scalability because an application can be added or updated easily, reduces hardware costs

Containers are similar to VMs, but they have provide extra benefits like better efficiency, resource isolation (predictable application performance), resource utilization (high efficiency and density) and much more. Therefore, containers are considered lightweight.

Why Containerize?

Containerization was a concept basically sold out on the basis of scaling. Containers package the application and isolate them from the host and everything else which makes containers fast, reliable, lightweight and scalable. They start and stop much faster than virtual machines. They are more portable as it hosts environment that are very consistent, no matter which type of operating system is being hosted on them

The Problem With Scaling!

Even though containers solved maximum of the problems aroused by the ancient architectures but still it lacks few aspects when considered on a large scale. For example, we have an container but we want to scale it upto 2 ,3 or maybe more of them. On a smaller pace, it might look smooth but what if we have to scale it to 50 or maybe 100 or 10000…..!!

Here comes the problems related to scaling :

Communication : all of the containers work together to basically host the application on the server but if none are of them are communicating with each other, the hosting will be ruined.

Management : checking on the active status, condition and related management of containers

Traffic distributions : distribution of traffic throughout the network of containers and not overloading one with all the traffic

Appropriate deployment : making sure that all the containers are followed in the same cloud and not plugged at different locations which will increase complications.

Auto Scaling : at times traffic increases by 2x, 3x during peak hours, which might be manageable for short term but not recurringly, leading to crashing of servers due to extensive requests per sec/per minute.

As scaling related customization was complex in Virtual Machines, containers were brought into existence. But due to increased demand of containerization, we needed something that could help in managing containers in bulk. That is when KUBERNETES CAME INTO EXISTENCE..!!

What is Kubernetes?

Kubernetes, also known as K8s, is an open source Container Management (CM) tool which automates container deployment, (de)scaling and container load balancing. It can speed up the development process by making easy, automated deployments, updates (rolling-update) and by managing apps and services with almost zero downtime. In other words, you can cluster together groups of hosts running Linux containers, and kubernetes will help you to easily and efficiently manage those clusters.

Written in Golang, it has a huge community because it was first developed by Google and later donated to CNCF.

History of Kubernetes —

The name Kubernetes originates from Greek, meaning helmsman or pilot. Google open-sourced the Kubernetes project in 2014.

Google relied on containers and their advantages in many ways. In order to manage containers, the employees developed the “Borg” project. Borg was an undisputed competitive advantage of Google because it utilized the machines much better than purely virtualized operations. Google strengthened its market position by being able to provide huge infrastructure landscapes at a much lower cost.

The big hit for the general public was the idea of making Borg available as an open-source solution under the name “Kubernetes”

The Kubernetes Infrastructure —

Kubernetes is structured according to the so-called master-slave architecture. The master component controls the nodes on which the containers run. The Kubernetes architecture includes:

Kubernetes Infrastructure

Kubernetes Master: The Kubernetes Master is the central control element that distributes and manages the containers on the nodes. To achieve high availability, several masters can be distributed.

Nodes: A node, also called a worker machine or minion, can be a virtual machine (VM) or a physical server. The pods run on the nodes.

Pods: Pods are the smallest deployable unit. They contain one or more containers that share the allocated resources.

etcd: The etcd stores the configurations of the Kubernetes cluster and thus represents the key value database. The communication with the etcd manages Kubernetes via the API server.

API server: The API server contains all the information of the etcd, making it one of the most important components of Kubernetes. Via REST interfaces, for example, it communicates with all internal and external services of the Kubernetes Cluster.

kube-scheduler: The kube-scheduler monitors and manages the utilization of the nodes by deciding on the basis of the resources on which node a pod starts.

Controller Manager: The Controller Manager contains all control mechanisms and is therefore an essential component for monitoring. It communicates with the API server to read and write all statuses.

Features Of Kubernetes —

Automatic Binpacking

Service Discovery & Load Balancing

Secret & Configuration Managements

Automatic Rollbacks & Rollouts

Storage Orchestration

Self Healing

Batch Execution

Horizontal Scaling

Real World Use Cases —

I) Tinder

Due to high traffic volume, Tinder’s engineering team faced challenges of scale and stability. What did they do?

The answer is, of course, Kubernetes.

Tinder on Kubernetes

Almost three years ago, Tinder decided to move its platform to Kubernetes. Kubernetes afforded them an opportunity to drive Tinder Engineering toward containerization and low-touch operation through immutable deployment.

When scaling became critical, they often suffered through several minutes of waiting for new EC2 instances to come online. The idea of containers scheduling and serving traffic within seconds as opposed to minutes was appealing to them .Tinder’s engineering team solved interesting challenges to migrate 200 services and run a Kubernetes cluster at scale totaling 1,000 nodes, 15,000 pods, and 48,000 running containers.

Starting January 2018, they worked their way through various stages of the migration effort. They started by containerizing all of the services and deploying them to a series of Kubernetes hosted staging environments. Beginning October, they began methodically moving all of their legacy services to Kubernetes. By March the following year, they finalized their migration and the Tinder Platform now runs exclusively on Kubernetes.

Was that easy? No way. However, they had to do it for the smooth business operations going further. One of their engineering leaders said, “As we onboarded more and more services to Kubernetes, we found ourselves running a DNS service that was answering 250,000 requests per second.” Tinder’s entire engineering organization now has knowledge and experience on how to containerize and deploy their applications on Kubernetes.

II) Airbnb

Airbnb’s transition from a monolithic to a microservices architecture is pretty amazing. They needed to scale continuous delivery horizontally, and the goal was to make continuous delivery available to the company’s 1,000 or so engineers so they could add new services. Airbnb adopted Kubernetes to support over 1,000 engineers concurrently configuring and deploying over 250 critical services to Kubernetes (at a frequency of about 500 deploys per day on average).

Airbnb on Kubernetes

In the conference regarding deployment of Airbnb on Kubernetes, Melanie Cebula, an infrastructure engineer at Airbnb said “Kubernetes uses containers. Containers have portability, immutability, and reproducibility. So having that immutable state where things don’t change, just being able to roll back and know that we’re rolling back to this particular version of our code. And then YAML, for all of its defects, it is human friendly and it’s a standard format, and was definitely better than ERB format, which is what we were using before. So that’s how we landed on Kubernetes.

As of a week ago, 50% of our services are now in Kubernetes. This is about the services we know, so several hundred services. About 250 of those are in the critical production path. Some of these are more critical than others. But for example, when you go to airbnb.com, and you look at that homepage, that’s a Kubernetes service. When you type into the search bar, “I am looking for homes in London this weekend to stay at,” that’s also a Kubernetes service. Similarly, when you’re booking that Airbnb and making those payments, that’s also going through Kubernetes services.”

III) Pinterest

With over 250 million monthly active users and serving over 10 billion recommendations every single day, the engineers at Pinterest knew these numbers are going to grow day by day, and they began to realize the pain of scalability and performance issues.

Pinterest on Kubernetes

Their initial strategy was to move their workload from EC2 instances to Docker containers; they first moved their services to Docker to free up engineering time spent on Puppet and to have an immutable infrastructure.

The next strategy was to move to Kubernetes. Now they can take ideas from ideation to production in a matter of minutes, whereas earlier they used to take hours or even days. They have cut down so much overhead cost by utilizing Kubernetes and have removed a lot of manual work without making engineers worry about the underlying infrastructure.

Gearing up for a Kubernetes future—

Around the world, many CIO’s and technologists have chosen to use Kubernetes, and it is expected to evolve much more in the years to come.

One of the more interesting aspects of these various case studies is their consistency. Regardless of industry — be it financial services, media, retail, or technology — organizations of all sizes are grappling with a sea change in the way software is built and deployed in small, discrete, loosely coupled chunks of functionality.

There are also consistencies among challenges and benefits. All of these organizations are compelled to enact sometimes painful cultural change and face significant recruitment challenges as they compete for talent with the likes of Google and Facebook. All of these organizations are also starting to speed up their development cycles, reduce costs and downtime, and deliver more value more frequently for their customers.

At this point, it’s not an exaggeration to say that any organization that fails to get up to speed with containers and Kubernetes will struggle to keep up in our new, accelerated, software-driven world.