摘要：管理其下控制的的生命周期，保證指定數量的正常運行。青云在國內是獨樹一幟，特別適合用來部署這種分布式應用。其中，是提供的命令行工具，可在任何被管理的機器上運行。這里嘗試用命令行工具檢查下集群狀態。

Kubernetes是Google一直在推進的容器調度和管理系統，是Google內部使用的容器管理系統Borg的開源版本。它可以實現對Docker容器的部署，配置，伸縮和監控等。當下，Kubernetes絕對是最火熱的開源工程之一，在短短的一年多時間里，其Github工程已有接近兩萬次的Commits提交，一千多個PR。目前已經正式發布1.0版本，具備服務生產環境的能力。

Kubernetes作為容器管理和調度系統，能在多臺Host上部署預定義的容器，實現跨Host容器的互通訪問。下圖是Kubernetes的High-level架構圖：

Kubernetes的基本概念包括：

Cluster：Kubernetes維護一個集群，Docker的containers都運行其上。并且，這個集群可以運維在任何云及Bare Metal物理機上。
Master：Master節點包含apiserver，controller-manager，sheduler等核心組件（常常也將etcd部署于其中）。

Node：Kubernetes采用Master-Slaves方式部署，多帶帶一臺Slave機器稱為一個Node（以前叫 Minion）。

Pods：Kubernetes最小管理單位，用于控制創建、重啟、伸縮一組功能相近，共享磁盤的Docker容器。雖然Pod可以多帶帶創建使用，但是推薦通過Replication Controller管理。

Replication controllers(RC)：管理其下控制的Pods的生命周期，保證指定數量（replicas）的Pods正常運行。

Service：可用作服務發現，類似于Loadbalancer，通過Selectors為一組Pods提供對外的接口。

Labels：K/V鍵值對，用來標記Kubernetes組件的類別關系（例如標記一組Pods是frontServices，另一組是backServices）。Labels對于Kubernetes的伸縮調度非常重要。

如果想了解Low-Level的架構細節，可以查看其官網的架構圖http://kubernetes.io/v1.0/docs/design/architecture.png。

從官網的架構圖中可以看到，Kubernetes是一個組件多且依賴復雜的系統（上圖僅僅是單Master，三臺Node的情況。目前，Kubernetes已經支持Multi-Masters的部署架構，即需要至少三臺主機作為Master）。并且Kubernetes社區開發速度非常快，版本差異大，文檔更新往往不及時。所以，如果需要完整部署測試仍然有不少的工作量。如果要在生產中使用它，其運維管理也有較高的門檻。這里，我們將詳細介紹如何使用FIT2CLOUD幫助用戶高效完成Kubernetes的系統部署、日常運維等，降低用戶使用它的難度。

首先，Kubernetes作為容器管理系統，其自身也需要部署在相應的計算資源之上。而我們認為只有部署在IaaS平臺上的Kubernetes才能充分發揮其彈性調度管理的特性。這里，我們選擇了QingCloud作為部署Kubernetes集群的IaaS平臺，主要是考慮如下幾個因素：

從安全角度看，類似Kubernetes這類的PaaS應該是部署在VPC內。青云VPC在國內是獨樹一幟，特別適合用來部署Kubernetes這種分布式應用。

從部署管理角度看，青云提供的“userdata”和“metadata”功能在自動初始化云主機上非常有用，可以簡化整個部署過程。

從成本和靈活性角度看，青云的按秒計費，資源快速響應是非常有吸引力的。這點以我們自身為例：一年多以來我們已經在青云上面創建了超過1萬五千臺虛機，花費僅在1000多。

其次，Kubernetes本身作為一個復雜的分布式應用，也需要工具（比如FIT2CLOUD）來實現快速部署、統一管理、監控告警、升級和伸縮。Kubernetes負責容器的調度和管理，FIT2CLOUD則負責主機的調度和管理。

最后，從目標用戶視角看，Kubernetes集群(容器云)的使用者是應用開發人員，或者準確的講是基于Docker容器的微服務開發者，而FIT2CLOUD和QingCloud的使用者是Kubernetes集群（容器云）運維和系統管理員。下圖清晰描述了Kubernetes、QingCloud、FIT2CLOUD三者及其使用者之間的關系：

QingCloud的VPC基于二層網絡隔離，實現了100%的私有網絡隔離，并且用戶在其Web控制臺就能完全操作VPC私有網絡，包括創建私有網絡，綁定公網 IP，DHCP，端口映射轉發等。

