How can Kubernetes help you to manage your containers?

In this section, we will focus on Kubernetes, which is the purpose of this book.

Kubernetes – designed to run workloads in production

If you open the official Kubernetes website (at https://kubernetes.io), the title you will see is Production-Grade Container Orchestration:

Figure 1.8: The Kubernetes home page showing the header and introducing Kubernetes as a production container orchestration platform

Those four words perfectly sum up what Kubernetes is: it is a container orchestration platform for production. Kubernetes does not aim to replace Docker or any of the features of Docker or other container engines; rather, it aims to manage the clusters of machines running container runtimes. When working with Kubernetes, you use both Kubernetes and the full-featured standard installations of container runtimes.

The title mentions production. Indeed, the concept of production is central to Kubernetes: it was conceived and designed to answer modern production needs. Managing production workloads is different today compared to what it was in the 2000s. Back in the 2000s, your production workload would consist of just a few bare-metal servers, if not even one on-premises. These servers mostly ran monoliths directly installed on the host Linux system. However, today, thanks to public cloud platforms such as Amazon Web Services (AWS) or Google Cloud Platform (GCP), anyone can now get hundreds or even thousands of machines in the form of instances or virtual machines with just a few clicks. Even better, we no longer deploy our applications on the host system but as containerized microservices on top of Docker Engine instead, thereby reducing the footprint of the host system.

A problem will arise when you must manage Docker installations on each of these virtual machines on the cloud. Let’s imagine that you have 10 (or 100 or 1,000) machines launched on your preferred cloud and you want to achieve a very simple task: deploy a containerized Docker app on each of these machines.

You could do this by running the docker run command on each of your machines. It would work, but of course, there is a better way to do it. And that’s by using a container orchestrator such as Kubernetes. To give you an extremely simplified vision of Kubernetes, it is a REST API that keeps a registry of your machines executing a Docker daemon.

Again, this is an extremely simplified definition of Kubernetes. In fact, it’s not made of a single centralized REST API, because as you might have gathered, Kubernetes was built as a suite of microservices.

Also note that while Kubernetes excels at managing containerized workloads, it doesn’t replace virtual machines (VMs) entirely. VMs can still be valuable for specific use cases, such as running legacy applications or software with complex dependencies that are difficult to containerize. However, Kubernetes is evolving to bridge the gap between containers and VMs.

KubeVirt – a bridge between containers and VMs

KubeVirt is a project that extends Kubernetes’ ability to manage virtual machines using the familiar Kubernetes API. This allows users to leverage the power and flexibility of Kubernetes for VM deployments alongside containerized applications. KubeVirt embraces Infrastructure as Code (IaC) principles, enabling users to define and manage VMs declaratively within their Kubernetes manifests. This simplifies VM management and integrates it seamlessly into existing Kubernetes workflows.

By incorporating VMs under the Kubernetes umbrella, KubeVirt provides a compelling approach for organizations that require a hybrid environment with both containers and VMs. It demonstrates the ongoing evolution of Kubernetes as a platform for managing diverse workloads, potentially leading to a more unified approach to application deployment and management.

We have learned about containers and the complications of managing and orchestrating containers at a large scale. In the next section, we will learn about the history and evolution of Kubernetes.