Monitoring solution for Kubernetes cluster

The monitoring of the Kubernetes cluster itself is also very important. We need to know the running status of the cluster at all times.
For cluster monitoring, we generally need to consider the following aspects:

  1. Monitoring of Kubernetes nodes: such as cpu, load, disk, memory and other indicators of the node
  2. Status of internal system components: detailed operating status of components such as kube-scheduler, kube-controller-manager, kubedns/coredns, etc.
  3. Orchestration-level metrics: data metrics such as deployment status, resource requests, scheduling, and API latency
    .

The monitoring solutions for Kubernetes clusters currently mainly include the following solutions:

  1. Heapster: Heapster is a cluster-wide monitoring and data aggregation tool that runs in the cluster in the form of a Pod. Insert picture description hereIt should be noted that Heapster has been deprecated, and metrics-server will be used instead in subsequent versions.
  2. cAdvisor: cAdvisor is Google's open source container resource monitoring and performance analysis tool. It is specially created for containers. It also supports Docker containers. In Kubernetes, we do not need to install it separately. As a part of the built-in kubelet program, cAdvisor can be used directly .
  3. Kube-state-metrics: kube-state-metrics generates state indicators related to resource objects, such as Deployment, Node, Pod, by listening to the API Server. It should be noted that kube-state-metrics simply provides metrics data and does not store them These indicator data, so we can use Prometheus to grab these data and store them.
  4. metrics-server: metrics-server is also a cluster-wide resource data aggregation tool. It is a substitute for Heapster. Similarly, metrics-server only displays data and does not provide data storage services.

There is still a big difference between kube-state-metrics and metrics-server. The main differences between the two are as follows:

  1. kube-state-metrics mainly focuses on some business-related metadata, such as Deployment, Pod, copy status, etc.
  2. The metrics-server is mainly concerned with the implementation of resource measurement APIs, such as CPU, file descriptor, memory, request latency and other indicators.

Guess you like

Origin blog.csdn.net/zhangshaohuas/article/details/108559205