当 Kubernetes master 发生故障时会发生什么？
What happens when the Kubernetes master fails?
我一直在试图弄清楚当 Kubernetes 主节点在只有一个主节点的集群中发生故障时会发生什么。如果发生这种情况，Web 请求是否仍会路由到 pods，或者整个系统是否只是关闭？
根据构建在 Kubernetes 之上的 OpenShift 3 文档 (https://docs.openshift.com/enterprise/3.2/architecture/infrastructure_components/kubernetes_infrastructure.html)，如果主节点发生故障，节点将继续正常运行，但系统将失去管理 pods. vanilla Kubernetes 也是这样吗？
在典型设置中，主节点 运行 API 和 etcd 主要或全部负责管理底层云基础设施。当它们离线或降级时，API 将离线或降级。
如果它们、etcd 或 API 完全离线，则集群不再是集群，而是在此期间的一堆临时节点。集群将无法响应节点故障、创建新资源、将 pods 移动到新节点等。直到：
- 足够的 etcd 实例重新联机以形成法定人数并取得进展（有关其工作原理和这些术语含义的直观解释，请参阅 this page）。
- 至少有一个 API 服务器可以处理请求
在部分降级状态下，API 服务器可能能够响应仅读取数据的请求。
但是，在任何情况下，除非节点重新启动，否则应用程序的生命将继续正常，或者在此期间出现某种严重故障，因为 TCP/UDP 服务、负载平衡器、DNS、仪表板、等等。都应该至少继续运行一段时间。最终，这些东西都会在不同的时间尺度上失败。在单主设置或完全 API 故障中，DNS 故障可能会在缓存过期时首先发生（大约几分钟，though the exact timing is configurable, see the coredns cache plugin documentation）。这是考虑多主机设置的一个很好的理由——DNS 和服务路由可以在降级状态下无限期地继续运行，即使 etcd 不能再取得进展。
作为操作员，您可以采取一些措施来加速故障，尤其是在完全降级的状态下。例如，重启节点会导致 DNS 查询，实际上可能会导致所有 pod 和服务网络功能，直到至少有一个主服务器恢复在线。重启 DNS pods 或 kube-proxy 也不行。
如果您想自己测试一下，我推荐 kubeadm-dind-cluster, kind 或者，对于更奇特的设置，kubeadm 在 VM 或裸机上。注意：kubectl proxy 在 API 故障期间将不起作用，因为它通过主节点路由流量。
没有 master 的 Kubernetes 集群就像没有经理的公司运行。
除了Manager（主节点），没有其他人可以指示worker（k8s组件）
（即使是集群的所有者，也只能指示Manager）
一切如常。直到工作完成或者有什么事情阻止了他们。（因为主节点在分配工作后死了）
由于没有Manager给他们重新分配工作，所以工人们会一直等到Manager回来。
最佳做法是为您的集群分配多个管理器（master）。
我一直在试图弄清楚当 Kubernetes 主节点在只有一个主节点的集群中发生故障时会发生什么。如果发生这种情况，Web 请求是否仍会路由到 pods，或者整个系统是否只是关闭？
根据构建在 Kubernetes 之上的 OpenShift 3 文档 (https://docs.openshift.com/enterprise/3.2/architecture/infrastructure_components/kubernetes_infrastructure.html)，如果主节点发生故障，节点将继续正常运行，但系统将失去管理 pods. vanilla Kubernetes 也是这样吗？
在典型设置中，主节点 运行 API 和 etcd 主要或全部负责管理底层云基础设施。当它们离线或降级时，API 将离线或降级。
如果它们、etcd 或 API 完全离线，则集群不再是集群，而是在此期间的一堆临时节点。集群将无法响应节点故障、创建新资源、将 pods 移动到新节点等。直到：
- 足够的 etcd 实例重新联机以形成法定人数并取得进展（有关其工作原理和这些术语含义的直观解释，请参阅 this page）。
- 至少有一个 API 服务器可以处理请求
在部分降级状态下，API 服务器可能能够响应仅读取数据的请求。
但是，在任何情况下，除非节点重新启动，否则应用程序的生命将继续正常，或者在此期间出现某种严重故障，因为 TCP/UDP 服务、负载平衡器、DNS、仪表板、等等。都应该至少继续运行一段时间。最终，这些东西都会在不同的时间尺度上失败。在单主设置或完全 API 故障中，DNS 故障可能会在缓存过期时首先发生（大约几分钟，though the exact timing is configurable, see the coredns cache plugin documentation）。这是考虑多主机设置的一个很好的理由——DNS 和服务路由可以在降级状态下无限期地继续运行，即使 etcd 不能再取得进展。
作为操作员，您可以采取一些措施来加速故障，尤其是在完全降级的状态下。例如，重启节点会导致 DNS 查询，实际上可能会导致所有 pod 和服务网络功能，直到至少有一个主服务器恢复在线。重启 DNS pods 或 kube-proxy 也不行。
如果您想自己测试一下，我推荐 kubeadm-dind-cluster, kind 或者，对于更奇特的设置，kubeadm 在 VM 或裸机上。注意：kubectl proxy 在 API 故障期间将不起作用，因为它通过主节点路由流量。
没有 master 的 Kubernetes 集群就像没有经理的公司运行。
除了Manager（主节点），没有其他人可以指示worker（k8s组件）
（即使是集群的所有者，也只能指示Manager）
一切如常。直到工作完成或者有什么事情阻止了他们。（因为主节点在分配工作后死了）
由于没有Manager给他们重新分配工作，所以工人们会一直等到Manager回来。
最佳做法是为您的集群分配多个管理器（master）。