摘要：隨著社區(qū)及各大廠商的不斷改進(jìn)發(fā)展，將成為容器管理領(lǐng)域的領(lǐng)導(dǎo)者。以集群的方式運(yùn)行管理跨機(jī)器的容器。的自我修復(fù)機(jī)制使得容器集群總是運(yùn)行在用戶期望的狀態(tài)。

本文來源于Infoq的一篇文章（見參考部分），并在難懂的地方自己理解的基礎(chǔ)上做了修改。實(shí)際在ubuntu上部署 kubernetes 操作另見 文章 。

  
Together we will ensure that Kubernetes is a strong and open container management framework for any application and in any environment, whether in a private, public or hybrid cloud.  --Urs H?lzle, Google

Kubernetes 作為Docker生態(tài)圈中重要一員，是Google多年大規(guī)模容器管理技術(shù)的開源版本，是產(chǎn)線實(shí)踐經(jīng)驗(yàn)的最佳表現(xiàn)。如Urs H?lzle所說，無論是公有云還是私有云甚至混合云，Kubernetes將作為一個(gè)為任何應(yīng)用，任何環(huán)境的容器管理框架無處不在。正因?yàn)槿绱?，目前受到各大巨頭及初創(chuàng)公司的青睞，如Microsoft、VMWare、Red Hat、CoreOS、Mesos等，紛紛加入給Kubernetes貢獻(xiàn)代碼。隨著Kubernetes社區(qū)及各大廠商的不斷改進(jìn)、發(fā)展，Kuberentes將成為容器管理領(lǐng)域的領(lǐng)導(dǎo)者。

接下來我們一起探索Kubernetes是什么、能做什么以及怎么做。

Kubernetes是Google開源的容器集群管理系統(tǒng)，使用Golang開發(fā)，其提供應(yīng)用部署、維護(hù)、擴(kuò)展機(jī)制等功能，利用Kubernetes能方便地管理跨機(jī)器運(yùn)行容器化的應(yīng)用，其主要功能如下：

使用Docker對應(yīng)用程序包裝(package)、實(shí)例化(instantiate)、運(yùn)行(run)。

以集群的方式運(yùn)行、管理跨機(jī)器的容器。

解決Docker跨機(jī)器容器之間的通訊問題。

Kubernetes的自我修復(fù)機(jī)制使得容器集群總是運(yùn)行在用戶期望的狀態(tài)。

當(dāng)前Kubernetes支持GCE、vShpere、CoreOS、OpenShift、Azure等平臺(tái)，除此之外，也可以直接運(yùn)行在物理機(jī)上。

這個(gè)官方給出的完整的架構(gòu)圖：（可放大看）

在Kubernetes系統(tǒng)中，調(diào)度的最小顆粒不是單純的容器，而是抽象成一個(gè)Pod，Pod是一個(gè)可以被創(chuàng)建、銷毀、調(diào)度、管理的最小的部署單元。把相關(guān)的一個(gè)或多個(gè)容器（Container）構(gòu)成一個(gè)Pod，通常Pod里的容器運(yùn)行相同的應(yīng)用。Pod包含的容器運(yùn)行在同一個(gè)Minion(Host)上，看作一個(gè)統(tǒng)一管理單元，共享相同的volumes和network namespace/IP和Port空間。

Services也是Kubernetes的基本操作單元，是真實(shí)應(yīng)用服務(wù)的抽象，每一個(gè)服務(wù)后面都有很多對應(yīng)的容器來支持，通過Proxy的port和服務(wù)selector決定服務(wù)請求傳遞給后端提供服務(wù)的容器，對外表現(xiàn)為一個(gè)單一訪問地址，外部不需要了解后端如何運(yùn)行，這給擴(kuò)展或維護(hù)后端帶來很大的好處。

這一點(diǎn)github上的官網(wǎng)文檔services.md講的特別清楚。

