一个节点宕机后 Kubernetes 集群变得无响应
Kubernetes cluster become unresponsive after one node goes down
我们通过使用 kubeadm 初始化集群，在具有 2 个主节点和 5 个工作节点的数据中心上设置了 k8s 集群。添加了集群配置以供参考。
kind: InitConfiguration
apiVersion: kubeadm.k8s.io/v1beta3
localAPIEndpoint:
advertiseAddress: VIP_ADDRESS
---
kind: ClusterConfiguration
apiVersion: kubeadm.k8s.io/v1beta3
kubernetesVersion: v1.22.0
controlPlaneEndpoint: "MANAGEMENT_VIP_ADDRESS:6444"
networking:
podSubnet: 192.168.0.0/16
---
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: 0.0.0.0
cgroupDriver: ADVERTISED_CGROUP_DRIVER_NAME
shutdownGracePeriod: 6m
shutdownGracePeriodCriticalPods: 4m
用于不同组件的版本。
etcd:3.5.0-0
kube-api服务器：v1.22
kube-controller-manager:v1.22
kubelet-1.22.1
我们确实遇到的问题是一旦我们关闭节点一，然后整个服务器开始行为异常并且节点在大多数 cases.Even 上变为只读我们无法 运行 kubectl 命令。
在 kube 中获取异常 api 日志：-
W0128 11:23:25.351294 1 clientconn.go:1326] [核心] grpc: addrConn.createTransport 无法连接到 {127.0.0.1:2379 127.0.0.1 0 }。错误：连接错误：desc =“传输：拨号 tcp 127.0.0.1:2379 时出错：连接：连接被拒绝”。正在重新连接...
W0128 11:23:26.347009 1 clientconn.go:1326] [core] grpc: addrConn.createTransport 无法连接到 {127.0.0.1:2379 127.0.0.1 0 }。错误：连接错误：desc =“传输：拨号 tcp 127.0.0.1:2379 时出错：连接：连接被拒绝”。正在重新连接...
W0128 11:23:26.352155 1 clientconn.go:1
您的 etcd 设置不是 highly-available，它至少需要 3 个节点才能容忍 1 个节点故障，否则 etcd 可能会在 split-brain 场景
中损坏数据
您应该至少再添加一个节点到 etcd 集群（但 5 个节点是生产设置的推荐集群大小）。假设你的主节点也是运行ning etcd，因为你没有另外指定，你应该运行 3个主节点
见https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance
An etcd cluster operates so long as a member quorum can be established.
It is recommended to have an odd number of members in a cluster. An odd-size cluster tolerates the same number of failures as an even-size cluster but with fewer nodes. The difference can be seen by comparing even and odd sized clusters:
Cluster Size
Majority
Failure Tolerance
1
1
0
2
2
0
3
2
1
4
3
1
5
3
2
6
4
2
7
4
3
8
5
3
我们通过使用 kubeadm 初始化集群，在具有 2 个主节点和 5 个工作节点的数据中心上设置了 k8s 集群。添加了集群配置以供参考。
kind: InitConfiguration apiVersion: kubeadm.k8s.io/v1beta3 localAPIEndpoint: advertiseAddress: VIP_ADDRESS --- kind: ClusterConfiguration apiVersion: kubeadm.k8s.io/v1beta3 kubernetesVersion: v1.22.0 controlPlaneEndpoint: "MANAGEMENT_VIP_ADDRESS:6444" networking: podSubnet: 192.168.0.0/16 --- kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 address: 0.0.0.0 cgroupDriver: ADVERTISED_CGROUP_DRIVER_NAME shutdownGracePeriod: 6m shutdownGracePeriodCriticalPods: 4m
用于不同组件的版本。 etcd:3.5.0-0 kube-api服务器：v1.22 kube-controller-manager:v1.22 kubelet-1.22.1
我们确实遇到的问题是一旦我们关闭节点一，然后整个服务器开始行为异常并且节点在大多数 cases.Even 上变为只读我们无法 运行 kubectl 命令。
在 kube 中获取异常 api 日志：-
W0128 11:23:25.351294 1 clientconn.go:1326] [核心] grpc: addrConn.createTransport 无法连接到 {127.0.0.1:2379 127.0.0.1 0 }。错误：连接错误：desc =“传输：拨号 tcp 127.0.0.1:2379 时出错：连接：连接被拒绝”。正在重新连接... W0128 11:23:26.347009 1 clientconn.go:1326] [core] grpc: addrConn.createTransport 无法连接到 {127.0.0.1:2379 127.0.0.1 0 }。错误：连接错误：desc =“传输：拨号 tcp 127.0.0.1:2379 时出错：连接：连接被拒绝”。正在重新连接... W0128 11:23:26.352155 1 clientconn.go:1
您的 etcd 设置不是 highly-available，它至少需要 3 个节点才能容忍 1 个节点故障，否则 etcd 可能会在 split-brain 场景
中损坏数据您应该至少再添加一个节点到 etcd 集群（但 5 个节点是生产设置的推荐集群大小）。假设你的主节点也是运行ning etcd，因为你没有另外指定，你应该运行 3个主节点
见https://etcd.io/docs/v3.5/faq/#what-is-failure-tolerance
An etcd cluster operates so long as a member quorum can be established.
It is recommended to have an odd number of members in a cluster. An odd-size cluster tolerates the same number of failures as an even-size cluster but with fewer nodes. The difference can be seen by comparing even and odd sized clusters:
| Cluster Size | Majority | Failure Tolerance |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
| 6 | 4 | 2 |
| 7 | 4 | 3 |
| 8 | 5 | 3 |