帶你玩轉kubernetes-k8s（第64篇-Kubernetes之使用Web UI Dashboard 管理集羣，Helm應用包管理工具）

Kubernetes的Web UI網頁管理工具kubernetes-dashboard可提供部署應用、資源對象管理、容器日誌查詢、系統監控等常用的集羣管理功能。爲了在頁面上顯示系統資源的使用情況，要求部署Metrics Server

可通過https://rawgit.com/kubernetes/dashboard/ master/src/deploy/kubernetes-dashboard.yaml頁面下載部署kubernetes-dashboard的YAML配置文件。該配置文件的內容如下，其中包含Deployment和Service的定義：

---
kind: Deployment
apiVersion: extensions/v1beta1
metadata:
  labels:
    app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: kubernetes-dashboard
  template:
    metadata:
      labels:
        app: kubernetes-dashboard
      annotations:
        scheduler.alpha.kubernetes.io/tolerations: |
          [
            {
              "key": "dedicated",
              "operator": "Equal",
              "value": "master",
              "effect": "NoSchedule"
            }
          ]
    spec:
      containers:
      - name: kubernetes-dashboard
        image: gcr.io/google_containers/kubernetes-dashboard-amd64:v1.6.0
        imagePullPolicy: Always
        ports:
        - containerPort: 9090
          protocol: TCP
        args:
        livenessProbe:
          httpGet:
            path: /
            port: 9090
          initialDelaySeconds: 30
          timeoutSeconds: 30

---
kind: Service
apiVersion: v1
metadata:
  labels:
    app: kubernetes-dashboard
  name: kubernetes-dashboard
  namespace: kube-system
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 9090
    nodePort: 9090
  selector:
    app: kubernetes-dashboard

詳細部署過程可以參考第2篇。

Helm: Kubernetes應用包管理工具

隨着容器技術逐漸被企業接受，在Kubernetes上已經能便捷地部署簡單的應用了。但對於複雜的應用中間件，在Kubernetes上進行容器化部署並非易事，通常需要先研究Docker鏡像的運行需求、環境變量等內容，並能爲這些容器定製存儲、網絡等設置，最後設計和編寫Deployment、ConfigMap、Service及Ingress等相關YAML配置文件，再提交給Kubernetes部署。這些複雜的過程將逐步被Helm應用包管理工具實現。

Helm概述

Helm是一個由CNCF孵化和管理的項目，用於對需要在Kubernetes上部署的複雜應用進行定義、安裝和更新。Helm以Chart的方式對應用軟件進行描述，可以方便地創建、版本化、共享和發佈複雜的應用軟件。

Helm的主要概念

Helm的主要概念如下。
◎　Chart：一個Helm包，其中包含運行一個應用所需要的工具和資源定義，還可能包含Kubernetes集羣中的服務定義，類似於Homebrew中的formula、APT中的dpkg或者Yum中的RPM文件。
◎　Release：在Kubernetes集羣上運行的一個Chart實例。在同一個集羣上，一個Chart可以被安裝多次。例如有一個MySQL Chart，如果想在服務器上運行兩個MySQL數據庫，就可以基於這個Chart安裝兩次。每次安裝都會生成新的Release，會有獨立的Release名稱。
◎　Repository：用於存放和共享Chart倉庫。
      簡單來說，Helm整個系統的主要任務就是，在倉庫中查找需要的Chart，然後將Chart以Release的形式安裝到Kubernetes集羣中。

安裝Helm

Helm由HelmClient和TillerServer兩個組件組成，下面講解這兩個組件。

HelmClient

HelmClient是一個客戶端，擁有對Repository、Chart、Release等對象的管理能力，可以通過二進制文件或腳本進行安裝。
通過二進制文件安裝時，從https://github.com/kubernetes/helm/releases下載二進制文件，將其解壓並複製到執行目錄即可。
通過腳本安裝的代碼如下：

# curl https://raw.githubusercontent.com/kubernetes/helm/master/scripts/get > get_helm.sh

# chmod 700 get_helm.sh
# ./get_helm.sh

TilerServer

TillerServer負責客戶端指令和Kubernetes集羣之間的交互，根據Chart定義，生成和管理各種Kubernetes的資源對象。

對TillerServer的安裝可以使用helm init命令進行（官方推薦），這一命令會在kubectl當前context指定集羣內的kube-system命名空間創建一個Deployment和一個Service，運行TillerServer服務。

