Helm簡(jiǎn)介

一、什么是 Helm(官網(wǎng)：https://helm.sh/)

?在沒使用 helm 之前，向 kubernetes 部署應(yīng)用，我們要依次部署 deployment、svc 等，步驟較繁瑣。況且隨著很多項(xiàng)目微服務(wù)化，復(fù)雜的應(yīng)用在容器中部署以及管理顯得較為復(fù)雜，helm 通過打包的方式，支持發(fā)布的版本管理和控制，很大程度上簡(jiǎn)化了 Kubernetes 應(yīng)用的部署和管理，就像 Java 使用 maven；node 使用 npm；python 使用 pip；Linux 使用 yum **

?Helm 本質(zhì)就是讓 K8s 的應(yīng)用管理（Deployment,Service 等 ) 可配置，能動(dòng)態(tài)生成。通過動(dòng)態(tài)生成 K8s 資源清單文件（deployment.yaml，service.yaml）。然后調(diào)用 Kubectl 自動(dòng)執(zhí)行 K8s 資源部署**。

helm的主要功能：

#查找要安裝和使用的預(yù)打包軟件
#輕松創(chuàng)建和托管自己的軟件包
#將軟件包安裝到任何 K8S 集群中
#查詢集群以查看已安裝和正在運(yùn)行的程序包
#更新、刪除、回滾或查看已安裝軟件包的歷史記錄

二、Helm中的基本概念Chart

?Helm 使用的包格式稱為 chart，它是一個(gè)描述 Kubernetes 相關(guān)資源對(duì)象的文件集合。它的技術(shù)特點(diǎn)類似 jinja模版，以渲染模版的方式，生成運(yùn)行一個(gè)服務(wù)實(shí)例所需的一系列資源對(duì)象文件，并以此進(jìn)行服務(wù)的發(fā)布。通過這種方式，我們也可以十分簡(jiǎn)單的制作自定義的 chart。

Chart 有自已特定的目錄布局，我們以官方提供的 wordpress為例說(shuō)明，chart 的文件目錄結(jié)構(gòu)如下：

wordpress/
  Chart.yaml                # 包含了chart信息的YAML文件
  LICENSE                   # 可選: 包含chart許可證的純文本文件
  README.md                 # 可選: 可讀的README文件
  values.yaml               # chart 默認(rèn)的配置值
  values.schema.json        # 可選: 一個(gè)使用JSON結(jié)構(gòu)的values.yaml文件
  charts/                   # 包含chart依賴的其他chart
  crds/                     # 自定義資源的定義
  templates/                # 模板目錄， 當(dāng)和values 結(jié)合時(shí)，可生成有效的Kubernetes manifest文件
  templates/NOTES.txt       # 可選: 包含簡(jiǎn)要使用說(shuō)明的純文本文件

  #Helm Chart 基本元素為 charts/、Chart.yaml、templates/、values.yaml，并保留 crds/ ，要正確的使用 chart 進(jìn)行發(fā)布，該元素是必不可少的。

Repo

?Helm chart 可以被存儲(chǔ)在專用的 HTTP 服務(wù)器上，稱為 chart 倉(cāng)庫(kù)（repositories)，和 yum repository類似，chart 倉(cāng)庫(kù)提供了一個(gè) index.yaml 來(lái)描述一批 chart，并且提供了每個(gè) chart 的下載地址信息。

?Helm 客戶端可以指向多個(gè) chart 倉(cāng)庫(kù)，默認(rèn)情況下是沒有配置倉(cāng)庫(kù)的，需要使用 helm repo add 來(lái)進(jìn)行添加。helm3 中對(duì)于一些常用服務(wù)的下載安裝，用 bitnami 倉(cāng)庫(kù) 取代了原來(lái)的stable 倉(cāng)庫(kù)，但是仍保留了 stable 倉(cāng)庫(kù)的使用

Release

?當(dāng) chart 被發(fā)布后，Helm 庫(kù)會(huì)創(chuàng)建一個(gè) release 來(lái)跟蹤這個(gè)發(fā)布的對(duì)象，它的實(shí)質(zhì)是在 Kubernetes 中運(yùn)行的各種資源，service、deployment、configmap、secret 等，在 K8S 集群中的直接的表現(xiàn)就是一個(gè)或多個(gè) pod.

?Helm 的 release 是允許啟動(dòng)多個(gè)不同服務(wù)的，且每個(gè)服務(wù)之間遵循依賴關(guān)系，這點(diǎn)就比較類似 docker compose.

三、從Helm2到Helm3的變化

1.Helm3新增的功能

?Helm3新增了許多新功能，以下幾個(gè)功能需要特別指出：

