有了Kubernetes，為啥還需要Helm？
隨著容器技術的興起，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 mychartmychart結構如下：
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/
