# **一、Kubernetes架構概覽**  ***** 上圖為Kubernetes的架構的概覽。在Kubernetes集群中主要由兩類角色，分別為：Master節點和Worker節點；簡單來說，Master節點主要用來管理和調度集群資源的，而Worker節點則是提供資源（運行實際的業務服務的）；在一個高可用Kubernetes集群中，Master和Worker節點都需要由多個節點構成。這些節點可以是物理機，也可以是虛擬機，也可以直接是云主機 ***** Worker節點提供的資源單位稱為Pod，簡單來說，Pod就是Kubernetes云平臺提供的虛擬機。Pod是Kubernetes調度的最小單位，在Pod里可以運行單個容器或者多個容器。 一個Pod里面的多個容器共享存儲資源和網絡資源 ***** Kubernetes主要解決集群資源調度的問題，簡單來說，就是Kubernetes需要根據集群服務器的資源空閑現狀，將我們的應用服務分配到空閑的Worker節點上。同時，Kubernetes也需要監控集群的狀態，當有節點或者Pod掛掉，它要能夠重新協調和啟動Pods，保證應用高可用，另外，Kubernetes需要管理集群網絡，保證Pod/服務之間可以互通互聯 ***** #### **二、Master/Worker節點組件構成**  **Master節點是Kubernetes集群大腦，它由如下組件構成：** 1、Etcd： 它是Kubernetes的集中狀態存儲，所有的集群狀態數據，例如節點，Pods，發布，配置等等，最終都存儲在Etcd中。Etcd是一個分布式KV數據庫，采用Raft分布式一致性算法。Etcd高可用部署一般需要至少三個節點。Etcd集群可以獨立部署，也可以和Master節點住在一起。 2、API Server： 它是Kubenretes集群的接口和通訊總線。用戶通過kubectl，dashboard或者sdk等方式操作Kubenretes，其背后通過API server和集群進行交互。并且集群內的其它組件，例如Kubelet/Kube-Proxy/Scheduler/Controller-Manager等，都通過API server和集群進行交互。API Server是唯一能夠訪問操作Etcd數據庫的組件，其它組件，都必須通過API server間接操作Etcd。API server不僅接受其它組件的API請求，它還是集群的事件總線，其它組件可以訂閱在API server上，當有新事件發生時候，API server會將相關事件通知到感興趣的組件。 3、Scheduler：它是Kubenretes集群負責調度決策的組件。Scheduler掌握當前的集群資源使用情況，當有新的應用發布請求被提交到Kubenretes集群，它負責決策相應的Pods應該分布到哪些空閑節點上去。Kubenretes中的調度決策算法是可以擴展的。 4、Controller Manager：它是保證集群狀態最終一致的組件。它通過API server監控集群狀態，確保實際狀態和預期狀態最終一致，如果一個應用要求發布十個Pods，Controller Manager保證這個應用最終啟動十個Pods，如果中間有Pods掛了，Controller Manager會負責協調重啟Pods，如果Pods啟多了，Controller Manager會負責協調關閉多余Pods。也即是說，Kubenretes采用最終一致調度策略，它是集群自愈的背后實現機制。  **Worker節點是K8s集群資源的提供者，它由如下組件構成：** 1、Kubelet： 它是Worker節點資源的管理者，相當于一個Agent角色。它監聽API server的事件，根據Master節點的指示啟動或者關閉Pod等資源，也將本節點狀態數據匯報給Master節點。如果說Master節點是Kubenretes集群的大腦，那么Kubelet就是Worker節點的小腦 2、Container Runtime: 它是節點容器資源的管理者，如果采用Docker容器，那么它就是Docker Engine。Kubelet并不直接管理節點的容器資源，它委托Container Runtime進行管理，比如啟動或者關閉容器，收集容器狀態等。Container Runtime在啟動容器時，如果本地沒有鏡像緩存，則需要到Docker Registry(或Docker Hub)去拉取相應鏡像，然后緩存本地 3、Kube-Proxy： 它是管理Kubernetes中的服務(Service)網絡的組件，Pod在Kubernetes是不固定的，PodIP可能會變(包括預期和非預期的)。為了屏蔽PodIP的可能的變化，Kubenretes中引入了Service概念，它可以屏蔽應用的PodIP，并且在調用時進行負載均衡。Kube-Proxy是實現Kubenretes服務(Service)網絡的背后機制。另外，當需要把Kubenretes中的服務(Service)暴露給外網時，也需要通過Kube-Proxy進行代理轉發。 ***** #### **三、流程樣例**  下面我們通過一個發布流程，展示上面介紹的這些組件是如何配合工作的： 1、要發布一個新應用，他通過Kubectl命令行工具將發布請求提交到API server，API server將請求存儲到Etcd數據庫中 2、Scheduler通過API server監聽到有新的應用發布請求，它通過調度算法決策，選擇若干可發布的空閑節點，并將發布決策更新到API server 3、被選中的Worker節點上的Kubelet通過API server監聽到有給自己的新發布任務,它根據任務指示在本地啟動相應的Pods(間接通過Container Runtime啟動容器)，并將任務執行成功情況報告給API server 4、所有Worker節點上Kube-Proxy通過API server監聽到有新的發布，它獲取應用的PodIP/ClusterIP/端口等相關數據，更新本地的iptables表規則，讓本地的Pods可以通過iptables轉發方式，訪問到新發布應用的Pods 5、Controller Manager通過API server，時刻監控新發應用的健康狀況，保證實際狀態和預期狀態最終一致 ***** #### **四、Kuberneter總體架構**  除了上述組件，K8s外圍一般還有存儲，監控，日志和分析等配套支持服務