Replication Controller，理解成更復(fù)雜形式的pods，它確保任何時(shí)候Kubernetes集群中有指定數(shù)量的pod副本(replicas)在運(yùn)行，如果少于指定數(shù)量的pod副本(replicas)，Replication Controller會(huì)啟動(dòng)新的Container，反之會(huì)殺死多余的以保證數(shù)量不變。Replication Controller使用預(yù)先定義的pod模板創(chuàng)建pods，一旦創(chuàng)建成功，pod 模板和創(chuàng)建的pods沒有任何關(guān)聯(lián)，可以修改 pod 模板而不會(huì)對已創(chuàng)建pods有任何影響，也可以直接更新通過Replication Controller創(chuàng)建的pods。對于利用 pod 模板創(chuàng)建的pods，Replication Controller根據(jù) label selector 來關(guān)聯(lián)，通過修改pods的label可以刪除對應(yīng)的pods。Replication Controller主要有如下用法：

Rescheduling
如上所述，Replication Controller會(huì)確保Kubernetes集群中指定的pod副本(replicas)在運(yùn)行， 即使在節(jié)點(diǎn)出錯(cuò)時(shí)。

Scaling
通過修改Replication Controller的副本(replicas)數(shù)量來水平擴(kuò)展或者縮小運(yùn)行的pods。

Rolling updates
Replication Controller的設(shè)計(jì)原則使得可以一個(gè)一個(gè)地替換pods來滾動(dòng)更新（rolling updates）服務(wù)。

Multiple release tracks
如果需要在系統(tǒng)中運(yùn)行multiple release的服務(wù)，Replication Controller使用labels來區(qū)分multiple release tracks。

以上三個(gè)概念便是用戶可操作的REST對象。Kubernetes以RESTfull API形式開放的接口來處理。

service和replicationController只是建立在pod之上的抽象，最終是要作用于pod的，那么它們?nèi)绾胃鷓od聯(lián)系起來呢？這就引入了label的概念：label其實(shí)很好理解，就是為pod加上可用于搜索或關(guān)聯(lián)的一組key/value標(biāo)簽，而service和replicationController正是通過label來與pod關(guān)聯(lián)的。為了將訪問Service的請求轉(zhuǎn)發(fā)給后端提供服務(wù)的多個(gè)容器，正是通過標(biāo)識(shí)容器的labels來選擇正確的容器；Replication Controller也使用labels來管理通過 pod 模板創(chuàng)建的一組容器，這樣Replication Controller可以更加容易，方便地管理多個(gè)容器。

如下圖所示，有三個(gè)pod都有l(wèi)abel為"app=backend"，創(chuàng)建service和replicationController時(shí)可以指定同樣的label:"app=backend"，再通過label selector機(jī)制，就將它們與這三個(gè)pod關(guān)聯(lián)起來了。例如，當(dāng)有其他frontend pod訪問該service時(shí)，自動(dòng)會(huì)轉(zhuǎn)發(fā)到其中的一個(gè)backend pod。

Kubenetes整體框架如下圖，主要包括kubecfg、Master API Server、Kubelet、Minion(Host)以及Proxy。

Master定義了Kubernetes 集群Master/API Server的主要聲明，包括Pod Registry、Controller Registry、Service Registry、Endpoint Registry、Minion Registry、Binding Registry、RESTStorage以及Client, 是client(Kubecfg)調(diào)用Kubernetes API，管理Kubernetes主要構(gòu)件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等組成。從下圖可知Master的工作流主要分以下步驟：

Kubecfg將特定的請求，比如創(chuàng)建Pod，發(fā)送給Kubernetes Client。

Kubernetes Client將請求發(fā)送給API server。

API Server根據(jù)請求的類型，比如創(chuàng)建Pod時(shí)storage類型是pods，然后依此選擇何種REST Storage API對請求作出處理。

REST Storage API對的請求作相應(yīng)的處理。

將處理的結(jié)果存入高可用鍵值存儲(chǔ)系統(tǒng)Etcd中。

在API Server響應(yīng)Kubecfg的請求后，Scheduler會(huì)根據(jù)Kubernetes Client獲取集群中運(yùn)行Pod及Minion信息。

依據(jù)從Kubernetes Client獲取的信息，Scheduler將未分發(fā)的Pod分發(fā)到可用的Minion節(jié)點(diǎn)上。

