The Key Concepts of Kubernetes

Understanding How Kubernetes Works

In this article, I’ll explain the fundamental components of the Kubernetes operating philosophy. To understand how Kubernetes works, there are two related concepts you need to understand.

1. Kubernetes Object Model

2. Principle Of Declarative Management

The first, Kubernetes object model. Each thing Kubernetes manages is represented by an object, and you can view and change these objects’ attributes and states.

The second is the principle of declarative management. Kubernetes expects you to tell it what you want the state of the objects under its management to be. It will work to bring that state into being and keep it there.

Formally, a Kubernetes object is defined as a persistent entity that represents the state of something running in a cluster, its desired state, and its current state. Various kinds of objects represented are;

· Containerized applications,

· The resources that are available to them, and

· The policies that affect their behavior.

Kubernetes objects have two important elements.

Object Spec

You give Kubernetes an object spec for each object you want to create. With this spec, you define the desired state of the object by providing the characteristics that you want. The object status is simply the current state of the object provided by the Kubernetes control plane. By the way, we use the term Kubernetes control plane to refer to the various system processes that collaborate to make a Kubernetes cluster work. Each object is of a certain type or kind, as Kubernetes calls them.

Pods

Pods are the basic building block of the standard Kubernetes model, and they’re the smallest deployable Kubernetes object. You may be surprised to see me write that. Maybe you were expecting me to write that the smallest Kubernetes object is the container. Not so. Every running container in a Kubernetes system is in a pod.

A pod embodies the environment where the containers live, and that environment can accommodate one or more containers. If there is more than one container in a pod, they are tightly coupled and share resources, including networking and storage. Kubernetes assigns each pod a unique IP address. Every container within a Pod shares the network namespace, including IP address and network ports. Containers within the same pod can communicate through localhost, the famous 127.0.0.1 IP address that you pranked your friends with back in school. A pod can also specify a set of storage volumes to be shared among its containers.

Let’s consider a simple example where you want three instances of the Nginx web server each in its own container running all the time. How is this achieved in Kubernetes?

Remember that Kubernetes embodies the principle of declarative management. You declare some objects to represent those Nginx containers. What kind of object? Perhaps pods. Now it is Kubernetes’ job to launch those pods and keep them in existence. But be careful. Pods are not self‑healing. If we want to keep all our Nginx web servers not just in existence, but also working together as a team. We might want to ask for them to use a more sophisticated kind of object.

Let’s suppose that we have given Kubernetes a desired state that consists of three Nginx pods always kept running. We did this by telling Kubernetes to create and maintain one or more objects that represent them. Now Kubernetes compares the desired state to the current state.

Let’s imagine that our declaration of three Nginx containers is completely new. The current state does not match the desired state. So Kubernetes, specifically its control plane, will remedy the situation. Because the number of desired pods running we declared is three, and zero are presently running, three will be launched. And the Kubernetes control plane will continuously monitor the state of the cluster, endlessly comparing reality to what has been declared and remedying the state as needed.

These are the basics of how Kubernetes works.