本文分析的代碼爲當前的github master（即介於1.5與1.6）之間，主要對kubelet啓動的整個流程的代碼進行解析。
其main函數在 cmd/kubelet/kubelet.go 中，首先整理了kubelet的參數，並放入KubeletServer 中。然後，使用KubeletServer 作爲參數調用Run 函數來啓動kubelet。Run 函數主要調用了cmd/kubelet/app/server.go 中的函數進行kubelet的啓動。從文件名也能出，kubelet是一個daemon進程。
Run 函數主要進行了以下操作：
- 啓動一個後臺進程對kubelet的配置與API server進行實時同步：首先創建可以於API server進行交互的kubeclient，通過這個client取得當前node的configmap。在configmap中取得
kubelet.config字段所對應的值，就是kubelet配置對應的json格式。然後啓動一個go程，將現在的配置和API server中的進行對比，如果兩者不同則重啓kubelet，以此來確保kubelet使用了最新的配置。 - 對kubelet的crt與key文件（kubelet與其他組件通信的公私鑰文件）進行設置。
- 創建與apiserver通信的
EventClient，用來獲取kubelet所需的各種事件。 - 調用
UnsecuredKubeletDeps創建了kubdeps對象。在此過程中，如果使用docker作爲runtime，那麼則會調用github.com/docker/engine-api/client來創建docker的client。 - 對QOS（即服務質量，通過cgroup實現）進行解析和設置。
- 初始化
kubeDeps.ContainerManager，並創建container manager。其中儲存了是否使用CRI和使用何種runtime等信息。 - 調用
RunKubelet函數，繼續kubelet的啓動工作。 - 再給點的端口healthz端口提供健康檢查服務。
RunKubelet 繼續整理各種參數。然後調用CreateAndInitKubelet 來真正實例化一個kubelet對象。在CreateAndInitKubelet 中首先調用了NewMainKubelet。
- 首先對container/image的垃圾回收（GC）和disk space policy進行了配置。
- 創建工作節點本地的service和node的cache，並且使用list/watch機制持續對其進行更新。
- 創建DiskSpaceManager，用以與cadvisor配合進行工作節點的磁盤管理，這與kubelet是否接受新的pod在該工作節點上運行有密切關係。
- 創建ContainerRefManager，用以記錄每個container及其對應的引用的映射關係，主要用於在pod更新或者刪除時進行事件的記錄。
- 創建OOMWatcher，用以從cadvisor中獲取系統的內存溢出（out of memory, oom）事件，並對其進行記錄。
- 解析kubeconfig中的DNS設置。
- 初始化kubelet網絡插件，可以指定傳入一個文件夾中的plugin作爲kubelet的網絡插件。
- 對容器的runtime進行判斷，如果是docker&&CRI，則啓動dockershim。
kubelet啓動完成後通過事件收集器向APIServer發送一個kubelet已經啓動的event，表明集羣新加入了一個新的工作節點，kubelet將這一過程稱爲BirthCry，即”出生的啼哭”。並且開始進行容器和鏡像的垃圾回收，對應的時間間隔分別爲1分鐘和5分鐘。
最後調用startKubelet 。startKubelet 則主要對指定的kubelet端口進行監聽，以此與其他組件進行交互。