下面是Master的主要構(gòu)件的詳細(xì)介紹。

Minion Registry負(fù)責(zé)跟蹤Kubernetes 集群中有多少M(fèi)inion(Host)。Kubernetes封裝Minion Registry成實(shí)現(xiàn)Kubernetes API Server的RESTful API接口REST，通過這些API，我們可以對Minion Registry做Create、Get、List、Delete操作，由于Minon只能被創(chuàng)建或刪除，所以不支持Update操作，并把Minion的相關(guān)配置信息存儲(chǔ)到etcd。除此之外，Scheduler算法根據(jù)Minion的資源容量來確定是否將新建Pod分發(fā)到該Minion節(jié)點(diǎn)。

可以通過curl http://{master-apiserver-ip}:4001/v2/keys/registry/minions/來驗(yàn)證etcd中存儲(chǔ)的內(nèi)容。

Pod Registry負(fù)責(zé)跟蹤Kubernetes集群中有多少Pod在運(yùn)行，以及這些Pod跟Minion是如何的映射關(guān)系。將Pod Registry和Cloud Provider信息及其他相關(guān)信息封裝成實(shí)現(xiàn)Kubernetes API Server的RESTful API接口REST。通過這些API，我們可以對Pod進(jìn)行Create、Get、List、Update、Delete操作，并將Pod的信息存儲(chǔ)到etcd中，而且可以通過Watch接口監(jiān)視Pod的變化情況，比如一個(gè)Pod被新建、刪除或者更新。

Service Registry負(fù)責(zé)跟蹤Kubernetes集群中運(yùn)行的所有服務(wù)。根據(jù)提供的Cloud Provider及Minion Registry信息把Service Registry封裝成實(shí)現(xiàn)Kubernetes API Server需要的RESTful API接口REST。利用這些接口，我們可以對Service進(jìn)行Create、Get、List、Update、Delete操作，以及監(jiān)視Service變化情況的watch操作，并把Service信息存儲(chǔ)到etcd。

Controller Registry負(fù)責(zé)跟蹤Kubernetes集群中所有的Replication Controller，Replication Controller維護(hù)著指定數(shù)量的pod 副本(replicas)拷貝，如果其中的一個(gè)容器死掉，Replication Controller會(huì)自動(dòng)啟動(dòng)一個(gè)新的容器，如果死掉的容器恢復(fù)，其會(huì)殺死多出的容器以保證指定的拷貝不變。通過封裝Controller Registry為實(shí)現(xiàn)Kubernetes API Server的RESTful API接口REST， 利用這些接口，我們可以對Replication Controller進(jìn)行Create、Get、List、Update、Delete操作，以及監(jiān)視Replication Controller變化情況的watch操作，并把Replication Controller信息存儲(chǔ)到etcd。

Endpoints Registry負(fù)責(zé)收集Service的endpoint，比如Name："mysql"，Endpoints: ["10.10.1.1:1909"，"10.10.2.2:8834"]，同Pod Registry，Controller Registry也實(shí)現(xiàn)了Kubernetes API Server的RESTful API接口，可以做Create、Get、List、Update、Delete以及watch操作。

Binding包括一個(gè)需要綁定Pod的ID和Pod被綁定的Host，Scheduler寫B(tài)inding Registry后，需綁定的Pod被綁定到一個(gè)host。Binding Registry也實(shí)現(xiàn)了Kubernetes API Server的RESTful API接口，但Binding Registry是一個(gè)write-only對象，所有只有Create操作可以使用， 否則會(huì)引起錯(cuò)誤。

Scheduler收集和分析當(dāng)前Kubernetes集群中所有Minion節(jié)點(diǎn)的資源(內(nèi)存、CPU)負(fù)載情況，然后依此分發(fā)新建的Pod到Kubernetes集群中可用的節(jié)點(diǎn)。由于一旦Minion節(jié)點(diǎn)的資源被分配給Pod，那這些資源就不能再分配給其他Pod， 除非這些Pod被刪除或者退出， 因此，Kubernetes需要分析集群中所有Minion的資源使用情況，保證分發(fā)的工作負(fù)載不會(huì)超出當(dāng)前該Minion節(jié)點(diǎn)的可用資源范圍。具體來說，Scheduler做以下工作：

