如何理解Kubernetes架構?

前言

理解K8s的架構是運用好K8s的基礎，本文波波幫助大家梳理一下K8s的架構。我們先會對K8s的架構進行一個概覽，然後分別剖析Master和Worker節點的組件構成，然後把這些組件再集成起來，通過一個發佈樣例展示這些組件是如何配合工作的，最後展示K8s集羣的總體架構。

架構概覽

上圖是K8s架構的概覽。K8s集羣中主要有兩類角色，一類是Master節點，另外一類是Worker節點，簡單講，Master節點主要用來管理和調度集羣資源的，而Worker節點則是提供資源的。在一個高可用的K8s集羣中，Master和Worker一般都有多個節點構成，這些節點可以是物理機，也可以是虛擬機。

Worker節點提供的資源單位稱爲Pod，簡單理解，Pod就是K8s雲平臺提供的虛擬機。Pod裏頭住的是應用容器，比如Docker容器，容器是CPU/Mem資源隔離單位。大部分場景下，一個Pod只住一個應用容器，但是也有一些場景，一個Pod裏頭可以住多個容器，其中一個是主容器，其它則是輔助容器。一個Pod裏頭的容器共享Pod的網絡棧和存儲資源。

K8s主要解決集羣資源調度的問題。簡單講，就是當有應用發佈請求過來的時候，K8s需要根據集羣資源空閒現狀，將這個應用的Pods合理的分配到空閒的Worker節點上去。同時，K8s需要時刻監控集羣，如果有節點或者Pods掛了，它要能夠重新協調和啓動Pods，保證應用高可用，這個術語叫自愈。還有，K8s需要管理集羣網絡，保證Pod/服務之間可以互通互聯。

Master節點組件

Master節點是K8s集羣大腦，它由如下組件構成：

1. Etcd： 它是K8s的集中狀態存儲，所有的集羣狀態數據，例如節點，Pods，發佈，配置等等，最終都存儲在Etcd中。Etcd是一個分佈式KV數據庫，採用Raft分佈式一致性算法。Etcd高可用部署一般需要至少三個節點。Etcd集羣可以獨立部署，也可以和Master節點住在一起。
2. API server： 它是K8s集羣的接口和通訊總線。用戶通過kubectl，dashboard或者sdk等方式操作K8s，背後都通過API server和集羣進行交互。集羣內的其它組件，例如Kubelet/Kube-Proxy/Scheduler/Controller-Manager等，都通過API server和集羣進行交互。API server可以認爲是Etcd的一個代理Proxy，它是唯一能夠訪問操作Etcd數據庫的組件，其它組件，都必須通過API server間接操作Etcd。API server不僅接受其它組件的API請求，它還是集羣的事件總線，其它組件可以訂閱在API server上，當有新事件發生時候，API server會將相關事件通知到感興趣的組件。
3. Scheduler： 它是K8s集羣負責調度決策的組件。Scheduler掌握當前的集羣資源使用情況，當有新的應用發佈請求被提交到K8s集羣，它負責決策相應的Pods應該分佈到哪些空閒節點上去。K8s中的調度決策算法是可以擴展的。
4. Controller Manager： 它是保證集羣狀態最終一致的組件。它通過API server監控集羣狀態，確保實際狀態和預期狀態最終一致，如果一個應用要求發佈十個Pods，Controller Manager保證這個應用最終啓動十個Pods，如果中間有Pods掛了，Controller Manager會負責協調重啓Pods，如果Pods啓多了，Controller Manager會負責協調關閉多餘Pods。也即是說，K8s採用最終一致調度策略，它是集羣自愈的背後實現機制。

Worker節點組件

Worker節點是K8s集羣資源的提供者，它由如下組件構成：

1. Kubelet: 它是Worker節點資源的管理者，相當於一個Agent角色。它監聽API server的事件，根據Master節點的指示啓動或者關閉Pod等資源，也將本節點狀態數據彙報給Master節點。如果說Master節點是K8s集羣的大腦，那麼Kubelet就是Worker節點的小腦。
2. Container Runtime: 它是節點容器資源的管理者，如果採用Docker容器，那麼它就是Docker Engine。Kubelet並不直接管理節點的容器資源，它委託Container Runtime進行管理，比如啓動或者關閉容器，收集容器狀態等。Container Runtime在啓動容器時，如果本地沒有鏡像緩存，則需要到Docker Registry(或Docker Hub)去拉取相應鏡像，然後緩存本地。
3. Kube-Proxy: 它是管理K8s中的服務(Service)網絡的組件。Pod在K8s中是ephemeral的概念，也就是不固定的，PodIP可能會變(包括預期和非預期的)。爲了屏蔽PodIP的可能的變化，K8s中引入了Servie概念，它可以屏蔽應用的PodIP，並且在調用時進行負載均衡。Kube-Proxy是實現K8s服務(Service)網絡的背後機制。另外，當需要把K8s中的服務(Service)暴露給外網時，也需要通過Kube-Proxy進行代理轉發。

流程樣例

如果我們把Master節點和Worker節點集成起來，就構成上圖所示的K8s集羣。下面我們通過一個發佈流程，展示上面介紹的這些組件是如何配合工作的。

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，時刻監控新發應用的健康狀況，保證實際狀態和預期狀態最終一致。

總體架構

上圖是一個K8s集羣的總體架構。實際K8s集羣中還有一個覆蓋(Overlay)網絡，集羣中的Pods通過覆蓋網絡可以實現IP尋址和通訊。實現覆蓋網絡的技術有很多，例如Flannel/VxLan/Calico/Weave-Net等等。外網流量如果要訪問K8s集羣內部的服務，一般要走負載均衡器(Load Balancer)，背後流量會通過Kube-Proxy間接轉發到服務Pods上。

除了上述組件，K8s外圍一般還有存儲，監控，日誌和分析等配套支持服務。

總結和課程推薦

下表我把本文講到的一些K8s關鍵組件的作用做一個梳理總結，方便大家理解記憶。

波波近期和極客時間合作，開設了一門叫《Spring Boot和K8s雲原生微服務實踐》的課程，以案例項目驅動形式，講解如何基於Spring Boot技術棧開發一個微服務SaaS應用，也講解K8s的架構和網路原理，並最終將案例應用部署到本地和阿里雲K8s環境，歡迎大家關注學習。