• release 的信息以新的形式存儲(chǔ)
• 移除了 Tiller 組件
• Helm3 包含了對(duì)新版本 Helm charts （Charts v2）的支持
• Helm3 支持 library charts —— 一種作為其他 charts 元素的 charts
• 將 Chart 推送保存到 OCI 注冊(cè)中心（類似 DockerRegistry ），以進(jìn)行復(fù)用
• 升級(jí)Kubernetes資源時(shí)將應(yīng)用向戰(zhàn)略合并補(bǔ)丁
• 支持使用 JSON Schema 對(duì) charts 的 values 進(jìn)行校驗(yàn)
• 為了使Helm更安全，可用和健壯，已進(jìn)行了許多小的改進(jìn)。

2.重要變化概述

?1）移除Tiller

?Tiller 在 Helm2 中是一個(gè)重要的組成部分。Helm2 使用它和 GRPC 來(lái)處理 Helm chart 的安裝和管理，呈現(xiàn) chart 并將其推送到 Kubernetes API Server。Tiller 允許團(tuán)隊(duì)共享一個(gè) Kubernetes 集群，多個(gè) operator 可以使用同一組發(fā)行版，團(tuán)隊(duì)成員通過它就可以在一個(gè)共享的 Kubernetes 集群中管理復(fù)雜的應(yīng)用發(fā)布。

?但是從 Kubernetes 1.6 開始，考慮到安全性，集群默認(rèn)會(huì)開啟角色訪問控制（RBAC），這使得管理和配置Tiller會(huì)變得非常復(fù)雜，因?yàn)榭赡艿陌踩呗詳?shù)量太多了。為了簡(jiǎn)化安全模型實(shí)現(xiàn)方式，并使管理員/SRE不需要去深入研究 Kubernetes 的安全組件，helm 提供了一個(gè)不需要太過關(guān)注安全規(guī)則的默認(rèn)配置，但是這又會(huì)使得授權(quán)變得寬松，這反而會(huì)導(dǎo)致安全隱患。

?因此在 Helm3 中干脆移除了 Tiller，而是選擇從 Kubernetes API Server 中獲取信息來(lái)渲染 Charts 客戶端，并在 Kubernetes 中存在安裝記錄，這些過程既沒有 Tiller 也可以實(shí)現(xiàn)。

?Helm3 可以支持所有的 Kubernetes 認(rèn)證及鑒權(quán)等全部安全特性。Helm和本地的 kubeconfig flie 中的配置使用一致的權(quán)限。管理員可以按照自己認(rèn)為合適的粒度來(lái)管理用戶權(quán)限，下圖可詳細(xì)看出helm2到helm3的改變

?2）Chart倉(cāng)庫(kù)升級(jí)

?在 Helm3 中，helm search 除了支持本地 repository 搜索外，還支持 helm search hub 搜索 Artifact Hub 中所有公開的 charts。

?3）改進(jìn)升級(jí)策略：使用三路策略合并補(bǔ)丁

?在 Helm2 中，使用了雙路策略合并補(bǔ)丁，簡(jiǎn)單來(lái)說(shuō)就是在使用 helm upgrade 更新過程中，會(huì)比對(duì)本次發(fā)布的 chart manifest 和 最近一次發(fā)布的 chart manifest 的差異，以此來(lái)決定哪些更改被應(yīng)用到 Kubernetes 的資源中去。并且，Helm 只會(huì)將最后一次應(yīng)用的 chart manifest 作為 release 的當(dāng)前狀態(tài)，如果 chart 狀態(tài)沒有更改，資源的活動(dòng)狀態(tài)就不會(huì)更改，也就是說(shuō)使用諸如 kubectl edit 、kubectl scale 這種外部方式進(jìn)行的修改不會(huì)被 Helm 識(shí)別的，這種情況下如果發(fā)生回滾操作，Helm 會(huì)由于 chart 并沒有發(fā)生變化而導(dǎo)致回滾失敗。

?而在 Helm3 中，這種策略被升級(jí)成了三路策略合并，Helm 在生成一個(gè)補(bǔ)丁時(shí)，也會(huì)考慮之前老的 manifest 的活動(dòng)狀態(tài)。也就是說(shuō)，在使用老的 chart manifest 生成新的補(bǔ)丁時(shí)，Helm 還會(huì)考慮當(dāng)前的活動(dòng)狀態(tài)，并將其與之前老的 manifest 進(jìn)行比對(duì)，并再比對(duì)新的 manifest 是否有改動(dòng)，并進(jìn)行自動(dòng)補(bǔ)全，以此來(lái)生成最終的更新補(bǔ)丁。

?示例說(shuō)明

用Chart渲染生成的manifest如下

containers:
- name: server
    image: my_app:2.0.0

