Kubernetes學習之路（三十）Helm程序包管理器

_____egon新書來襲請看：https://egonlin.com/book.html

一 Helm介紹

1、什么是helm？

helm是k8s的另外一個項目,相當於linux的yum

在yum的倉庫中,yum不光要解決包之間的依賴關系,還要提供具體的程序包

而在helm的倉庫里面只有配置清單文件,而沒有鏡像,鏡像還是由鏡像倉庫來提供,比如hub.docker.com、私有倉庫.

2、為何要用helm

舉個例子，我們需要部署一個MySQL服務，Kubernetes則需要部署以下對象：

① 為了能夠讓外界訪問到MySQL，需要部署一個mysql的service；

②需要進行定義MySQL的密碼，則需要部署一個Secret；

③Mysql的運行需要持久化的數據存儲，此時還需要部署PVC；

④保證后端mysql的運行，還需要部署一個Deployment，以支持以上的對象。

針對以上對象，我們可以使用YAML文件進行定義並部署，但是僅僅對於單個的服務支持，如果應用需要由一個甚至幾十個這樣的服務組成，並且還需要考慮各種服務的依賴問題，可想而知，這樣的組織管理應用的方式就顯得繁瑣。為此就誕生了一個工具Helm，就是為了解決Kubernetes這種應用部署繁重的現象。

3、helm核心概念

• 1、Chart：---》類似與yum的軟件包
• 比如對於一個nginx,我們需要一個deployment的清單文件、一個service的清單文件、一個hpa的清單文件,把這三個文件打包到一起,就是一個應用程序的程序包,稱之為Chart，或稱helm的程序包，其實質只是一個模板,我們可以對這個模板進行賦值(value),形成我們自定義的清單文件,也就實現我們生產個性化的需求
• 2、Repository：存放Chart的倉庫，用於集中存儲和分發Chart；

 

• 3、Config：應用程序實例化安裝運行時所需要的配置信息；
• 4、Release：特定的Chart部署於目標集群上的一個實例，代表這一個正在運行的應用。當chart被安裝到Kubernetes集群，就會生成一個release，chart可以多次安裝到同一個集群，每次安裝都是一個release。

4、helm程序架構與工作流程

 

Helm主要由Helm客戶端、Tiller服務器和Charts倉庫組成，如下圖：

 

1、在客戶端（helm工具，Chart倉庫）

Helm把Kubernetes資源打包到一個chart中，而chart被保存到chart倉庫中,通過chart倉庫可用來存儲和分享chart。

helm工作在k8s集群之外，helm管理的Chart倉庫存放於本地，helm不直接操作apiserver,而是和Tiller交互，用於發送Chart，實例安裝、查詢、卸載等操作。

2、服務端（Tlller）

通常運行在K8S集群之上。用於接收helm發來的Charts和Conifg，合並生成release，完成部署。

ps

19年發布的helm 3 的一個很大變化就是移除了heml2中非常重要的組成部分Tiller，即helm3只需要當前用戶家目錄下有admin.conf就可以與k8s集群通信了，第三小節部署Tiller這一步就不需要了

在helm2中Tiller是helm的一個重要組成部分。它可以在一個共享的集群中管理復雜的應用發布。 從kubernetes 1.6開始默認開啟RBAC。這是Kubernetes安全性/企業可用的一個重要特性。但是在RBAC開啟的情況下管理及配置Tiller變的非常復雜。為了簡化helm的嘗試成本我們給出了一個不需要關注安全規則的默認配置。但是，這會導致一些用戶意外獲得了他們並不需要的權限。並且，管理員/SRE需要學習很多額外的知識才能將Tiller部署的到關注安全的生產環境的多租戶K8S集群中並使其正常工作。 在了解了社區成員通常的使用場景后，我們發現Tiller的發布管理系統不需要依靠集群內的Operator來維護狀態或充當Helm發布信息的中央樞紐。相反，我們可以簡單地從Kubernetes API服務器中獲取信息，渲染Charts客戶端，並在Kubernetes中存儲安裝記錄。 沒有Tiller也能實現所有的功能，所以我們針對Helm 3做出的第一個決定就是徹底刪除Tiller。 移除掉Tiller大大簡化了hlem的安全模型實現方式。Helm3現在可以支持所有的kubernetes認證及鑒權等全部安全特性。Helm和本地的kubeconfig flie中的配置使用一致的權限。管理員可以按照自己認為合適的粒度來管理用戶權限。

 

 

二 部署Helm

Helm的部署方式有兩種：預編譯的二進制程序和源碼編譯安裝，這里使用二進制的方式進行安裝