在Deployment中使用的鏡像是gcr.io/kubernetes-helm/tiller:v[helm-version]，可以通過helm version命令獲得其Helm版本。如果無法連接互聯網獲取該鏡像，則可以先通過一臺能夠聯網的服務器下載這個鏡像並保存到鏡像私庫，利用helm init子命令的--tiller-image參數來指定私庫中的鏡像執行初始化過程。

安裝結束之後，用helm version命令驗證安裝情況，一切正常的話，會分別顯示Tiller和Helm的版本信息。一個常見的問題是，Tiller部分顯示一個錯誤信息“uid:unable to do port forwarding: socat not found”，這是因爲所在節點沒有socat，無法進行端口轉發，這時在主機上安裝socat軟件即可。

對TillerServer的安裝還可以在本地進行，在服務器本地直接運行Tiller，這種安裝方式需要讓Helm指定要連接的服務地址，有以下兩種方法。

◎　使用--host指定Tiller運行的監聽地址。
◎　設置HELM_HOST環境變量。
需要注意的是，Tiller仍會使用kubectl配置中的context連接Kubernetes集羣。

Helm的常見用法

下面介紹Helm的常見用法，包括搜索Chart、安裝Chart、自定義Chart配置、更新或回滾Release、刪除Release、創建自定義Chart、搭建私有倉庫等。

1.helm search：搜索可用的Chart
       Helm在初始化完成之後，默認配置爲使用官方的Kubernetes Chart倉庫。官方倉庫包含大量的經過組織和持續維護的Chart，這個倉庫通常被命名爲stable。

在沒有過濾的情況下，通過helm search命令會顯示所有可用的Chart，可以使用參數進行過濾：

爲什麼在列表中會有MariaDB？因爲在MariaDB的描述信息中包含了mysql關鍵字。可以通過helm inspect <chart_name>命令查看Chart的詳細信息：

在找到需要安裝的Chart之後，就可以進行安裝了。

2.helm install：安裝Chart

使用helm install命令安裝應用，最簡單的參數是Chart的名稱。以MariaDB爲例：

至此，MariaDB就安裝完成了。可以看到系統創建了一個新的名爲falling-lightningbug的Release對象，可以在helm install命令中使用--name參數修改其名稱。

在安裝過程中，Helm客戶端會輸出一些有用的信息，例如Release的狀態及額外的配置步驟等。
        Helm不會等待所有創建過程的完成，這是因爲有些Chart的Docker鏡像較大，會消耗很長的時間進行下載和創建。
        在helm install命令的執行過程中，可以使用helm status命令跟蹤Release的狀態：

在成功安裝Chart後，系統會在kube-system命名空間內創建一個ConfigMap用於保存Release對象的數據：

3.自定義Chart的配置

前面介紹的安裝過程使用的是Chart的默認配置。然而在很多情況下，我們希望使用自定義的配置部署應用。
       首先，通過helm inspect命令查看Chart的可配置內容：

用戶可以編寫一個YAML配置文件來覆蓋上面這些設置，然後利用這一文件來給安裝過程提供配置。例如，我們可以自定義額外的兩個配置文件config.yaml和config2.yaml，用於在執行helm install命令安裝MariaDB之後，在MariaDB啓動時自動創建名爲firstdb和seconddb的數據庫，並且設置root用戶的密碼：

在安裝完成之後，可以登錄MariaDB Pod查看數據庫是否創建成功。
自定義Chart的配置有兩種方法。
◎　--values或者-f：使用YAML配置文件進行參數配置，可以設置多個文件，最後一個優先生效。多個文件中的重複value會進行覆蓋操作，不同的value會疊加生效。上面的例子使用的就是這種方式。
◎　--set：在命令行中直接設置參數。
如果同時使用兩個參數，則--set會以高優先級合併到--values中。

--set的格式和限制

--set參數可以使用0個或多個名稱/值的組合，最簡單的方式是--set name=value，YAML配置文件中的等效描述是：

name: value

多個值可以使用逗號進行分隔，例如--set a=b,c=d的YAML配置等效於下面的描述：

a: b
c: d

還可以用來表達多層結構的變量--set outer.inner=value：

outher:
  inner: value

大括號（{}）可以用來表達列表數據，例如--set name={a,b,c}會被翻譯成：

name:
  - a
  - b
  - c