我們推薦在QingCloud的VPC內網中部署Kubernetes，之后通過綁定公網IP和端口映射將KubernetesMaster節點的apiserver endpoint暴露出來。具體部署架構如下圖所示：

在此之前，我們需要在QingCloud的Web控制臺上配置下VPC網絡。具體如下：

創建一個VPC私有網絡，同時創建一個路由器，如下圖所示：

創建一個虛擬路由器，并把上一步創建的私有網絡連接到該路由器上，如下圖所示：

注意：創建虛擬路由器時，需打開該虛擬路由器所用防火墻下行8080端口。因為該端口將在后面用于向外暴露Kubernetes服務接口。

申請一個公網 IP，綁定在路由器上，以便VPC內的Kubernetes apiserver 可以通過路由器對外提供服務。

在VPC內建立一個負載均衡器（LoadBalancer），并為其在8080端口負載均衡器的監聽器來監聽Kubernetes Master節點上的apiserver服務（該服務默認運行在8080端口）。 這樣做的好處是可以只需要配置一次VPC私有網絡及端口轉發規則，在私有網絡內部啟動關閉主機都會自動attach到LoadBalancer，對外提供服務。 具體操作如下圖：

一旦VPC創建配置完成，就可以開始通過FIT2CLOUD快速部署Kubernetes集群。

如上所示，本次示例中，我們會部署一個單Master(192.168.0.3)，2個Nodes（Minions）節點的Kubernetes集群。首先，我們會在FIT2CLOUD上創建兩個不同的虛機組。一個是k8s-master，作為Master節點；一個是k8s-node作為Nodes 節點。具體步驟如下所示：

注：通過FIT2CLOUD在QingCloud上啟動機器，需要先登入FIT2CLOUD控制臺并綁定QingCloud云賬號，具體步驟可以參考FIT2CLOUD官方文檔。另外請參考 FIT2CLOUD新手指南（QingCloud版）了解如何快速開始在FIT2CLOUD中管理QingCloud資源。

第一步：通過FIT2CLOUD控制臺創建Kubernetes集群和虛機組

如下圖創建Master節點虛機組。注意這里必須按指定虛機組名稱，因為后續的初始化Master節點腳本需要利用到這個參數自動發現master的相關信息。

類似創建Node節點的虛機組。兩個虛機組創建完成后會在虛機組列表中顯示，如下圖：

第二步：新建虛機創建模版，分別用來Provision Master節點主機和Nodes節點主機

“虛機創建模板”是FIT2CLOUD內用來快速創建云主機的預定義模板。包括云賬號信息、云主機配置以及相關初始化操作。為快速Provision這里的Kubernetes集群，我們需要首先新建這些模板。為新建這些模板并實現自動部署Kubernetes集群，我們已經在FIT2CLOUD中內置了3個Kubernetes集群部署腳本（這些腳本在CentOS 7.0系統上測試通過，在本示例中無論是Master節點還是Salve節點都請選擇CentOS 7.0操作系統），分別如下：

k8s_master_installer.sh：用來部署Kubernetes Master節點。

k8s_node_installer.sh： 用來部署Kubernetes Node節點。

k8s_ui_installer.sh：用來激活安裝 kube-ui (Kubernetes webUI)。
這些腳本可以在FIT2CLOUD的腳本列表中查看到，如下圖：

首先，設置Master節點的“創建虛機模版”，如下圖：

在這其中有兩個點需要注意，具體如下：

第一點：如上圖可見，創建虛機模版時可以在初始化操作中執行腳本，這里選擇Kubernetes Master節點的安裝部署腳本k8s_master_installer.sh。如希望了解Master節點的部署流程，請倉庫該腳本內具體內容。

第二點：需要在Master節點的“創建虛機模板”內指定Master主機自動attach到負載均衡器上，從而將Kubernetes Master節點上的apiserver暴露給VPC外部，方便用戶從VPC外部通過公網IP控制Kubernetes集群。同時，集群上運行的真正負載Service也可以由此通過apiserver proxy供外部訪問。該設置如下圖所示：

其次，設置Node節點的“創建虛機模板”。和Master節點類似，設置Node節點的“創建虛機模板”時候需要指定初始化腳本為k8s_node_installer.sh，并同樣把啟動的Node節點放到和Master節點相同的QingCloud私有網絡。但是，Node節點不需要如同Master節點那樣掛載到負載均衡器上（因為Node節點在本示例不需要對外暴露端口，而是通過Master節點的apiserver proxy轉發的方式對外暴露服務）。k8s_node_installer.sh腳本中詳細描述了整個Node節點的部署流程，如下圖：

