Kubelet (Kubernetes): deep in co

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

Run 初始化 KubeClient、EventClient、CAdvisorInterface、ContainerManager 等

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

RunKubelet 中的函数 startKubelet 最终启动 kubelet，当然之前需要初始化 Kubelet，CreateAndInitKubelet->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 中获取更新信息，直接 syncPod；syncPod 首先去本地 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） 来的更新：ADD、UPDATE、REMOVE、RECONCILE、DELETE，交由各个 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.