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

This article mainly introduces "what is the concept of Kubernetes". In daily operation, I believe that many people have doubts about the concept of Kubernetes. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts about "what is the concept of Kubernetes?" Next, please follow the editor to study!

Before starting to use, you should first understand the relevant concepts and terms about Kubernetes, which will be of great help to the follow-up study and use. There are many concepts of Kubernetes, it is recommended to strengthen the understanding, and be clear about the location and relevance! )

Most of the concepts in Kubernetes, such as Node, Pod, Replication Controller, Service, etc., can be regarded as resource objects. Almost all resource objects can be added, deleted, changed, looked up and stored in etcd through the kubectl tool (or API interface) provided by Kubernetes.

From this point of view, Kubernetes is actually a highly automated resource control system, which realizes the advanced functions of automatic control and automatic error correction by tracking and comparing the differences between the "resource expected state" saved in the etcd library and the "actual resource state" in the current environment.

This article introduces the basic concepts and terminology of an important resource object in Kubernetes, namely, Kubernetes.

1 、 Master

Master refers to the control node (Master Node) in the Kubernetes cluster. In each Kubernetes cluster, a Master is needed to manage and control the whole cluster, and almost all control commands are sent to it. It is responsible for the specific execution process, and all subsequent commands are basically run on the Master.

Master provides a unique perspective on clustering and has a range of components, such as Kubernetes API Server. API Server provides REST endpoints that can be used to interact with the cluster. Pod, replicas, and services can be maintained through the command line or a graphical interface.

Include the following components on Master:

Etcd: distributed key-value storage, which stores cluster state data and resource object data.

API Server (kube-api-server): the HTTP Rest interface provided by Kubernetes is the only entry for adding, deleting, modifying, querying and other operations of all resources, as well as the entry process controlled by the cluster.

Controllers (kube-controller-manager): the automation control center for all resource objects in Kubernetes.

Scheduler (kube-scheduler): the process responsible for resource scheduling (Pod scheduling), which is equivalent to the "dispatching room" of a bus company.

2 、 Node

Except for the other clusters in the Master,Kubernetes cluster, they are called Node, namely: Worker Node (work node). Like Master, Node can be either a physical host or a virtual machine.

Node is a workload node in a Kubernetes cluster. Each Node will be assigned some workload by Master. When a Node goes down, the workload on it will be automatically transferred to other nodes by Master.

The following key components are running on each Node:

Kubelet: responsible for container creation, start and stop and other tasks corresponding to Pod, and work closely with Master to achieve the basic functions of cluster management.

Kube-proxy: an important component that implements the communication and load balancing mechanism of Kubernetes Service.

Container Runtime: download image and run container. Such as the Docker engine, which is responsible for the creation and management of native containers.

Node can be dynamically added to the Kubernetes cluster during re-operation, and kubelet registers itself with Master by default. Once Node is included in the cluster management, the kubelet process will regularly report its own information to Master, such as operating system, Docker version, machine CPU and memory, and which Pod is currently running, so that Master can know the resource usage of each Node and implement an efficient and balanced resource scheduling strategy. When a Node does not report information for more than a specified time, it will be judged as "lost" by Master and marked as unavailable (Not Ready), and then Master will trigger the automatic process of "large workload transfer".

Execute the command kubectl get nodes to see how many Node there are in the cluster:

[xcbeyond@localhost ~] $kubectl get nodesNAME STATUS ROLES AGE VERSIONminikube Ready master 17d v1.19.0

Then view the details of a Node through kubectl describe node:

[xcbeyond@localhost ~] $kubectl describe node minikubeName: minikubeRoles: masterLabels: beta.kubernetes.io/arch=amd64 beta.kubernetes.io/os=linux kubernetes.io/arch=amd64 kubernetes.io/hostname=minikube kubernetes.io/os=linux. 3 、 Pod

Pod is the atomic object in Kubernetes and the basic building block.

