使用FIT2CLOUD在青云QingCloud快速部署和管理Kubernetes集群
一、Kubernetes概述
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、青云QingCloud、FIT2CLOUD三者之間的關系
首先，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配置
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集群。
四、使用FIT2CLOUD部署和管理Kubernetes集群
4.1、創建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: 3selector:app: nginxtemplate:metadata:name: nginxlabels:app: nginxspec:containers:- name: nginximage: index.alauda.cn/library/nginx:latestports:- 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: nginxservicename: nginxservice spec:ports:- port: 80selector: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。其上會展示該集群的基本信息、當前狀態等。
4.2、Kubernetes集群監控
與前文所述，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集群的自動伸縮。
4.3、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臺。
觀察自動伸縮情況，現在總共有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可以讓用戶非?？焖俜€定地從底至頂搭建一套容器管理系統。
總結
以上是生活随笔為你收集整理的使用FIT2CLOUD在青云QingCloud快速部署和管理Kubernetes集群的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： HeartBeat 集群组件概述
- 下一篇： 小游戏Item表