Kubelet (Kubernetes): deep in code

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 开始 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.