Shulou(Shulou.com)05/31 Report--

This article introduces you how to summarize K8S knowledge points, the content is very detailed, interested friends can refer to, hope to be helpful to you.

Kubernetes is a container-based distributed resource management system: automatic deployment of containerized applications, scaling and management of resources.

If you want to use K8s to manage applications, first package the application as a container image (such as Docker image), and then use K8s to manage containers. K8s typical application scenarios:

In the micro-service scenario, when the request traffic increases and the number of backend services increases, the traffic decreases and the number of services decreases.

In big data scenario, spark and flink combined with Namespace of K8s to achieve multi-tenant resource isolation. For example, more work nodes, memory, cpu and other resources can be allocated to online computing during the day, while less offline computing can be allocated. In the early morning, offline tasks have to be pulled up, and more resources can be allocated to offline computing, so there can be less real-time computing.

1. K8s cluster components

Control Plane/Master

Master in Kubernetes refers to the cluster control node. In each Kubernetes cluster, a Master is needed to manage and control the whole cluster. Basically, all the control commands of Kubernetes are sent to it, and it is responsible for the specific execution process. Master usually occupies a separate server (three servers are recommended for high-availability deployment), mainly because it is too important and is the "head" of the entire cluster. If it is down or unavailable, then the management of container applications in the cluster will fail. Key services running on master:

◎ Kubernetes API Server (kube-apiserver): provides the key service process of HTTP Rest interface, which is the only entry for adding, deleting, modifying and querying all resources in Kubernetes, and is also the entry process controlled by the cluster.

◎ Kubernetes Controller Manager (kube-controller-manager): the automation control center for all resource objects in Kubernetes

◎ Kubernetes Scheduler (kube-scheduler): the process responsible for resource scheduling (Pod scheduling), such as listening on a newly created Pods without an assigned node, selecting a node, and running it.

◎ etcd:KV data storage service, where the data of all resource objects in Kubernetes is stored in etcd.

Node

In addition to the other machines in the Master,Kubernetes cluster that are called Node,Node as the working nodes in the cluster, running real applications, the minimum running unit managed by Kubernetes on Node is Pod. Like Master, Node can be either a physical host or a virtual machine. Node is a workload node in a Kubernetes cluster. Each Node is assigned some workload (Docker container) by Master. When a Node goes down, the workload on it is automatically transferred to other nodes by Master. Key services running on node:

◎ kubelet: responsible for the creation, start and stop and other tasks of containers corresponding to Pod, while working 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.

◎ Docker Engine (docker): the Docker engine, which is responsible for native container creation and management.

Node can be dynamically added to the Kubernetes cluster during runtime, provided that the above key processes have been correctly installed, configured, and started on this node, and kubelet registers itself with Master by default, which is the Node management recommended by Kubernetes. Once Node is included in the cluster management, the kubelet process will regularly report its intelligence to Master, such as the 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. On the other hand, when a Node does not report information for a specified time, it will be judged as "lost" by Master, the status of Node will be marked as unavailable (Not Ready), and then Master will trigger the automatic process of "workload transfer".

2 、 Pod

Pod is the smallest running unit managed by Kubernetes. Each Pod runs a special container called Pause, and the other containers are business containers. These business containers share the network stack of the Pause container and the Volume mount volume, so the communication and data exchange between them is more efficient. In the design, we can make full use of this feature to put a group of closely related service processes into the same Pod.

If two or more containers are tightly coupled and provide services as a whole, the two containers should be reported as a Pod;. For example, if you use Flume to collect Nginx logs, then you can put Nginx containers and Flume containers into one Pod. Multiple container applications belonging to the same Pod can communicate with each other only through localhost when they access each other, making this group of containers "bound" in one environment.

Kubernetes assigns a unique IP address to each Pod, which is called PodIP. Multiple containers in a Pod share the PodIP address. When Pod is restarted, the PodIP address will change.

Important parameters of the Pod definition file:

◎ spec.resources.limits.cpu, spec.resources.limits.memory: the maximum allowed amount of this resource cannot be breached. When a container tries to use more than this amount of resource, it may be "killed" and restarted by Kubernetes.

◎ spec.resources.requests.cpu, spec.resources.requests.memory: the minimum number of requests for this resource

◎ nodeSelector: the Label,Pod that sets the Node will be scheduled on the Node with these Lable. If you expect all copies of a certain Pod to run on one or more specified nodes, for example, you want to schedule the MySQL database to a target node with a SSD disk, then the NodeSelector attribute in the Pod template begins to play a role: 1) put the Node with the SSD disk with a custom label "disk=ssd" (2) set the value of NodeSelector to "disk: ssd" in the Pod template.

The kube-controller process filters the number of Pod replicas to be monitored through the LabelSelector defined on the resource object RC, so that the number of Pod replicas always conforms to the expected fully automatic control flow.

3 、 Label

Label is the equivalent of a familiar "tag". Defining a Label for a resource object is equivalent to tagging it, and then you can query and filter resource objects that own some Label through LabelSelector (tag selector).

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. We can realize the multi-dimensional resource grouping management function by bundling one or more different Label to the specified resource object, so as to manage the resource allocation, scheduling, configuration and deployment flexibly and conveniently. For example, deploy different versions of applications to different environments; monitor and analyze applications (logging, monitoring, alarm); for example, expect a copy of a certain Pod to run on certain nodes specified by the K8s cluster. Label usage scenarios:

The ◎ kube-controller process filters the number of Pod replicas to be monitored through the LabelSelector defined on the resource object RC, so that the number of Pod replicas always conforms to the expected fully automatic control process.

