Kubernetes

Introduction

Kubernetes (from other Greek: κυβερνήτης – “handler”, “helmsman”, often also used by the numeronym K8s) – open source software for orchestrating containerized applications – automating their deployment, scaling and coordination in a cluster.

Maintenance of containerization technologies, including Docker rkt, it is also possible to support hardware virtualization technologies.

The original version was developed by Google for internal use, and later transferred to the Cloud Native Computing Foundation.

Used by a number of large organizations and Internet projects, in particular, the infrastructure of the Wikimedia Foundation moved from self-developed software for organizing clusters to Kubernetes. Written in language Go .

Concepts

Under (pod)

A pod, also known as a pod, cocoon, is the basic unit for running and managing applications: one or more containers that Run on a single node is guaranteed, resource sharing and interprocess interaction are provided and unique within the cluster is provided. IP address .

The latter allows applications deployed on the pod to use fixed and predefined port numbers without the risk of conflict.

Pods can be directly controlled using the Kubernetes API or managed by the controller.

Node.

A separate physical or virtual machine on which application containers are deployed and executed.

Each node in the cluster contains services for running applications in containers. (e.g., Docker, and components designed to centralized management of the node.

The assembly consists of the following components:

Kubelet

Container Runtime (CRI - Container Runtime Interface. For example, Docker, containerd, CRI-O, katacontainers, gVisor

Kube-proxy

One or more pods.

Some cloud providers provide K8s without nodes. The so-called nodeless K8s. You can work there directly with pods, and everything is lower. Hidden «under the hood»

Tom (volume)

Shared storage resource for sharing from containers deployed within a single feed.

Tags and selectors

All control objects (nodes, pods, containers) in Kubernetes are marked with labels (label), label selectors (label selector) are requests that allow you to get a link to objects corresponding to one of the labels.

Tags and selectors are the main mechanism of Kubernetes, which allows you to choose which of the objects to use for the requested operation.

Service

A service in Kubernetes is a set of logically related subsets and access policies.

For example, a service may correspond to one layer of software designed according to the principles of a multi-layered software architecture.

The set of pods corresponding to the service is obtained as a result of the selector of the corresponding label.

Kubernetes provides services discovery and routing on request.

In particular, the system is able to reassign the IP address and domain name of the service necessary for accessing the service to various feeds that are part of it.

This ensures load balancing in the style of Round robin DNS between the pods, whose labels correspond to the service, as well as correct operation in the event that one of the nodes of the cluster failed and placed on it pods were automatically moved to other nodes.

By default, the service is available inside the managed Kubernetes cluster – for example, the pods of the backend are grouped to ensure load balancing and in this form are provided to the frontend.

Also, the cluster can be configured to provide access to its components from the outside as a single frontend.

Controller (controller)

A process that manages the state of a cluster by attempting to bring it from the actual state to the desired state; it does so by operating on a set of pods defined by label selectors that are part of the controller definition.

The controllers are executed by the Kubernetes Controller Manager component.

One of the types of controllers, the most famous is the Replication Controller, which provides scaling by running a specified number of copies of the feed in the cluster.

It also ensures the launch of new instances of the feed in the event that the node on which the sub controlled by this controller operates fails.

Other controllers included in the core Kubernetes system include a “DaemonSet Controller,” which provides feed running on each machine (or a subset of machines), and a “Job Controller” for running pods that run before completion, for example as part of a batch task.

Operators

A specialized type of Kubernetes software designed to be included in a cluster of services that maintain their state between executions (stateful), such as DBMS, monitoring or caching systems.

The purpose of operators is to provide the ability to manage stateful applications in the Kubernetes cluster in a transparent way and hide the details of their settings from the main process of managing the Kubernetes cluster.

Architecture and components

The system implements the "lead-led" architecture: a cluster management subsystem is allocated, and some components are controlled by individual, led nodes (called Kubernetes nodes themselves).

Management subsystem

The control subsystem provides communication and load distribution within the cluster; components of the subsystem can be executed on one or more parallel operating master nodes, jointly providing a high availability mode.

Etcd

The control subsystem component responsible for the consistent storage of cluster configuration data is, in a sense, the distributed equivalent of the /etc Unix directory.

Implemented as a lightweight distributed NoSQL-DBMS of the key-value class; created as part of the CoreOS project.

API server

Key management subsystem component providing REST-style API (using communication in format) JSON on top of HTTP transport, and used to organize external and internal access to Kubernetes functions.

The API server updates the state of objects stored in etcd, allowing its clients to manage the distribution of containers and loads between the nodes of the managed system.

Scheduler (scheduler)

A management subsystem component that selects which node to run a specific sub, based on resource availability criteria.

The scheduler monitors the use of resources at each node, ensuring that the load is distributed so that it does not exceed the available amount of resources.

For this purpose, the scheduler must have information about the resources available at each of the nodes, the requirements for them from the managed subs, as well as various additional user restrictions and policies, such as QoS, affinity and anti-affinity requirements (affinity – bundles or decoupling of control objects with each other), data localization.

In other words, the role of the scheduler is to find and provide resources depending on the requests that arise in connection with the boot.

Controller Manager (Controller Manager)

A process that executes core Kubernetes controllers such as DaemonSet Controller and Replication Controller. Controllers interact with the Kubernetes API server to create, update and delete the resources they manage (pods, service entry points, and others).

Kubectl

A command-line interface, along with an API that manages resources controlled by Kubernetes.

Node components

The operation procedure of Kubernetes is that the resources of nodes are dynamically distributed among the subheads executed on them.

Each node in the cluster contains a number of typical components.

The container launch service provides performance functions for containers of the appropriate type (depending on the type of container engine used).

In terms of the Kubernetes software environment, containers are encapsulated in pods, with the containers themselves being the lowest-level software components that Kubernetes software interacts with.

They, in turn, contain executable applications, libraries and other resources necessary for the operation of these applications.

For the outside world, containers are accessible through the IP address assigned to each of the pods.

1. Kubelet

Kubelet is the main Kubernetes agent. Each node works on a Kubelet.

Responsible for the status of the execution of pods on the node - monitors whether each of the containers is correctly executed while in working condition.

Kubelet allows you to start, stop and manage application containers organized into pods. After kubelet is installed on the node, it registers in the cluster and monitors the API server to receive tasks.

Functionally, Kubelet can be considered as an analogue of supervisord.

If it is found that one of the subs is in an incorrect state, the component tries to re-deploy and restart it on the node.

The status of the node itself is sent to the control subsystem every few seconds in the form of a heartbeat message.

If the master node, based on the content of these messages or their absence, detects that a particular node is not working properly, the Replication Controller process tries to restart the necessary pods on another node that is in working condition.

2. Container runtime

Container Runtime (CRI - Container Runtime Interface. For example, Docker, containerd, CRI-O, katacontainers, gVisor

3. Kube-proxy

A component that is a combination of a network proxy server and a load balancer.

The network layer operations implemented in it use the abstraction of the service.

It is responsible for routing incoming traffic to specific containers operating within the feed located on the node.

Routing is provided based on the IP address and port of the incoming request.

4. cAdvisor

The Kubernetes internal monitoring system agent that collects performance metrics and container usage information operating within the node, such resources as the operating time of the CPU, RAM, the load on the file and network systems.

5. Pods

There may be several subs in the node. Each sub can contain several containers.

Development and deployment

Kubernetes provides a range of tools for integrating the development and deployment of software running the system.

Among the most frequently used tools for this purpose:

• Helm is the official Kubernetes package manager, the functional equivalent of apt-get and yum.
  
  
• Minikube - a specialized configuration of Kubernetes, designed for deployment on a local machine, for example, a developer's computer, is used for studying and local experiments on Kubernetes;
  
  
• Skaffold is a Google utility for local development in Kubernetes.
  
  

For each of these tools, there are alternatives, for example, Terraform is sometimes used instead of Helm.

The opposite approach adopted by the developers of Helm, when resource files are placed in the repository of the version control system and work with them is carried out only through it (usually Git, this method of work is offered by the kubecfg project), has also gained some popularity.

The category of methodologies providing for the configuration of Kubernetes infrastructure in Git in the spirit of “infrastructure as code” is denoted by “GitOps” (implemented by ArgoCD, Flux, werf projects).

Documentation.

Deployment: https://kubernetes.io/docs/concepts/workloads/controllers/deployment

Pods: https://kubernetes.io/docs/concepts/workloads/pods/

Service: https://kubernetes.io/docs/concepts/services-networking/service/

Ingress: https://kubernetes.io/docs/concepts/services-networking/ingress/

Ingress Controller: https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

Volumes and Claims: https://kubernetes.io/docs/concepts/storage/persistent-volumes/

Secrets: https://kubernetes.io/docs/concepts/configuration/secret/

ConfigMaps: https://kubernetes.io/docs/concepts/configuration/configmap/

Article author: Andrei Olegovich