[k8s生产系列]：k8s集群故障恢复，etcd数据不一致，kubernetes集群异常

文章目录

摘要
1 背景说明
2 故障排查
- 2.1 查询docker与kubelet状态
- 2.2 查看kubelet服务日志
- 2.3 重启docker与kubelet服务
- - 2.3.1 首先kubelet启动起来了，但是报错master节点找不到
  - 2.3.2 查询kubernetes集群服务，发现etcd与kube-apiserver均启动异常
- 2.4 etcd与kube-apiserver
- - 2.4.1 etcd简介
  - 2.4.2 kube-apiserver简介
  - 2.4.3 关系
3 解决方案
4 解决实践
- 4.1 查看etcd本地持久化数据目录地址
- 4.2 查看当前节点的数据存放地址
4.3 实景
5 总结
6 参考文献

摘要

摘要：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集群中其他节点数据，使得集群数据一直，最终故障修复成功。