kubelet 的架构

image.png

Kubelet 分三层：
API 层：声明式 API
syncLoop 层：Kubelet 的核心工作层，即控制循环、由生产者和消费者通过事件驱动循环运行；
CRI ：提供容器和镜像的服务接口

syncLoop 重要组件：

  • PLEG：调用容器运行时的接口来获取本节点 containers/sandboxes 的信息，与本地维护的 pod cache 进行对比，生成对应的 PodLifecycleEvent ,然后通过 eventChannel 发送到 Kubelet syncLoop ,然后由定时任务来同步 pod，最终达到用户的期望状态；
  • CAdvisor：集成在 Kubelet 中的容器监控工具，用于收集本节点和容器的监控信息；
  • PodWorkers：注册了多个 pod handler，分别处理 pod 的不同事件，包括创建、更新、删除等；
  • oomWatcher：系统 OOM 的监听器，会与 CAdvisor 模块之间建立 SystemOOM，通过 Watch 方式从 CAdvisor 那里收到 OOM 信号，并产生相关事件；
  • imageGC：负责 node 节点的镜像回收，当本地的存放镜像的本地磁盘空间达到某阀值的时候，会触发镜像的回收，删除掉不被 pod 所使用的镜像；
  • Managers：包含各种 manager，管理与 pod 相关的各类资源。如 imageManager,volumeManager, evictionManager, statusManager, probeManager, runtimeManager, podManager。

Kubelet 工作原理

syncloop 循环中调用 syncLoopIteration 方法，而 syncLoopIteration 会对传入的所有 channel 遍历，发现任何一个管道由消息就交给 handler 去处理
image.png

创建 Pod 的过程

Kubelet 创建 pod 的过程是由 configCh 中的 ADD 事件触发的。

Handler

当 configCh 中出现 ADD 事件， loop 会触发 SyncHandler 的 HandlePodAdditions 方法，
image.png
mirror pod 镜像pod：是 static pod 在 kueblet 在 apiserver 创建的一份副本。kubelet 直接管理 static pod， apiserver 无法感知到 static pod 的存在，所以为了能够通过 kubectl logs 命令直接查看到 static pod 的日志，kubelet 通过 apiserver 为每一个 static pod 创建一个对应的 mirror pod。

pod 的准入控制：

  1. 节点是否满足 pod 的亲和性规则；
  2. 节点是否有足够的资源分配给 pod；
  3. 节点是否使用 HostNetwork 或者 HostIPC，若使用了，是否在节点的白名单里；
  4. /proc 挂载目录满足要求；
  5. pod 是否配置且是否配置正确的 AppArmor

所有条件满足时触发 podWorker 同步 pod

podWorkers

image.png

  1. podUpdates 以 pod uid 为 key，为每个 pod 维护一个 channel；
  2. 当有事件时，首先从这个 map 里获取对应的 channel，然后启动一个 goroutine 监听这个 channel，并执行 managePodLoop。另一方面 podWorker 向这个 channel 中传入需要同步的 pod；
  3. managePodLoop 接收到事件后，会先从 pod cache 中获取该 pod 最新的 status，以确保当前处理的 pod 是最新状态；然后调用 kubelet 的 syncPod 方法，将其同步后的结果记录在 workQueue 中，等待下一次定时同步任务处理。

kubelet syncPod

image.png
syncPod 是 kubelet 对象，在文件 pkg/kubelet/kubelet.go 中。这个方法直接与 container runtime 层交互。

  1. 是否是 KILL 事件，是调用 runtime 的 killpod；
  2. 是否可以在节点上运行，pod 的准入控制；
  3. CNI 插件是否 ready ，不 ready，则只在 pod 使用 host network 的时候 创建并更新 pod 的 cgroups；ready 则直接创建 cgroups；
  4. 是否是静态 pod，如果是就创建相应的 mirror pod；否就挂载所需目录
  5. 最后调用 runtime 的 syncPod

runtime syncPod

image.png

sandbox

image.png

备注

pod 的亲和性规则：亲和性功能包含两种类的亲和性，节点亲和性、pod 间亲和性与反亲和性，用于 pod 节点按需调度
AppArmor：是一个 linux 内核安全模块，通过配置文件，为应用程序减少潜在的攻击面，并且提供更深入的防御。用于对 pod 的保护。