Kubernetes 控制平面通信

Question

我正在研究 K8s 架构，重点研究系统中 pod 旋转的流程。

我想知道控制平面的不同组件如何（即谁发起通信）以及何时相互通信。

我关注了Jérôme Petazzoni在 LISA 2019 上的精彩演讲（此处）以了解控制平面的架构，并阅读了kubernetes.io上的概念。

但是，我仍然没有找到以下问题的答案：

1. 谁发起每个节点的资源检查，在文档中是这样写的：

节点对象跟踪有关节点资源容量的信息：例如，可用内存量和 CPU 数量。 自行注册的节点在注册期间报告其容量。 如果手动添加一个Node，那么在添加的时候需要设置该节点的容量信息。

但是，没有关于它何时在etcd更新以及谁发起定期更新（更新节点状态的心跳除外）的规范。

另外，调度程序的缓存什么时候更新？

2. 谁通知不同组件有关新的待处理请求？ 也就是说， controller-manager / scheduler controller-manager如何“知道”它应该何时完成其工作？ 每个请求都由kube-api-server写入etcd的清单，但这些组件不直接连接到etcd 。

这是否意味着 API-Server 需要将每个新请求通知每个组件？

我有很多可能的答案，但没有具体确认当前 K8s 架构中的真实过程。

Answer 1

回答您的问题：

每个节点的资源检查谁来发起？

对此负责的组件是“节点状态管理器” ，它是kubelet 代理组件“ SyncLoop”的子控制循环。

更详细的答案在这篇文章中： Kubernetes Deep Dive：Kubelet ：

可以看到， kubelet的工作核心是一个控制循环，即： SyncLoop 。

例如，节点状态管理器是负责应对变化中的状态Node ，然后收集的状态Node ，并将其报告给APIServer通过心跳。

还有一个很好的图：

回答第二部分：

谁通知不同组件有关新的待处理请求？ 也就是说， controller-manager / scheduler controller-manager如何“知道”它应该何时完成其工作？

对此负责的组件是Kubernetes 的控制器和调度程序本身。 这篇文章中有很好的例子和解释：当...... Kubernetes 版时会发生什么！ ,

基本上在 Kubernetes 验证请求（身份验证、授权、准入控制）之后，它被保存到数据存储（ etcd ），然后它被初始化器获取，它可能对资源执行一些额外的逻辑（并不总是），之后它是可见的kube 服务器。 您可能感兴趣的主要部分是Control loops 。 他们不断检查数据存储中是否存在新请求，如果是，他们正在继续。 示例 - 当您部署新部署时：

• 部署控制器正在接受一个请求 - 它会意识到没有关联的 ReplicaSet 记录，它将推出新的记录
• ReplicaSets 控制器，就像部署控制器一样，它将接受一个请求并推出新的 pod
• Pod 已准备就绪，但处于挂起状态 - 现在调度程序（就像以前的控制器一样，不断侦听来自数据存储的新请求 - 它实际上是您问题的答案）将找到合适的节点并将 Pod 调度到节点。 现在，节点上的 kubelet 代理将创建一个新的 pod。

有关更多详细信息，我强烈建议您阅读前面提到的文章 -当 ... Kubernetes 版时会发生什么！ .

这是否意味着 API-Server 需要将每个新请求通知每个组件？

它以不同的方式工作 - kube-apiserver 使请求可见，控制器（循环）正在检测新请求并开始处理它们。