Pod represents a set of running containers on the cluster. Pod is usually created to run a single master container. Pod can also run an optional sidecar container to implement complementary features such as logging. (for example, istio-proxy and istio-init containers that exist with applications in Service Mesh)

Deployment is usually used to manage Pod.

A Pod can contain multiple containers (other containers as functional additions), which are responsible for handling the container's data volume, secret key, and configuration.

The following figure shows the composition of the Pod, and we can see that each Pod has a special Pause container called the root container. The image corresponding to the Pause container is part of the Kubernetes platform. In addition to the Pause container, each Pod also contains one or more closely related user business containers.

Why did Kubernetes design a whole new concept of Pod, and why does Pod have such a special structure?

In the case of a group of containers as a unit, it is difficult for us to simply judge and effectively control the "whole". For example, if a container dies, is it considered as a whole death? This problem is solved simply and skillfully by introducing the Pause container which is business-independent and not easy to die as the root container of Pod and using its state to represent the state of the whole container group.

Multiple business containers in Pod share the IP of Pause containers and the Volume attached to Pause containers, which not only simplifies the communication problems between closely related business containers, but also solves the problem of file sharing between them.

Kubernetes assigns a unique IP address to each Pod, called Pod IP, and multiple containers in a Pod share Pod IP addresses.

Kubernetes requires the underlying network to support direct TCP/IP communication between any two Pod in the cluster, which is usually implemented by virtual layer 2 network technologies, such as Flannel, Open vSwitch, etc., so we need to keep in mind that in Kubernetes, the container in one Pod can communicate directly with the Pod container on another host.

There are two types of Pod:

Ordinary Pod

Static Pod (Static Pod)

The latter is special, it is not stored in Kubernetes's etcd storage, but in a file on a Node, and only starts running on this Node. Once a normal Pod is created, it is stored in etcd, then dispatched to a specific Node by Kubernetes Master and Binding, and then the Pod is instantiated into a set of related Docker containers by the kubelet process on the corresponding Node and started.

By default, when a container in Pod stops, Kubernetes automatically detects the problem and restarts the Pod (restart all containers in Pod). If the Node where the Pod is located is down, all Pod on this Node will be rescheduled to other nodes. The diagram of Pod, container, and Node is shown in the following figure.

The life cycle of Pod is uncertain and may be very short, but Pod has a strong ability to regenerate and can automatically restart after death (restart mechanism). Throughout the Pod lifecycle, it is usually possible to be in one of the following five stages:

Pending: Pod is correctly defined and submitted to Master, but the container image it contains has not been fully created. In general, it takes some time for Master to schedule Pod, it takes time for Node to download container images, and it takes some time to start the container.

Running: Pod has been assigned to a Node, and all containers have been created, at least one container is running, or a container is being started or restarted.

Succeeded: all containers in Pod have been run successfully and will not be restarted. This is a final state of Pod.

Failed: all the containers in Pod are finished, and at least one of them ends abnormally (exit code is not 0). This is also a final state of Pod.

Unknown: the status of the Pod cannot be obtained, usually due to the inability to communicate with the Node where the Pod is located.

4 、 Label

Label (tag) is another core concept in Kubernetes. A Label is a key-value pair of key=value, where key and value are specified by the user. Label can be attached to various resource objects, such as Node, Pod, Service, RC, etc. A resource object can define any number of Label, and the same Label can also be added to any number of resource objects. Label is usually determined when the resource object is defined, and can also be dynamically added or deleted after the object is created.

Generally speaking, we will define multiple label for the specified resource object to achieve multi-dimensional resource grouping management, so as to flexibly and conveniently manage resource allocation, scheduling, configuration, deployment and so on. For example, deploy different versions of applications to different environments, or monitor and analyze applications (logging, monitoring, alarms, etc.). Some common examples of Label are as follows:

Version tag: release:stable, release: canary