# 官方部署文檔：https://helm.sh/docs/intro/install/
curl -O https://get.helm.sh/helm-v3.7.1-linux-amd64.tar.gz
tar -zxvf helm-v3.0.0-linux-amd64.tar.gz
mv linux-amd64/helm /usr/local/bin/helm

三 部署Tiller

helm第一次init時，需要鏈接api-server並進行認證，所以在運行helm時，會去讀取kube-config文件，所以必須確認當前用戶存在kube-config文件。

Tiller運行在K8s集群之上，也必須擁有集群的管理權限，也就是需要一個serviceaccount，進行一個clusterrolebinding到cluster-admin。

Tiller的RBAC配置示例鏈接：

# https://github.com/helm/helm/blob/master/docs/rbac.md

cd mainfests/
mkdir helm
cd  helm
cat > tiller-rbac.yaml << EOF
apiVersion: v1
kind: ServiceAccount
metadata:
  name: tiller
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: tiller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
  - kind: ServiceAccount
    name: tiller
    namespace: kube-system

EOF

創建rbac

# kubectl apply -f tiller-rbac.yaml 

# kubectl get sa -n kube-system |grep tiller
tiller                               1         18s

 

安裝tiller

# 下載或者從本地導入鏡像
docker load -i /home/repos/images/k8s-images/tiller-v2.16.1.tar

# 注意把標簽打成gcr.io/kubernetes-helm/tiller:v2.16.1，如果已經打好了則忽略
docker tag 自己的鏡像 gcr.io/kubernetes-helm/tiller:v2.16.1

# helm init --service-account tiller   --tiller-image gcr.io/kubernetes-helm/tiller:v2.16.1 --stable-repo-url https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
helm init --service-account tiller   --tiller-image gcr.io/kubernetes-helm/tiller:v2.16.1

# 
kubectl get pods -n kube-system |grep tiller 
tiller-deploy-759cb9df9-ls47p 1/1 Running 0 16m

四 helm的使用

官方可用的Chart列表：

https://hub.kubeapps.com

helm常用命令：
- helm search:    搜索charts
- helm fetch:     下載charts到本地目錄
- helm install:   安裝charts
- helm list:      列出charts的所有版本

用法:
  helm [command]

命令可用選項:
  completion  為指定的shell生成自動補全腳本（bash或zsh）
  create      創建一個新的charts
  delete      刪除指定版本的release
  dependency  管理charts的依賴
  fetch       下載charts並解壓到本地目錄
  get         下載一個release
  history     release歷史信息
  home        顯示helm的家目錄
  init        在客戶端和服務端初始化helm
  inspect     查看charts的詳細信息
  install     安裝charts
  lint        檢測包的存在問題
  list        列出release
  package     將chart目錄進行打包
  plugin      add(增加), list（列出）, or remove（移除） Helm 插件
  repo        add(增加), list（列出）, remove（移除）, update（更新）, and index（索引） chart倉庫
  reset       卸載tiller
  rollback    release版本回滾
  search      關鍵字搜索chart
  serve       啟動一個本地的http server
  status      查看release狀態信息
  template    本地模板
  test        release測試
  upgrade     release更新
  verify      驗證chart的簽名和有效期
  version     打印客戶端和服務端的版本信息

總結

helm repo list                 　　　　　　　　#查看倉庫
helm ls                           　　　　　　#查看release
helm install 倉庫名/包名    　　　　　　　　　　 #安裝
helm template 倉庫名/包名 > test.yaml    　　  #把要安裝的軟件包注入到yaml文件中，然后可以kubectl apply -f來應用
helm uninstall release名字          　　　　　 #卸載release
helm repo add 自定義倉庫名字 倉庫路徑      　　　#添加倉庫
helm repo remove 倉庫名稱         　　　　　　　#刪除倉庫
helm lint 軟件包目錄                 　　　　　 #檢查里面文件的語法
helm upgrade 倉庫名/包名 或者 軟件包名稱        #更新helm之前部署的應用
helm create 名稱             　　　　　　　　　　#創建自定義chart
helm plugin add 插件網址       　　　　　　　　　#安裝插件，比如helmpush
helm pull 倉庫名/包名         　　　　　　　　　　#拉去helm鏡像，一般為tgz結尾
helm status release名稱      　　　　　　　　　　#查看release狀態
helm version                    　　　　　　　　#查看helm版本
helm show values release名稱      　　　　　　　#查看release的values文件
helm show all release名稱            　　　　　#查看release的所有信息
helm show chart release名稱        　　　　　　 #查看release中Chart信息
helm repo update                       　　　　#更新倉庫信息
helm packages 路徑                            #打包 

