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是什麼、能做什麼以及怎麼做。

Kubernetes是Google開源的容器叢集管理系統，其提供應用部署、維護、 擴充機制等功能，利用Kubernetes能友善地管理跨機器運作容器化的應用，其主要功能如下：

1) 使用Docker對應用程式包裝(package)、執行個體化(instantiate)、運作(run)。

2) 以叢集的方式運作、管理跨機器的容器。

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

4) Kubernetes的自我修複機制使得容器叢集總是運作在使用者期望的狀态。

目前Kubernetes支援GCE、vShpere、CoreOS、OpenShift、Azure等平台，除此之外，也可以直接運作在實體機上。

接下來本文主要從以下幾方面闡述Kubernetes：

1) Kubernetes的主要概念。

2) Kubernetes的構件，包括Master元件、Kubelet、Proxy的詳細介紹。

Pod是Kubernetes的基本操作單元，把相關的一個或多個容器構成一個Pod，通常Pod裡的容器運作相同的應用。Pod包含的容器運作在同一個Minion(Host)上，看作一個統一管理單元，共享相同的volumes和network namespace/IP和Port空間。

Services也是Kubernetes的基本操作單元，是真實應用服務的抽象，每一個服務後面都有很多對應的容器來支援，通過Proxy的port和服務selector決定服務請求傳遞給後端提供服務的容器，對外表現為一個單一通路接口，外部不需要了解後端如何運作，這給擴充或維護後端帶來很大的好處。

1) Rescheduling

如上所述，Replication Controller會確定Kubernetes叢集中指定的pod副本(replicas)在運作， 即使在節點出錯時。

2) Scaling

通過修改Replication Controller的副本(replicas)數量來水準擴充或者縮小運作的pods。

3) Rolling updates

Replication Controller的設計原則使得可以一個一個地替換pods來rolling updates服務。

4) Multiple release tracks

如果需要在系統中運作multiple release的服務，Replication Controller使用labels來區分multiple release tracks。

Labels是用于區分Pod、Service、Replication Controller的key/value鍵值對，Pod、Service、 Replication Controller可以有多個label，但是每個label的key隻能對應一個value。Labels是Service和Replication Controller運作的基礎，為了将通路Service的請求轉發給後端提供服務的多個容器，正是通過辨別容器的labels來選擇正确的容器。同樣，Replication Controller也使用labels來管理通過pod 模闆建立的一組容器，這樣Replication Controller可以更加容易，友善地管理多個容器，無論有多少容器。

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

圖3-1 Kubernetes High 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的工作流主要分以下步驟：

1) Kubecfg将特定的請求，比如建立Pod，發送給Kubernetes Client。

2) Kubernetes Client将請求發送給API server。

3) API Server根據請求的類型，比如建立Pod時storage類型是pods，然後依此選擇何種REST Storage API對請求作出處理。

4) REST Storage API對的請求作相應的處理。

5) 将處理的結果存入高可用鍵值存儲系統Etcd中。

6) 在API Server響應Kubecfg的請求後，Scheduler會根據Kubernetes Client擷取叢集中運作Pod及Minion資訊。

7) 依據從Kubernetes Client擷取的資訊，Scheduler将未分發的Pod分發到可用的Minion節點上。

下面是Master的主要構件的詳細介紹：

圖3-2 Master主要構件及工作流

Pod Registry負責跟蹤Kubernetes叢集中有多少Pod在運作，以及這些Pod跟Minion是如何的映射關系。将Pod Registry和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。

Controller Registry負責跟蹤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。

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

Binding包括一個需要綁定Pod的ID和Pod被綁定的Host，Scheduler寫Binding Registry後，需綁定的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做以下工作：

1) 實時監測Kubernetes叢集中未分發的Pod。

2) 實時監測Kubernetes叢集中所有運作的Pod，Scheduler需要根據這些Pod的資源狀況安全地将未分發的Pod分發到指定的Minion節點上。

3) Scheduler也監測Minion節點資訊，由于會頻繁查找Minion節點，Scheduler會緩存一份最新的資訊在本地。

4) 最後，Scheduler在分發Pod到指定的Minion節點後，會把Pod相關的資訊Binding寫回API Server。

圖3-3 Kubernetes詳細構件

根據上圖3-3可知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元件，具體工作如下：

1) 通過Worker給Pod異步運作特定的Action。

2) 設定容器的環境變量。

3) 給容器綁定Volume。

4) 給容器綁定Port。

5) 根據指定的Pod運作一個單一容器。

6) 殺死容器。

7) 給指定的Pod建立network 容器。

8) 删除Pod的所有容器。

9) 同步Pod的狀态。

10) 從Cadvisor擷取container info、 pod info、root info、machine info。

11) 檢測Pod的容器健康狀态資訊。

12) 在容器中運作指令。

Proxy是為了解決外部網絡能夠通路跨機器叢集中容器提供的應用服務而設計的，從上圖3-3可知Proxy服務也運作在每個Minion上。Proxy提供TCP/UDP sockets的proxy，每建立一種Service，Proxy主要從etcd擷取Services和Endpoints的配置資訊，或者也可以從file擷取，然後根據配置資訊在Minion上啟動一個Proxy的程序并監聽相應的服務端口，當外部請求發生時，Proxy會根據Load Balancer将請求分發到後端正确的容器處理。

下篇講述在CentOS7上用Kubernetes來管理容器。

本文轉自feisky部落格園部落格，原文連結：http://www.cnblogs.com/feisky/p/4106456.html，如需轉載請自行聯系原作者