2

根据我对 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 节点，但这对于我目前正在做的事情是不可行的。

4

3 回答 3

3

kube-proxy 不会停止路由到主节点上的 pod 是预期的行为，还是有什么“坏的”？

是否有任何变通办法可用于这种设置以允许工作节点仍然正常运行？

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

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

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

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

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

于 2020-02-16T09:55:05.550 回答
2

一旦你删除了污点，kubernetes 调度程序就不需要任何容忍来在你的主节点上调度 Pod。因此，它与运行控制平面组件的工作节点一样好，您也可以在此节点上运行工作负载 pod（尽管不推荐这样做）。

Kube-proxy ( https://kubernetes.io/docs/concepts/overview/components/#kube-proxy ) 是部署在集群所有节点上的组件，它处理与 Pod 的网络和路由连接。因此，即使您的主节点关闭，kube-proxy 仍然可以在工作节点上正常工作，它会将流量路由到在工作节点上运行的 pod。

如果您的所有 pod 都在工作节点中运行（这些节点仍在运行），那么 kube-proxy 将继续将流量路由到您的 pod，甚至通过服务。

于 2020-02-15T06:31:23.950 回答
1

Kubernetes 中没有任何内在因素会导致这种情况。节点角色仅适用于人类，master如果您已删除污点，则节点只是普通节点。也就是说，请记住有关调度和资源请求的通常规则适用，因此如果您的 pod 不完全适合，那么事情就不会被安排。您的 Kubernetes 部署系统可能会在控制平面节点周围设置更专业的防火墙规则或类似规则，但这取决于该系统。

于 2020-02-14T18:19:46.960 回答