helm install命令可以從多個來源安裝：

1. 通過chart倉庫: helm install stable/mariadb
2. 通過本地 chart 壓縮包: helm install ./nginx-1.2.3.tgz
3. 通過解壓后的chart目錄 helm install ./nginx
4. 通過完整URL: helm install https://example.com/charts/nginx-1.2.3.tgz

命令

helm install /home/nginx-1.2.3.tgz --version 1.1 --namespace nginx --name nginx --values=/home/nginx.conf

有用參數：
--name release的名字
--namespace release的命名空間
-dry-run 模擬一次安裝，常和--debug一起使用，調試chart模板是否正常
--no-hooks 在安裝過程中不使用hooks
--values 使用YAML文件中指定值

helm upgrade的策略

Helm會嘗試執行最小侵入式升級。它只會更新自上次發布以來發生更改的內容。

helm upgrade --install prometheus --namespace prometheus prometheus -f /tmp/prometheus \
  --set manifests.job=true \
  --set storege.requests.size=100Gi

helm upgrde 的時候無法修改job的標簽

 當部署一個Chart，其中部署了Job和CronJob等。我們需要更新部署為Job/CronJob的容器的標簽，並且在update --install --atomic收到此錯誤期間：

Error: UPGRADE FAILED: release X failed, and has been rolled back due to atomic being set: cannot patch "X" with kind Job: Job.batch "Y" is invalid: spec.template: Invalid value: [skipped]: field is immutable

• 原因：
  問題是Kubernetes認為某些事情是不可變的。您不能在某些類型的Kubernetes對象上升級某些值。但是，Helm不知道這些值是什么值，因為它們不會被架構公開。因此，Helm將清單發送給Kubernetes，Kubernetes會以不可變的字段列表作為響應。部署失敗，因為無法升級對象。
  解決方案是讓您的圖表不嘗試修改不可變字段。您可以在Kubernetes文檔https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/中找到更多信息

如果確定要重新運行該Job，我們建議在Job名稱后添加一個隨機字符串

metadata:
  name: {{ template "fullname" . }}-{{ randAlphaNum 5 | lower }}

helm 加上--dry-run --debug做調試

我們用模板來生成資源文件的清單，但是如果我們想要調試就非常不方便了，不可能我們每次都去部署一個release實例來校驗模板是否正確，所幸的時 Helm 為我們提供了 --dry-run --debug這個可選參數，在執行helm install的時候帶上這兩個參數就可以把對應的 values 值和生成的最終的資源清單文件打印出來，而不會真正的去部署一個release實例，比如我們來調試上面創建的 chart 包：

helm install  /home/ceilometer-6.0.1-beta.164.tgz --dry-run  --debug --version 6.0.1-beta.164 --namespace openstack --name ceilometer --values=/tmp/ceilometer

 

五 charts解讀

5.1 常用文件

tree hello-helm/
hello-helm/
├── charts/
├── Chart.yaml
├── templates/
├── requirements.yaml
└── values.yaml

 

• charts/   （可選項）是一個目錄，存放一些調用的charts
• Chart.yaml （必需項）定義一些基礎信息。例如作者、版本等
• templates/  （必需項）是應用需要的yaml文件模板
• requirements.yaml  （可選項）同charts一樣的。
• values.yaml  （必需項）默認配置值。例如定義的一些變量等。

5.2 Chart.yaml 描述

• apiVersion：api版本（v1）
• name：chart的名稱
• version：版本
• kubeVersion：k8s的兼容版本
• description：描述本項目
• keywords：關於本項目
• home：本項目主頁
• maintainers：作者
• icon：圖標
• appVersion：應用版本
• deprecated：是否已棄用
• tillerVersion：tiller版本

5.3 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

使用dependencies引用一個列表。每個對象列表都是要依賴到的chart。

• name: chart的名稱
• version: chart的版本
• repository: chart所在的倉庫

5.4 templates描述

├── templates
│   ├── deployment.yaml
│   ├── _helpers.tpl
│   ├── ingress.yaml
│   ├── NOTES.txt
│   └── service.yaml

 

• NOTES.txt：chart 的 “幫助文本”。這會在用戶運行 helm install 時顯示給用戶。
• deployment.yaml：創建 Kubernetes deployment 的基本 manifest
• service.yaml：為 deployment 創建 service 的基本 manifest
• ingress.yaml: 創建 ingress 對象的資源清單文件
• _helpers.tpl：放置模板助手的地方，可以在整個 chart 中重復使用

如何創建模版

1、我們刪除templates下的所有文件。創建一個configmap.yaml

# rm -rf ./templates/*.*

