原文鏈接：Kubernetes Pod 工作流

我們知道Pod是Kubernetes中最小的調(diào)度單元，平時我們操作Pod的時間也是最多的，那么你知道Pod是怎樣被創(chuàng)建出來的嗎？知道他的工作流程嗎？

組件之間的通信

我們知道在Kubernetes集群中apiserver是整個集群的控制入口，etcd在集群中充當數(shù)據(jù)庫的作用，只有apiserver才可以直接去操作etcd集群，而我們的apiserver無論是對內(nèi)還是對外都提供了統(tǒng)一的REST API服務，包括一個8080端口的非安全服務和6443端口的安全服務。組件之間當然也是通過apiserver進行通信的，其中kube-controller-manager、kube-scheduler、kubelet是通過apiserver watch API來監(jiān)控我們的資源變化，并且對資源的相關(guān)狀態(tài)更新操作也都是通過apiserver進行的，所以說白了組件之間的通信就是通過apiserver REST API和apiserver watch API進行的。

Pod 工作流

那么我們創(chuàng)建Pod的時候到底發(fā)生了什么呢？是怎樣創(chuàng)建成功Pod的呢？

下面圖示就是一個非常典型的Pod工作流程圖：
[站外圖片上傳中...(image-d783df-1535680178141)]

和上面的組件通信一致：

• 第一步通過apiserver REST API創(chuàng)建一個Pod
• 然后apiserver接收到數(shù)據(jù)后將數(shù)據(jù)寫入到etcd中
• 由于kube-scheduler通過apiserver watch API一直在監(jiān)聽資源的變化，這個時候發(fā)現(xiàn)有一個新的Pod，但是這個時候該Pod還沒和任何Node節(jié)點進行綁定，所以kube-scheduler就經(jīng)過一系列復雜的調(diào)度策略，選擇出一個合適的Node節(jié)點，將該Pod和該目標Node進行綁定，當然也會更新到etcd中去的
• 這個時候一樣的目標Node節(jié)點上的kubelet通過apiserver watch API檢測到有一個新的Pod被調(diào)度過來了，他就將該Pod的相關(guān)數(shù)據(jù)傳遞給后面的容器運行時(container runtime)，比如Docker，讓他們?nèi)ミ\行該Pod
• 而且kubelet還會通過container runtime獲取Pod的狀態(tài)，然后更新到apiserver中，當然最后也是寫入到etcd中去的。

這樣一個典型的Pod工作流就完成了，通過這個流程我們可以看出整個過程中最重要的就是apiserver watch API和kube-scheduler的調(diào)度策略。

廣告

另外我也無恥地??給大家推薦一個我的課程：從 Docker 到 Kubernetes 進階??，學完本課程以后，你將會對Docker和 Kubernetes有一個更加深入的認識，我們會講到 Docker 的一些常用方法，當然我們的重點會在 Kubernetes 上面，會用 kubeadm 來搭建一套 Kubernetes 的集群，理解 Kubernetes 集群的運行原理，常用的一些控制器使用方法、還有 Kubernetes 的一些調(diào)度策略、Kubernetes 的運維、包管理工具 Helm 的使用以及最后我們會實現(xiàn)基于 Kubernetes 的 CI/CD。

[站外圖片上傳中...(image-4c830a-1535680178141)]

掃描下面的二維碼(或微信搜索k8s技術(shù)圈)關(guān)注我們的微信公眾帳號，在微信公眾帳號中回復 加群 即可加入到我們的 kubernetes 討論群里面共同學習。
[站外圖片上傳中...(image-a0a671-1535680178141)]