背景说明

  二进制方式安装的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  listetcdctl --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.servicesystemctl daemon-reload

 7） 启动服务

systemctl  start etcdsystemctl  status etcd

 8) 检查etcd集群状态