客戶端創建pod 流程：
- 用戶管理員創建 Pod 的請求默認是通過kubectl 客戶端管理命令 api server 組件進行交互的，默認會將請求發送給 API Server。
- API Server 會根據請求的類型選擇用何種 REST API 對請求作出處理（比如：創建 Pod 時 Storage 類型是 Pods 時，其對應的就是 REST Storage API）。
- REST Storage API 會對請求作相應的處理並將處理的結果存入高可用鍵值存儲系統 Etcd 中。
- 在 API Server 響應管理員kubectl 的請求后，Scheduler 會根據ETCD集群中運行 Pod情況 及 Node 信息進行判斷，將需要創建的 Pod 分發到可用的 Node 節點上。然后根據一組相關規則將pod分配到可以運行它們的節點上，並更新數據庫，記錄pod分配情況。
- Kubelet監控數據庫變化，管理后續pod的生命周期，發現被分配到它所在的節點上運行的那些pod，就會進行docker組件的啟動，docker組件會啟動對應的容器（pod），會在該節點上運行這個新pod。
- kube-proxy運行在集群各個節點主機上，管理網絡通信，如服務發現、負載均衡。例如當有數據發送到主機時，將其路由到正確的pod或容器。對於從主機上發出的數據，它可以基於請求地址發現遠程服務器，並將數據正確路由，在某些情況下會使用輪訓調度算法(Round-robin)將請求發送到集群中的多個實例。
集群功能各模塊功能描述：
Master節點：
Master節點上面主要由四個模塊組成，APIServer，schedule,controller-manager,etcd.
APIServer: APIServer負責對外提供RESTful的kubernetes API的服務，它是系統管理指令的統一接口，任何對資源的增刪該查都要交給APIServer處理后再交給etcd，如圖，kubectl(kubernetes提供的客戶端工具，該工具內部是對kubernetes API的調用）是直接和APIServer交互的。
schedule:
schedule負責調度Pod到合適的Node上，如果把scheduler看成一個黑匣子，那么它的輸入是pod和由多個Node組成的列表，輸出是Pod和一個Node的綁定。
kubernetes目前提供了調度算法，同樣也保留了接口。用戶根據自己的需求定義自己的調度算法。
controller manager: 如果APIServer做的是前台的工作的話，那么controller manager就是負責后台的。每一個資源都對應一個控制器。而controller manager就是負責管理這些控制器的，比如我們通過APIServer創建了一個Pod，當這個Pod創建成功后，APIServer的任務就算完成了。
etcd：etcd是一個高可用的鍵值存儲系統，kubernetes使用它來存儲各個資源的狀態，從而實現了Restful的API。
Node節點：
每個Node節點主要由三個模板組成：kublet, kube-proxy
kube-proxy:
該模塊實現了kubernetes中的服務發現和反向代理功能。kube-proxy支持TCP和UDP連接轉發，默認基Round
Robin算法將客戶端流量轉發到與service對應的一組后端pod。服務發現方面，kube-proxy使用etcd的watch機制監控集群中service和endpoint對象數據的動態變化，並且維護一個service到endpoint的映射關系，從而保證了后端pod的IP變化不會對訪問者造成影響，另外，kube-proxy還支持session
affinity。
kublet：kublet是Master在每個Node節點上面的agent，是Node節點上面最重要的模塊，它負責維護和管理該Node上的所有容器，但是如果容器不是通過kubernetes創建的，它並不會管理。本質上，它負責使Pod的運行狀態與期望的狀態一致。