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

本文來源于Infoq的一篇文章（見參考部分），并在難懂的地方自己理解的基礎(chǔ)上做了修改。實際在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)線實踐經(jīng)驗的最佳表現(xiàn)。如Urs H?lzle所說，無論是公有云還是私有云甚至混合云，Kubernetes將作為一個為任何應(yīng)用，任何環(huán)境的容器管理框架無處不在。正因為如此，目前受到各大巨頭及初創(chuàng)公司的青睞，如Microsoft、VMWare、Red Hat、CoreOS、Mesos等，紛紛加入給Kubernetes貢獻代碼。隨著Kubernetes社區(qū)及各大廠商的不斷改進、發(fā)展，Kuberentes將成為容器管理領(lǐng)域的領(lǐng)導(dǎo)者。

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

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

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

以集群的方式運行、管理跨機器的容器。

解決Docker跨機器容器之間的通訊問題。

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

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

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

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

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

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

Replication Controller，理解成更復(fù)雜形式的pods，它確保任何時候Kubernetes集群中有指定數(shù)量的pod副本(replicas)在運行，如果少于指定數(shù)量的pod副本(replicas)，Replication Controller會啟動新的Container，反之會殺死多余的以保證數(shù)量不變。Replication Controller使用預(yù)先定義的pod模板創(chuàng)建pods，一旦創(chuàng)建成功，pod 模板和創(chuàng)建的pods沒有任何關(guān)聯(lián)，可以修改 pod 模板而不會對已創(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會確保Kubernetes集群中指定的pod副本(replicas)在運行， 即使在節(jié)點出錯時。

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

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

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

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

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

如下圖所示，有三個pod都有l(wèi)abel為"app=backend"，創(chuàng)建service和replicationController時可以指定同樣的label:"app=backend"，再通過label selector機制，就將它們與這三個pod關(guān)聯(lián)起來了。例如，當(dāng)有其他frontend pod訪問該service時，自動會轉(zhuǎn)發(fā)到其中的一個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時storage類型是pods，然后依此選擇何種REST Storage API對請求作出處理。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

根據(jù)上圖可知Kubelet是Kubernetes集群中每個Minion和Master API Server的連接點，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

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

給容器綁定Volume

給容器綁定Port

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

殺死容器

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

刪除Pod的所有容器

同步Pod的狀態(tài)

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

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

在容器中運行命令。

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

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

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

參考

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

An Introduction to Kubernetes

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

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

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