Today, I will continue to introduce Linux operation and maintenance related knowledge. The main content of this article is Kubernetes cluster components.
1. Overview of Kubernetes cluster components
Kubernetes consists of multiple components that run on different nodes and play different roles. The schematic diagram of the Kubernetes cluster components is as follows:
2. Master component
The Master node of Kubernetes mainly includes the following components:
(1) API Server
API Server is the gateway of the entire Kubernetes cluster, responsible for outputting RESTful commands, as well as receiving, verifying and responding to all REST requests, and the result status is permanently stored in ETCD.
(2) ETCD
ETCD can persistently store state information in Kubernetes clusters in the form of key-value pairs, which can be used for service discovery, shared configuration, and consistency assurance, and also provides a monitoring mechanism for monitoring and pushing changes. In the Kubernetes cluster, when the key-value pair of ETCD changes, the API Server will be notified, and the monitoring mechanism will output it to the administrator. In this way, based on the monitoring mechanism, various components in the Kubernetes cluster achieve efficient collaboration.
It is worth mentioning that ETCD is developed by CoreOS based on the Raft protocol. It is an independent service component and does not belong to the Kubernetes cluster itself.
(3) Controller Manager
The Controller Manager is the cluster controller and can perform most cluster-level functions. The Controller Manager process is integrated in the kube-controller-manager daemon, and mainly completes the following two functions:
1. Life cycle functions
include Namespace creation and declaration cycle, Event garbage collection, garbage collection related to Pod termination, and cascade garbage collection And Node garbage collection, etc.
2. API business logic
such as Pod expansion executed by ReplicaSet, etc.
(4) Scheduler
Scheduler, that is, the scheduler, is responsible for the work and the bottom layer of the Kubernetes cluster, and makes scheduling decisions according to the status of each node in the Kubernetes cluster and the resource requirements of the container. Kubernetes also supports user-defined schedulers.
3. Node components
The Node node of Kubernetes mainly includes the following components:
(1) Kubelet
Kubelet is a daemon process running on the Node node in the Kubernetes cluster. The process receives configuration information about the Pod resource object from the API Server and executes the instructions of the Master node. In addition, it will also register the current worker node on the API Server, monitor the resource usage of containers and nodes through the Advisor, and report the node resource usage to the Master node regularly.
(2) Kube-proxy
Kube-proxy works on the Node node and is responsible for generating iptables or ipvs rules for the Service object, so as to capture the data traffic accessing the Service and forward the traffic to the backend Pod object.
(3) Docker
Located on the Node node, used to run the container.
Fourth, the core accessories
In addition to the above components, Kubernetes has the following core add-ons to make a Kubernetes cluster more complete.
） 一） KubeDNS
KubeDNS is the Pod responsible for providing DNS services in the Kubernetes cluster. It can provide DNS services to other Pods in the Kubernetes cluster to resolve hostnames. But since Kubernetes 1.1, the KubeDNS component has been replaced by the CoreDNS project.
（二）Kubernetes Dashboard
Web page for administration in a Kubernetes cluster.
（三）Heapster
Heapster is a performance monitoring and analysis system for containers and nodes. It is responsible for collecting and parsing various metrics data, such as resource utilization, life cycle events, etc. But in the new version of Kubernetes, Heapster will be replaced by Prometheus combined with other components.
(4) Ingress Controller
Ingress is an accessory that implements the HTTP or HTTPs load balancing mechanism on the application layer, but the Ingress resource itself cannot forward data traffic like a Service, and it is only a series of rules. These rules need to work through the Ingress controller.
Originality is not easy, please indicate the source for reprinting: https://blog.csdn.net/weixin_40228200