Kubernetes學習總結(2)——Kubernetes設計架構

一杯甜酒發表於2017-11-20

Kubernetes叢集包含有節點代理kubelet和Master元件(APIs, scheduler, etc),一切都基於分散式的儲存系統。下面這張圖是Kubernetes的架構圖。


Kubernetes節點
在這張系統架構圖中,我們把服務分為執行在工作節點上的服務和組成叢集級別控制板的服務。
Kubernetes節點有執行應用容器必備的服務,而這些都是受Master的控制。
每次個節點上當然都要執行Docker。Docker來負責所有具體的映像下載和容器執行。
Kubernetes主要由以下幾個核心元件組成:
etcd儲存了整個叢集的狀態;
apiserver提供了資源操作的唯一入口,並提供認證、授權、訪問控制、API註冊和發現等機制;
controller manager負責維護叢集的狀態,比如故障檢測、自動擴充套件、滾動更新等;
scheduler負責資源的排程,按照預定的排程策略將Pod排程到相應的機器上;
kubelet負責維護容器的生命週期,同時也負責Volume(CVI)和網路(CNI)的管理;
Container runtime負責映象管理以及Pod和容器的真正執行(CRI);
kube-proxy負責為Service提供cluster內部的服務發現和負載均衡;
除了核心元件,還有一些推薦的Add-ons:
kube-dns負責為整個叢集提供DNS服務
Ingress Controller為服務提供外網入口
Heapster提供資源監控
Dashboard提供GUI
Federation提供跨可用區的叢集

Fluentd-elasticsearch提供叢集日誌採集、儲存與查詢



分層架構

Kubernetes設計理念和功能其實就是一個類似Linux的分層架構,如下圖所示


核心層:Kubernetes最核心的功能,對外提供API構建高層的應用,對內提供外掛式應用執行環境
應用層:部署(無狀態應用、有狀態應用、批處理任務、叢集應用等)和路由(服務發現、DNS解析等)
管理層:系統度量(如基礎設施、容器和網路的度量),自動化(如自動擴充套件、動態Provision等)以及策略管理(RBAC、Quota、PSP、NetworkPolicy等)
介面層:kubectl命令列工具、客戶端SDK以及叢集聯邦
生態系統:在介面層之上的龐大容器叢集管理排程的生態系統,可以劃分為兩個範疇
Kubernetes外部:日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等
Kubernetes內部:CRI、CNI、CVI、映象倉庫、Cloud Provider、叢集自身的配置和管理等
kubelet
kubelet負責管理pods和它們上面的容器,images映象、volumes、etc。
kube-proxy
每一個節點也執行一個簡單的網路代理和負載均衡(詳見services FAQ )(PS:官方 英文)。 正如Kubernetes API裡面定義的這些服務(詳見the services doc)(PS:官方 英文)也可以在各種終端中以輪詢的方式做一些簡單的TCP和UDP傳輸。
服務端點目前是通過DNS或者環境變數( Docker-links-compatible 和 Kubernetes{FOO}_SERVICE_HOST 及 {FOO}_SERVICE_PORT 變數都支援)。這些變數由服務代理所管理的埠來解析。
Kubernetes控制皮膚
Kubernetes控制皮膚可以分為多個部分。目前它們都執行在一個master 節點,然而為了達到高可用性,這需要改變。不同部分一起協作提供一個統一的關於叢集的檢視。
etcd
所有master的持續狀態都存在etcd的一個例項中。這可以很好地儲存配置資料。因為有watch(觀察者)的支援,各部件協調中的改變可以很快被察覺。
Kubernetes API Server
API服務提供Kubernetes API (PS:官方 英文)的服務。這個服務試圖通過把所有或者大部分的業務邏輯放到不兩隻的部件中從而使其具有CRUD特性。它主要處理REST操作,在etcd中驗證更新這些物件(並最終儲存)。
Scheduler
排程器把未排程的pod通過binding api繫結到節點上。排程器是可插拔的,並且我們期待支援多叢集的排程,未來甚至希望可以支援使用者自定義的排程器。
Kubernetes控制管理伺服器
所有其它的叢集級別的功能目前都是由控制管理器所負責。例如,端點物件是被端點控制器來建立和更新。這些最終可以被分隔成不同的部件來讓它們獨自的可插拔。
replicationcontroller(PS:官方 英文)是一種建立於簡單的 pod API之上的一種機制。一旦實現,我們最終計劃把這變成一種通用的外掛機制。
參考:
https://github.com/kubernetes/kubernetes/blob/release-1.2/docs/design/architecture.md
https://feisky.gitbooks.io/kubernetes/architecture/architecture.html

相關文章