Environmental tags: environment: dev, environemnt: qa, environment: production

Architecture tags: tier: frontend, tier: backend, tier: middleware

……

After a resource object defines Label, you can query and filter the resource objects of Label through Label Selector (tag selector). Kubernetes implements an object query mechanism similar to SQL in this way.

Usually we specify the Label by describing the spec.selector field in the file, so that Kubernetes finds all the objects that contain the Label you specify and manages it.

Kubernetes currently supports two types of Label Selector:

Selector (Equality-based) based on the equation: the equation Ray expression matches the tag.

Collection-based Selector (Set-based): collection manipulation class expressions match tags.

Using Label, one or more groups of tags can be created for objects. Label and Label Selector together constitute the core application model of Kubernetes system, which enables objects to be finely grouped and managed, while achieving high availability of clusters.

5 、 Replication Controller

Replication Controller, referred to as RC, is one of the core concepts in Kubernetes, which defines an expected scenario, that is, to declare that the number of copies of a certain Pod meets a certain expected value at any time.

The definition of RC includes the following parts:

The expected number of copies of Pod.

The Label Selector used to filter the target Pod.

The Pod template used to create a new Pod when the number of copies of the Pod is less than expected.

Let's take a cluster with three Node as an example to illustrate how Kubernetes can automatically control the number of Pod replicas through RC.

If 2 copies of the redis-slave Pod are defined in our RC, it is possible for the system to create a Pod in two of the Node, as shown in the following figure:

If the Pod on Node 2 terminates unexpectedly, a new Pod will be automatically created and started according to the number of replicas defined by the RC, to ensure that there are always two Kubernetes running in the entire cluster. As shown in the following figure, Kubernetes may choose Node 3 or Node 1 to create a new Pod.

In addition, at run time, we can change the number of copies of RC to achieve dynamic Scaling of Pod, which can be done by executing the kubectl scale rc redis-slave-- replicas=3 command with one click. The execution result is shown in the following figure:

Note: deleting a RC does not affect the Pod created through that RC. To delete all Pod, you can set the value of replicas to 0, and then update the RC. In addition, kubectl provides stop and delete commands to delete all Pod controlled by RC and RC at once.

Finally, summarize the features and functions of RC:

In most cases, automatic control of the Pod creation process and the number of copies is achieved by customizing a RC.

The complete pod definition template is included in RC.

RC realizes the automatic control of pod copy through label selector mechanism.

By changing the number of Pod copies in RC, the capacity of Pod can be expanded and reduced.

By changing the mirror version of the Pod template in RC, you can achieve the rolling upgrade function of Pod.

6 、 Deployment

Deployment is a new concept introduced by Kubernetes in version 1.2, which is used to better solve the problem of Pod choreography. For this reason, Deployment uses Replica Set internally to implement it. No matter from the role of Deployment, the definition of YAML, or its specific command line operation, we can think of it as an upgrade of RC.

One of the biggest upgrades to Deployment over RC is that we can keep abreast of the progress of the current Pod deployment.

Typical usage scenarios:

Create a Deployment object to generate the corresponding Replica set and complete the creation of a copy of the Pod.

Check the status of the Deployment to see if the deployment action is complete (whether the number of Pod copies reaches the expected value).

Update Deployment to create a new Pod.

If the current Deployment is unstable, roll back to a previous version of Deployment.

Pause Deployment in order to modify multiple PodTemplateSpec configuration items at once, and then resume Deployment for a new release.

Extend Deployment to cope with high loads.

Check the Deployment status as an indicator of the success of the publication.

7 、 StatefulSet

In Kubernetes, Pod's management objects RC, Deployment, DaemonSet, and Job are all stateless services. But in reality, many services are stateful, especially some complex middleware clusters, such as MySQL cluster, MongoDB cluster, Kafka cluster, Zookeeper cluster and so on. These application clusters have something in common.

