How Kubernets Works

In this blog post, I would like to explain my understanding of how Kubernets works.

What is Kubernets?

In the home page of the official Kubernets documentation there is the following definition for Kubernets:

Kubernetes is an open source system for managing containerized applications across multiple hosts, providing basic mechanisms for deployment, maintenance, and scaling of applications. 

In this other page of the documentation there is another good definition:

Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. Google open-sourced the Kubernetes project in 2014. Kubernetes builds upon a decade and a half of experience that Google has with running production workloads at scale, combined with best-of-breed ideas and practices from the community.

Kubernets can be considered a container platform, a microservice platform, a portable cloud platform and much more. Imagine you want to develop an application that must scale horizontally, use storage and networking. Kubernets allows you to implement it easily with the simplicity of a PaaS, flexibility of an IaaS and portable cross provider infrastructure.

Kubernetes inherit from traditional, all-inclusive PaaS several features like deployment, logging, monitoring, scaling and load balancing, but it must not be confused with PaaS because it operates at container level instead of hardware level. For this reason, it is important to underline what Kubernets is not.

What Kubernets is not

In order to understand what Kubernets is, it is important to underline the differences with traditional PaaS. For this reason, I list here what traditional PaaS features are not present on Kubernets.

• It does not provide application level services like databases (i.e. MySQL), data-processing framework (i.e. Spark), cache, middleware and others. You can deploy these services on Kubernets and access to them via Open Service Broker.
• It does not store or build the source code and other Continuous Integration, Delivery and Deploys (CI/CD) features.
• No support for logging, monitoring, and alerting solutions.
• No limit on the type of applications supported. If an application runs on a container it can run on Kubernates.
• Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self.healing systems.

Containers vs Traditional Application approach

In a traditional application environment, there is a physical machine where runs an operating system, a set of libraries shared by applications. 

PHOTO

I worked with this approach for several decades and I know that it entangles each application executable, configuration, libraries, and lifecycles with each other and the operating system.

Kubernates enable a containerized approach where each application with its own libraries live in its own container and they run on top the operating system kernel.

PHOTO

Benefits of Containers

I already talked about benefits of application developed in containers instead of standalone and monolithic piece of software here.