有時需要在--set時使用一些特殊字符，這裏可以使用斜線進行轉義，比如--set name=value1\,value2。類似地，可以對點符號“.”進行轉義，這樣Chart使用toYaml函數解析註解、標籤或者node selector時就很方便了，例如：--set nodeSelector."kubernetes\.io/role"=master。

儘管如此，--set語法的表達能力依然無法和YAML語言相提並論，尤其是在處理集合時。目前沒有方法能夠實現“把列表中第3個元素設置爲XXX”這樣的語法。

更多的安裝方法

使用helm install命令時，可以通過多種安裝源進行安裝。
◎　上面用到的Chart倉庫。
◎　本地的Chart壓縮包（helm install foo-0.1.1.tgz）。
◎　一個Chart目錄（helm install path/to/foo）。
◎　一個完整的URL（helm install https://example.com/charts/foo-1.2.3.tgz）。

helm upgrade和helm rollback：應用的更新或回滾

當一個Chart發佈新版本或者需要修改一個Release的配置時，就需要使用helm upgrade命令了。

helm upgrade命令會利用用戶提供的更新信息來對Release進行更新。因爲Kubernetes Chart可能會有很大的規模或者相對複雜的關係，所以Helm會嘗試進行最小影響範圍的更新，只更新相對於上一個Release來說發生變化的內容。

例如，我們要更新一個Release的資源限制，則可以創建config3.yaml配置文件，內容如下：

resources:
  requests:
    memory: 256Mi
    cpu: 500m

使用upgrade命令完成更新：

helm upgrade -f cibfug.yaml nomadic-terrier stable/mariadb

看到更新提示之後，我們可以用Helm的list指令查看Release的信息，會發現revision一列發生了變化。接下來通過kubectl的get pods，deploy指令可以看到Pod已經更新；通過kubectl describe deploy指令還會看到Deployment的更新過程和一系列的ScalingReplicaSet事件。

如果對更新後的Release不滿意，則可以使用helm rollback命令對Release進行回滾，例如：

helm rollback nomadic-terrier 2

這個命令將把名爲nomadic-terrier的Release回滾到版本2。
在執行命令之後，同樣可以使用前面提到的幾個查詢指令，會看到類似的結果。
最後，可以使用helm history <release_name>命令查看一個Release的變更歷史。

helm install/upgrade/rollback命令的常用參數

Helm 有很多參數可以幫助用戶指導命令的行爲。本節介紹一些常用參數，用戶可以使用helm <command> help命令獲取所有參數的列表。

◎　--timeout：等待Kubernetes命令完成的時間，單位是s，默認值爲300，也就是5min。
◎　--wait：等待Pod，直到其狀態變爲ready，PVC才完成綁定。Deployment完成其最低就緒要求的Pod創建，並且服務有了IP地址，才認爲Release創建成功。這一等待過程會一直持續到超過--timeout，超時後這一Release被標記爲FAILED（注意：當Deployment的replicas被設置爲1，同時滾動更新策略的maxUnavailable不爲0時，--wait纔會因爲最小就緒Pod數量達成而返回ready狀態）。
◎　--no-hooks：該命令會跳過Hook執行。
◎　--recreate-pods：會引起所有Pod的重建（Deployment所屬的Pod除外）。

helm delete: 刪除一個Release

通過helm delete命令可以刪除一個Release，例如通過helm delete happy-panda命令可以從集羣中刪除名爲happy-panda的Release。

可以通過helm list命令列出在集羣中部署的Release。如果給list加上--deleted參數，則會列出所有刪除的Release；--all參數會列出所有的Release，包含刪除的、現存的及失敗的Release。

正因爲Helm會保存所有被刪除Release的信息，所以Release的名字是不可複用的（如果堅持複用，則可以使用--replace參數，這一操作不建議在生產環境中使用），這樣被刪除的Release也可以被回滾，甚至重新激活。

helm repo： 倉庫的使用

我們在前面使用的Chart來自stable倉庫。我們也可以對Helm進行配置，讓其使用其他倉庫。Helm在helm repo命令中提供了很多倉庫相關的工具。

◎　helm repo list：列出所有倉庫。
◎　helm repo add：添加倉庫，例如從repo_url中添加名爲dev的倉庫helm repo add dev http://<repo_url>/dev-charts。
◎　helm repo update：更新倉庫中的Chart信息。

自定義Chart

用戶可以將自己的應用定義爲Chart並進行打包部署，本節對其進行簡單介紹，詳細的開發指南參見https://docs.helm.sh/developing-charts。

