kubernetes - 当 Kubernetes 主节点出现故障时会发生什么？

Question

我一直试图弄清楚当 Kubernetes 主节点在只有一个主节点的集群中出现故障时会发生什么。如果发生这种情况，Web 请求是否仍会路由到 Pod，或者整个系统是否只是关闭？

根据构建在 Kubernetes 之上的 OpenShift 3 文档 (https://docs.openshift.com/enterprise/3.2/architecture/infrastructure_components/kubernetes_infrastructure.html)，如果主节点发生故障，节点将继续正常运行，但系统将失去管理 pod 的能力。这对于 vanilla Kubernetes 是一样的吗？

Answer 1

在典型的设置中，主节点同时运行 API 和 etcd，并且主要或完全负责管理底层云基础设施。当它们离线或降级时，API 将离线或降级。
如果它们、etcd 或 API 完全脱机，则该集群将不再是一个集群，而是在此期间一堆临时节点。集群将无法响应节点故障、创建新资源、将 pod 移动到新节点等。直到两者:

足够多的 etcd 实例重新上线以形成法定人数并取得进展(有关其工作原理和这些术语含义的直观解释，请参阅 this page)。

至少一个 API 服务器可以为请求提供服务

在部分降级状态下，API 服务器可能能够响应仅读取数据的请求。
但是，无论如何，除非重新启动节点，否则应用程序的生命周期将照常继续，或者在此期间出现某种严重故障，因为 TCP/UDP 服务、负载均衡器、DNS、仪表板等都应该继续至少运行一段时间。最终，这些事情都会在不同的时间尺度上失败。在单个主设置或完整的 API 故障中，DNS 故障可能会在缓存过期时首先发生(以分钟为单位， though the exact timing is configurable ，参见 the coredns cache plugin documentation )。这是考虑多主设置的一个很好的理由——DNS 和服务路由可以在降级状态下无限期地继续运行，即使 etcd 不能再取得进展。
作为运算符(operator)，您可以采取一些措施来加速故障，尤其是在完全降级的状态下。例如，重新启动节点会导致 DNS 查询，实际上可能会导致所有 pod 和服务网络功能，直到至少有一个 master 重新上线。重新启动 DNS pod 或 kube-proxy 也会很糟糕。
如果你想自己测试一下，我推荐 kubeadm-dind-cluster , kind或者，对于更奇特的设置，虚拟机或裸机上的 kubeadm。注: kubectl proxy在 API 故障期间将无法工作，因为它会通过主节点路由流量。