在Slave節點的部署腳本中需要注意如下兩點：

上圖第一處紅色標注中，腳本會調用f2cadm命令獲取集群Master節點的內網IP信息，以便配置Node節點的kubelet服務，使其加入集群。 其中，f2cadm是FIT2CLOUD提供的命令行工具，可在任何被FIT2CLOUD管理的機器上運行。該命令行工具可從FIT2CLOUD服務端獲取當前集群／虛機組／虛機的元數據信息。這里，f2cadm工具通過虛機組名稱"k8s-master"來獲取集群中Master節點的內網IP信息，這也是為什么前面創建Master節點虛機組名稱必須為"k8s-master"的原因。當然，理論上只需要保持腳本內和虛機組定名稱一致即可，不一定必須是"k8s-master"。

kubelet配置文件中，設定 KUBELET_ARGS="--pod-infra-container-image=repository.fit2cloud.com:5000/pause:latest"。如果不設置，國內用戶啟動 kubelet 服務會到Google服務器下載 pause 的image，這會導致網絡問題。

第三步：創建Kubernetes集群所需的虛機

完成上述配置之后，我們就可以回到控制臺虛機頁面，按順序啟動一臺KubernetesMaster 主機，等待其創建成功并執行初始化部署腳本完畢，再啟動2臺Nodes主機（以后如果需要擴展Node節點，只需要再啟動所需數量的Nodes主機即可）。如下圖，Kubernetes集群已經創建完畢：

至此，Kubernetes集群啟動完畢，并已經可以部署完成并正常工作。這里嘗試用kubectl命令行工具檢查下集群狀態。在本地運行該命令后，其結果會展示2個Node節點已經上線（Ready），具體如下。

?  ~ export KUBERNETES_MASTER=http://119.254.111.36:8080
?  ~ kubectl get nodes
NAME            LABELS                                 STATUS
192.168.100.3   kubernetes.io/hostname=192.168.100.3   Ready
192.168.100.5   kubernetes.io/hostname=192.168.100.5   Ready

由于是本地使用 kubectl 命令，需要設定下 KUBERNETES_MASTER 環境變量（apiserver endpoint地址），即為VPC出口公網IP的8080端口。

這時候我們就可以開始測試一些Kubernetes的基本功能，比如創建Replication Controllers，啟動nginx pods 并注冊一個名為nginxservice的Service做服務發現。

創建 replication controller

?  k8s cat ./nginx-rc.yaml
apiVersion: v1
kind: ReplicationController
metadata:
  name: nginx
spec:
  replicas: 3
  selector:
    app: nginx
  template:
    metadata:
      name: nginx
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: index.alauda.cn/library/nginx:latest
        ports:
        - containerPort: 80
?  k8s kubectl create -f nginx-rc.yaml
replicationcontrollers/nginx

檢查 pods 啟動狀態：

?  k8s kubectl get pods
NAME             READY     REASON    RESTARTS   AGE
nginx-5wjo3      1/1       Running   0          14m
nginx-a2nak      1/1       Running   0          14m
nginx-lb5rv      1/1       Running   0          14m

注冊名為nginxservice的Service：

?  k8s cat nginx-svc.yaml
apiVersion: v1
kind: Service
metadata:
  labels:
    name: nginxservice
  name: nginxservice
spec:
  ports:
    - port: 80
  selector:
    app: nginx
?  k8s kubectl create -f nginx-svc.yaml
services/nginxservice

創建好nginx pods和相應service后，我們可以通過apiserver proxy轉發集群內部的service， 這樣我們就可以通過 Master節點8080端口訪問集群Node節點上運行的nginx服務。

本示例為簡單起見，選擇了apiserver proxy來轉發集群內Node節點的服務。用戶還可以設置其他方式訪問Node節點上的服務。更多具體的Kubernetes的操作細節，可以參考 Kubernetes 官方文檔。

第四步：安裝Kubnetes WebUI

此外，FIT2CLOUD還內置了Kubernetes webUI addon的安裝腳本，只需要在Master節點上執行一下 kube_ui_installer.sh腳本就可以激活安裝 kube-ui。

