Shulou(Shulou.com)06/02 Report--

This article focuses on "how to understand the building blocks choreographed by Kubernetes containers". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let the editor take you to learn how to understand the building blocks choreographed by Kubernetes containers.

Container orchestration is a tool and platform for automating, managing, and scheduling workloads defined by individual containers. There are many players in container orchestration, open source tools and proprietary tools such as Hashicorp's Nomad,Apache Mesos,AWS 's ECS and, of course, Google's Borg project (from which Kubernetes evolved). Each technology has its advantages and disadvantages, but the growing popularity of Kubernetes and the strong support of the community have made it clear that Kubernetes is now a well-deserved leader in container orchestration.

Kubernetes has obvious advantages when using open source software. As an open source platform, it can be deployed locally, and it makes sense to build other open source software on top of Kubernetes. In addition, as one of the most active open source ecosystems, it has more than 40000 contributors, and because many developers are already familiar with Kubernetes, users can more easily integrate Kubernetes-based open source solutions.

Decompose Kubernetes into building blocks

The easiest way to break down Kubernetes is to look at the core concepts of container orchestration. There are containers that serve as basic work modules and then build components on top of each other to tie the system together.

There are two core types of components:

Workload Manager: a way to host and run containers

Cluster Manager: a global approach to cluster decision-making

In Kubernetes terminology, these roles are performed by the worker node and the control plane (that is, the Kubernetes component) that manages the work.

Manage workload

The Kubernetes worker node has a nested component layer. At the base layer is the container itself.

Cluster and its components

Technically, the container runs in the container, which is the atomic object type in the Kubernetes cluster. The relationship between them is as follows:

Pod:Pod defines the logical unit of an application; it can contain one or more containers and each Pod is deployed to a node.

Node (Node): this is the virtual machine that acts as the workload in the cluster; Pod runs on the node.

Cluster: composed of work nodes and managed by the control plane.

Each node runs an agent called kublet, which is used to run the container in the container, while a kube-proxy is used to manage network rules.

Manage the cluster

The worker node manages the container, and the Kubernetes controls the cluster to make global decisions.

Control plane and its components

The control plane contains several basic components:

Memory storage (etcd): this is the back-end storage of all cluster data. Although you can use other backup storage etcd to run Kubernetes clusters, the default is open source distributed key storage.

Kube-scheduler: the scheduler is responsible for assigning the newly created Pod to the appropriate node.

API front end (kube-apiserver): this is the gateway where developers can interact with Kubernetes to deploy services, obtain metrics, check logs, and so on.

Controller manager (kube-controller-manager): monitors the cluster and makes the necessary changes to keep the cluster in the desired state, such as expanding nodes, maintaining the correct number of Pod for each replication controller, and creating new namespaces.

The control plane makes decisions to ensure the proper operation of the cluster and abstracts these decisions so that developers do not have to worry about them. Its function is very complex, and the users of the system need to understand the logical constraints of the control plane without getting caught up in details.

Use controllers and templates

The components of the cluster determine how the cluster manages itself, but how does the developer administrator tell the cluster to run the software? This is where controllers and templates come into play.

The controller orchestrates Pod, while Kubernetes uses different types of controllers for different use cases. But what matters are Jobs (for jobs that are completed at once) and ReplicaSets (for running a specified set of the same containers that provide services).

Like everything else in Kubernetes, these concepts make up the building blocks of more complex systems that allow developers to run flexible services. It is recommended that you do not use ReplicaSets directly, but rather use Deployments. The deployment manages the ReplicaSet on behalf of the user and allows rolling updates. Kubernetes deployment ensures that only certain Pod are turned off when they are updated, resulting in zero downtime deployment. Similarly, CronJobs manages jobs and is used to run planned and repetitive processes. Many layers of Kubernetes allow for better customization, but CronJobs and Deployments are sufficient for most use cases.

Once you know which controller to choose to run the service, you need to configure it using a template.

Template analysis

The Kubernetes template is an YAML file that defines the parameters used by the container to run. Like any form of code configuration, it has its own specific format and requirements and has a lot to learn. Fortunately, the information you need to provide is the same as the running code for any container orchestration:

Tell it how to name the application.

Tell it where to find an image of the container (often called the container registry)

Tell it how many instances to run (in the above terminology, the number of ReplicaSets)

Configuration flexibility is one of the many advantages of Kubernetes. Using different resources and templates, you can also provide cluster information about:

Environment variable

Password location

Any data volumes that should be mounted by the container for use

How much CPU and memory are allowed per container or Pod

Specific commands that the container should run

And there are many such examples.

Bring together all

Combine templates from different resources so that users can interoperate components in Kubernetes and customize them according to their own needs.

In a larger ecosystem, developers can combine Jobs,services and Deployments with ConfigMap and Secrets to form an application (during deployment), all of which must be carefully planned.

The management of these orchestration steps can be done manually or using one of the common package management options. Although it is absolutely possible to deploy according to Kubernetes API, it is usually a good idea to package the configuration (especially if the open source software to be delivered may be directly deployed and managed by someone who is not on the team).

The preferred package manager for Kubernetes is Helm. Using Helm doesn't take a lot of time, and it allows you to package your own software for easy installation on a Kubernetes cluster.

At this point, I believe you have a deeper understanding of "how to understand the building blocks choreographed by Kubernetes containers". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.