As containerization technology was getting popular with each progressive day, the challenges were not left unnoticed. Container application is at its max speed, it is even predicted that by 2023 70% of the organizational infrastructure will be on containers. But containers alone weren’t able to meet all the industry requirements. It came into notice that they need some orchestration management tools. That is when Kubernetes(commonly referred to as k8s or Kube) came into notice.
What is Kubernetes?
Kubernetes is an open-source system that is an extensible, portable platform used for automating deployment, scaling, managing containerized workloads and services(deploying, managing, and scaling), that facilitates both declarative configuration and automation.
Kubernetes was originally designed and developed by the engineers of Google. Google was one of the early contributors to Linux container technology and open-sourced Kubernetes in 2014. Google sees the potential in the adoption of containers, microservices, and Kubernetes for cloud services.
How Kubernetes work
Since it is an orchestration system, it manages the lifecycle of containerized applications across an entire fleet. Several containers running the same application are grouped and these containers act as replicas and serve to load balance incoming requests. Kubernetes then supervises these groups, ensuring that they are operating correctly. This is done to ensure that the application which is deployed on containers does not face the problem of downtime. If a container needs to be restarted or acquire more resources, Kubernetes will manage it by restarting it, scaling up, or scaling down.
All the machines in a cluster are considered as a single pool of resources. Kubernetes takes the responsibility of managing a distributed operating system by effectively managing the scheduling, allocating the resources, monitoring the health of the infrastructure continuously, and even by maintaining the desired state of infrastructure and workloads. Kubernetes is an operating system that is capable of running modern applications across multiple clusters and infrastructures on various cloud services and private data center environments. Kubernetes works with a head and worker architecture just like any other mature distributed system. The head nodes typically run the control plane responsible for scheduling and managing the life cycle of workloads. The worker nodes act as the workhorses that run applications. The collection of head nodes and worker nodes becomes a cluster.
The DevOps team is responsible for managing the cluster talk to the control plane’s API via the command-line interface (CLI) or third-party tools. The users access the applications running on the worker nodes. The applications are composed of one or more container images that are stored in an accessible image registry. The architecture it creates is known as master-worker architecture.
Features of Kubernetes
- Automates various manual processes: Kubernetes will control for you which server will host the container, how it will be launched, etc.
- Interacts with several groups of containers: Kubernetes can manage more clusters at the same time.
- Provides additional services: It offers various other features like security, networking, and storage services.
- Self-monitoring: Kubernetes checks constantly the health of nodes and containers and hosts another if found unhealthy.
- Horizontal scaling: Kubernetes allows you to scale resources not only vertically but also horizontally, easily and quickly.
- Storage orchestration: Kubernetes mounts and adds a storage system of your choice to run apps.
- Automated rollouts and rollbacks: if after a change to your application something goes wrong, Kubernetes will rollback for you.
- Container balancing: Kubernetes has the ability to predict the best location to place containers.
- Run everywhere: Kubernetes is an open-source tool and it can be run everywhere like on-premises, hybrid, or public cloud infrastructure, letting you move workloads to anywhere you want.
Kubernetes vs docker
Kubernetes is meant to run across a cluster while Docker runs on a single node. Kubernetes pods are the scheduling units that can contain one or more containers in the Kubernetes ecosystem, which are distributed among nodes to provide high availability. Kubernetes with Docker is robust:
- Makes our infrastructure more robust and your app more highly available. Your app will remain online, even if some of the nodes go offline.
- Makes our application more scalable. If your app starts to get a lot more load and you need to scale out to be able to provide a better user experience, it is simple to spin up more containers or add more nodes to your Kubernetes cluster.
Kubernetes and Docker work together. Docker provides an open standard for packaging and distributing containerized applications. Using Docker, we can build and run containers and store and share container images. One can easily run a Docker build on a Kubernetes cluster.
The architecture of Kubernetes
A Kubernetes cluster consists of a set of worker machines, called nodes, that run containerized applications. Every cluster has at least one worker node which is a single host which is capable of running on a physical or virtual machine. A node should run both Kube-proxy, minikube, and kubelet which are considered as a part of the cluster. The worker node hosts the Pods that are the main components of the application workload. A pod is a group of containers and the most basic execution unit of Kubernetes. If Kubernetes is an operating system, a pod represents a set of processes where each process may be mapped to a container running on the cluster.
The pod serves as the core unit of workload management for Kubernetes, acting as the logical boundary for containers sharing the same execution context and resources. The control plane manages the worker nodes and the pods in the cluster. In production environments, the control plane usually runs across multiple computers and a cluster usually runs multiple nodes, providing fault-tolerance and high availability.
Control Pane Components
It is the main entry point for administrators and users to manage the various nodes. It makes global decisions about the cluster as well as detecting and responding to cluster events. Operations are issued to it either through HTTP calls or connecting to the machine and running command-line scripts. It contains the following parts
It is responsible for exposing the Kubernetes API and it is the front end of the Kubernetes control plane. The main implementation of a Kubernetes API server is kube-apiserver. It is designed to scale horizontally. We can run several instances of kube-apiserver and balance traffic between those instances.
The consistent and highly-available key-value store is used as Kubernetes backing store for all cluster data and it needs a backing plan to store the data.
Its role is to watch for newly created Pods with no assigned node, and selects a node for them to run on. Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and deadlines.
Its responsibility is to run controller processes. Each controller is a separate process, but to reduce complexity, they are all compiled into a single binary and run in a single process.
Some types of these controllers are:
- Node controller: Responsible for noticing and responding when nodes go down.
- Job controller: Responsible for monitoring Job objects that represent one-off tasks, then creates Pods to run those tasks to completion.
- Endpoints controller: Populates the Endpoints object.
- Service Account & Token controllers: Create default accounts and API access tokens for new namespaces.
It embeds cloud-specific control logic and provides the facility to link clusters into your cloud provider’s API, and separates the components that interact with that cloud platform from components that just interact with your cluster.
The cloud-controller-manager only runs controllers that are specific to current cloud providers. It combines several logically independent control loops into a single binary that you run as a single process.
The following controllers can have cloud provider dependencies:
- Node controller: For checking the cloud provider to determine if a node has been deleted in the cloud after it stops responding.
- Route controller: For setting up routes in the underlying cloud infrastructure.
- Service controller: For creating, updating, and deleting cloud provider load balancers.
Node components run on every node, maintaining running pods and providing the Kubernetes runtime environment.
An agent that runs on each node in the cluster. It makes sure that containers are running in a Pod. The kubelet takes a set of PodSpecs that are provided through various mechanisms and ensures that the containers described in those PodSpecs are running and healthy. The kubelet doesn’t manage containers that were not created by Kubernetes.
kube-proxy is a network proxy that runs on each node in your cluster, implementing part of the Kubernetes Service concept. It maintains network rules on nodes. These network rules allow network communication to your Pods from network sessions inside or outside of your cluster. kube-proxy uses the operating system packet filtering layer if there is one and it’s available. Otherwise, kube-proxy forwards the traffic itself.
The container runtime is the software that is responsible for running containers.
Kubernetes supports several container runtimes: Docker, containers, CRI-O, and any implementation of the Kubernetes CRI.
AppDirect offers a subscription commerce platform that eliminates the complexity of building a recurring business model. It gives the ability to sell any product, through any channel, on any device — as a service. The platform efficiently powers all sales, direct or indirect, lowering customer acquisition costs, and uniquely unifies identity, data, mobile, and billing management for digital services to extend customer lifetime value. they supply scores of subscriptions worldwide for organizations like Jaguar Land Rover, Comcast, Sage, Keller Williams, ADP, and Deutsche Telekom. They faced a challenge by deploying on tomcat infrastructure, the full reason was complex. there have been plenty of manual steps involved, with one engineer building a feature, then another team reading the change. the corporate realized it needed a much better infrastructure to both support that growth and increase velocity. They were trying to find something where teams can deploy their services faster. Today, AppDirect has quite 50 microservices in production and 15 Kubernetes clusters deployed on AWS and on-premise around the world. Their technical engineer stated that Moving to Kubernetes and services has meant that deployments became much faster thanks to less dependency on custom-made, brittle shell scripts with SCP commands. The time to deploy a replacement version has shrunk from 4 hours to some minutes.
adidas has its roots in Germany but we are a truly global company. Their team is a group of optimists driven by action, with a desire to shape a better future together. They believe ‘Impossible is Nothing’ and see the world of sports where they could provide the best quality products to meet all athletes meet as Athletes do not settle for average. They have a clear mission: To be the best sports brand in the world. They faced the challenges in accessing a developer VM which was earlier accessed by sending a request form with the purpose, the title of the project, who’s responsible, and the internal cost center a call so that they can do recharges. They were looking for ways to shorten the time the whole procedure 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. 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