关于etcd:Etcd-高可用故障演练

40次阅读

共计 1541 个字符，预计需要花费 4 分钟才能阅读完成。

本次演练旨在测试 Kubernetes 的 etcd 高可用性，测验是否可能在其中一个 etcd 节点产生故障的状况下，其余 etcd 节点可能接管其工作，确保集群仍能失常运行。

集群架构

在一个三节点的 Kubernetes 集群中，咱们将模仿其中一个 etcd 节点的故障，察看残余的 etcd 节点是否可能失常运行。

确认集群以后衰弱状态

kubectl get componentstatuses # 确认所有组件状态均为失常
kubectl -n kube-system get endpoints | grep etcd # 确认 etcd Endpoints 列表
kubectl -n kube-system get pods | grep etcd # 确认 etcd Pod 的数量
# 确认 etcd 集群状态
ETCD_CA_CERT="/etc/kubernetes/pki/etcd/ca.crt"
ETCD_CERT="/etc/kubernetes/pki/etcd/server.crt"
ETCD_KEY="/etc/kubernetes/pki/etcd/server.key"
ETCDCTL_API=3 /usr/local/bin/etcdctl --endpoints=https://127.0.0.1:2379 \
  --cacert="${ETCD_CA_CERT}" --cert="${ETCD_CERT}" --key="${ETCD_KEY}" member list
ETCDCTL_API=3 /usr/local/bin/etcdctl --endpoints=${HOST1},${HOST2},${HOST3} \
  --cacert="${ETCD_CA_CERT}" --cert="${ETCD_CERT}" --key="${ETCD_KEY}" endpoint health

进行 M3 节点 etcd 服务

mkdir -p /home/clay/etcdbak
mv /etc/kubernetes/manifests/etcd.yaml /home/clay/etcdbak/

确认残余节点是否能失常提供服务
```
# 反复执行步骤一命令 
```
在其余 etcd 节点上执行 kubectl create 命令测试 Kubernetes 集群是否可能失常运行，例如 kubectl create deployment nginx

继续通过 vip + 域名两种形式，调用 apiserver 服务，统计影响时长

启动 M3 节点 etcd 服务

mv /home/clay/etcdbak/etcd.yaml /etc/kubernetes/manifests/

确认集群以后衰弱状态
```
# 反复执行步骤一命令 
```

因为现有架构为 apiserver 调用本地 127.0.0.1 的 etcd 服务，所以当 M3 节点 etcd 服务进行后，M3 节点的 apiserver 也不能失常提供服务

所以 haproxy 和 nginx 都必要配置正确的健康检查策略，能够主动剔除故障节点

在进行一个 etcd 节点的 etcd 过程后，其余 etcd 节点可能顺利接管其工作，确保 Kubernetes 集群的失常运行。当第一个 etcd 节点重新加入集群后，所有 etcd 节点均可能复原到衰弱状态，集群依然可能失常工作。演练后果证实 Kubernetes 的 etcd 子系统具备较高的可用性，能够无效地应答节点故障的状况。

通过本次演练，咱们验证了 Kubernetes 的 etcd 子系统的高可用性，并理解了在一个节点产生故障的状况下，其余节点是如何接管其工作的。在理论生产环境中，咱们倡议对 Kubernetes 集群的 etcd 子系统进行高可用性测试，以确保集群可能稳固、牢靠地运行。此外，咱们还应定期检查 Kubernetes 集群的各个组件状态，确保其失常运行，避免出现故障导致的服务中断。

正文完