前因后果：

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. 监控还是很有必要的，不论你是鄙视还是器重。很大水平下面能够防止更多的失误，作为一个掂量指标