The ◎ kube-proxy process selects the corresponding Pod through the Label Selector of Service, and automatically establishes the request forwarding routing table of each Service to the corresponding Pod, thus realizing the intelligent load balancing mechanism of Service.

By defining a specific Label for some Node and using NodeSelector as a label scheduling strategy in the Pod definition file, the kube-scheduler process can achieve the Pod-oriented scheduling feature.

Label and LabelSelector together constitute the core application model of the Kubernetes system, which enables the managed objects to be managed in fine groups and realizes the high availability of the whole cluster.

4 、 Replication Controller

The RC resource object defines an expected scenario, that is, it declares that the number of copies of a certain Pod meets a certain expected value at any time, so the definition of RC includes the following parts:

1. The number of copies expected by Pod

2. Label Selector used to filter the target Pod

3. When the number of copies of Pod is less than expected, the Pod template (template) is used to create a new Pod. In the RC definition file, the corresponding configuration item:

◎ spec.selector: is RC's Pod tag selector, which monitors and manages Pod instances with these tags to ensure that there are always and only replicas Pod instances running in the current cluster. When the number of Pod running in the cluster is less than replicas, RC generates a new Pod instance based on the Pod template defined in spec.template

Expected value for a copy of ◎ spec.replicas:Pod

After we define a RC and submit it to the Kubernetes cluster, the Replication Controller (replica controller) in the Controller Manager component on the Master is notified to regularly inspect the target Pod currently alive in the system and ensure that the number of target Pod instances is exactly equal to the expected value of this RC. If there are too many copies of Pod running, the system will stop some Pod, otherwise the system will automatically create some more Pod. It can be said that the high availability of user application cluster is realized through RC,Kubernetes, and a lot of manual operation and maintenance work that system administrators need to complete in the traditional IT environment (such as host monitoring script, application monitoring script, fault recovery script, etc.) is greatly reduced. At run time, we can modify the number of copies of RC to achieve Scaling of Pod. The rolling update of the service is assisted by replacing the Pod one by one.

It is best not to create Pod directly beyond RC, because Replication Controller (replica controller) manages Pod replicas through RC, automatically creating, replenishing, replacing and deleting Pod replicas, which can improve the disaster recovery capability of the system and reduce losses caused by unexpected conditions such as node crashes. Even if your application uses only one copy of Pod, it is strongly recommended that you use RC to define Pod.

5 、 Replica Set

The only difference between Replica Set and RC currently is that Replica Sets supports set-based Label selector (Set-based selector), while RC only supports equation-based Label Selector (equality-based selector), which makes Replica Set more powerful.

6 、 Deployment

Deployment uses Replica Set internally to implement it. No matter from the function and purpose of Deployment, the definition of YAML, or its specific command line operation, we can think of it as an upgrade of RC. The similarity between the two is more than 90%. Instead of using the underlying Replica Set to control the Pod copy, we should use the Deployment object that manages the Replica Set to control the copy.

One of the main functions of Deployment or RC is to automatically deploy multiple copies of a container application and continuously monitor the number of copies to maintain the number of copies specified by users in the cluster.

If the Pod is created through Deployment, the user can modify the Pod definition (spec.template) or mirror name of the Deployment at run time and apply it to the Deployment object, and the system can complete the automatic update of the Deployment. If an error occurs during the update, you can also restore the version of Pod through a rollback operation.

Once the image name (or Pod definition) is changed, the system is triggered to complete all rolling upgrades of Deployment running Pod. Deployment rolling upgrade Pod process is: when the initial creation of Deployment, the system created a ReplicaSet, and according to the needs of users to create n copies of Pod. When the Deployment is updated, the system creates a new ReplicaSet, expands its number of copies to 1, and then reduces the old ReplicaSet to NMel 1. After that, the system continues to adjust the new and old ReplicaSet one by one according to the same update strategy. Finally, the new ReplicaSet runs n new Pod copies, and the number of old ReplicaSet copies is reduced to 0.

7. Resource isolation Pod

Each Pod can set a limit on the computing resources on its server. Currently, there are two kinds of computing resources that can be set: CPU and Memory. The resource unit of CPU is the number of CPU (Core), which is an absolute value rather than a relative value, and the Memory quota is also an absolute value, its unit is the number of bytes of memory. In Kubernetes, the following two parameters need to be set when a computing resource is limited to a quota:

◎ Requests: the minimum number of requests for this resource, the system must meet the requirements.

◎ Limits: the maximum allowed amount of this resource cannot be broken. When the container tries to use more than this amount of resource, it may be "killed" and restarted by Kubernetes.

Namespace

Within an organization, different workgroups can work in the same Kubernetes cluster. Kubernetes distinguishes different workgroups through the settings of namespace and Context, so that they can not only share the services of the same Kubernetes cluster, but also do not interfere with each other, and the Pod and RC created between the composite groups are not visible to each other. Namespace is used in many cases to achieve resource isolation for multi-tenancy.

For Kubernetes cluster management, it is cumbersome to configure Requests and Limits for each Pod. More often, we need to impose a global restriction on the configuration of Requests and Limits of tenants in the cluster. By "allocating" the resource objects within the cluster to different Namespace, Namespace 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. When creating a Namespace for each tenant to achieve multi-tenant resource isolation, it can also be combined with Kubernetes resource quota management to limit the resources that different tenants can occupy, such as CPU usage, memory usage, and so on.

On how to summarize K8S knowledge points will be shared here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

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.