Helm簡(jiǎn)介

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

?在沒(méi)使用 helm 之前，向 kubernetes 部署應(yīng)用，我們要依次部署 deployment、svc 等，步驟較繁瑣。況且隨著很多項(xiàng)目微服務(wù)化，復(fù)雜的應(yīng)用在容器中部署以及管理顯得較為復(fù)雜，helm 通過(guò)打包的方式，支持發(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)生成。通過(guò)動(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ā)布。通過(guò)這種方式，我們也可以十分簡(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)情況下是沒(méi)有配置倉(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ì)成員通過(guò)它就可以在一個(gè)共享的 Kubernetes 集群中管理復(fù)雜的應(yīng)用發(fā)布。

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

?因此在 Helm3 中干脆移除了 Tiller，而是選擇從 Kubernetes API Server 中獲取信息來(lái)渲染 Charts 客戶端，并在 Kubernetes 中存在安裝記錄，這些過(guò)程既沒(méi)有 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 更新過(guò)程中，會(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)沒(méi)有更改，資源的活動(dòng)狀態(tài)就不會(huì)更改，也就是說(shuō)使用諸如 kubectl edit 、kubectl scale 這種外部方式進(jìn)行的修改不會(huì)被 Helm 識(shí)別的，這種情況下如果發(fā)生回滾操作，Helm 會(huì)由于 chart 并沒(méi)有發(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

通過(guò)非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，通過(guò)chart進(jìn)行升級(jí)操作

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

containers:
- name: server
    image: my_app:2.1.0

而在 Helm3 中，通過(guò)三路合并策略，會(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á)式的形式并沒(méi)有變化，但是現(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 模版可以訪問(wèn)的內(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 沒(méi)有向上兼容機(jī)制，故按照官方推薦安裝即可：

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

最新評(píng)論