通過非Helm的方式將應(yīng)用的活動(dòng)狀態(tài)修改如下：

containers:
- name: server
    image: my_app:2.0.0
- name: sidecar
  	image: dump_handler:1.0.0

而現(xiàn)在我們想要將應(yīng)用的鏡像升級(jí)到2.1.0，通過chart進(jìn)行升級(jí)操作

在 Helm2 中，由于不會(huì)考慮 chart 之外的修改，而是檢測(cè) chart 生成的 manifest 之間的區(qū)別，因此修改后的狀態(tài)如下：

containers:
- name: server
    image: my_app:2.1.0

而在 Helm3 中，通過三路合并策略，會(huì)檢查到除了 chart 的修改外，還多了一個(gè) sidecar 容器，因此會(huì)進(jìn)行補(bǔ)全，最終修改狀態(tài)如下：

containers:
- name: server
    image: my_app:2.1.0
- name: sidecar
  	image: dump_handler:1.0.0

?4）release名稱存儲(chǔ)位置改變

?在 Helm2 中，release 的相關(guān)信息都被保存在 Tiller 的 namespace下，所以 release 的名稱必須是唯一的；而隨著 Tiller 組件的移除， Helm3 中release 相關(guān)的信息都被保存在了應(yīng)用自己相對(duì)應(yīng)的 namespace 下，因此根據(jù) namespace 的隔離性質(zhì)，在不同的 ns 下，release 的名稱可以重復(fù)。

?Helm3 中，在執(zhí)行 helm list 時(shí)需要添加 --all-namespaces 參數(shù)才能獲取到 Helm2 中同樣的結(jié)果

?5）requirements.yaml合并入 Chart.yaml

?動(dòng)態(tài)依賴關(guān)系的chart 依賴從 requirements.yaml 和 requirements.lock 移至 Chart.yaml 和 Chart.lock。 推薦在 Helm3 的新 chart 中使用 Chart API v2 的新格式，但是 Helm3 中依然可以識(shí)別 v1 版本，并且會(huì)自動(dòng)加載已有的 requirements.yaml 文件。

?在 Helm2 中，requirements.yaml 的表達(dá)式類似如下形式：

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://charts.helm.sh/stable
  condition: mariadb.enabled
  tags:
    - database

?而在 Helm3 中，表達(dá)式的形式并沒有變化，但是現(xiàn)在需要寫在 Chart.yaml 中。Chart 依然會(huì)下載和放置在 charts/ 目錄，所以 charts/ 目錄中的子 chart 不需要做任何修改，可以沿用 Helm2 的。

?6）CLI命令重命名

#刪除release
	helm delete ---> helm uninstall
#在 Helm2 中，如果要清楚 release 的各種資源，必須要使用 --purge 參數(shù)，Helm3 中默認(rèn)就會(huì)啟用次功
#如果要保留歷史行為數(shù)據(jù)，需執(zhí)行 
	helm uninstall ---> keep-history
	helm inspect ---> helm show
    helm feach ---> helm pull
#這些命令還保留了它們較舊的命令作為別名，因此您可以繼續(xù)以任何一種形式使用它們。

?7）簡(jiǎn)化模板對(duì)象 .Capabilities

?Capabilities 是 Helm 模版可以訪問的內(nèi)置對(duì)象之一，其提供了關(guān)于 Kubernetes 集群支持的功能的信息，包含以下內(nèi)容：

四、Helm版本支持策略

?1、版本形式

?Helm 的版本用 x.y.z 的形式描述，x 是主版本，y 是次版本，z 是補(bǔ)丁版本。當(dāng)一個(gè) Helm 的新版本發(fā)布時(shí)，都是針對(duì) Kubernetes 的一個(gè)特定版本編譯的，比如 3.0.0 基于 Kubernetes 的 1.16.2 的客戶端API版本構(gòu)建，則可以兼容 Kubernetes 1.16。

?2、可支持的版本偏差

?相較于 Helm2 對(duì)于 Kubernetes 次版本變更支持的嚴(yán)格（n-1），Helm3 可以向下兼容 n-3 的次版本，比如你使用一個(gè)針對(duì) Kubernetes 1.18 客戶端 API 版本編譯的 Helm3 版本，那么它可以支持的 Kubernetes 版本為 1.18、1.17、1.16、1.15 ；

?如果你使用一個(gè)針對(duì) Kubernetes 1.15 客戶端 API 版本編譯的 Helm2 版本，那么它可以支持的 Kubernetes 版本為 1.15、1.14。

? Helm 沒有向上兼容機(jī)制，故按照官方推薦安裝即可：

到此這篇關(guān)于K8s-helm簡(jiǎn)介的文章就介紹到這了,更多相關(guān)K8s-helm簡(jiǎn)介內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論