Kubernetes初探：原理及實踐應(yīng)用

[日期：2014-11-03]

來源：CSDN?作者：張俊

[字體：大 中 小]

　　總體概覽

　　如下圖所示是我初步閱讀文檔和源代碼之后整理的總體概覽，基本上可以從如下三個維度來認識Kubernetes。

　　

?

　　操作對象

　　Kubernetes以RESTFul形式開放接口，用戶可操作的REST對象有三個：

　　pod：是Kubernetes最基本的部署調(diào)度單元，可以包含container，邏輯上表示某種應(yīng)用的一個實例。比如一個web站點應(yīng)用由前端、后端及數(shù)據(jù)庫構(gòu)建而成，這三個組件將運行在各自的容器中，那么我們可以創(chuàng)建包含三個container的pod。

　　service：是pod的路由代理抽象，用于解決pod之間的服務(wù)發(fā)現(xiàn)問題。因為pod的運行狀態(tài)可動態(tài)變化(比如切換機器了、縮容過程中被終止了等)，所以訪問端不能以寫死IP的方式去訪問該pod提供的服務(wù)。service的引入旨在保證pod的動態(tài)變化對訪問端透明，訪問端只需要知道service的地址，由service來提供代理。

　　replicationController：是pod的復(fù)制抽象，用于解決pod的擴容縮容問題。通常，分布式應(yīng)用為了性能或高可用性的考慮，需要復(fù)制多份資源，并且根據(jù)負載情況動態(tài)伸縮。通過replicationController，我們可以指定一個應(yīng)用需要幾份復(fù)制，Kubernetes將為每份復(fù)制創(chuàng)建一個pod，并且保證實際運行pod數(shù)量總是與該復(fù)制數(shù)量相等(例如，當(dāng)前某個pod宕機時，自動創(chuàng)建新的pod來替換)。

　　可以看到，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)的。如下圖所示，有三個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。

　　

?

　　功能組件

　　如下圖所示是官方文檔里的集群架構(gòu)圖，一個典型的master/slave模型。

　　

?

　　master運行三個組件：

　　apiserver：作為kubernetes系統(tǒng)的入口，封裝了核心對象的增刪改查操作，以RESTFul接口方式提供給外部客戶和內(nèi)部組件調(diào)用。它維護的REST對象將持久化到etcd(一個分布式強一致性的key/value存儲)。

　　scheduler：負責(zé)集群的資源調(diào)度，為新建的pod分配機器。這部分工作分出來變成一個組件，意味著可以很方便地替換成其他的調(diào)度器。

　　controller-manager：負責(zé)執(zhí)行各種控制器，目前有兩類：

　　endpoint-controller：定期關(guān)聯(lián)service和pod(關(guān)聯(lián)信息由endpoint對象維護)，保證service到pod的映射總是最新的。

　　replication-controller：定期關(guān)聯(lián)replicationController和pod，保證replicationController定義的復(fù)制數(shù)量與實際運行pod的數(shù)量總是一致的。

　　slave(稱作minion)運行兩個組件：

　　kubelet：負責(zé)管控docker容器，如啟動/停止、監(jiān)控運行狀態(tài)等。它會定期從etcd獲取分配到本機的pod，并根據(jù)pod信息啟動或停止相應(yīng)的容器。同時，它也會接收apiserver的HTTP請求，匯報pod的運行狀態(tài)。

　　proxy：負責(zé)為pod提供代理。它會定期從etcd獲取所有的service，并根據(jù)service信息創(chuàng)建代理。當(dāng)某個客戶pod要訪問其他pod時，訪問請求會經(jīng)過本機proxy做轉(zhuǎn)發(fā)。

　　工作流

　　上文已經(jīng)提到了Kubernetes中最基本的三個操作對象：pod, replicationController及service。 下面分別從它們的對象創(chuàng)建出發(fā)，通過時序圖來描述Kubernetes各個組件之間的交互及其工作流。

　　

?

　　使用示例

　　最后，讓我們進入實戰(zhàn)模式，這里跑一個最簡單的單機示例(所有組件運行在一臺機器上)，旨在打通基本流程。

　　搭建環(huán)境

　　第一步，我們需要Kuberntes各組件的二進制可執(zhí)行文件。有以下兩種方式獲取：

