Sitemap

About Kubernetes and its use cases

8 min readDec 26, 2020

--

Press enter or click to view image in full size

Hello Everyone, I have written about kubernetes, its features, reason for kubernetes drops docker and some companies use cases as with its challenge and solutions.

What is Kubernetes?

Kubernetes (“also known as K8s”) is an open-source system for automating deployment, scaling, and management of containerized applications.

It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

Kubernetes defines a set of building blocks (“primitives”), which collectively provide mechanisms that deploy, maintain, and scale applications based on CPU, memory or custom metrics. Kubernetes is loosely coupled and extensible to meet different workloads. This extensibility is provided in large part by the Kubernetes API, which is used by internal components as well as extensions and containers that run on Kubernetes. The platform exerts its control over compute and storage resources by defining resources as Objects, which can then be managed as such.

Kubernetes follows the primary/replica architecture. The components of Kubernetes can be divided into those that manage an individual node and those that are part of the control plane.

Features of Kubernetes

Press enter or click to view image in full size
  1. Automatic Binpacking- It Automatically places containers based on their resource requirements and other constraints, while not sacrificing availability. Mix critical and best-effort workloads in order to drive up utilization and save even more resources.
  2. Service Discovery & Load Balancing- There is no need to modify your application to use an unfamiliar service discovery mechanism. Kubernetes gives Pods their own IP addresses and a single DNS name for a set of Pods, and can load-balance across them.
  3. Storage Orchestration- It Automatically mount the storage system of your choice, whether from local storage, a public cloud provider such as GCP or AWS, or a network storage system such as NFS, iSCSI, Gluster, Ceph, Cinder, or Flocker.
  4. Self Healing- It restarts the containers that fail, replaces and reschedules containers when nodes die, kills containers that don’t respond to your user-defined health check, and doesn’t advertise them to clients until they are ready to serve.
  5. Secret & Configuration Management- It deploy and update secrets and application configuration without rebuilding your image and without exposing secrets in your stack configuration.
  6. Batch Execution- In addition to services, Kubernetes can manage your batch and CI workloads, replacing containers that fail, if desired.
  7. Horizontal Scaling- It scales your application up and down with a simple command, with a UI, or automatically based on CPU usage.
  8. Automatic Rollbacks & Rollouts- Kubernetes progressively rolls out changes to your 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, Kubernetes will rollback the change for you. Take advantage of a growing ecosystem of deployment solutions.

Why Kubernetes Drops Docker?

Press enter or click to view image in full size

Kubernetes drops docker because kubernetes created a standard interface called CRI for all runtime implementations. Docker declined to support that directly, so for backwards compat there is a service called “dockershim” which speaks CRI protocol on one side and Dockerd protocol on the other. We would rather not keep supporting that forever since it’s a maintenance burden and the whole point of CRI was that upstream projects can choose to support Kubernetes by implementing CRI themselves in their own daemons (like dockerd).

But that said, Dockerd doesn’t actually run containers anymore. Long ago the Docker project spun that off into a second daemon called Containerd, which Dockerd talks to. Containerd does natively speak CRI and can be used as a runtime directly. This is 99% the same codepath as used by docker run, just without going through Dockerd. The one main limitation here is that by default, Containerd doesn’t show non-Dockerd containers via the Dockerd interfaces, so docker ps can’t see stuff created by CRI. Instead there is a separate tool crictl that has a similar overall CLI but speaks to the CRI side of the universe.

Industries Use Cases

1. HUAWEI

Press enter or click to view image in full size

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.

2. ING

Press enter or click to view image in full size

Challenge- After undergoing an agile transformation, ING realized it needed a standardized platform to support the work their developers were doing. “Our DevOps teams got empowered to be autonomous,” says Infrastructure Architect Thijs Ebbers. “It has benefits; you get all kinds of ideas. But a lot of teams are going to devise the same wheel. Teams started tinkering with Docker, Docker Swarm, Kubernetes, Mesos. Well, it’s not really useful for a company to have one hundred wheels, instead of one good wheel.

Solution- Using Kubernetes for container orchestration and Docker for containerization, the ING team began building an internal public cloud for its CI/CD pipeline and green-field applications. The pipeline, which has been built on Mesos Marathon, will be migrated onto Kubernetes. The bank-account management app Yolt in the U.K. (and soon France and Italy) market already is live hosted on a Kubernetes framework. At least two greenfield projects currently on the Kubernetes framework will be going into production later this year. By the end of 2018, the company plans to have converted a number of APIs used in the banking customer experience to cloud native APIs and host these on the Kubernetes-based platform.

Impact- “Cloud native technologies are helping our speed, from getting an application to test to acceptance to production,” says Infrastructure Architect Onno Van der Voort. “If you walk around ING now, you see all these DevOps teams, doing stand-ups, demoing. They try to get new functionality out there really fast. We held a hackathon for one of our existing components and basically converted it to cloud native within 2.5 days, though of course the tail takes more time before code is fully production ready.”

3. SPOTIFY

Press enter or click to view image in full size

Challenge- Launched in 2008, the audio-streaming platform has grown to over 200 million monthly active users across the world. “Our goal is to empower creators and enable a really immersive listening experience for all of the consumers that we have today — and hopefully the consumers we’ll have in the future,” says Jai Chakrabarti, Director of Engineering, Infrastructure and Operations. An early adopter of microservices and Docker, Spotify had containerized microservices running across its fleet of VMs with a homegrown container orchestration system called Helios. By late 2017, it became clear that “having a small team working on the features was just not as efficient as adopting something that was supported by a much bigger community,” he says.

Solution- “We saw the amazing community that had grown up around Kubernetes, and we wanted to be part of that,” says Chakrabarti. Kubernetes was more feature-rich than Helios. Plus, “we wanted to benefit from added velocity and reduced cost, and also align with the rest of the industry on best practices and tools.” At the same time, the team wanted to contribute its expertise and influence in the flourishing Kubernetes community. The migration, which would happen in parallel with Helios running, could go smoothly because “Kubernetes fit very nicely as a complement and now as a replacement to Helios,” says Chakrabarti.

Impact- The team spent much of 2018 addressing the core technology issues required for a migration, which started late that year and is a big focus for 2019. “A small percentage of our fleet has been migrated to Kubernetes, and some of the things that we’ve heard from our internal teams are that they have less of a need to focus on manual capacity provisioning and more time to focus on delivering features for Spotify,” says Chakrabarti. The biggest service currently running on Kubernetes takes about 10 million requests per second as an aggregate service and benefits greatly from autoscaling, says Site Reliability Engineer James Wen. Plus, he adds, “Before, teams would have to wait for an hour to create a new service and get an operational host to run it in production, but with Kubernetes, they can do that on the order of seconds and minutes.” In addition, with Kubernetes’s bin-packing and multi-tenancy capabilities, CPU utilization has improved on average two- to threefold.

I hope you read very carefully that article. If you like it then give some likes and comment as well in this article.

THANKING YOU

PRABHJEET SINGH

--

--