Kubernetes系統架構簡介mysql
Together we will ensure that Kubernetes is astrong and open container management framework for any application and in anyenvironment, whether in a private, public or hybrid cloud.git
Urs Hlzle, Googlegithub
Kubernetes做爲Docker生態圈中重要一員,是Google多年大規模容器管理技術的開源版本。如Urs Hlzle所說,不管是共有云仍是私有云甚至混合雲,Kubernetes將做爲一個爲任何應用,任何環境的容器管理框架無處不在。正由於如此,目前受到各大巨頭及初創公司的青睞,如Microsoft、VMWare、Red Hat、CoreOS、Mesos等,紛紛加入給Kubernetes貢獻代碼。隨着Kubernetes社區及各大廠商的不斷完善、改進、發展,Kuberentes將成爲容器管理領域的領導者。算法
接下來本文會對Kubernetes的主要概念、MasterAPI Server、Kubelet、Proxy構件的詳細介紹,後期用一系列文章帶領你們逐一詳細地探索Kubernetes的深層原理。sql
Kubernetes是Google開源的容器集羣管理系統,其提供應用部署、維護、 擴展機制等功能,利用Kubernetes能方便地管理跨機器運行容器化的應用,其主要功能以下:docker
使用Docker對應用程序包裝(package)、實例化(instantiate)、運行(run)。後端
以集羣的方式運行、管理跨機器的容器。緩存
解決Docker跨機器容器之間的通信問題。安全
Kubernetes的自我修復機制使得容器集羣老是運行在用戶指望的狀態。網絡
當前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平臺,除此以外,也能夠直接運行在物理機上。
Pod是Kubernetes的基本操做單元,把相關的一個或多個容器構成一個Pod,一般Pod裏的容器運行相同的應用。Pod包含的容器運行在同一個Minion(Host)上,看做一個統一管理單元,共享相同的volumes和network namespace/IP和Port空間。
Services也是Kubernetes的基本操做單元,是真實應用服務的抽象,每個服務後面都有不少對應的容器來支持,經過Proxy的port和服務selector決定服務請求傳遞給後端提供服務的容器,對外表現爲一個單一訪問接口,外部不須要了解後端如何運行,這給擴展或維護後端帶來很大的好處。
ReplicationController確保任什麼時候候Kubernetes集羣中有指定數量的pod副本(replicas)在運行,若是少於指定數量的pod副本(replicas),Replication Controller會啓動新的Container,反之會殺死多餘的以保證數量不變。Replication Controller使用預先定義的pod模板建立pods,一旦建立成功,pod 模板和建立的pods沒有任何關聯,能夠修改pod 模板而不會對已建立pods有任何影響,也能夠直接更新經過Replication Controller建立的pods。對於利用pod 模板建立的pods,Replication Controller根據label selector來關聯,經過修改pods的label能夠刪除對應的pods。Replication Controller主要有以下用法:
Rescheduling
如上所述,ReplicationController會確保Kubernetes集羣中指定的pod副本(replicas)在運行,即便在節點出錯時。
Scaling
經過修改ReplicationController的副本(replicas)數量來水平擴展或者縮小運行的pods。
Rolling updates
ReplicationController的設計原則使得能夠一個一個地替換pods來rolling updates服務。
Multiple release tracks
若是須要在系統中運行multiplerelease的服務,Replication Controller使用labels來區分multiple release tracks。
Labels是用於區分Pod、Service、ReplicationController的key/value鍵值對,Pod、Service、 Replication Controller能夠有多個label,可是每一個label的key只能對應一個value。Labels是Service和ReplicationController運行的基礎,爲了將訪問Service的請求轉發給後端提供服務的多個容器,正是經過標識容器的labels來選擇正確的容器。一樣,Replication Controller也使用labels來管理經過pod 模板建立的一組容器,這樣Replication Controller能夠更加容易,方便地管理多個容器,不管有多少容器。
Kubenetes總體框架以下圖3-1,主要包括kubecfg、Master APIServer、Kubelet、Minion(Host)以及Proxy。
圖3-1 KubernetesHigh Level構件
Master定義了Kubernetes集羣Master/API Server的主要聲明,包括Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage以及Client, 是client(Kubecfg)調用Kubernetes API,管理Kubernetes主要構件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等組成。從下圖3-2可知Master的工做流主要分如下步驟:
Kubecfg將特定的請求,好比建立Pod,發送給KubernetesClient。
Kubernetes Client將請求發送給APIserver。
API Server根據請求的類型,好比建立Pod時storage類型是pods,而後依此選擇何種RESTStorage API對請求做出處理。
REST Storage API對的請求做相應的處理。
將處理的結果存入高可用鍵值存儲系統Etcd中。
在API Server響應Kubecfg的請求後,Scheduler會根據Kubernetes Client獲取集羣中運行Pod及Minion信息。
依據從Kubernetes Client獲取的信息,Scheduler將未分發的Pod分發到可用的Minion節點上。
下面是Master的主要構件的詳細介紹:
圖3-2 Master主要構件及工做流
Minion Registry負責跟蹤Kubernetes集羣中有多少Minion(Host)。Kubernetes封裝Minion Registry成實現Kubernetes API Server的RESTful API接口REST,經過這些API,咱們能夠對Minion Registry作Create、Get、List、Delete操做,因爲Minon只能被建立或刪除,因此不支持Update操做,並把Minion的相關配置信息存儲到etcd。除此以外,Scheduler算法根據Minion的資源容量來肯定是否將新建Pod分發到該Minion節點。
Pod Registry負責跟蹤Kubernetes集羣中有多少Pod在運行,以及這些Pod跟Minion是如何的映射關係。將PodRegistry和Cloud Provider信息及其餘相關信息封裝成實現Kubernetes API Server的RESTful API接口REST。經過這些API,咱們能夠對Pod進行Create、Get、List、Update、Delete操做,並將Pod的信息存儲到etcd中,並且能夠經過Watch接口監視Pod的變化狀況,好比一個Pod被新建、刪除或者更新。
Service Registry負責跟蹤Kubernetes集羣中運行的全部服務。根據提供的Cloud Provider及Minion Registry信息把Service Registry封裝成實現Kubernetes API Server須要的RESTful API接口REST。利用這些接口,咱們能夠對Service進行Create、Get、List、Update、Delete操做,以及監視Service變化狀況的watch操做,並把Service信息存儲到etcd。
ControllerRegistry負責跟蹤Kubernetes集羣中全部的Replication Controller,Replication Controller維護着指定數量的pod 副本(replicas)拷貝,若是其中的一個容器死掉,Replication Controller會自動啓動一個新的容器,若是死掉的容器恢復,其會殺死多出的容器以保證指定的拷貝不變。經過封裝Controller Registry爲實現Kubernetes API Server的RESTful API接口REST,利用這些接口,咱們能夠對Replication Controller進行Create、Get、List、Update、Delete操做,以及監視Replication Controller變化狀況的watch操做,並把Replication Controller信息存儲到etcd。
EndpointsRegistry負責收集Service的endpoint,好比Name:"mysql",Endpoints: ["10.10.1.1:1909","10.10.2.2:8834"],同PodRegistry,Controller Registry也實現了Kubernetes API Server的RESTful API接口,能夠作Create、Get、List、Update、Delete以及watch操做。
Binding包括一個須要綁定Pod的ID和Pod被綁定的Host,Scheduler寫BindingRegistry後,需綁定的Pod被綁定到一個host。Binding Registry也實現了Kubernetes API Server的RESTful API接口,但Binding Registry是一個write-only對象,全部只有Create操做可使用,不然會引發錯誤。
Scheduler收集和分析當前Kubernetes集羣中全部Minion節點的資源(內存、CPU)負載狀況,而後依此分發新建的Pod到Kubernetes集羣中可用的節點。因爲一旦Minion節點的資源被分配給Pod,那這些資源就不能再分配給其餘Pod,除非這些Pod被刪除或者退出,所以,Kubernetes須要分析集羣中全部Minion的資源使用狀況,保證分發的工做負載不會超出當前該Minion節點的可用資源範圍。具體來講,Scheduler作如下工做:
實時監測Kubernetes集羣中未分發的Pod。
實時監測Kubernetes集羣中全部運行的Pod,Scheduler須要根據這些Pod的資源情況安全地將未分發的Pod分發到指定的Minion節點上。
Scheduler也監測Minion節點信息,因爲會頻繁查找Minion節點,Scheduler會緩存一份最新的信息在本地。
最後,Scheduler在分發Pod到指定的Minion節點後,會把Pod相關的信息Binding寫回API Server。
圖3-3 Kubernetes詳細構件
根據上圖3-3可知Kubelet是Kubernetes集羣中每一個Minion和Master APIServer的鏈接點,Kubelet運行在每一個Minion上,是Master API Server和Minion之間的橋樑,接收Master API Server分配給它的commands和work,與持久性鍵值存儲etcd、file、server和http進行交互,讀取配置信息。Kubelet的主要工做是管理Pod和容器的生命週期,其包括Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker組件,具體工做以下:
經過Worker給Pod異步運行特定的Action。
設置容器的環境變量。
給容器綁定Volume。
給容器綁定Port。
根據指定的Pod運行一個單一容器。
殺死容器。
給指定的Pod建立network 容器。
刪除Pod的全部容器。
同步Pod的狀態。
從Cadvisor獲取container info、 pod info、root info、machine info。
檢測Pod的容器健康狀態信息。
在容器中運行命令。
Proxy是爲了解決外部網絡可以訪問跨機器集羣中容器提供的應用服務而設計的,從上圖3-3可知Proxy服務也運行在每一個Minion上。Proxy提供TCP/UDP sockets的proxy,每建立一種Service,Proxy主要從etcd獲取Services和Endpoints的配置信息,或者也能夠從file獲取,而後根據配置信息在Minion上啓動一個Proxy的進程並監聽相應的服務端口,當外部請求發生時,Proxy會根據Load Balancer將請求分發到後端正確的容器處理。
下篇講述在CentOS7上用Kubernetes來管理容器。