Each node has a fixed identity ID, through which members of the cluster can discover and communicate with each other.

The size of the cluster is relatively fixed, and the size of the cluster can not be changed at will.

Each node in the cluster is stateful and usually persists the data to permanent storage.

If the disk is damaged, a node in the cluster cannot function properly and the cluster function is impaired.

If we use RC or Deployment to control the number of Pod replicas to implement the above stateful cluster, we will find that the first point cannot be satisfied, because the name of Pod is randomly generated, and the IP address of Pod is determined and may change at runtime. We cannot determine a unique constant ID for each Pod in advance, in order to be able to recover a failed node on other nodes. Pod in this cluster needs to be attached to some kind of shared storage. to solve this problem, Kubernetes introduced PetSet, a new resource object from v1.4, and changed its name to StatefulSet,StatefulSet in v1.5. In essence, it can be regarded as a special variant of Deployment/RC, which has the following features.

Each Pod in StatefulSet has a stable, unique network identity that can be used to discover other members of the cluster. Suppose the name of StatefulSet is kafka, then the first Pod is kafak-0, the second Pod is kafak-1, and so on.

The start-stop order of the Pod copy controlled by StatefulSet is controlled, and when the nth Pod is operated, the previous Pod is already running and ready.

Pod in StatefulSet uses stable persistent storage volumes, which is realized through PV/PVC. When deleting Pod, StatefulSet-related storage volumes are not deleted by default (to ensure data security).

In addition to being bundled with PV volumes to store Pod state data, StatefulSet is also used with Headless Service, that is, which Headless Service it belongs to is declared in the definition of each StatefulSet. The key difference between Headless Service and normal Service is that it does not have a Cluster IP. If the DNS domain name of a Headless Service is resolved, the Endpoint list of all Pod corresponding to that Service is returned. In addition to Headless Service, StatefulSet creates a DNS domain name for each Pod instance controlled by StatefulSet. The format of this domain name is:

$(podname). $(headless service name)

For example, for a 3-node Kafka StatefulSet cluster, if the name of the corresponding Headless Service is kafka,StatefulSet and the name is kafka, then the DNS names of the three Pod in the StatefulSet are kafka-0.kafka, kafka-1.kafka and kafka-3.kafka, respectively. These DNS names can be fixed directly in the configuration file of the cluster.

8 、 Service

Service is also one of the core resource objects in Kubernetes. Each Service in Kubernetes is actually a "micro service" in the micro-service architecture that we often talk about. The resource objects such as Pod and RC we mentioned above are actually laying the groundwork for explaining Kubernetes Service. The following figure shows the logical relationship between Pod, RC, and Service.

From the figure, we can see that the Service of Kubernetes defines an access entry address for the service. The front-end application (Pod) accesses a group of cluster instances composed of Pod replicas behind it through this entry address, and the "seamless docking" between Service and its back-end Pod replica cluster is achieved through Label Selector. In fact, the function of RC is to ensure that the service capability and quality of Service are always in the expected standard.

9 、 Job

Job (batch task) starts multiple processes in parallel or serially to process a batch of work, and after the processing is completed, the whole batch task ends. Starting with Kubernetes 1.2, batch-type applications are supported, and a batch task Job can be defined and started through Kubernetes Job, a new resource object. Like RC, Deployment, and ReplicaSet, Job is also used to control a set of Pod containers.

Job is responsible for batch processing of temporary one-time tasks, that is, tasks that are executed only once, which ensures the successful completion of one or more Pod of the batch task.

10 、 Volume

Volume (Storage Volume) is a shared directory in Pod that can be accessed by multiple containers. The concept, purpose and purpose of Volume of Kubernetes are similar to those of Volume of Docker, but they are not equivalent. First, the Volume in Kubernetes is defined on Pod and then mounted to a specific file directory by multiple containers in a Pod; second, the data in Volume in Kubernetes is not lost. Finally, Kubernetes supports many types of Volume, such as advanced distributed file systems such as Gluster and Ceph.