# vim templates/t1.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: mychart-configmap
data:
  myvalue: "Hello World"

2、安裝這個charts

[root@localhost test]# helm install --generate-name ./hello-helm/  # 或者指定名字helm install xxx ./hello-helm/
NAME: xxx
LAST DEPLOYED: Wed Dec  1 19:56:02 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None

# 如果報錯Error: validation: chart.metadata.version is required
那是因為hello-helm/Chart.yaml內沒有定version

[root@localhost test]# cat hello-helm/Chart.yaml 
name: xxx
version: 1.1  # 新增這一行

 

 

 3、查看渲染后的資源文件

[root@localhost test]# helm list
NAME                   NAMESPACE    REVISION    UPDATED                                    STATUS      CHART                         APP VERSION
。。。
xxx                    default      1           2021-12-01 19:56:02.315445984 +0800 CST    deployed    xxx-1.1                                  
[root@localhost test]# helm get manifest xxx
---
# Source: xxx/templates/t1.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: mychart-configmap
data:
  myvalue: "Hello World"

 

4、 通過變量創建一個簡單的模版

Helm Chart 模板使用的是Go語言模板編寫而成，並添加了Sprig庫中的50多個附件模板函數以及一些其他特殊的函。

現在我們來重新定義下上面的 configmap.yaml 文件：

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ .Release.Name }}-configmap
data:
  myvalue: "Hello World"

我們將名稱替換成了 {{ .Release.Name }}-configmap ，其中包含在{{和}}之中的就是模板指令， {{ .Release.Name }}  將 release 的名稱注入到模板中來，這樣最終生成的 ConfigMap 名稱就是以 release 的名稱開頭的了。這里的 Release 模板對象屬於 Helm 內置的一種對象，還有其他很多內置的對象，稍后我們將接觸到。

# 1、刪除
helm uninstall xxx  # helm delete xxx

# 2、重新安裝
helm install xxx666 ./hello-helm/ --dry-run --debug  

會發現變量{{ .Release.Name }}被替換成xxx666

內置對象

剛剛我們使用 {{.Release.Name}} 將 release 的名稱插入到模板中。這里的 Release 就是 Helm 的內置對象，下面是一些常用的內置對象，在需要的時候直接使用就可以：

• Release：這個對象描述了 release 本身。它里面有幾個對象：
  • Release.Name：release 名稱
  • Release.Time：release 的時間
  • Release.Namespace：release 的 namespace（如果清單未覆蓋）
  • Release.Service：release 服務的名稱（始終是 Tiller）。
  • Release.Revision：此 release 的修訂版本號，從1開始累加。
  • Release.IsUpgrade：如果當前操作是升級或回滾，則將其設置為 true。
  • Release.IsInstall：如果當前操作是安裝，則設置為 true。
• Values：從values.yaml文件和用戶提供的文件傳入模板的值。默認情況下，Values 是空的。
• Chart：Chart.yaml文件的內容。所有的 Chart 對象都將從該文件中獲取。chart 指南中Charts Guide列出了可用字段，可以前往查看。
• Files：這提供對 chart 中所有非特殊文件的訪問。雖然無法使用它來訪問模板，但可以使用它來訪問 chart 中的其他文件。請參閱 "訪問文件" 部分。
  • Files.Get 是一個按名稱獲取文件的函數（.Files.Get config.ini）
  • Files.GetBytes 是將文件內容作為字節數組而不是字符串獲取的函數。這對於像圖片這樣的東西很有用。
• Capabilities：這提供了關於 Kubernetes 集群支持的功能的信息。
  • Capabilities.APIVersions 是一組版本信息。
  • Capabilities.APIVersions.Has $version 指示是否在群集上啟用版本（batch/v1）。
  • Capabilities.KubeVersion 提供了查找 Kubernetes 版本的方法。它具有以下值：Major，Minor，GitVersion，GitCommit，GitTreeState，BuildDate，GoVersion，Compiler，和 Platform。
  • Capabilities.TillerVersion 提供了查找 Tiller 版本的方法。它具有以下值：SemVer，GitCommit，和 GitTreeState。
• Template：包含有關正在執行的當前模板的信息
• Name：到當前模板的文件路徑（例如 mychart/templates/mytemplate.yaml）
• BasePath：當前 chart 模板目錄的路徑（例如 mychart/templates）

上面這些值可用於任何頂級模板，要注意內置值始終以大寫字母開頭。這也符合Go的命名約定。當你創建自己的名字時，你可以自由地使用適合你的團隊的慣例。

 

https://www.cnblogs.com/xzkzzz/p/10445807.html

https://www.cnblogs.com/fengzi7314/p/13824992.html