實(shí)時(shí)監(jiān)測Kubernetes集群中未分發(fā)的Pod。

實(shí)時(shí)監(jiān)測Kubernetes集群中所有運(yùn)行的Pod，Scheduler需要根據(jù)這些Pod的資源狀況安全地將未分發(fā)的Pod分發(fā)到指定的Minion節(jié)點(diǎn)上。

Scheduler也監(jiān)測Minion節(jié)點(diǎn)信息，由于會(huì)頻繁查找Minion節(jié)點(diǎn)，Scheduler會(huì)緩存一份最新的信息在本地。

最后，Scheduler在分發(fā)Pod到指定的Minion節(jié)點(diǎn)后，會(huì)把Pod相關(guān)的信息Binding寫回API Server。

根據(jù)上圖可知Kubelet是Kubernetes集群中每個(gè)Minion和Master API Server的連接點(diǎn)，Kubelet運(yùn)行在每個(gè)Minion上，是Master API Server和Minion之間的橋梁，接收Master API Server分配給它的commands和work，與持久性鍵值存儲(chǔ)etcd、file、server和http進(jìn)行交互，讀取配置信息。Kubelet的主要工作是管理Pod和容器的生命周期，其包括Docker Client、Root Directory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker組件，具體工作如下：

通過Worker給Pod異步運(yùn)行特定的Action

設(shè)置容器的環(huán)境變量

給容器綁定Volume

給容器綁定Port

根據(jù)指定的Pod運(yùn)行一個(gè)單一容器

殺死容器

給指定的Pod創(chuàng)建network 容器

刪除Pod的所有容器

同步Pod的狀態(tài)

從cAdvisor獲取container info、 pod info、 root info、 machine info

檢測Pod的容器健康狀態(tài)信息

在容器中運(yùn)行命令。

Proxy是為了解決外部網(wǎng)絡(luò)能夠訪問跨機(jī)器集群中容器提供的應(yīng)用服務(wù)而設(shè)計(jì)的，運(yùn)行在每個(gè)Minion上。Proxy提供TCP/UDP sockets的proxy，每創(chuàng)建一種Service，Proxy主要從etcd獲取Services和Endpoints的配置信息（也可以從file獲?。缓蟾鶕?jù)配置信息在Minion上啟動(dòng)一個(gè)Proxy的進(jìn)程并監(jiān)聽相應(yīng)的服務(wù)端口，當(dāng)外部請求發(fā)生時(shí)，Proxy會(huì)根據(jù)Load Balancer將請求分發(fā)到后端正確的容器處理。

所以Proxy不但解決了同一主宿機(jī)相同服務(wù)端口沖突的問題，還提供了Service轉(zhuǎn)發(fā)服務(wù)端口對外提供服務(wù)的能力，Proxy后端使用了隨機(jī)、輪循負(fù)載均衡算法。關(guān)于更多 kube-proxy 的內(nèi)容 KUBERNETES代碼走讀之MINION NODE 組件 KUBE-PROXY 。

etcd在上面架構(gòu)圖上提到過幾次，但它并不是kubernetes的一部分，它是 CoreOS 團(tuán)隊(duì)發(fā)起的一個(gè)管理配置信息和服務(wù)發(fā)現(xiàn)（service discovery）項(xiàng)目，目標(biāo)是構(gòu)建一個(gè)高可用的分布式鍵值（key-value）數(shù)據(jù)庫。與kubernetes和docker一樣還是在快速迭代開發(fā)中的產(chǎn)品，沒有ZooKeeper那樣成熟。有機(jī)會(huì)再另外通過文章介紹。

參考

Kubernetes系統(tǒng)架構(gòu)簡介

An Introduction to Kubernetes

Kubernetes-DESIGN （Kubernetes 設(shè)計(jì)概要）

怎樣構(gòu)建一個(gè)容器集群

原文鏈接地址：http://seanlook.com/2015/02/03/docker-kubernetes-arch-introduction/