Kubernetes是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

Kubernetes設計架構：

Kubernetes主要由以下幾個核心元件組成：

• etcd儲存了整個叢集的狀態；
• apiserver提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；
• controller manager負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等；
• scheduler負責資源的排程，按照預定的排程策略將Pod排程到相應的機器上；
• kubelet負責維護容器的生命週期，同時也負責Volume（CVI）和網路（CNI）的管理；
• Container runtime負責映象管理以及Pod和容器的真正執行（CRI）；
• kube-proxy負責為Service提供cluster內部的服務發現和負載均衡；

kubernetes叢集分為一個Master節點和若干Node節點，Master是Kubernetes 的主節點。

　　Master元件可以在叢集中任何節點上執行。但是為了簡單起見，通常在一臺虛擬機器上啟動所有Master元件，並且不會在此VM機器上執行使用者容器。

叢集所有的控制命令都傳遞給Master元件，在Master節點上執行。kubectl命令在其他Node節點上無法執行，原因是kubectl命令需要使用kubernetes-admin來執行。如需執行請：將主節點中的【/etc/kubernetes/admin.conf】檔案拷貝到從節點相同目錄下，然後配置環境變數。

master四個元件的主要功能可以概括為：

　　1. api server：負責對外提供restful的Kubernetes API服務，其他Master元件都通過呼叫api server提供的rest介面實現各自的功能，如controller就是通過api server來實時監控各個資源的狀態的。

　　2. etcd：是 Kubernetes 提供的一個高可用的鍵值資料庫，用於儲存叢集所有的網路配置和資源物件的狀態資訊，也就是儲存了整個叢集的狀態。資料變更都是通過api server進行的。整個kubernetes系統中一共有兩個服務需要用到etcd用來協同和儲存配置，分別是：
　　　　1）網路外掛flannel，其它網路外掛也需要用到etcd儲存網路的配置資訊；
　　　　2）kubernetes本身，包括各種資源物件的狀態和元資訊配置。

　　3. scheduler：監聽新建pod副本資訊，並通過排程演算法為該pod選擇一個最合適的Node節點。會檢索到所有符合該pod要求的Node節點，執行pod排程邏輯。排程成功之後，會將pod資訊繫結到目標節點上，同時將資訊寫入到etcd中。一旦繫結，就由Node上的kubelet接手pod的接下來的生命週期管理。如果把scheduler看成一個黑匣子，那麼它的輸入是pod和由多個Node組成的列表，輸出是pod和一個Node的繫結，即將這個pod部署到這個Node上。Kubernetes目前提供了排程演算法，但是同樣也保留了介面，使用者可以根據自己的需求定義自己的排程演算法。

　　4. controller manager：負責維護叢集的狀態，比如故障檢測、自動擴充套件、滾動更新等。每個資源一般都對應有一個控制器，這些controller通過api server實時監控各個資源的狀態，controller manager就是負責管理這些控制器的。當有資源因為故障導致狀態變化，controller就會嘗試將系統由“現有狀態”恢復到“期待狀態”，保證其下每一個controller所對應的資源始終處於期望狀態。比如我們通過api server建立一個pod，當這個pod建立成功後，api server的任務就算完成了。而後面保證pod的狀態始終和我們預期的一樣的重任就由controller manager去保證了。
controller manager 包括執行管理控制器（kube-controller-manager）和雲管理控制器（cloud-controller-manager）

Node主要元件：包括kubelet、kube-proxy、container runtime

Node上執行著Master分配的pod，當一個Node宕機，其上的pod會被自動轉移到其他Node上。每一個Node節點都安裝了Node元件，包括kubelet、kube-proxy、container runtime。

　　1. kubelet 會監視已分配給節點的pod，負責pod的生命週期管理，同時與Master密切協作，維護和管理該Node上面的所有容器，實現叢集管理的基本功能。即Node節點通過kubelet與master元件互動，可以理解為kubelet是Master在每個Node節點上面的agent。本質上，它負責使Pod的執行狀態與期望的狀態一致。

　　2. kube-proxy 是實現service的通訊與負載均衡機制的重要元件，將到service的請求轉發到後端的pod上。

　　3. Container runtime：容器執行環境，目前Kubernetes支援docker和rkt兩種容器。

pod建立流程

　　1 kubelet client 端執行kubelet create pod命令提交post kubelet apiserver請求

　　2 apiserver 監聽接受到請求
　　2.1 對請求進行、解析、認證、授權、超時處理、審計通過
　　2.2 pod請求事件進入MUX和route流程，apiserver會根據請求匹配對應pod型別的定義，apiserver會進行一個convert工作，將請求內容轉換成super version物件
　　2.3 apiserver會先進行admission() 准入控制，比如新增標籤，新增sidecar容器等和校驗個欄位合法性
　　2.4 apiserver將驗證通過的api物件轉換成使用者最初提交的版本，進行序列化操作，並呼叫etcd api儲存apiserver處理pod事件資訊，apiserver把pod物件add到排程佇列中

　　3.1schedule排程器會通過監聽apiserver add到pod物件佇列，
　　3.2排程器開始嘗試排程，篩選出適合排程的節點，並打分選出一個最高分的節點
　　3.3 排程器會將pod物件與node繫結，排程器將資訊同步apiserver儲存到etcd中完成排程

　　4.1 節點kubelet通過watch監聽機制，監聽與自己相關的pod物件，kubelet會把相關pod資訊podcache快取到節點記憶體
　　4.2 kubelet通過檢查該pod物件在kubelet記憶體狀態，kubelet就能夠判斷出是一個新排程pod物件
　　4.3 kubelet會啟動 pod update worker、單獨goroutine處理pod物件生成對應的pod status，檢查pod所生命的volume、網路是否準備好
　　4.4 kubelet呼叫docker api 容器執行時CRI，發起外掛pod所定義容器Container Runtime Interface, CRI請求
　　4.5 docker 容器執行時比如docker響應請求，然後開始建立對應容器

官方文件：https://www.kubernetes.org.cn/k8s
資料文件：https://blog.csdn.net/weixin_38645718/article/details/85931795，https://blog.csdn.net/sq4521/article/details/105912608，https://blog.51cto.com/zjunzz/2549946