K8s 集群高可用master节点故障如何恢复?
不必太纠结于当下,也不必太忧虑未来,当你经历过一些事情的时候,眼前的风景已经和从前不一样了。——村上春树
写在前面
- 很常见的集群运维场景,整理分享
- 博文内容为 K8s 集群高可用
master
节点故障如何恢复的过程 - 理解不足小伙伴帮忙指正
不必太纠结于当下,也不必太忧虑未来,当你经历过一些事情的时候,眼前的风景已经和从前不一样了。——村上春树
遇到了什么问题
今天做实验发现 ,集群其中一个 master
节点上的 etcd
和 apiserver
都挂掉了
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
vms100.liruilongs.github.io
这个节点 上的 apiserver
和 etcd
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
查看 keepalived
对应的静态Pod运行正常
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
所以可能是 etcd
不同步,或者什么原因 导致etcd
挂掉了。因为 每个 master
节点的 apiserver
只和 本节点的 etcd
进行 通信(每个 etcd
的写请求会转发到 etcd
的领导节点),etcd 挂掉,apiserver 无法提供能力,所以也会挂掉。
通过 etcdctl
可以发现 vms100.liruilongs.github.io
上的 etcd
彻底死掉了
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
如何排查
这里我们换一个 etcd
节点 执行 命令
查看 etcd 集群成员
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
查看节点状态
1 | ┌──[root@vms101.liruilongs.github.io]-[~] |
确定 ETCD 节点故障
1 | ┌──[root@vms101.liruilongs.github.io]-[~] |
查看 etcd
的容器日志
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
如何解决
这里最快的办法是重新同步一下这个节点的数据,即把这个故障节点移出 集群,清理完故障节点旧数据在重新添加,操作步骤
清理数据目录
,移动静态Pod 的yaml 文件:停止故障节点服务,然后删除etcd
数据目录。- 移
除故障节点
:使用member remove
命令剔除错误节点,可以在健康的节点执行命令。 添加节点
:使用member add
命令添加故障节点。重新启动
:移动故障节点yaml文件,进行启动
注: 静态Pod 通过加载指定目录的 yaml 文件来调度,kubelet
会定时扫描,删除移动 yaml 文件,静态 Pod 会自动停止,同理。添加 yaml 文件会自动创建静态 Pod
移动静态Pod 的yaml 文件
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
删除etcd
数据目录
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
确认节点 的 etcd
和 apiservier
都已经停止
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
获取故障节点 ID,下面的操作我们在健康的 etcd
节点执行,或者可以修改 --endpoints
1 | ┌──[root@vms101.liruilongs.github.io]-[~] |
移除故障节点
1 | ┌──[root@vms101.liruilongs.github.io]-[~] |
重新添加
1 | ┌──[root@vms101.liruilongs.github.io]-[~] |
回到 100 节点机器,移动 Yaml 文件,恢复节点
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
确认 Pod 状态
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
查看 etcd 集群状态
1 | ┌──[root@vms101.liruilongs.github.io]-[~] |
这里我们发现 新添加的节点状态不正常,一直是 unstarted
我们在 故障节点执行 etcd
命令。发现故障节点并没有添加到集群,而是作为一个单节点运行。
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
也没有同步 当前集群的数据
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
遇到这种情况,大部分原因是 某个节点的 etcd
配置文件的问题,我的这个问题是 故障节点的 etcd 配置文件,没有集群信息相关配置
,所以这里把集群相关配置写入配置
原本的配置文件
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
集群信息不全的,添加后的配置文件
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
然后我们以上面相同的方式从新恢复一次,发现节点直接没有起来
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
查看日志
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
根据日志信息,可以看到有用的信息 RemovedMemberIDs:[]}: member count is unequal
,成员数量不相等,在分析日志
1 | { |
可以看到它提示 可能错误与 vms102.liruilongs.github.io
节点相关
然后我们看一下 vms102.liruilongs.github.io
的配置文件
1 | ┌──[root@vms102.liruilongs.github.io]-[~] |
通过配置文件比对
,可以发现,之前配置的故障节点的配置任然有问题,少了一个vms102.liruilongs.github.io=https://192.168.26.102:2380
节点信息。
1 | "--initial-cluster=vms100.liruilongs.github.io=https://192.168.26.100:2380,vms101.liruilongs.github.io=https://192.168.26.101:2380", |
修改完配置,按照上面相同的流程重新恢复节点, 节点恢复
通过 etcdctl
命令检查
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
1 | ┌──[root@vms100.liruilongs.github.io]-[~] |
© 2018-至今 liruilonger@gmail.com, All rights reserved. 保持署名-非商用-相同方式共享(CC BY-NC-SA 4.0)
K8s 集群高可用master节点故障如何恢复?
https://liruilongs.github.io/2024/03/16/K8s/环境部署-运维/K8s 集群高可用master节点挂掉如何恢复/
1.K8s 集群高可用master节点ETCD全部挂掉如何恢复?
2.K8s 镜像缓存管理 kube-fledged 认知
3.K8s集群故障(The connection to the server <host>:<port> was refused - did you specify the right host or port)解决
4.关于 Kubernetes中Admission Controllers(准入控制器) 认知的一些笔记
5.K8s Pod 创建埋点处理(Mutating Admission Webhook)
6.关于AI(深度学习)相关项目 K8s 部署的一些思考
7.K8s Pod 安全认知:从openshift SCC 到 PSP 弃用以及现在的 PSA
8.K8s:通过 PSA(Pod Security Admission) 定义K8s 集群安全基线