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 未满，则将该 statuspodStatusSyncRequest{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.
