在調度這一步完成后，Kubernetes 就需要負責將這個調度成功的 Pod，在宿主機上創建出來，並把它所定義的各個容器啟動起來。這些，都是 kubelet 這個核心組件的主要功能。
kubelet 本身，也是按照“控制器”模式來工作的。它實際的工作原理，可以用如下所示的一幅示意圖來表示清楚。
kubelet 的工作核心，就是一個控制循環，即：SyncLoop（圖中的大圓圈）。而驅動這個控制循環運行的事件，包括四種：
1、Pod 更新事件；
2、Pod 生命周期變化；
3、kubelet 本身設置的執行周期；
4、定時的清理事件。
kubelet 啟動的時候，要做的第一件事情，就是設置 Listers，也就是注冊它所關心的各種事件的 Informer。這些 Informer，就是 SyncLoop 需要處理的數據的來源。
此外，kubelet 還負責維護着很多很多其他的子控制循環（也就是圖中的小圓圈）。這些控制循環的名字，一般被稱作某某 Manager，比如 Volume Manager、Image Manager、Node Status Manager 等等。這些控制循環的責任，就是通過控制器模式，完成 kubelet 的某項具體職責。比如 Node Status Manager，就負責響應 Node 的狀態變化，然后將 Node 的狀態收集起來，並通過 Heartbeat 的方式上報給 APIServer。再比如 CPU Manager，就負責維護該 Node 的 CPU 核的信息，以便在 Pod 通過 cpuset 的方式請求 CPU 核的時候，能夠正確地管理 CPU 核的使用量和可用量。
SyncLoop，又是如何根據 Pod 對象的變化，來進行容器操作的呢？
kubelet 也是通過 Watch 機制，監聽了與自己相關的 Pod 對象的變化。當然，這個 Watch 的過濾條件是該 Pod 的 nodeName 字段與自己相同。kubelet 會把這些 Pod 的信息緩存在自己的內存里。
而當一個 Pod 完成調度、與一個 Node 綁定起來之后， 這個 Pod 的變化就會觸發 kubelet 在控制循環里注冊的 Handler，也就是上圖中的 HandlePods 部分。此時，通過檢查該 Pod 在 kubelet 內存里的狀態，kubelet 就能夠判斷出這是一個新調度過來的 Pod，從而觸發 Handler 里 ADD 事件對應的處理邏輯。
在具體的處理過程當中，kubelet 會啟動一個名叫 Pod Update Worker 的、單獨的 Goroutine 來完成對 Pod 的處理工作。
比如，如果是 ADD 事件的話，kubelet 就會為這個新的 Pod 生成對應的 Pod Status，檢查 Pod 所聲明使用的 Volume 是不是已經准備好。然后，調用下層的容器運行時（比如 Docker），開始創建這個 Pod 所定義的容器。
而如果是 UPDATE 事件的話，kubelet 就會根據 Pod 對象具體的變更情況，調用下層容器運行時進行容器的重建工作。
kubelet 調用下層容器運行時的執行過程，並不會直接調用 Docker 的 API，而是通過一組叫作 CRI（Container Runtime Interface，容器運行時接口）的 gRPC 接口來間接執行的。Kubernetes 項目之所以要在 kubelet 中引入這樣一層單獨的抽象，當然是為了對 Kubernetes 屏蔽下層容器運行時的差異。