The internal architecture and working mechanism of Kubernetes

Kubernetes is a production-level container orchestration platform and cluster management system that can create and schedule containers, monitor and manage servers.

An important function of the operating system is abstraction, which abstracts some simple concepts from tedious underlying transactions, and then manages system resources based on these concepts.

The same is true for Kubernetes. Its management goal is large-scale clusters and applications. It must be able to abstract the system to a high enough level and decompose some loosely coupled objects in order to simplify the system model and reduce the mental burden of users.

Kubernetes adopts the popular "Control Plane / Data Plane" architecture. The computers in the cluster are called "Nodes", which can be real machines or virtual machines. A small number of nodes use It is used as the control plane to perform the management and maintenance of the cluster, and most of the other nodes are classified as the data plane to run business applications.

The node on the control plane is called Master Node in Kubernetes, generally referred to as Master for short. It is the most important part of the entire cluster, and it can be said to be the brain and heart of Kubernetes.

The nodes on the data plane are called Worker Nodes, generally referred to as Workers or Nodes, which are equivalent to the hands and feet of Kubernetes and work under the command of the Master.

There are 4 components in Master, namely apiserver, etcd, scheduler, and controller-manager.

Apiserver is the Master node—and also the only entrance to the entire Kubernetes system. It exposes a series of RESTful APIs, and adds functions such as authentication and authorization. All other components can only communicate directly with it. It can be said that it is Kubernetes liaison officer.

etcd is a highly available distributed Key-Value database, which is used to persist various resource objects and states in the storage system, which is equivalent to the configuration administrator in Kubernetes. Note that it only has a direct connection with the apiserver, which means that any other component that wants to read or write data in etcd must go through the apiserver.

The scheduler is responsible for the arrangement of the container, checks the resource status of the node, and schedules the Pod to run on the most suitable node, which is equivalent to the deployment personnel. Because the node status and Pod information are stored in etcd, the scheduler must be obtained through the apiserver.

controller-manager is responsible for maintaining the status of resources such as containers and nodes, and implementing functions such as fault detection, service migration, and application scaling, which is equivalent to monitoring operation and maintenance personnel. Similarly, it must obtain the information stored in etcd through the apiserver in order to realize various operations on resources.

The three components in Node are kubelet, kube-proxy, and container-runtime.

Kubelet is an agent of Node, which is responsible for managing most of the operations related to Node. It is the only one on Node that can communicate with apiserver, realize status reporting, command delivery, start and stop containers and other functions, which is equivalent to a "little housekeeper" on Node.

The role of kube-proxy is a bit special. It is the network proxy of Node and is only responsible for managing the network communication of the container. In simple terms, it forwards TCP/UDP data packets for the Pod, which is equivalent to a full-time "little postman".

container-runtime It is the actual user of containers and images. It creates containers under the command of kubelet and manages the life cycle of Pods. It is the real "coolie" of work.

Among these three components, only kube-proxy is containerized, and because kubelet must manage the entire node, containerization will limit its capabilities, so it must run outside the container-runtime.

The general workflow of Kubernetes is as follows:

  • The kubelet on each Node will periodically report the node status to the apiserver, and the apiserver will store it in etcd.
  • The kube-proxy on each Node implements a TCP/UDP reverse proxy, allowing the container to provide stable services externally.
  • The scheduler obtains the current node status through the apiserver, schedules the Pod, and then the apiserver sends a command to the kubelet of a Node, and the kubelet calls the container-runtime to start the container.
  • The controller-manager also obtains real-time node status through the apiserver, monitors possible abnormal situations, and then uses corresponding means to adjust and recover.

Therefore, these components are like countless tireless operation and maintenance engineers, moving the original tedious and inefficient human work into high-efficiency computers, they can discover changes and abnormalities in the cluster at any time, and then cooperate with each other to maintain the cluster. health status.

This article is a study note for Day 9 in July. The content comes from "Kubernetes Introductory Practical Course" by Geek Time . This course is recommended.

Guess you like

Origin blog.csdn.net/key_3_feng/article/details/131623645