有了Kubernetes，為啥還需要Helm？

作者：程序員Aike 2024-11-26 07:37:22

雖然Kubernetes本身已經非常強大，但隨著容器化應用規模的擴大以及復雜度的增加，直接通過YAML文件來管理這些應用變得愈發困難。

隨著容器技術的興起，Kubernetes（簡稱K8s）已經成為部署、管理和擴展容器化應用的事實標準。然而，在實際使用過程中，直接通過YAML文件管理復雜的Kubernetes應用程序變得越來越困難。為了解決這一問題，Helm應運而生。本次將介紹為什么在擁有K8s之后仍然需要Helm，并簡要介紹下Helm。

一、什么是Helm？

Helm是Kubernetes的一個包管理器，它允許開發者定義、安裝和升級最復雜Kubernetes應用程序。Helm使用一種稱為Charts的打包格式來描述一組相關的Kubernetes資源。這使得團隊能夠更容易地共享和重用他們的Kubernetes配置。

二、有了K8s，為何還需要Helm？

我們直接先給出一幅對比圖：

圖片

1、簡化部署過程

（1）簡化復雜的YAML文件：對于大型項目來說，維護成百上千個相互關聯的YAML文件是一項艱巨的任務。Helm通過模板化這些文件并將其組織成易于理解和管理的charts來解決這個問題。

（2）參數化配置：Helm支持通過values文件或命令行參數動態改變chart中的值，從而讓同一個chart可以適應不同環境的需求。

2、提高可移植性和復用性

（1）易于分享和重用：一旦創建了一個chart，就可以很容易地與其他人共享，或者在不同的環境中重復使用。

（2）版本控制：Helm提供了對charts進行版本管理的能力，這意味著你可以輕松回滾到之前的版本，或者嘗試新功能而不影響生產環境。

3、便于團隊協作

（1）促進團隊合作：通過標準化的應用程序部署流程，團隊成員之間可以統一使用Helm協作部署。

（2）集成CI/CD管道：Helm非常適合集成到持續集成/持續交付(CI/CD)工作流中，實現自動化測試、構建及部署。

三、Helm快速入門

1、Helm整體架構

2、Helm核心概念

Helm有三個核心概念：chart、repository和release。

（1）Chart 代表著 Helm 包。它包含在 Kubernetes 集群內部運行應用程序，工具或服務所需的所有資源定義。你可以把它看作是 Homebrew formula，Apt dpkg，或 Yum RPM 在Kubernetes 中的等價物。

（2）Repository（倉庫）是用來存放和共享 charts 的地方。它就像 Fedora 的軟件包倉庫，只不過它是供 Kubernetes 包所使用的。

（3）Release 是運行在 Kubernetes 集群中的 chart 的實例。一個 chart 通常可以在同一個集群中安裝多次。每一次安裝都會創建一個新的 release。以 MySQL chart為例，如果你想在你的集群中運行兩個數據庫，你可以安裝該chart兩次。每一個數據庫都會擁有它自己的 release 和 release name。

3、Helm安裝與使用

從以下命令中，我們可以看到Helm的安裝和使用過程非常簡單。

（1）安裝Helm客戶端

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod 700 get_helm.sh
$ ./get_helm.sh
#macOS安裝
brew install helm

（2）創建自己的Chart

$ helm create mychart

mychart結構如下：

mychart/
  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 # 可選: 包含簡要使用說明的純文本文件

Chart.yaml文件是chart必需的。包含了以下字段：

apiVersion: chart API 版本 （必需）
name: chart名稱 （必需）
version: 語義化2 版本（必需）
kubeVersion: 兼容Kubernetes版本的語義化版本（可選）
description: 一句話對這個項目的描述（可選）
type: chart類型 （可選）
keywords:
- 關于項目的一組關鍵字（可選）
home: 項目home頁面的URL （可選）
sources:
- 項目源碼的URL列表（可選）
dependencies: # chart 必要條件列表 （可選）
- name: chart名稱 (nginx)
version: chart版本 ("1.2.3")
repository: （可選）倉庫URL ("https://example.com/charts") 或別名 ("@repo-name")
condition: （可選） 解析為布爾值的yaml路徑，用于啟用/禁用chart (e.g. subchart1.enabled )
tags: # （可選）
- 用于一次啟用/禁用 一組chart的tag
import-values: # （可選）
- ImportValue 保存源值到導入父鍵的映射。每項可以是字符串或者一對子/父列表項
alias: （可選） chart中使用的別名。當你要多次添加相同的chart時會很有用
maintainers: # （可選）
- name: 維護者名字 （每個維護者都需要）
email: 維護者郵箱 （每個維護者可選）
url: 維護者URL （每個維護者可選）
icon: 用做icon的SVG或PNG圖片URL （可選）
appVersion: 包含的應用版本（可選）。不需要是語義化，建議使用引號
deprecated: 不被推薦的chart （可選，布爾值）
annotations:
example: 按名稱輸入的批注列表 （可選）.

(3) 部署并查看Chart

# 安裝chart
$ helm install mychart ./mychart
# 查看已安裝的chart
$ helm list
# 查看chart的依賴
$ helm dependency list mychart
# 查看Chart的歷史
$ helm history mychart

(4) 升級或卸載Chart

$ helm upgrade mychart ./mychart
$ helm uninstall mychart

四、結語

雖然Kubernetes本身已經非常強大，但隨著容器化應用規模的擴大以及復雜度的增加，直接通過YAML文件來管理這些應用變得愈發困難。Helm作為Kubernetes的一個包管理器，不僅簡化了部署流程，還極大地提高了配置的可維護性與復用性，使得開發團隊能夠更高效地協作，并且輕松應對多環境下的持續集成/持續交付(CI/CD)需求。

此外，Helm的強大之處不僅僅體現在其對于單個應用或服務的打包能力上，它還能幫助用戶構建復雜的微服務架構。通過定義清晰的服務依賴關系，并利用版本控制系統來跟蹤每次變更，Helm讓整個系統的演進過程更加透明可控。這對于需要頻繁更新和迭代的大中型企業級項目尤為重要。

值得注意的是，盡管Helm提供了許多便利功能，但在實際使用過程中也需要注意一些潛在問題。例如，不恰當的chart設計可能會導致資源過度消耗；而缺乏足夠的安全性考量，則可能使系統面臨不必要的風險。因此，在享受Helm帶來便捷的同時，開發者們也需要不斷學習最佳實踐，確保自己的Kubernetes集群被高效安全地管理。

參考： https://helm.sh/docs/

責任編輯：武曉燕來源：程序員Aike