Kubernetes – Google分散式容器技術初體驗

Kubernetes是Google開源的容器叢集管理系統。前幾天寫的 分散式服務框架的4項特性 中提到一個良好的分散式服務框架需要實現

服務的配置管理。包括服務發現、負載均衡及服務依賴管理。
服務之間的排程及生命週期管理。

由於Kubernetes包含了上述部分特性，加上最近Google新推出的Container Engine也是基於Kubernetes基礎上實現，因此最近對Kubernetes進行了一些嘗試與體驗。

執行環境

Kubernetes目前處於一個快速迭代的階段，同時它的相關生態圈（比如docker，etcd）也在快速發展，這也意味沒有適合新手使用非常順暢的版本，網上的各種文件（也包括官方文件）和當前最新的釋出版會有不同程度滯後或不適用的情況，因此在使用時可能會碰到各種細節的障礙，而且這些新版本碰到的問題，很有可能在網上也搜尋不到解決方案。

Kubernetes設計上並未繫結Google Cloud平臺，但由於以上原因，為了減少不必要的障礙，初次嘗試建議使用GCE作為執行環境（儘管GCE是一個需要收費的環境）。預設的cluster啟動指令碼會建立5個GCE instance，測試完需要自己及時主動刪除。為了避免浪費，可以將minions減少，同時instance型別選擇f1-micro。費用方面一個f1-micro instance執行1個月大約50元人民幣，因此用GCE來測試Kubernetes，如果僅是測試時候開啟的話，並不會產生太多費用。

Pods及Replication Controller

Kubernetes的基本單元是pods，用來定義一組相關的container。Kubernetes的優點是可以透過定義一個replicationController來將同一個模組部署到任意多個容器中，並且由Kubernetes自動管理。比如定義了一個apache pod，透過replicationController設定啟動100個replicas，系統就會在pod建立後自動在所有可用的minions中啟動100個apache container。並且輕鬆的是，當container或者是所在的伺服器不可用時，Kubernetes會自動透過啟動新的container來保持100個總數不變，這樣管理一個大型系統變得輕鬆和簡單。

Service 微服務

在解決部署問題之後，分散式服務中存在的一大難題是服務發現（或者叫定址），使用者訪問的前端模組需要訪問系統內部的後端資源或者其他各種內部的服務，當一個內部服務透過replicationController動態部署到不同的節點後，而且還存在前文提到的動態切換的功能，前端應用如何來發現並訪問這些服務？Kubernetes的另外一個亮點功能就是service，service是一個pod服務池的代理抽象，目前的實現方法是透過一個固定的虛擬IP及埠來定義，並且透過分佈在所有節點上的proxy來實現內部服務對service的訪問。

Kubernetes自身的配置是儲存在一個etcd（類似ZooKeeper）的分散式配置服務中。服務發現為什麼不透過etcd來實現？Tim的判斷更多的是為了Kubernetes上的系統和具體的配置服務解耦。由於服務發現屬於各個系統內部的業務邏輯，因此如果使用etcd將會出現業務程式碼的邏輯中耦合了etcd，這樣可能會讓很多架構師望而卻步。

儘管沒有耦合etcd，部署在Kubernetes中的服務需要透過container中的環境變數來獲得service的地址。環境變數雖然簡單，但它也存在很多弊端，如存在不方便動態更改等問題。另外service目前的實現是將虛擬IP透過iptables重定向到最終的pod上，作者也提到iptables定向的侷限性，不適合作為大型服務的實現。

小結

總的看來Kubernetes提供的能力非常令人激動，pod、replicationController以及service的設計非常簡單實用。但如果立即將服務遷移到Kubernetes，還需要面對易變的環境。另外一方面儘管Kubernetes提供health check的機制，但service生產環境所需的苛刻的可用性還未得到充分的驗證。

安裝說明

Kubernetes cluster簡單安裝說明如下，需要嘗試的朋友可參考。

前提準備

一個64bit linux環境，最好在牆外的，避免訪問google cloud出現超時或reset等問題；另外建立Google Cloud帳號，確保建立instances以及Cloud Storage功能可用；

安裝步驟

1. 安裝go語言環境（可選，如果需要編譯程式碼則需要）

2. 安裝Google cloud sdk

$ curl https://sdk.cloud.google.com | bash
$ gcloud auth login

按提示完成授權及登入

3. 安裝 etcd 二進位制版本(V0.4.6), 解壓後將其目錄加入PATH

4. 安裝 kubernetes最新的relase binary版本（V0.5.1）

修改 cluster/gce/config-default.sh，主要是修改以下欄位以便節約資源。

MASTER_SIZE=f1-micro
MINION_SIZE=f1-micro
NUM_MINIONS=3

在kubernetes目錄執行

$ cluster/kube-up.sh

執行成功後會顯示 done

5. 測試pod

以上指令碼啟動了examples/monitoring 下面定義的service，如果嘗試啟動其它自己的pods，比如啟動一個tomcat叢集

{
  "id": "tomcatController",
  "kind": "ReplicationController",
  "apiVersion": "v1beta1",
  "desiredState": {
    "replicas": 2,
    "replicaSelector":{"name": "tomcatCluster"},
    "podTemplate":{
  "desiredState": {
    "manifest": {
      "version": "v1beta1",
      "id": "tomcat",
      "containers": [{
        "name": "tomcat",
        "image": "tutum/tomcat",
     "ports": [
     {"containerPort":8080,"hostPort":80}
     ]
     }]
    }
  },
  "labels": {"name": "tomcatCluster"}}
  },
  "labels": {
    "name": "tomcatCluster",
  }
}

其中pod的tomcat image可以透過Docker Hub Registry https://registry.hub.docker.com/ 搜尋及獲取

$ cluster/kubectl.sh create -f tomcat-pod.json

建立成功後透過 cluster/kubectl.sh get pods 來檢視它所在minion及ip，可以透過curl或瀏覽器來訪問（請開啟GCE防火牆埠設定）。

再定義一個 service

{
  "id": "tomcat",
  "kind": "Service",
  "apiVersion": "v1beta1",
  "port": 8080,
  "containerPort": 8080,
  "labels": {
    "name": "tomcatCluster"
  },
  "selector": {
    "name": "tomcatCluster"
  }
}

儲存為 tomcat-service.json

$ cluster/kubectl.sh create -f tomcat-service.json

檢查service啟動後的ip及埠，由於service是內部ip，可以在GCE上透過curl來測試及驗證。

$ cluster/kubectl.sh get services

6. 關閉cluster

cluster/kube-down.sh