11 、 Namespace

Namespace (Namespace) is another very important concept in Kubernetes systems. Namespace is used in many cases to achieve multi-tenant resource isolation. By "allocating" the resource objects within the cluster to different Namespce, Nameaspace forms logically grouped different projects, groups or user groups, so that different groups can be managed separately while sharing the resources of the whole cluster.

By default, the Kubernetes cluster creates a Namespace named default, which can be viewed through kubectl:

[xcbeyond@bogon ~] $kubectl get namespacesNAME STATUS AGEdefault Active 23distio-system Active 22dkube-node-lease Active 23dkube-public Active 23dkube-system Active 23dkubernetes-dashboard Active 23d

If Namespace is not specifically specified, user-created Pod, RC, Service, and so on will be created into the default default's Namespace.

12 、 Annotation

Annotation is similar to Label in that it is defined in the form of key/value key-value pairs. The difference is that Label has a strict naming convention, which defines the metadata (Metadata) of Kubernetes objects and is used for Label Selector. On the other hand, Annotation is the "additional" information defined by users arbitrarily, so that it can be found by external tools. In many cases, the modules of Kubernetes will mark the special information of resource objects by Annotation.

Generally speaking, the information recorded with Annotation is as follows:

Build information, release information, Docker image information, such as timestamp, release id number, PR number, image hash value, docker registry address, etc.

Address information of log library, monitoring library, analysis library and other resource libraries.

Program debugging tool information, such as tool, version number, etc.

Contact information such as the team, such as phone number, name of the person in charge, website, etc.

13 、 ConfigMap

In order to accurately and deeply understand the function and value of Kubernetes ConfigMap, we can start with Docker. As we all know, Docker solves the problem due to differences in application deployment by "packaging and solidifying" programs, dependent libraries, data and configuration files into an immutable image file, but this also brings another thorny problem, that is, how to modify the parameters in the configuration file during operation. To solve this problem, Docker provides the following two ways:

Parameters are passed through environment variables.

The configuration files outside the container are mapped into the container through Docker Volume.

In most cases, we prefer the latter approach, where most applications usually have multiple parameters and configuration files are mapped in a concise way. However, this approach also has obvious drawbacks: the configuration file must be created on the host before it can be mapped to the container when the container starts.

In a distributed system, it becomes even worse, and it is difficult to create the same configuration files on multiple hosts and to ensure the consistency of these profiles. To this end, Kubernetes introduced ConfigMap to solve this problem cleverly.

Treat all configuration items as key-value strings, such as: configuration items host=192.168.1.1, user=root, password=123456 are used to represent the configuration parameters to connect to the FTP server. As an item in the Map table, the data of the entire Map is persistently stored in the etcd of Kubernetes, and API is provided to facilitate Kubernetes-related components or application CRUD operations. Here, the Map used to store configuration parameters is the Kubernetes ConfigMap resource object.

ConfigMap mechanism: the ConfigMap stored in etcd is transformed into a configuration file in the target Pod by Volume mapping. No matter which server the target Pod is scheduled to, the mapping will be completed from Euro East. If the key-value data in ConfigMap is modified, the profile mapped to Pod is automatically updated. As a result, ConfigMap forms the simplest configuration center in the distributed system and does not invade the application.

14. Summary

These conceptual terms are also the core components of Kubernetes, and together they constitute the framework and computing model of Kubernetes. By combining them flexibly, users can configure, create and manage container clusters quickly and easily. In addition to the concepts introduced in this article, there are many other concepts in Kubernetes to assist in configuring resource objects, such as LimitRange, ResourceQuota, etc. More conceptual terms can be found in the official glossary: https://kubernetes.io/zh/docs/reference/glossary/?fundamental=true

At this point, the study of "what is the concept of Kubernetes" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.