K8s helm基本概念是什么

本篇內容介紹了“K8s helm基本概念是什么”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

Helm簡介

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

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

Helm 本質就是讓 K8s 的應用管理（Deployment,Service 等 ) 可配置，能動態生成。通過動態生成 K8s 資源清單文件（deployment.yaml，service.yaml）。然后調用 Kubectl 自動執行 K8s 資源部署**。

helm的主要功能：

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

二、Helm中的基本概念Chart

Helm 使用的包格式稱為 chart，它是一個描述 Kubernetes 相關資源對象的文件集合。它的技術特點類似 jinja模版，以渲染模版的方式，生成運行一個服務實例所需的一系列資源對象文件，并以此進行服務的發布。通過這種方式，我們也可以十分簡單的制作自定義的 chart。

Chart 有自已特定的目錄布局，我們以官方提供的 wordpress為例說明，chart 的文件目錄結構如下：

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

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

Repo

Helm chart 可以被存儲在專用的 HTTP 服務器上，稱為 chart 倉庫（repositories)，和 yum repository類似，chart 倉庫提供了一個 index.yaml 來描述一批 chart，并且提供了每個 chart 的下載地址信息。

Helm 客戶端可以指向多個 chart 倉庫，默認情況下是沒有配置倉庫的，需要使用 helm repo add 來進行添加。helm3 中對于一些常用服務的下載安裝，用 bitnami 倉庫 取代了原來的stable 倉庫，但是仍保留了 stable 倉庫的使用

Release

當 chart 被發布后，Helm 庫會創建一個 release 來跟蹤這個發布的對象，它的實質是在 Kubernetes 中運行的各種資源，service、deployment、configmap、secret 等，在 K8S 集群中的直接的表現就是一個或多個 pod.

Helm 的 release 是允許啟動多個不同服務的，且每個服務之間遵循依賴關系，這點就比較類似 docker compose.

三、從Helm2到Helm3的變化

1.Helm3新增的功能

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

• release 的信息以新的形式存儲

• 移除了 Tiller 組件

• Helm3 包含了對新版本 Helm charts （Charts v2）的支持

• Helm3 支持 library charts —— 一種作為其他 charts 元素的 charts

• 將 Chart 推送保存到 OCI 注冊中心（類似 DockerRegistry ），以進行復用

• 升級Kubernetes資源時將應用向戰略合并補丁

• 支持使用 JSON Schema 對 charts 的 values 進行校驗

• 為了使Helm更安全，可用和健壯，已進行了許多小的改進。

2.重要變化概述

1）移除Tiller

Tiller 在 Helm2 中是一個重要的組成部分。Helm2 使用它和 GRPC 來處理 Helm chart 的安裝和管理，呈現 chart 并將其推送到 Kubernetes API Server。Tiller 允許團隊共享一個 Kubernetes 集群，多個 operator 可以使用同一組發行版，團隊成員通過它就可以在一個共享的 Kubernetes 集群中管理復雜的應用發布。

但是從 Kubernetes 1.6 開始，考慮到安全性，集群默認會開啟角色訪問控制（RBAC），這使得管理和配置Tiller會變得非常復雜，因為可能的安全策略數量太多了。為了簡化安全模型實現方式，并使管理員/SRE不需要去深入研究 Kubernetes 的安全組件，helm 提供了一個不需要太過關注安全規則的默認配置，但是這又會使得授權變得寬松，這反而會導致安全隱患。

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

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

2）Chart倉庫升級

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

3）改進升級策略：使用三路策略合并補丁

在 Helm2 中，使用了雙路策略合并補丁，簡單來說就是在使用 helm upgrade 更新過程中，會比對本次發布的 chart manifest 和 最近一次發布的 chart manifest 的差異，以此來決定哪些更改被應用到 Kubernetes 的資源中去。并且，Helm 只會將最后一次應用的 chart manifest 作為 release 的當前狀態，如果 chart 狀態沒有更改，資源的活動狀態就不會更改，也就是說使用諸如 kubectl edit 、kubectl scale 這種外部方式進行的修改不會被 Helm 識別的，這種情況下如果發生回滾操作，Helm 會由于 chart 并沒有發生變化而導致回滾失敗。

而在 Helm3 中，這種策略被升級成了三路策略合并，Helm 在生成一個補丁時，也會考慮之前老的 manifest 的活動狀態。也就是說，在使用老的 chart manifest 生成新的補丁時，Helm 還會考慮當前的活動狀態，并將其與之前老的 manifest 進行比對，并再比對新的 manifest 是否有改動，并進行自動補全，以此來生成最終的更新補丁。

示例說明

用Chart渲染生成的manifest如下

containers:
- name: server
    image: my_app:2.0.0

通過非Helm的方式將應用的活動狀態修改如下：

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

而現在我們想要將應用的鏡像升級到2.1.0，通過chart進行升級操作

在 Helm2 中，由于不會考慮 chart 之外的修改，而是檢測 chart 生成的 manifest 之間的區別，因此修改后的狀態如下：

containers:
- name: server
    image: my_app:2.1.0

而在 Helm3 中，通過三路合并策略，會檢查到除了 chart 的修改外，還多了一個 sidecar 容器，因此會進行補全，最終修改狀態如下：

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

4）release名稱存儲位置改變

在 Helm2 中，release 的相關信息都被保存在 Tiller 的 namespace下，所以 release 的名稱必須是唯一的；而隨著 Tiller 組件的移除， Helm3 中release 相關的信息都被保存在了應用自己相對應的 namespace 下，因此根據 namespace 的隔離性質，在不同的 ns 下，release 的名稱可以重復。

Helm3 中，在執行 helm list 時需要添加 --all-namespaces 參數才能獲取到 Helm2 中同樣的結果

5）requirements.yaml合并入 Chart.yaml

動態依賴關系的chart 依賴從 requirements.yaml 和 requirements.lock 移至 Chart.yaml 和 Chart.lock。 推薦在 Helm3 的新 chart 中使用 Chart API v2 的新格式，但是 Helm3 中依然可以識別 v1 版本，并且會自動加載已有的 requirements.yaml 文件。

在 Helm2 中，requirements.yaml 的表達式類似如下形式：

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

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

6）CLI命令重命名

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

7）簡化模板對象 .Capabilities

Capabilities 是 Helm 模版可以訪問的內置對象之一，其提供了關于 Kubernetes 集群支持的功能的信息，包含以下內容：

四、Helm版本支持策略

1、版本形式

Helm 的版本用 x.y.z 的形式描述，x 是主版本，y 是次版本，z 是補丁版本。當一個 Helm 的新版本發布時，都是針對 Kubernetes 的一個特定版本編譯的，比如 3.0.0 基于 Kubernetes 的 1.16.2 的客戶端API版本構建，則可以兼容 Kubernetes 1.16。

2、可支持的版本偏差

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

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

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

“K8s helm基本概念是什么”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！