kubernetes - kube-proxy 无法到达 master 时如何表现？

Question

根据我对 Kubernetes 的了解，如果 master(s) 死亡，worker 应该仍然能够正常运行 (https://stackoverflow.com/a/39173007/281469)，尽管不会发生新的调度。

但是，我发现当 master 也可以调度 worker pod 时情况并非如此。以一个 2 节点集群为例，其中一个节点是主节点，另一个节点是工作节点，主节点已删除污点:

如果我将 master 和 docker exec 关闭到 worker 的其中一个容器中，我可以看到:

nc -zv ip-of-pod 80

成功了，但是

nc -zv ip-of-service 80

失败一半的时间。 Kubernetes版本为v1.15.10，kube-proxy使用iptables模式。

我猜测，由于工作节点上的 kube-proxy 无法连接到 apiserver，因此它不会从 iptables 规则中删除主节点。

问题:

1. kube-proxy 不会停止路由到主节点上的 pod 是预期的行为，还是存在“损坏”的东西？
2. 是否有任何解决方法可用于此类设置以允许工作节点仍然正常运行？

我意识到最好的办法是将 CP 节点分开，但这对我目前正在做的事情来说不可行。

Answer 1

Is it expected behaviour that kube-proxy won't stop routing to pods on master nodes, or is there something "broken"?

Are any workarounds available for this kind of setup to allow the worker nodes to still function correctly?

集群主节点扮演集群节点中各种事件的决策者角色。这可以包括调度工作负载、管理工作负载的生命周期、扩展等。每个节点都由主组件管理，并包含运行 pod 所需的服务。节点上的服务通常包括 kube-proxy、容器运行时和 kubelet。

kube-proxy 组件在节点上执行网络规则，并帮助 kubernetes 管理 Pod 和服务之间的连接。此外，kube-proxy 充当基于导出的负载均衡 Controller ，持续监控 kubernetes API 服务器并基于它持续更新节点的 iptables 子系统。

简单来说，主节点只是知道一切，并负责创建路由规则列表以及基于节点的添加或删除等。kube-proxy 充当一种执行者，负责检查与 master 同步信息并执行列表上的规则。

如果主节点(API服务器)宕机，集群将无法响应API命令或部署节点。如果另一个主节点不可用，则没有其他可用的人可以指示工作节点更改工作分配，因此他们将继续执行早先由主节点调度的操作，直到主节点返回并给出不同的指示。与其内联，kube-proxy 也不能通过与 master 同步来获取最新规则，但是它不应该停止路由并继续处理网络和路由功能(使用在 master 之前确定的早期 iptable 规则节点出现故障)，如果工作节点中的所有 Pod 仍正常运行，这将允许与您的 Pod 进行网络通信。

基于单一主节点的架构不是生产的首选部署架构。考虑到弹性和可靠性是 kubernetes 的主要业务目标之一，建议将基于 HA 集群的架构作为最佳实践来避免单点故障。