等待腳本執行完畢，訪問VPC路由器上綁定的公網IP(端口為8080），即http://<公網_IP>:8080/ui，就能看到部署成功的Kubernetes WebUI。其上會展示該集群的基本信息、當前狀態等。

與前文所述，Kubernetes負責的是容器的創建、部署、監控和伸縮，FIT2CLOUD負責的是VM（虛機／云主機）的創建，部署，監控和伸縮。FIT2CLOUD默認系統監控可以對Kubernetes集群的CPU、內存、硬盤和網絡進行監控，也可以設定`自定義監控指標，對Docker或者Containers做應用級別的監控。例如，可以監控每臺KubernetesNode上的containers數量，方便以后基于Nodes節點的Containers數量來伸縮Nodes虛機。如下圖嘗試設置該自定義監控。

將其應用于Kubernetes Node虛機組（包括兩臺機器）上：

Kubernetes集群的Node節點已經應用了一個自定義監控指標，現在可以嘗試啟動50個nginx的容器，在Master節點執行如下命令

kubectl run my-nginx --image=nginx --replicas=50 --port=80

等待幾分鐘后就可以在監控面板上實時查看Kubernetes集群中每個Node上的container數量（如下圖所示）：

除此之外，也可以在通過這個自定義監控實現VM水平上的自動伸縮，下面馬上會介紹如何利用FIT2CLOUD自定義監控實現Kubernetes集群的自動伸縮。

我們知道，kubectl scale 命令可以用來伸縮容器數量，實現容器(應用)水平的伸縮，但是對于虛機水平的伸縮，Kubernetes自身無能為力，這就需要類似FIT2CLOUD這樣的管理平臺來幫忙實現。FIT2CLOUD所做的虛機水平自動伸縮，能保證Kubernetes集群中容器（應用）水平的伸縮能夠不受限于節點數量和每個節點的配額限制，保證容器（應用）的成功伸縮。

這里假設Kubernetes Nodes中的Pods/Containers的資源配額是40個，通過FIT2CLOUD設定自定義監控指標監控Nodes中的Containers數量。當超過80%資源配額（40*80%＝32個）后，自動創建一臺新的Kubernetes Nodes云主機，并自動部署后加入到集群之中；同理也可以設定當每臺Nodes中的Pods/Containers平均數量小于一定數值時，自動回收云主機，節約開支。通過如此設置就能夠保證當Kubernetes集群的負載達到資源配額上限前提前通過FIT2CLOUD擴容云主機并加入集群，保證上層容器擴容得以順利實施。當突發負載發生并觸發Node節點的資源配額上限時，同樣會觸發FIT2CLOUD自動伸縮機制并擴容云主機加入集群，然后由Kubernetes調度機制保證新加入云主機最終承擔相應的負載。下面示例將演示突發負載這一場景。

現在假定已經通過上述教程創建好了一個單Master節點，3個Node節點的Kubernetes集群。接下來演示如何利用FIT2CLOUD自動伸縮功能支持上層Kubernetes的彈性伸縮特性。

首先，在虛擬機組頁面，對Kubernetes Node節點，設定自動伸縮。

采用情景伸縮，針對我們上面所述自定義監控指標，當Node節點上的平均pod數量超過32個時擴容一臺Node云主機；當其中Node節點上的平臺pod數量最小值小于20臺時，縮容一臺Node云主機，由Kubernetes自行將這一臺上已有的pod在其他Node上重新啟動。具體設置如下：

其次，當自動伸縮設置完畢之后嘗試通過kubectl工具，把nginx pod總數擴展到150臺。

kubectl scale rc my-nginx --replicas=150

觀察自動伸縮情況，現在總共有3臺Node。當pod總數突然擴展到150臺時，由于Kubernetes的默認配額限制（每個節點pod數量不得超過40），現在每臺Node上最多運行40個pods，總共3*40=120個，無法滿足Kubernetes層擴容到150臺的要求，如圖：

當前總共有3臺Node

自定義監控每臺Node上實際的pod數量

但是，這時平均每臺Node上會運行40個pod，這會觸發40>32個pods的自動伸縮條件，FIT2CLOUD自動伸縮機制會擴容一臺Node主機，如圖所示：

系統已經擴展了一臺Node，新擴展的節點通過虛機模板創建啟動，自動會加入Kubernetes集群

新啟動的Node節點加入Kubernetes集群后，Kubernetes會自動把前面未成功scale的30個containers調度到該臺Node節點運行。在FIT2CLOUD中查看之前創建的自定義監控指標“podsNum”即可觀察到這一點。

Kubernetes代表著目前最先進的容器管理系統，但是它作為PaaS(容器云)與IaaS（或者Bare-Metal物理機）之間還需要FIT2CLOUD對其進行運維管理。FIT2CLOUD可以幫助類似Kubernetes這樣的PaaS(容器云)更好在云環境中使用。Kubernetes＋FITCLOUD＋QingCloud可以讓用戶非常快速穩定地從底至頂搭建一套容器管理系統。