但是，另一方面kubernetes云原生集群「复杂性较高」，集群自身存在非常多的组件，如master节点上运行着：api-server组件、etcd组件、kube-scheduler组件、kube-controller-manager组件、coredns组件等，node节点上有kubelet组件、kube-proxy组件等。这里还隐含着另一个问题就是：一旦云原生集群出现问题，云原生集群上部署的应用组件可能都会受到影响，「影响面比较大」。

所以，作为云原生集群的运维人员，关注云原生集群组件的整体运行情况，特别是一些核心组件的运行状况，避免某些组件出现性能瓶颈、异常奔溃等导致整个云原生集群性能低下甚至不可用风险的发生，这一节我们就来重点关注下云原生集群核心组件的监控。

kubernetes架构

在对kubernetes服务组件进行监控之前，我们要先来了解下kubernetes的架构(见下图)：

kubernetes集群节点大致分为两类：控制节点和工作节点。

左边蓝色框框中就是控制节点上运行的核心组件：

API Server组件：API Server可以看着的整个集群的大脑，从图上可以看出基本所有组件都要和API Server组件进行交互，同时，内外部接口请求也都要经过API Server组件，如kubectl指令、client-go获取监听集群资源等。

ETCD组件：API Server组件作为集群的对外接口层，会接收大量外部请求，肯定需要持久化数据库存储这些元数据信息，ETCD组件就是kubernetes元数据存储的数据库。

Scheduler组件：kubernetes作为大规模多节点容器调度平台，可灵活的基于多种策略实现容器的调度，这就是Scheduler组件的职责。

Controller Manager组件：kubernetes中核心的设计理念是声明式，kubernetes集群中所有的操作都可以通过声明式的yaml文件将需求描述清楚，具体底层如何实现用户是无需太多关注的，这其中背后实现的逻辑就是kubernetes集群中存在的大量控制器的功劳，kubernetes二次开发主要也是自定义各种控制器，而Controller Manager组件就是管理这些控制器的管理器。

右边框框就是工作节点，控制节点相当于集群管理层，驱动着整个集群的运行，而工作节点是真正运行业务容器的节点，即将控制节点调度分配过来的任务干好即可。其核心组件：

kubelet组件：工作节点上最重要的一个组件就是kubelet组件，主要负责底层容器创建、管理、运行等，kubelet基于CRI(Container Runtime Interface)与容器运行时(Docker、containerd等)进行通信，这种标准化的接口使得kubernetes能够与不同的容器运行时进行交互，提高了系统的灵活性和可扩展性。

kube-proxy组件：kube-proxy是kubernetes集群中负责网络代理和负载均衡的重要组件，它通过转发请求、负载均衡和会话绑定等功能，确保服务的可访问性和高可用性，为应用程序提供稳定和可靠的网络服务。

API Server组件监控

1、API Server作为kubernetes最核心的组件，当然他的监控也是非常有必要的。API Server组件部署在kube-system命名空间下：

并在default命名空间下创建service，并通过手工配置endpoint：

2、因此，我们可以基于service的endpoints服务发现：

3、通过prometheus target界面查看采集点接入正常：

4、导入15761 dashboard，API Server组件监控指标就展示到模板上。

比如可以看到API Server组件健康检查状态，API Server组件作为kubernetes集群大脑，主要对外提供API接口，所以，这里重点监控API Server组件的请求量、请求响应延迟大小、错误请求量等：

ETCD组件监控

kubernetes集群的ETCD默认是开启暴露metrics数据的。

1、获取Etcd Pod名称：

我们可以看到启动参数里面有一个 --listen-metrics-urls=http://127.0.0.1:2381 的配置，该参数就是来指定 Metrics 接口运行在 2381 端口下面的，而且是http的协议，所以也不需要什么证书配置，这就比以前的版本要简单许多了，以前的版本需要用 https 协议访问，所以要配置对应的证书。

注意：这里监听的是127.0.0.1，需要修改/etc/kubernetes/manifests/etcd.yaml，将--listen-metrics-urls=http://127.0.0.1:2381修改成--listen-metrics-urls=http://0.0.0.0:2381，编辑后会自动更新Pod(静态Pod)。

2、创建etcd组件service服务：

3、prometheus监控接入：

4、通过prometheus target界面查看采集点接入正常：

5、导入3973 或者 3070 dashboard，ETCD组件监控指标就展示到模板上。

Scheduler组件监控

1、创建kube-scheduler组件service：kube-scheduler.yaml

2、修改/etc/kubernetes/manifests/kube-scheduler.yaml

修改点主要有两处：

将-bind-address=127.0.0.1修改成-bind-address=0.0.0.0，否则外部无法访问。

使用-port标志为 HTTP 服务指定端口，你可能已经完全-port=0禁用HTTP服务，这里配置-port=10251。

修改完成后等待重启：

在kube-scheduler-k8s-01组件运行的master节点(k8s-01)上查看端口是否开启监听：

❝
-port=0禁用时，只有10259 HTTPS监听端口开启，将--port=10251配置后，10251 HTTP监听端口也会开启。

3、prometheus监控接入：

4、通过prometheus target界面查看采集点接入正常：

Controller Manager组件

1、创建kube-scheduler组件service：kubeControllerManager.yaml

2、修改/etc/kubernetes/manifests/kube-controller-manager.yaml

修改点主要有两处：

将-bind-address=127.0.0.1修改成-bind-address=0.0.0.0，否则外部无法访问。

使用-port标志为 HTTP 服务指定端口，你可能已经完全-port=0禁用HTTP服务，这里配置-port=10252。

修改完成后等待重启：

在kube-controller-manager-k8s-01组件运行的master节点(k8s-01)上查看端口是否开启监听：

❝
-port=0禁用时，只有10257 HTTPS监听端口开启，将--port=10251配置后，10252 HTTP监听端口也会开启。

3、prometheus监控接入：

4、通过prometheus target界面查看采集点接入正常：

kubelet组件

kubelet组件集成cAdvisor，通过/metrics/cadvisor端点暴露容器性能指标，kubelet组件还通过/metrics端点暴露自身组件指标。

1、prometheus监控接入：

2、通过prometheus target界面查看采集点接入正常：

kube-proxy组件

kube-proxy默认暴露两个端口，一个是10249，在/metrics端点暴露监控指标，另一个是10256。可以使用netstat命令检查这两个端口是否监听：

如果需要修改监听端口，修改kubectl edit configmap kube-proxy -n kube-system，将metricsBindAddress这段修改成metricsBindAddress: 0.0.0.0:10249即可。默认监听127.0.0.1，修改：

然后重新启动kube-proxy这个pod：

再次使用netstat检测10249监听到0.0.0.0上：

1、创建service：

2、prometheus监控接入：

3、通过prometheus target界面查看采集点接入正常：

CoreDNS

kubernetes集群中非常重要的CoreDNS插件，一般默认情况下就开启了 /metrics 接口：

上面ConfigMap中 prometheus :9153 就是开启prometheus的插件：

我们可以先尝试手动访问下 /metrics 接口，如果能够手动访问到那证明接口是没有任何问题的：

我们可以看到可以正常访问到，从这里可以看到CoreDNS的监控数据接口是正常的了，然后我们就可以将这个 /metrics 接口配置到 prometheus.yml 中去。

默认，以在kube-system命名空间下创建了CoreDNS组件的service：

CoreDNS组件监控接入配置：

通过prometheus target界面查看采集点接入正常：

Last update: 2024-8-14