前因后果：

1. 降级后的报警

Kubernetes 1.20.5 upgrade 1.21.0，降级实现忽然发现 Prometheus discover 中两个服务 down 了, 收到微信报警

登陆 Prometheus 控制台一看 controller-manager kube-scheduler 服务的确是 down：

2. 查看服务状态确认相干服务是失常状态

登陆集群查看 kubectl get pods -n kube-system 服务都是失常的。当然了也能够 kubectl logs -f $podname -n kube-system 去查看一下相干 pod 的 log 日志进行确认一下。

3. 定位起因

认真一想是不是降级的时候 controller-manager kube-scheduler 服务的配置文件给降级了呢 … 记得在搭建 Prometheus-oprator 的时候手动批改过两个服务的配置文件 what 认真一想也对 …upgrade 的时候 它难道把两个配置文件改了？

4. 批改 kube-controller-manage kube-scheduler 配置文件

持续参照：Kubernetes 1.20.5 装置 Prometheus-Oprator 中 1.5 查看 controller-manager kube-scheduler 服务的配置：
注：配置文件门路为：/etc/kubernetes/manifests
cat cat kube-controller-manager.yaml 发现 –bind-address=127.0.0.1 了 复原了初始的设置，在装置 Prometheus-oprator 的时候将其批改为 0.0.0.0 的同理批改。

批改 scheduler 配置文件 –bind-address=0.0.0.0

注：批改配置文件是针对所有 master 节点配置文件的。

5. 重启 kubelet 服务

重启 三个 master 节点 kubelet 服务：
注：我记得应该批改了相干的配置服务 管制立体的相干 pods 是会重启的吧？重启 kubelet 只是集体确保一下啊失常 ……

 systemctl restart kubelet

期待服务跑起来 running……

6. 确认 Prometheus 控制台 status 状态 up

登陆 Prometheus web 控制台确认监控恢复正常状态：

问题复盘：

1. 必须认同降级是必然的过程。保障集群的衰弱装置须要保障集群的一直 updata, 当然并不一定是最新的。
2. 相干服务的装置批改须要纯熟牢记。就像 Prometheus-oprator 中 controller-manager kube-scheduler 服务一样，起码能明确记得批改过两个相干配置文件。确认服务失常后，能够去很明确的查看定位配置文件的批改。
3. 监控还是很有必要的，不论你是鄙视还是器重。很大水平下面能够防止更多的失误，作为一个掂量指标