CASE STUDY | KUBERNETES |
Container
Before we try to understand Kubernetes, Let us spend little time on clarifying what a container is, and why they are so popular. After all, there is no point in talking about containers orchestrator (Kubernetes) without knowing what a container is :)
A “container” is… a container to hold all the stuff we put in. Duh!
Stuff like our application code, dependent libraries, and its dependencies all the way up to the kernel. The key concept here is isolation. Isolate all our stuff from the rest so that we have better control of them. There are three types of isolation provided by containers
Workspace isolation (Process, Network)
Resource isolation (CPU, Memory)
File system isolation (Union File System)
Think of containers like VMs on diet. They are lean, fast (to startup) and small. And, all this was not built ground up. Instead, they used the constructs (like cgroups, namespaces) to build a nice abstraction over it
Now we know what containers are, It is easy to understand why they are very popular. Instead of just shipping only our application binary / code, It is possible to ship the whole environment needed to run our application in a practical way as containers can be built as very small units. A perfect fix for “It works in any machine” issue.
History
Kubernetes was founded by Joe Beda, Brendan Burns, and Craig McLuckie, who were quickly joined by other Google engineers including Brian Grant and Tim Hockin, and was first announced by Google in mid-2014. Its development and design are heavily influenced by Google’s Borg system, and many of the top contributors to the project previously worked on Borg. The original codename for Kubernetes within Google was Project 7, a reference to the Star Trek ex-Borg character Seven of Nine. The seven spokes on the wheel of the Kubernetes logo are a reference to that codename. The original Borg project was written entirely in C++, but the rewritten Kubernetes system is implemented in Go.
Originally developed by Google as an offshoot of its Borg project, Kubernetes has established itself as the de facto standard for container orchestration. It’s the flagship project of the Cloud Native Computing Foundation, which is backed by such key players as Google, Amazon Web Services (AWS), Microsoft, IBM, Intel, Cisco, and RedHat.
Kubernetes continues to gain popularity with DevOps practitioners because it allows them to deliver a self-service Platform-as-a-Service (PaaS) that creates a hardware layer abstraction for development teams. Kubernetes is also extremely portable. It runs on Amazon Web Services (AWS), Microsoft Azure, the Google Cloud Platform (GCP), or on-premise installations. We can move workloads without having to redesign your applications or completely rethink your infrastructure — which helps you to standardize on a platform and avoid vendor lock-in.
Why you need Kubernetes and what it can do
Containers are a good way to bundle and run our applications. In a production environment, we 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?
That’s how Kubernetes comes to the rescue! Kubernetes provides us with a framework to run distributed systems resiliently. It takes care of scaling and failover for our application, provides deployment patterns, and more. For example, Kubernetes can easily manage a canary deployment for our system.
Kubernetes provides us with:
- Service discovery and load balancing Kubernetes can expose a container using the DNS name or using their own IP address. If traffic to a container is high, Kubernetes is able to load balance and distribute the network traffic so that the deployment is stable.
- Storage orchestration Kubernetes allows us to automatically mount a storage system of your choice, such as local storages, public cloud providers, and more.
- Automated rollouts and rollbacks We can describe the desired state for our deployed containers using Kubernetes, and it can change the actual state to the desired state at a controlled rate. For example, We can automate Kubernetes to create new containers for our deployment, remove existing containers and adopt all their resources to the new container.
- Automatic bin packing We provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. We tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto our nodes to make the best use of our resources.
- Self-healing Kubernetes restarts containers that fail, replaces containers, kills containers that don’t respond to our user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
- Secret and configuration management Kubernetes lets us store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys. we can deploy and update secrets and application configuration without rebuilding our container images, and without exposing secrets in our stack configuration.
When to use Kubernetes?
We need it when we get to this state, where there are too many containers to manage
Q: Where is my front end container, how many of them am I running?
A: Hard to tell. Use a container orchestrator
Q: How will I make my front end containers to talk to newly created backend containers?
A: Hardcode the IPs. Or, Use a container orchestrator
Q: How will I do rolling upgrades?
A: Manually hand holding in each step. Or, Use a container orchestrator
Why to prefer Kubernetes
There are multiple orchestrators like docker swarm, Mesos and Kubernetes. My choice is Kubernetes (and hence this article) because Kubernetes is …
… like lego blocks. It not only has the components needed to run a container orchestrator at scale, but also has the flexibility to swap different components in and out with custom ones. Want to have a custom scheduler, sure just plug it in. Need to have a new resource type, write a CRD. Also, the community is very active and evolving the tool rapidly
Now, that we have understood the need for Kubernetes, it’s a good time, that I tell us What is Kubernetes?
What Is Kubernetes?
Kubernetes is meant to simplify things and this article is meant to simplify Kubernetes for you! Kubernetes is a powerful open-source system that was developed by Google. It was developed for managing containerized applications in a clustered environment. Kubernetes has gained popularity and is becoming the new standard for deploying software in the cloud.
Kubernetes offers or in fact, it itself is a system that is used for running and coordinating applications across numerous machines. The system manages the lifecycle of containerized applications and services. For managing the lifecycle, it uses different methods that foster predictability, scalability, and high availability.
A Kubernetes user gets the freedom to decide as well as define how the applications should run and communicate. The user is also allowed to scale up/down the services, perform rolling updates, switch traffic between different application versions, and more. Kubernetes also offers different interfaces and platform primitives for defining/managing applications.
Kubernetes Features
The features of Kubernetes, are as follows:
- Automated Scheduling: Kubernetes provides advanced scheduler to launch container on cluster nodes based on their resource requirements and other constraints, while not sacrificing availability.
- Self Healing Capabilities: Kubernetes allows to replaces and reschedules containers when nodes die. It also kills containers that don’t respond to user-defined health check and doesn’t advertise them to clients until they are ready to serve.
- Automated rollouts & rollback: Kubernetes rolls out changes to the application or its configuration while monitoring application health to ensure it doesn’t kill all your instances at the same time. If something goes wrong, with Kubernetes you can rollback the change.
- Horizontal Scaling & Load Balancing: Kubernetes can scale up and scale down the application as per the requirements with a simple command, using a UI, or automatically based on CPU usage.
Kubernetes Architecture
Kubernetes Architecture has the following main components:
- Master nodes
- Worker/Slave nodes
Every Kubernetes cluster has two types of nodes (machines). Master and a Worker. As the name suggests, Master is to control and monitor the cluster where as the worker runs the payload (applications)
A cluster could work with a single master node. But better to have three of them for high availability (Known as HA Clusters)
I am going to discuss each one of them one by one. So, initially let’s start by understanding the Master Node.
Master Node
The master node is responsible for the management of Kubernetes cluster. It is mainly the entry point for all administrative tasks. There can be more than one master node in the cluster to check for fault tolerance.
As you can see in the above diagram, the master node has various components like API Server, Controller Manager, Scheduler and ETCD.
API Server : RESTful API server that exposes end points to operate the cluster. Almost all of the components in master and worker nodes communicates to this server to perform their duties
Control Manager : It is a control loop that watches the state of the cluster (gets this data by making calls to API server) and takes actions to bring it to the expected state
Scheduler: The scheduler schedules the tasks to slave nodes. It stores the resource usage information for each slave node.
etcd : Database to store all the data about kubernetes objects, their current state, access information and other cluster config information
Worker/Slave nodes
Worker nodes contain all the necessary services to manage the networking between the containers, communicate with the master node, and assign resources to the scheduled containers.
As we can see in the above diagram, the worker node has various components like Docker Container, Kubelet, Kube-proxy, and Pods.
Docker Container: Docker runs on each of the worker nodes, and runs the configured pods
kubelet : Is the heart of the worker node. It communicates with the master node API server and runs the containers scheduled for its node
kube Proxy : Takes care of networking needs of pods using IP tables / IPVS
Pod : The work horse of kubernetes which runs all your containers. You cannot run a containers inside kubernetes without a pod abstraction over it. A pod adds functionalities that is crucial to kuberenetes way of networking between containers
Kubernetes Usage Expanding in Large and Small Companies, CNCF Survey Shows
The State of Kubernetes report from VMware showed similar trends among large enterprises. 59% of respondents said they’re running Kubernetes in production. 33% operated 26 clusters or more, and 20% had more than 50 clusters in production. This report reminded readers that’s it’s still “early days.”
More than half of respondents (57%) are operating fewer than 10 Kubernetes clusters, and 60% are running less than half of their containerized workloads on Kubernetes. Early adopters of container technologies relied on other container orchestration tools (or no orchestration at all), and these environments remain in place.
Respondents to the CNCF survey identified further details about their Kubernetes deployments. Cluster ingress is dominated by nginx and HAProxy, with 62% and 22% usage, respectively. Envoy is one to watch, as it’s become the 3rd most popular option, and 29% are evaluating it for further use. Helm was the runaway favorite for packaging Kubernetes applications, with little else registering interest. When separating applications from each other, the preferred options were namespaces, and separate clusters.
The public cloud plays a big role for Kubernetes users. Amazon EKS and Google Kubernetes Engine (GKE) represented the top two management solutions, according to the CNCF report. 62% reported hosting in the public cloud, which was actually down from 2018 (77%). That’s likely due to “hybrid cloud” being a new option in 2019, as it garnered 38% of responses. The State of Kubenetes report painted a different picture, likely due to the respondents coming from solely large enterprises. 64% of respondents deployed Kubernetes on premises, and 31% were using multiple public cloud vendors.
The State of Kubernetes report went a step further and pointed out some of the decision-making challenges enterprises face when getting started with Kubernetes. 83% of respondents reported that more than one team was involved in choosing the product, with C-level executives playing a role 18% of the time. Interestingly, development teams were involved more than any other group. Some companies also appeared to be selecting technologies before deciding which problem to solve, for whom.
With more stakeholders at the table, complications arise. 40% of survey respondents cited a lack of internal alignment as a problem when selecting a Kubernetes distribution. Clearly, Kubernetes creates an opportunity to bring operators and developers closer together, but this has not been fully realized inside many companies.
Another misalignment identified by the State of Kubernetes report related to what impeded developer productivity. 29% of developers said that access to infrastructure was their top problem. Only 6% of executives answered that way. Rather, 49% of executives thought the top challenge for developers was the integration of new technologies. Only 29% of developers agreed.
Both surveys highlighted the benefits users saw by using Kubernetes, and cloud-native technologies. The CNCF respondents recognized faster deployment times, improved scalability and availability, and more cloud portability. The enterprises participating in the State of Kubernetes report realized benefits like improved resource utilization, faster software delivery, and reduced cloud costs, among others.
Kubernetes Market Share with its Competitors in Virtualization Management Software
We use the best indexing techniques combined with advanced data science to monitor the market share of over 12,500 technology products, including Virtualization Management Software. By scanning billions of public documents, we are able to collect deep insights on every company, with over 100 data fields per company at an average. In the Virtualization Management Software category, VMware vCenter has a market share of about 11.1%. Other major and competing products in this category include:
Industrial Use-Case
Who uses Kubernetes?
Companies
Developers
Kubernetes Integration
CASE STUDY
Kubernetes is adopted by number of industries, and after using they are getting a lots of advantages in terms of performance, Speed, Management and finally increased Net Worth by making Application’s Infrastructure strong that helps them to reach number of customers
1.)Adidas
Challenge
In recent years, the adidas team was happy with its software choices from a technology perspective — but accessing all of the tools was a problem. For instance, “just to get a developer VM, you had to send a request form, give the purpose, give the title of the project, who’s responsible, give the internal cost center a call so that they can do recharges,” says Daniel Eichten, Senior Director of Platform Engineering.
“The best case is you got your machine in half an hour. Worst case is half a week or sometimes even a week.”
Solution
To improve the process, “we started from the developer point of view,” and looked for ways to shorten the time it took to get a project up and running and into the adidas infrastructure, says Senior Director of Platform Engineering Fernando Cornago. They found the solution with containerization, agile development, continuous delivery, and a cloud native platform that includes Kubernetes and Prometheus.
Impact
Just six months after the project began, 100% of the adidas e-commerce site was running on Kubernetes. Load time for the e-commerce site was reduced by half. Releases went from every 4–6 weeks to 3–4 times a day.
With 4,000 pods, 200 nodes, and 80,000 builds per month, adidas is now running 40% of its most critical, impactful systems on its cloud native platform.
“For me, Kubernetes is a platform made by engineers for engineers. It’s relieving the development team from tasks that they don’t want to do, but at the same time giving the visibility of what is behind the curtain, so they can also control it.”
— FERNANDO CORNAGO, SENIOR DIRECTOR OF PLATFORM ENGINEERING AT ADIDAS
2.)AWS
Kubernetes on AWS
Kubernetes is open source software that allows you to deploy and manage containerized applications at scale. Kubernetes manages clusters of Amazon EC2 compute instances and runs containers on those instances with processes for deployment, maintenance, and scaling. Using Kubernetes, you can run any type of containerized applications using the same toolset on-premises and in the cloud.
AWS makes it easy to run Kubernetes in the cloud with scalable and highly-available virtual machine infrastructure, community-backed service integrations, and Amazon Elastic Kubernetes Service (EKS), a certified conformant, managed Kubernetes service.
How it works?
Kubernetes works by managing a cluster of compute instances and scheduling containers to run on the cluster based on the available compute resources and the resource requirements of each container. Containers are run in logical groupings called pods and you can run and scale one or many containers together as a pod.
Kubernetes control plane software decides when and where to run your pods, manages traffic routing, and scales your pods based on utilization or other metrics that you define. Kubernetes automatically starts pods on your cluster based on their resource requirements and automatically restarts pods if they or the instances they are running on fail. Each pod is given an IP address and a single DNS name, which Kubernetes uses to connect your services with each other and external traffic.
Why Kubernetes?
Because Kubernetes is an open source project, you can use it to run your containerized applications anywhere without needing to change your operational tooling. Kubernetes is maintained by a large community of volunteers and is always improving. Additionally, many other open source projects and vendors build and maintain Kubernetes-compatible software that you can use to improve and extend your application architecture.
3.)Bose
Challenge
A household name in high-quality audio equipment, Bose has offered connected products for more than five years, and as that demand grew, the infrastructure had to change to support it. “We needed to provide a mechanism for developers to rapidly prototype and deploy services all the way to production pretty fast,” says Lead Cloud Engineer Josh West.
In 2016, the company decided to start building a platform from scratch. The primary goal: “To be one to two steps ahead of the different product groups so that we are never scrambling to catch up with their scale,” says Cloud Architecture Manager Dylan O’Mahony.
Solution
From the beginning, the team knew it wanted a microservices architecture. After evaluating and prototyping a couple of orchestration solutions, the team decided to adopt Kubernetes for its scaled IoT Platform-as-a-Service running on AWS. The platform, which also incorporated Prometheus monitoring, launched in production in 2017, serving over 3 million connected products from the get-go. Bose has since adopted a number of other CNCF technologies, including Fluentd, CoreDNS, Jaeger, and OpenTracing
Impact
With about 100 engineers onboarded, the platform is now enabling 30,000 non-production deployments across dozens of microservices per year. In 2018, there were 1250+ production deployments. Just one production cluster holds 1,800 namespaces and 340 worker nodes. “We had a brand new service taken from concept through coding and deployment all the way to production, including hardening, security testing and so forth, in less than two and a half weeks,” says O’Mahony.
“At Bose we’re building an IoT platform that has enabled our physical products. If it weren’t for Kubernetes and the rest of the CNCF projects being free open source software with such a strong community, we would never have achieved scale, or even gotten to launch on schedule.”
4.)Huawei
Challenge
A multinational company that’s the largest telecommunications equipment manufacturer in the world, Huawei has more than 180,000 employees. In order to support its fast business development around the globe, Huawei has eight data centers for its internal I.T. department, which have been running 800+ applications in 100K+ VMs to serve these 180,000 users. With the rapid increase of new applications, the cost and efficiency of management and deployment of VM-based apps all became critical challenges for business agility. “It’s very much a distributed system so we found that managing all of the tasks in a more consistent way is always a challenge,” says Peixin Hou, the company’s Chief Software Architect and Community Director for Open Source. “We wanted to move into a more agile and decent practice.”
Solution
After deciding to use container technology, Huawei began moving the internal I.T. department’s applications to run on Kubernetes. So far, about 30 percent of these applications have been transferred to cloud native.
Impact
“By the end of 2016, Huawei’s internal I.T. department managed more than 4,000 nodes with tens of thousands containers using a Kubernetes-based Platform as a Service (PaaS) solution,” says Hou. “The global deployment cycles decreased from a week to minutes, and the efficiency of application delivery has been improved 10 fold.” For the bottom line, he says, “We also see significant operating expense spending cut, in some circumstances 20–30 percent, which we think is very helpful for our business.” Given the results Huawei has had internally — and the demand it is seeing externally — the company has also built the technologies into FusionStage™, the PaaS solution it offers its customers.
“If you’re a vendor, in order to convince your customer, you should use it yourself. Luckily because Huawei has a lot of employees, we can demonstrate the scale of cloud we can build using this technology.”
5.)IBM
IBM Cloud offers public, private, and hybrid cloud functionality across a diverse set of runtimes from its OpenWhisk-based function as a service (FaaS) offering, managed Kubernetes and containers, to Cloud Foundry platform as a service (PaaS). These runtimes are combined with the power of the company’s enterprise technologies, such as MQ and DB2, its modern artificial intelligence (AI) Watson, and data analytics services. Users of IBM Cloud can exploit capabilities from more than 170 different cloud native services in its catalog, including capabilities such as IBM’s Weather Company API and data services. In the later part of 2017, the IBM Cloud Container Registry team wanted to build out an image trust service.
The work on this new service culminated with its public availability in the IBM Cloud in February 2018. The image trust service, called Portieris, is fully based on the Cloud Native Computing Foundation (CNCF) open source project Notary, according to Michael Hough, a software developer with the IBM Cloud Container Registry team. Portieris is a Kubernetes admission controller for enforcing content trust. Users can create image security policies for each Kubernetes namespace, or at the cluster level, and enforce different levels of trust for different images. Portieris is a key part of IBM’s trust story, since it makes it possible for users to consume the company’s Notary offering from within their IKS clusters. The offering is that Notary server runs in IBM’s cloud, and then Portieris runs inside the IKS cluster. This enables users to be able to have their IKS cluster verify that the image they’re loading containers from contains exactly what they expect it to, and Portieris is what allows an IKS cluster to apply that verification.
Impact
IBM’s intention in offering a managed Kubernetes container service and image registry is to provide a fully secure end-to-end platform for its enterprise customers. “Image signing is one key part of that offering, and our container registry team saw Notary as the de facto way to implement that capability in the current Docker and container ecosystem,” Hough says. The company had not been offering image signing before, and Notary is the tool it used to implement that capability. “We had a multi-tenant Docker Registry with private image hosting,” Hough says. “The Docker Registry uses hashes to ensure that image content is correct, and data is encrypted both in flight and at rest. But it does not provide any guarantees of who pushed an image. We used Notary to enable users to sign images in their private registry namespaces if they so choose.”
“We see CNCF as a safe haven for cloud native open source, providing stability, longevity, and expected maintenance for member projects — no matter the originating vendor or project.”
6.) Pinterest.
Challenge
After eight years in existence, Pinterest had grown into 1,000 microservices and multiple layers of infrastructure and diverse set-up tools and platforms. In 2016 the company launched a roadmap towards a new compute platform, led by the vision of creating the fastest path from an idea to production,without making engineers worry about the underlying infrastructure.
Solution
The first phase involved moving services to Docker containers. Once these services went into production in early 2017, the team began looking at orchestration to help create efficiencies and manage them in a decentralized way. After an evaluation of various solutions, Pinterest went with Kubernetes.
Impact
“By moving to Kubernetes the team was able to build on-demand scaling and new failover policies, in addition to simplifying the overall deployment and management of a complicated piece of infrastructure such as Jenkins,” says Micheal Benedict, Product Manager for the Cloud and the Data Infrastructure Group at Pinterest. “We not only saw reduced build times but also huge efficiency wins. For instance, the team reclaimed over 80 percent of capacity during non-peak hours. As a result, the Jenkins Kubernetes cluster now uses 30 percent less instance-hours per-day when compared to the previous static cluster.”
“So far it’s been good, especially the elasticity around how we can configure our Jenkins workloads on that Kubernetes shared cluster. That is the win we were pushing for.”
7.)Pokemon Go
How was ‘Pokemon Go’ able to scale so efficiently & became so successful? The answer is Kubernetes. Pokemon Go was developed and published by Niantic Inc. 500+ million downloads and 20+ million daily active users.
Pokemon Go engineers never thought their user base would increase exponentially surpassing the expectations within a short time, they were not ready for it, and even the servers couldn’t handle this much traffic.
Challenge
The horizontal scaling on one side but Pokemon Go also faced a severe challenge when it came to vertical scaling because of the real-time activity by millions of users worldwide. Niantic was not prepared for this.
Solution
The magic of containers. The application logic for the game ran on Google Container Engine (GKE) powered by the open source Kubernetes project. Niantic chose GKE for its ability to orchestrate their container cluster at planetary-scale, freeing its team to focus on deploying live changes for their players.
In this way, Niantic used Google Cloud to turn Pokémon GO into a service for millions of players, continuously adapting and improving. This got them more time to concentrate on building the game’s application logic and new features rather than worrying about the scaling part.
Conclusion
Kubernetes has not only helped in the vertical and horizontal scaling of containers but have turned the tables for innovative engineering expectations. It has been succeeded in deployment for an initial estimate of servers. Also, it has gained so much popularity in a short span of time. Hence, most of the industry engineers will respond with inspiring stories to get their businesses right on tracks.
