Kubernetes help overcoming container Orchestration

Kubernetes is an open-source container-orchestration system for automating computer application deployment, scaling, and management. The Docker adoption is still growing exponentially, more and more companies have started using it in Production. It is important to use an orchestration platform to scale & manage your containers. Imagine a situation where you have been using Docker for a little while, and have deployed on a few different servers. Your application starts getting massive traffic, and you need to scale up fast, how will you go from few servers to thousands servers and how will you decide which container should go where. How would you monitor all these containers and make sure they are restarted if they exit?

Here comes the need for container orchestration tool which solve all the above mentioned problem in one click & Kubernetes is one of the best tool for such use cases & increase in adoption is showcased by a number of influential companies which have integrated the technology into their services.

Use Cases

let me have some common use cases to demonstrate Kubernetes’ capabilities. The use cases can be utilized together for different setups.

Self-Healing and Scaling Services

For simplicity, K8s process units can be detailed as pods and services. A pod is the smaller deployment unit available on Kubernetes. A pod can contain several containers that will have some related communication—such as network and storage. Services are the interface that provides accessibility to a set of containers. These services can be for internal or public access and can load balance several container instances.

Pods are mortal: once finished, they vanish from the cluster. Pod termination can be natural or through an error. A deployment is the most modern Kubernetes module to create and maintain pods. Using a single description file, a developer can specify everything necessary to deploy, keep running, scale, and upgrade the pod. One of the advantages of K8s is that it’s easy to understand what the platform is doing.

Serverless, with Server

Serverless architecture has taken the world by a storm since AWS launched Lambda. The principle is simple: just develop the code, and don’t worry about anything else. Server and scalability are handled by the cloud provider and code just has to be developed as functions that handle specific events: from HTTP requests to queue messages.

Vendor lock-in is the major disadvantage of this solution. It almost impossible to change cloud providers without refactoring most of the code. There are some solutions like Serverless that seek to standardize function code across clouds. Another solution is to use a Kubernetes cluster to create a vendor-free serverless platform. As mentioned above, K8S abstracts away the difference between cloud servers. Currently, two popular frameworks virtualize the cluster as a serverless platform: Kubeless and Fission.

Optimized Resource Usage with Namespaces

A K8s namespace is also known as a virtual cluster. Namespaces create a virtually separated cluster inside the real cluster. Clusters without namespaces probably have test, staging and production clusters. Virtual clusters usually waste some resources because they do not undergo continuous testing, and because staging is used from time to time to validate the work of a new feature. By using a virtual cluster, or a namespace, an operations team can use the same set of physical machines for different sets depending on a given workload.

Namespaces are closely related to DNS because services located within the same namespace are accessible through their names. Namespaces offer a good solution for creating similar environments that locate services through network names: instances from different namespaces will find their dependencies without having to take into account which namespace they are located in.

In addition, namespaces can have resource quotas: each virtual cluster can receive a defined allocation in order to avoid a resource competition between namespaces. This is particularly useful to avoid a production environment sharing computing resources with just a few priority environments. Finally, different permissions can be created with roles for each namespace in order to limit the number of individuals with access to production environments.

Hybrid and Multiclouds

A hybrid cloud utilizes computing resources from a local, conventional data center, and from a cloud provider. A hybrid cloud is normally used when a company has some servers in an on-premise data center and wants to use the cloud’s unlimited computing resources to expand or substitute company resources. A multicloud, on the other hand, refers to a cloud that uses multiple cloud providers to handle computing resources. Multiclouds are generally used to avoid vendor lock-in, and to reduce the risk from a cloud provider going down while performing mission-critical operations.

Both solutions are addressed by Kubernetes Federation. Multiple clusters — one for each cloud or on-premise data center — are created that are managed by the Federation. The Federation synchronizes computing resources, and even allows cross-cluster discovery: virtually any pod can communicate with a pod in another cluster without knowing the infrastructure.

The Federation setup is not simple, and there is a caveat: for obvious reasons, the solution doesn’t work on managed services like Google Kubernetes Engine, Azure Container Service or AWS EKS.

Let's take a look at how some of the most successful companies are successfully using Kubernetes for solving their challenges.

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," 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. 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.

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. "They 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."

WINK:

Challenge:- Building a low-latency, highly reliable infrastructure to serve communications between millions of connected smart-home devices and the company's consumer hubs and mobile app, with an emphasis on horizontal scalability, the ability to encrypt everything quickly and connections that could be easily brought back up if anything went wrong.

Solution:- Across-the-board use of a Kubernetes-Docker-CoreOS Container Linux stack.

Impact:- "Two of the biggest American retailers [Home Depot and Walmart] are carrying and promoting the brand and the hardware," Wink Head of Engineering Kit Klein says proudly – though he adds that "it really comes with a lot of pressure. It's not a retail situation where you have a lot of tech enthusiasts. These are everyday people who want something that works and have no tolerance for technical excuses." And that's further testament to how much faith Klein has in the infrastructure that the Wink team has built. With 80 percent of Wink's workload running on a unified stack of Kubernetes-Docker-CoreOS, the company has put itself in a position to continually innovate and improve its products and services. Committing to this technology "makes building on top of the infrastructure relatively easy."

Conclusion

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. Containers are becoming more and more popular in the software world and Kubernetes has become the industry standard for deploying containers in production.

Thanks for Reading!