自定義Chart時需要使用符合Helm規範的一組目錄和配置文件來完成。

對Chart目錄結構和配置文件的說明

Chart是一個包含一系列文件的目錄。目錄的名稱就是Chart的名稱（不包含版本信息），例如一個WordPress的Chart就被會存儲在wordpress目錄下。
該目錄的文件結構如下：

charts/子目錄和requirements.yaml的區別在於，前者需要提供整個Chart文件，後者僅需要註明依賴Chart的倉庫信息，例如一個requirements.yaml可以被定義爲：

dependencies:
  - name: apache
    version: 1.2.3
    repository: http://example.com/charts
  - name: mysql
    version: 3.2.1
    repository: http://another.example.com/charts

對Chart.yaml文件的說明

Chart.yaml文件（注意首字母大寫）是個必要文件，包含如下內容。
◎　name：Chart的名稱，必選。
◎　version：SemVer 2規範的版本號，必選。
◎　description：項目的描述，可選。
◎　keywords：一個用於描述項目的關鍵字列表，可選。
◎　home：項目的主頁，可選。
◎　sources：一個URL列表，說明項目的源代碼位置，可選。
◎　maintainers：維護者列表，可選。
◎　name：管理員的名字，必選。
◎　email：管理員的郵件，必選。
◎　engine：模板引擎的名稱，默認是gotpl，可選。
◎　icon：一個指向svg或png圖像的URL，作爲Chart的圖標，可選。
◎　appVersion：在Chart中包含的應用的版本，無須遵循SemVer規範，可選。
◎　deprecated：布爾值，該Chart是否標註爲“棄用”，可選。
◎　tillerVersion：可選，該Chart所需的Tiller版本。取值應該是一個SemVer的範圍，例如“>2.0.0”。

快速製作自定義的Chart

同其他軟件開發過程一樣，快速製作一個簡單Chart的方法，就是從其他項目中複製並修改。例如，我們要簡單地改寫前面MariaDB的Chart，令其使用本地的私有鏡像倉庫，就可以按照如下步驟進行。
◎　下載Chart：使用helm fetch stable/mariadb命令下載這一Chart的壓縮包。
◎　編輯Chart。
◎　利用tar解壓之後，我們將目錄重新命名爲mymariadb。
◎　修改templates中的deployment.yaml，簡單地將其中的image字段硬編碼爲需要的鏡像（當然不推薦這種用法，可以繼續以變量的方式在values中進行設置）。
◎　將Chart.yaml中的版本號修改爲0.1.1，name爲mymariadb。

◎　使用helm package mymariadb打包Chart，會生成一個名爲mymariadb-0.1.1.tgz的壓縮包。
◎　安裝Chart：通過helm install mymariadb-0.1.1.tgz命令即可將我們“新”生成的Chart安裝到集羣中。

搭建是有Repository

在自建Chart之後自然需要搭建私有倉庫。下面使用Apache搭建一個簡單的Chart私有倉庫，並將剛纔新建的mymariadb Chart保存到私有倉庫中，詳情可參考https://docs.helm.sh/ developing-charts/#chart-repo-guide。

Chart倉庫主要由前面提到的Chart壓縮包和索引文件構成，通過HTTP/HTTPS對外提供服務。這裏使用一個Apache應用來提供倉庫服務。Apache的設置如下。

◎　Apache使用/var/web/repo目錄進行倉庫的存儲。
◎　使用http://127.0.0.1/repo網址提供訪問服務。

將前面生成的mymariadb-0.1.1.tgz文件複製到倉庫的/var/web/repo目錄下。

接下來使用helm repo index /var/web/repo --url http://127.0.0.1/repo命令，Helm將自動根據目錄下的內容創建索引。在命令執行完畢後，可以看到在目錄下多出一個index.yaml文件。

最後啓動Web Server。
爲了能夠使用這個私有倉庫，需要將這個新的倉庫地址加入Helm配置中：

helm repo add localhost http://ip/repo

再次運行helm search mysql命令，會看到在Chart列表中多出localhost/mymariadb項目，也就是我們的新倉庫中的Chart。
現在可以通過helm install localhost/mymariadb命令安裝私有倉庫中的Chart了。

 

小結：

         到這裏我們k8s裏面涉及到的大部分概念，以及一些組件都講解完了。

         相信大家看到這裏，對k8的一些概念也比較清楚了，接下來我們會深入，甚至重複的來講解這些內容。

         感謝大家這段時間的支持！