背景说明
二进制方式安装的k8s集群,etcd集群有3个节点,某天有一台机器hang住了,无法远程ssh登陆,于是被管理员直接重启了,重启后发现k8s集群删除一个deployment应用,多次刷新一会有,一会没有,于是在3个节点上执行etcd命令去查询该数据,发现被重启的节点上仍存在删除的该应用的数据,于是判断etcd集群的该节点存在脏数据,和其他节点数据不同步。
排障过程
发现问题
# 删除应用
kubectl -n kube-system delete deploy metrics-server
# 检查应用状态
kubectl -n kube-system get pod | grep metrics-server
此处多次查询发现一会存在,一会不存在
# 检查etcd节点状态
etcdctl member list
etcdctl --endpoints=https://192.168.100.100:2379,https://192.168.100.101:2379,https://192.168.100.102:2379 --write-out=table endpoint status
# 在每个节点上执行查询,找出问题节点
ETCDCTL_API=3 etcdctl get /registry/deployments/kube-system/metrics-server
从上面发现etcd集群节点数据不一致的问题 ,虽然停掉该问题节点,集群仍然可以正常使用,但这也只能是临时的办法,2个节点,如果不能选举出谁是leader,会影响集群的健壮性和服务的可靠性,因此,我们需要对该问题节点的etcd服务进行修复。
如何修复
1. 备份数据
在做操作前需要做好正常数据的备份,以免修复不成功无法还原,这点是很重要的,特别是生产环境。
备份方式:
a. 直接打包数据目录
主要打包的目录有data wal 两个目录
b. etcd 快照方式备份
之前也写过,这里不再赘述。
2. 如何修复
1) 停掉问题节点的etcd服务
systemctl stop etcd
2) 清空数据目录
主要清空data wal 目录
3)获取问题节点etcd的id
etcdctl member list
4) 从集群中移除问题节点
etcdctl member remove <问题节点ID>
5)重新将问题节点加入集群
etcdctl [证书] --endpoints="https://192.168.100.100:2379,https://192.168.100.101:2379,https://192.168.100.102:2379" member add etcd-192.168.100.102 --peer-urls="https://192.168.100.102:2380"
6)修改etcd配置文件:将initial-cluster-state的值new改成existing
sed -i 's/new/existing/g' /etc/systemd/system/etcd.service
systemctl daemon-reload
7) 启动服务
systemctl start etcd
systemctl status etcd
8) 检查etcd集群状态
版权归原作者 筑梦之路 所有, 如有侵权,请联系我们删除。