　　下載源代碼自己編譯：

　　git clone https://github.com/GoogleCloudPlatform/kubernetes.git cd kubernetes/build ./release.sh

　　直接下載人家已經(jīng)編譯打包好的tar文件：

　　wget https://storage.googleapis.com/kubernetes/binaries.tar.gz

　　自己編譯源碼需要先安裝好golang，編譯完之后在kubernetes/_output/release-tars文件夾下可以得到打包文件。直接下載的方式不需要安裝其他軟件，但可能得不到最新的版本。

　　第二步，我們還需要etcd的二進制可執(zhí)行文件，通過如下方式獲取：

　　wget https://github.com/coreos/etcd/releases/download/v0.4.6/etcd-v0.4.6-linux-amd64.tar.gz tar xvf etcd-v0.4.6-linux-amd64.tar.gz

　　第三步，就可以啟動各個組件了：

　　etcd

　　cd etcd-v0.4.6-linux-amd64 ./etcd

　　apiserver

　　./apiserver \ -address=127.0.0.1 \ -port=8080 \ -portal_net="172.0.0.0/16" \ -etcd_servers=http://127.0.0.1:4001 \ -machines=127.0.0.1 \ -v=3 \ -logtostderr=false \ -log_dir=./log

　　scheduler

　　./scheduler -master 127.0.0.1:8080 \ -v=3 \ -logtostderr=false \ -log_dir=./log

　　controller-manager

　　./controller-manager -master 127.0.0.1:8080 \ -v=3 \ -logtostderr=false \ -log_dir=./log

　　kubelet

　　./kubelet \ -address=127.0.0.1 \ -port=10250 \ -hostname_override=127.0.0.1 \ -etcd_servers=http://127.0.0.1:4001 \ -v=3 \ -logtostderr=false \ -log_dir=./log

　　創(chuàng)建pod

　　搭好了運行環(huán)境后，就可以提交pod了。首先編寫pod描述文件，保存為redis.json：

　　{ "id": "redis", "desiredState": { "manifest": { "version": "v1beta1", "id": "redis", "containers": [{ "name": "redis", "image": "dockerfile/redis", "imagePullPolicy": "PullIfNotPresent", "ports": [{ "containerPort": 6379, "hostPort": 6379 }] }] } }, "labels": { "name": "redis" } }

　　然后，通過命令行工具kubecfg提交：

　　./kubecfg -c redis.json create /pods

　　提交完后，通過kubecfg查看pod狀態(tài)：

　　# ./kubecfg list /pods ID Image(s) Host Labels Status ---------- ---------- ---------- ---------- ---------- redis dockerfile/redis 127.0.0.1/ name=redis Running

　　Status是Running表示pod已經(jīng)在容器里運行起來了，可以用"docker ps"命令來查看容器信息：

　　# docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES ae83d1e4b1ec dockerfile/redis:latest "redis-server /etc/r 19 seconds ago Up 19 seconds k8s_redis.caa18858_redis.default.etcd_1414684622_1b43fe35

　　創(chuàng)建replicationController

　　{ "id": "redisController", "apiVersion": "v1beta1", "kind": "ReplicationController", "desiredState": { "replicas": 1, "replicaSelector": {"name": "redis"}, "podTemplate": { "desiredState": { "manifest": { "version": "v1beta1", "id": "redisController", "containers": [{ "name": "redis", "image": "dockerfile/redis", "imagePullPolicy": "PullIfNotPresent", "ports": [{ "containerPort": 6379, "hostPort": 6379 }] }] } }, "labels": {"name": "redis"} }}, "labels": {"name": "redis"} }

　　然后，通過命令行工具kubecfg提交：

　　./kubecfg -c redisController.json create /replicationControllers

　　提交完后，通過kubecfg查看replicationController狀態(tài)：

　　# ./kubecfg list /replicationControllers ID Image(s) Selector Replicas ---------- ---------- ---------- ---------- redisController dockerfile/redis name=redis 1

　　同時，1個pod也將被自動創(chuàng)建出來，即使我們故意刪除該pod，replicationController也將保證創(chuàng)建1個新pod。

總結(jié)

以上是生活随笔為你收集整理的Kubernetes初探：原理及实践应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。