Kubelet (Kubernetes): deep in code

cmd/kubelet/kubelet.go 进程入口函数,调用 server.go Run

Run 初始化 KubeClient、EventClient、CAdvisorInterface、ContainerManager

Run 中的函数 RunKubelet 继续启动 kubelet,做一些配置检查

RunKubelet 中的函数 startKubelet 最终启动 kubelet,当然之前需要初始化 KubeletCreateAndInitKubelet->NewMainKubelet

// start the kubelet
go wait.Until(func() { k.Run(podCfg.Updates()) }, 0, wait.NeverStop)

这块有两个分支,一支为 k.Run,另一支为 podCfg.Updates()

  • k.Run 函数从 podCfg.Updates() 返回的 channel 中获取到 updates 的 pod 信息
  • podCfg 负责将从 file / url / apiserver 获得的 pod updates 信息融合到一个 channel 中

k.Run 开始 syncLoop 之前(开始处理 updates 信息之前),会启动一系列周期 goroutine,如

  • volumeManager
  • syncNodeStatus(从 apiserver 获得 metadata.name==kl.nodename 的
    node 信息,更新本地 node 信息,随后又 update apiserver 上的对应 node 的信息)
  • syncNetworkStatus
  • updateRuntimeUp
  • syncNetworkUtil(刷 iptables 这两个规则 KUBE-MARK-DROP、KUBE-MARK-MASQ)
  • podKiller (删除没被 podWorker 正确处理的 pod)

还会启动一些 manager,如

  • go kl.volumeManager.Run(kl.sourcesReady, wait.NeverStop)
  • statusManager.Start() (syncPeriod=10s syncBatch 周期,或者从 podStatusChannel 中获取更新信息,直接 syncPodsyncPod 首先去本地 cache 确认是否需要更新,不需要更新直接返回,需要更新继续将本地 pod status 更新到 apiserver,如果 pod DeletionTimestamp 不为 nil,则该 pod 被标记删除,如果该 pod 仍有在运行的 container,则返回;否则调用 apiserver 删除 api,将 pod 从 etcd 中删除,成功后,本地 cache 通过 pod uid 将该 pod 删除。至于 syncBatch,从 podStatuses map 中获取到所有需要 update、reconcile 的 status,逐一调用 syncPod 处理这些 status。其中 podStatuses 的信息来源为,SetPodStatus -> updateStatusInternal,首先将 status 和 cache 比,相同且没有设置 forceUpdate 的话,就不用更新了;否则生成新的 versionedPodStatus,version + 1,存入本地 cache,即 podStatuses。若 podStatusChannel 未满,则将该 status podStatusSyncRequest{pod.UID, newStatus} 放入其中
    ,否则交由 syncBatch 处理,因为该 status 已经在 podStatuses 中了)
  • probeManager.Start()
  • pleg.Start() (pod lifecycle event generator)

syncLoop 重头戏

  • syncTicker(1s)
  • housekeepingTicker(2s)
  • pleg.Watch()
  • 如果有 runtimeErrors,则 skip sync and sleep 5s;否则 syncLoopIteration(updates, handler),这里的 updates 不是 status 是 PodUpdate,可能从 configCh(PodUpdate) 来的更新:ADDUPDATEREMOVERECONCILEDELETE,交由各个 handle 去处理;从 plegCh 来的事件 HandlePodSyncs;从 syncCh 来的 tick,HandlePodSyncs;从 livenessManager 来的 updates,HandlePodSyncs;housekeepingCh 来的 tick,sourcesReady.AllReady() 时,HandlePodCleanups();最后这个 handler 传入的其实就是 Kubelet

神奇的在 pkg 下的 kubelet.go 又看到一个 syncPod fun,这个是 real syncPod,之前那个是 status_manager 的 syncPod,是 sync status of pod 的;那么来解读一下 kubelet.go 的 syncPod 吧

  • 若 SyncPodKill: 则 kill pod 并 kl.statusManager.SetPodStatus(pod, apiPodStatus)
  • SyncPodCreate: metrics 记录第一次被 apiserver 看到的时间;生成 apiPodStatus (generateAPIPodStatus);如果 pod 仍未启动,则记录启动时延
  • 判断是否能 runPod,不能则给出 Reason 和 Message
  • 更新 status kl.statusManager.SetPodStatus(pod, apiPodStatus)
  • 创建 pcm (pod container manager)
  • 为 pod 启动做一系列动作,如创建 data 目录,挂卷(AttachAndMount)等
  • result := kl.containerRuntime.SyncPod(pod, apiPodStatus, podStatus, pullSecrets, kl.backOff) 使用 container 启动 pod (不过 SyncPod 是 Runtime 接口的一个方法,再找实现就不知道在哪里了,求问 go 里面怎么找接口实现,一脸懵逼)

pod 的创建似乎和 cgroups 有关,这块后继需要再了解一下

想想 kubelet 组件的作用不就是 create、update、delete pod 么

多处都使用到 HandlePodSyncs,有时间继续解析

另外 NewMainKubelet 这个也是重头,主要是创建 Kubelet,就是都要用到的 kl,初始化一系列东西

** 看这些主要是为了理出比较明确的 node 和 pod 的 status **

现在并没有看到 local 的 pod 信息在那写入的,当然 file 算一种,不过类似 OOM 这种运行时错误的上报没有发现;如果 pod 一开始就不能 Admit 当然是会立刻生成 status 的

先写到这 to be cont.

你可能感兴趣的:(Kubelet (Kubernetes): deep in code)