摘要
摘要：kubernetes，etcd，数据恢复，kube-apiserver
1 背景说明
二级生产环境（灰度环境），kubernetes测试环境，采用1master+2node架构，某次，公司突然断电，导致服务器突然宕机，来电后，重启服务器，在任何节点执行命令，都报如下错误：
[root@master kube-apiserver]# kubectl get ns
The connection to the server 192.168.150.100:6443 was refused - did you specify the right host or port?
2 故障排查
2.1 查询docker与kubelet状态
systemctl status docker #如下docker运行正常
systemctl status kubelet #如下kubelet一直在重启中
2.2 查看kubelet服务日志
journalctl -u kubelet #查询到日志如下，不能连接到docker
7月 04 10:15:14 master kubelet[687]: E0704 10:15:14.863276 687 reflector.go:153] k8s.io/kubernetes/pkg/kubelet/kubelet.go:458: Failed to list *v1.Node: Get https://192
7月 04 10:15:14 master kubelet[687]: I0704 10:15:14.864218 687 client.go:75] Connecting to docker on unix:///var/run/docker.sock
7月 04 10:15:14 master kubelet[687]: I0704 10:15:14.864271 687 client.go:104] Start docker client with request timeout=2m0s
7月 04 10:15:14 master kubelet[687]: F0704 10:15:14.865651 687 server.go:273] failed to run Kubelet: failed to create kubelet: failed to get docker version: Cannot con
7月 04 10:15:14 master systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
2.3 重启docker与kubelet服务
2.3.1 首先kubelet启动起来了，但是报错master节点找不到
2.3.2 查询kubernetes集群服务，发现etcd与kube-apiserver均启动异常
docker ps -a| grep kube-apiserver
docker ps -a| grep etcd
2.4 etcd与kube-apiserver
2.4.1 etcd简介
kubernetes集群中担任的角色：etcd是kubernetes集群数据存储后端，用于存储所有集群数据，l例如：集群状态、配置信息、服务发现信息等。
- 数据存储：所有集群数据，例如：pod状态、节点信息、service信息都被存储于etcd中。
- 一致性保证：etcd通过Raft协议保证数据强一致性和高可用性。
2.4.2 kube-apiserver简介
kubernetes集群中担任角色：kube-apiserver是kubernetes的API服务端点，提供整个系统的API入口。
- 功能：kube-apiserver接收来自kubectl（kubernetes的命令行工具）或其他kubernetes组件的API请求，随后，通过认证、授权和验证后，讲这些请求转发给ectd读取或更新数据。
- 数据操作：所有kubernetes资源（如pod、service、deployment等）的操作都通过kube-apiserver进行，通过kube-apiserver将操作映射到etcd中相应数据存储位置。
2.4.3 关系
etcd与kube-apiserver关系：
kube-apiserver作为集群的api服务器，通过etcd来持久化存储和管理整个集群状态和配置信息。那就显然，不出意外，master节点的etcd数据损坏了，为啥这么说呢
- etcd 成员（Member）：在 etcd 集群中，每个 etcd 实例被称为一个“成员”（Member）。这些成员共同协作，通过 etcd的Raft 一致性算法来确保数据的强一致性和高可用性。
3 解决方案
因此，经2.4的分析，首先打开etcd的日志存放地址（默认保存地址：/var/log/pods/kube-system_etcd XXX XXX），查看日志发现报错信息，查阅官方资料这种情况是由于 etcd 数据损坏，有两种解决方式。
- 方案1：在故障节点上停止etcd服务并删除损坏的 etcd 数据，现在etcd服务本来就没有启动，删除前先备份数据，最后启动etcd服务。
- 方案2：重置kubernetes集群（代价太大，放弃）。
4 解决实践
4.1 查看etcd本地持久化数据目录地址
cat /etc/kubernetes/manifests/etcd.yaml #etcd配置yaml默认存放路径
4.2 查看当前节点的数据存放地址
find ./ -type d -name member
4.3 实景
如下，kubernetes集群成功拉起
5 总结
首先，在kubernetes中存在etcd集群，该集群由多个节点组成，其次，kubernetes集群通过 kubectl和kube-apiserver与etcd集群进行交互，在此次事故中，由于master节点的etcd数据损坏，导致etcd集群数据无法做到一致性，进而导致kubernetes集群不可访问，当把master节点的损坏的etcd数据移除后，kubernetes会自动同步etcd集群中其他节点数据，使得集群数据一直，最终故障修复成功。