1、Master組件
-
API Server：K8S對外的唯一接口，提供HTTP/HTTPS RESTful API，即kubernetes API。所有的請求都需要經過這個接口進行通信。主要負責接收、校驗並響應所有的REST請求，結果狀態被持久存儲在etcd當中，所有資源增刪改查的唯一入口。
-
etcd：負責保存k8s 集群的配置信息和各種資源的狀態信息，當數據發生變化時，etcd會快速地通知k8s相關組件。etcd是一個獨立的服務組件，並不隸屬於K8S集群。生產環境當中etcd應該以集群方式運行，以確保服務的可用性。etcd不僅僅用於提供鍵值數據存儲，而且還為其提供了監聽（watch）機制，用於監聽和推送變更。在K8S集群系統中，etcd的鍵值發生變化會通知倒API Server，並由其通過watch API向客戶端輸出。
-
Controller Manager：負責管理集群各種資源，保證資源處於預期的狀態。Controller Manager由多種controller組成，包括replication controller、endpoints controller、namespace controller、serviceaccounts controller等 。由控制器完成的主要功能主要包括生命周期功能和API業務邏輯，具體如下：生命周期功能：包括Namespace創建和生命周期、Event垃圾回收、Pod終止相關的垃圾回收、級聯垃圾回收及Node垃圾回收等。API業務邏輯：例如，由ReplicaSet執行的Pod擴展等。
-
調度器（Schedule）：資源調度，負責決定將Pod放到哪個Node上運行。Scheduler在調度時會對集群的結構進行分析，當前各個節點的負載，以及應用對高可用、性能等方面的需求。
2、Node組件
-
Kubelet：kubelet是node的agent，當Scheduler確定在某個Node上運行Pod后，會將Pod的具體配置信息（image、volume等）發送給該節點的kubelet，kubelet會根據這些信息創建和運行容器，並向master報告運行狀態。
-
Container Runtime：每個Node都需要提供一個容器運行時（Container Runtime）環境，它負責下載鏡像並運行容器。目前K8S支持的容器運行環境至少包括Docker、RKT、cri-o、Fraki等。
-
Kube-proxy：service在邏輯上代表了后端的多個Pod，外借通過service訪問Pod。service接收到請求就需要kube-proxy完成轉發到Pod的。每個Node都會運行kube-proxy服務，負責將訪問的service的TCP/UDP數據流轉發到后端的容器，如果有多個副本，kube-proxy會實現負載均衡，有2種方式：LVS或者Iptables。
這個時序圖展示了創建pod的流程，基本的流程如下：
- 用戶提交創建Pod的請求，可以通過API Server的REST API ，也可用Kubectl命令行工具，支持Json和Yaml兩種格式；
- API Server 處理用戶請求，存儲Pod數據到Etcd；
- Schedule通過和 API Server的watch機制，查看到新的pod，嘗試為Pod綁定Node；
- 過濾主機：調度器用一組規則過濾掉不符合要求的主機，比如Pod指定了所需要的資源，那么就要過濾掉資源不夠的主機；
- 主機打分：對第一步篩選出的符合要求的主機進行打分，在主機打分階段，調度器會考慮一些整體優化策略，比如把一個Replication Controller的副本分布到不同的主機上，使用最低負載的主機等；
- 選擇主機：選擇打分最高的主機，進行binding操作，結果存儲到Etcd中；
- kubelet根據調度結果執行Pod創建操作： 綁定成功后，會啟動container, docker run, scheduler會調用API Server的API在etcd中創建一個bound pod對象，描述在一個工作節點上綁定運行的所有pod信息。運行在每個工作節點上的kubelet也會定期與etcd同步bound pod信息，一旦發現應該在該工作節點上運行的bound pod對象沒有更新，則調用Docker API創建並啟動pod內的容器。