Kubernetes Helm 套件管理應用程式佈署與生命週期

Kubernetes 應用程式生命週期管理涉及安裝、升級和回復等環節，在 Kubernetes 中，應用程式的安裝意味著建立相關資源並進行佈署和組態，每個修改批次都代表一次升級。然而，隨著應用程式版本迭代，追蹤變更歷史和回復到特定版本變得困難。Kubernetes 資原始檔本身的靜態特性和缺乏引數化機制也加劇了管理複雜性，尤其在多個應用程式具有相似組態的情況下，容易造成範本程式碼的蔓延。Helm 作為 Kubernetes 的套件管理器，有效解決了這些問題。它類別似於作業系統中的套件管理器，例如 Fedora 的 dnf，可以簡化應用程式的安裝、升級、回復和移除流程。Helm 使用 Charts 來封裝應用程式及其依賴項，並透過 Values 和 Templates 實作 Kubernetes 資源的動態組態，讓開發者能夠根據需求調整應用程式組態，而無需直接修改 Kubernetes 資原始檔。

瞭解 Kubernetes 與 Helm

應用程式生命週期的管理確實是一項挑戰。在這裡，我們將「生命週期管理」定義為安裝、升級以及回復應用程式的過程。在 Kubernetes 世界中，安裝一個應用程式意味著建立資源來佈署和組態應用程式。初次安裝會建立我們所稱的應用程式的第一版。

升級則可以被視為對一個或多個 Kubernetes 資源的修改或編輯。每一次批次的修改都可以看作是一個單獨的升級。開發者可能會修改一個 Service 資源，這會將版本號碼提升到第二版。接下來，開發者可能會修改 Deployment、ConfigMap 和 Service，這會將版本號碼提升到第三版。

隨著新版本的應用程式不斷佈署到 Kubernetes 上，追蹤所發生的變更變得越來越困難。大多數情況下，Kubernetes 本身並沒有內建的方式來記錄變更歷史。這使得升級變得更加難以追蹤，同時也使得還原應用程式的前一個版本變得更加困難。假設開發者之前在某個資源上進行了一個錯誤的編輯，那麼團隊該如何知道要回復到哪個版本呢？最新版本（n-1）很容易解決，因為那是最近的一個版本。然而，如果最新穩定版本是五個版本之前呢？團隊經常因為無法快速識別之前執行正常的最新穩定組態而陷入混亂。

資原始檔是靜態的

這是主要影響使用 YAML 資源進行宣告式組態風格的一個挑戰。使用宣告式方法的一部分困難在於 Kubernetes 資原始檔並不是原生設計來進行引數化處理的。資原始檔大多是設計成在應用之前寫完整並且其內容保持為真實來源直到檔案被修改。當處理 Kubernetes 時，這可能會讓人感到困擾。有些 API 資源可能會很長，包含許多不同可自定義的欄位，完全手寫和組態 YAML 資源可能會讓人感到不堪重負。

靜態檔案容易變成範本碼。範本碼代表的是在不同但相似情境中保持大致相同的文字或程式碼。如果開發者管理多個不同的應用程式，這就會成為問題，因為他們可能需要管理多個不同的 Deployment 資源、多個不同的 Service 等。在比較不同應用程式的資原始檔時，你可能會發現它們之間存在大量相似的 YAML 組態。

Helm 搶救！

以下圖示展示了兩個具有顯著範本組態之間的資源範例。藍色文字表示範本行，而紅色文字表示獨特行：

此圖示 - 兩個具有範本組態之間資源範例

可以看到，在這個範例中，每個檔案幾乎完全相同。當管理類別似於此類別檔案時，範本組態對於以宣告式方式管理應用程式的團隊來說就是一個主要麻煩。

Helm 搶救！

隨著時間推移，Kubernetes 社群發現建立和維護 Kubernetes 資源以佈署應用程式是非常困難的一件事。這促使開發了一個簡單但強大的工具來幫助團隊克服佈署應用程式到 Kubernetes 所帶來的挑戰。這個工具就是 Helm。Helm 是一個開放原始碼工具，用於封裝和佈署 Kubernetes 上的應用程式。它經常被稱為 Kubernetes Package Manager ，因為它與你在最喜愛作業系統上找到任何其他套件管理器類別似。

因為 Helm 與傳統套件管理器類別似，所以我們先從瞭解套件管理器開始探討 Helm。

悟解套件管理器

套件管理器用於簡化安裝、升級、回復以及移除系統上應用程式的過程。這些應用程式以套件單位定義，其中包含目標軟體及其依賴項的後設資料。

套件管理器背後的過程非常簡單。首先，使用者將軟體套件名稱作為引數傳遞給套件管理器。套件管理器然後對套件儲存函式庫進行查詢以檢查該套件是否存在。如果找到該套件，套件管理器就會安裝由該套件及其依賴項定義的應用程式到指定位置。

套件管理器使得管理軟體變得非常容易。例如，假設你想要在 Fedora 系統上安裝 htop ，一款 Linux 系統監控工具。安裝它就像輸入一條命令：

dnf install htop --assumeyes

這條命令指示 dnf ，自 2015 年起 Fedora 的套件管理器來找到 htop 在 Fedora 套件儲存函式庫中並安裝它。dnf 還負責安裝 htop 套件所需依賴項，因此你不必擔心事先安裝其需求。

隨著時間推移，htop 的新版本可能會出現在上游儲存函式庫中。dnf 和其他套件管理器允許使用者高效地升級至軟體新版本。使用 dnf 允許使用者升級子命令：

dnf upgrade htop --assumeyes

這條命令指示 dnf 將 htop 升級到其最新版本。它還會將依賴項升級到套件後設資料中指定的版本。

雖然向前推進通常更好，但套件管理器也允許使用者後退並必要時將應用程式回復到之前的版本。

dnf downgrade htop --assumeyes

這是一個強大的過程，因為套件管理器允許使用者在報告關鍵錯誤或漏洞時快速回復。

Kubernetes 與 Helm 的應用管理

在 Kubernetes 環境中，應用管理是一個關鍵問題。這裡，我們將探討 Helm 如何作為 Kubernetes 的套件管理器，並比較它與 Fedora 上的 dnf 包管理器的相似之處。這樣的比較可以幫助我們更好地理解 Helm 的功能和優勢。

dnf 與 Helm 的基本操作

首先，讓我們來看看 dnf 在 Fedora 上的一些基本操作。dnf 是一個強大的包管理工具，可以用來安裝、更新和移除軟體包。

# 安裝軟體包
dnf install htop --assumeyes

# 移除軟體包
dnf remove htop --assumeyes

這些命令展示了 dnf 的基本功能。在 Kubernetes 環境中，Helm 提供了類別似的功能，但專注於管理 Kubernetes 資源。

Helm 的基本概念

Helm 是 Kubernetes 的套件管理器，類別似於 dnf 在 Fedora 上的角色。Helm 主要用來管理 Kubernetes 上的應用程式，透過使用「Charts」來定義和佈署應用程式。Charts 可以被視為 Kubernetes 的套件，包含了所有必要的資源定義檔案和依賴項。

Charts 的結構

一個 Helm Chart 通常包含以下內容：

Chart.yaml：描述 Chart 的後設資料。
values.yaml：定義 Chart 的組態引數。
templates/：包含 Kubernetes 資源定義範本。
charts/：包含依賴的其他 Charts。

# Chart.yaml
apiVersion: v2
name: my-app
description: A Helm chart for my application
version: 0.1.0

# values.yaml
replicaCount: 2
image:
  repository: my-app-image
  tag: latest

# templates/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Release.Name }}-deployment
spec:
  replicas: {{ .Values.replicaCount }}
  template:
    metadata:
      labels:
        app: {{ .Release.Name }}
    spec:
      containers:
        - name: {{ .Release.Name }}
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"

佈署 Redis 的範例

假設我們想要在 Kubernetes 上佈署 Redis，可以使用 Helm 安裝一個已發布的 Chart。以下是具體步驟：

# 安裝 Redis Chart
helm install redis bitnami/redis --namespace=redis

# 升級 Redis Chart
helm upgrade redis bitnami/redis --namespace=redis

# 滾回到前一個版本
helm rollback redis 1 --namespace=redis

# 移除 Redis Chart
helm uninstall redis --namespace=redis

Helm 與 dnf 的對比

以下是 dnf 和 Helm 命令的對比表：

dnf 命令	Helm 命令	功能描述
`dnf install`	`helm install`	安裝套件或應用程式
`dnf upgrade`	`helm upgrade`	升級套件或應用程式
`dnm rollback`	`helm rollback`	滾回到前一個版本
`dnf remove`	`helm uninstall`	移除套件或應用程式

從這張表可以看出，Helm 和 dnf 提供了相似的命令和功能，這使得經驗豐富的 Linux 使用者可以很快上手使用 Helm。

## 次段落標題：內容解密：

這段程式碼展示瞭如何使用 Helm 安裝、升級、滾回和移除 Redis 應用。這些命令分別對應於安裝（install）、升級（upgrade）、滾回（rollback）和移除（uninstall）操作。

安裝 Redis Chart：這條命令會從 Bitnami 源安裝 Redis Chart，並將其佈署到名為 redis 的名稱空間中。
升級 Redis Chart：如果有新版本的 Redis Chart 被發布，這條命令會將現有的 Redis 應用升級到新版本。
滾回到前一個版本：如果在升級後發現問題，可以使用這條命令將 Redis 還原到前一個穩定版本。
移除 Redis Chart：當不再需要 Redis 應用時，可以使用這條命令將其完全移除。

Helm 帶來的優勢

Helm 不僅提供了類別似於傳統包管理器的功能，還解決了 Kubernetes 應用管理中的一些挑戰。以下是幾個主要優勢：

抽象化 Kubernetes 資源的複雜性

Kubernetes 資源組態通常非常複雜，特別是對於新手或中級使用者來說。Helm 提供了預先組態好的 Charts，使得開發者可以輕鬆地佈署複雜的應用程式。

清晰的版本歷史

Helm 支援版本歷史跟蹤，允許使用者在需要時進行滾回。這樣可以避免因為升級導致的問題而無法還原到穩定狀態。

此圖示展示了一個版本歷史示意圖。
```mermaid
graph TD;
    A[初始版本] --> B[第一次升級];
    B --> C[第二次升級];
    C --> D[第三次升級];
    D --> E[第四次升級];

## 次段落標題：內容解密：

此圖示展示了一個版本歷史示意圖。每個節點代表一次發布或升級操作。如果需要滾回到某個特定版本，只需指定該節點即可。

Kubernetes 與 Helm 的深入瞭解

動態組態的宣告性資源

在 Kubernetes 中，建立宣告性資源的一大困難在於這些資源是靜態的，無法引數化。這會導致資源在不同應用和相似組態之間變成範本程式碼，使團隊難以將應用程式作為程式碼進行組態。Helm 透過引入值和範本來解決這些問題。

值（Values）是 Helm 為圖表（Charts）所定義的引數。範本（Templates）是根據給定值集生成的動態檔案。這兩個建構使圖表開發者能夠編寫根據終端使用者提供的值自動生成的 Kubernetes 資源。透過這種方式，Helm 管理的應用程式變得更加靈活，範本程式碼減少，維護更加容易。

值和範本允許使用者執行以下操作：

引數化常見欄位，例如佈署（Deployment）中的映象名稱和服務（Service）中的埠
根據使用者輸入生成長片段 YAML 組態，例如佈署中的卷掛載或 ConfigMap 中的資料
根據使用者輸入包含或排除資源

動態生成宣告性資原始檔使得建立根據 YAML 的資源更加簡單，同時確保應用程式以可重複的方式建立。

本地與即時狀態的一致性

包管理器防止使用者手動管理應用程式及其依賴項。所有管理都可以透過包管理器本身完成。同樣的道理適用於 Helm。因為 Helm 圖表包含 Kubernetes 資源的靈活組態，使用者不需要對即時 Kubernetes 資源進行直接修改。想要修改其應用程式的使用者可以透過為 Helm 圖表提供新的值或將其應用程式升級到關聯圖表的較新版本來實作這一點。這使得本地狀態（由 Helm 圖表組態表示）和即時狀態在修改過程中保持一致，讓使用者能夠為其 Kubernetes 資源組態提供真實來源。

智慧佈署

Helm 簡化了應用程式的佈署，透過確定 Kubernetes 資源需要建立的順序。Helm 分析圖表中的每個資源，並根據其型別對其進行排序。這種預定義順序存在的目的是確保那些通常依賴於其他資源的資源優先建立。例如，Secret 和 ConfigMap 應在 Deployment 之前建立，因為 Deployment 可能會將它們作為捲來消耗。Helm 在沒有任何使用者互動的情況下執行此排序，因此抽象了該複雜性並防止使用者需要擔心這些資源的應用順序。

自動化生命週期鉤子

與其他包管理器類別似，Helm 提供了定義生命週期鉤子的能力。生命週期鉤子是在應用程式生命週期的不同階段自動發生的操作。它們可以執行以下操作：

在升級時執行資料備份。
在回復時還原資料。
在安裝之前驗證 Kubernetes 環境。

生命週期鉤子具有價值，因為它們抽象了可能不是特定於 Kubernetes 的任務複雜性。例如，Kubernetes 使用者可能不熟悉備份資料函式庫的最佳實踐或不知道何時執行此任務。生命週期鉤子允許專家編寫自動化程式碼來在推薦時執行這些最佳實踐，以便使用者能夠繼續保持生產力而不需要擔心這些細節。

架構趨勢演變：微服務架構與容器技術

在本章中，我們開始探討將應用程式拆解為多個輕量級且易於管理的應用程式之趨勢，這取代了傳統單一大型應用程式的架構模式。容器作為封裝與執行格式被廣泛採納，以更頻繁地產生釋出版本。然而隨之而來的是額外的營運挑戰，這些挑戰被 Kubernetes 作為容器協調平台來解決。

應用佈署與 Helm 的組態方式

我們接著討論了 Kubernetes 應用可透過佈署（Deployments）、服務（Services）及持久性儲存區宣告（PersistentVolumeClaims）等方式進行組態，這些資源可透過命令式及宣告式兩種應用組態方式來表達。每種組態方式都帶來了一系列挑戰：如理解 Kubernetes 資源工作原理所需知識量以及管理應用生命週期難度等。

為了更好地管理每個組成應用所需資產之方法，我們引入了 Helm 作為 Kubernetes 的套件管理工具。透過其豐富功能集合，我們能夠輕鬆管理從安裝、升級、回復到移除之應用全生命週期。

探索 Kubernetes 資源與 Helm 的進階功能

Kubernetes 資源是組成應用程式的一個重要部分，它們可以透過不同方式進行組態：如佈署、服務及持久性儲存區宣告等資源皆可表示為命令式及宣告式兩種應用組態方式。每種方式都各具挑戰：包括理解 Kubernetes 資源如何運作所需知識及如何有效管理應用生命週期等問題。

為了更好地管理組成應用程式之各項資產，「玄貓」介紹了 Helm 作為 Kubernetes 的套件管理工具。「玄貓」認為透過 Helm 的豐富功能集合，「玄貓」可以輕鬆管理從安裝、升級、回復到移除之應用全生命週期。

持續學習與實踐

在未來章節中，「玄貓」會逐步引導大家進行一個完整「Helm」環境組態、「Helm」工具安裝以及掌握「Helm」生態系統中一些實際案例。「玄貓」鼓勵讀者積極參與並實際操作「Helm」，以深化對「Helm」與「Kubernetes」技術內容理解。

延伸閱讀

為了更深入瞭解構成應用程式之「Kubernetes」資源，「玄貓」推薦讀者參閱「Kubernetes」官方檔案中的「Understanding Kubernetes Objects」，網址如下： https://kubernetes.io/docs/concepts/overview/working-with-objects/kubernetes-objects/

另外，「玄貓」也推薦讀者參考「Using Helm」頁面瞭解「Helm」的一些基本使用方法：「Helm」官方檔案如下： https://helm.sh/docs/intro/using_helm/

常見問題解答

單一架構與微服務架構有何不同？ 單一架構（Monolithic Architecture）指的是將所有功能集中在一個單一應用中執行；而微服務架構（Microservices Architecture）則是將應用拆分成多個獨立且小型服務執行。
Kubernetes 是什麼？它解決了哪些問題？ Kubernetes 是一個開放原始碼容器協調平台，主要解決了容器化應用佈署、擴充套件及管理問題。
在佈署應用到 Kubernetes時常見使用哪些 kubectl 命令？ 常見命令包括 kubectl apply、kubectl get、kubectl delete、kubectl describe 和 kubectl logs 等。
佈署到Kubernetes時常見遇到哪些挑戰？ 挑戰包括理解Kubernetes資源工作原理、組態檔案複雜度高、依賴項管理、資源分配和自動化流程等問題。
Helm 作為Kubernetes套件管理工具是如何運作並解決其帶來挑戰？ 「玄貓」認為 Helms 功能強大且靈活，「玄貓」可以透過 Helms 滿足從安裝到回復整個應程式生命週期需求。「玄貓」認為 Helms 能夠幫助使用者更有效率地管理他的資料。「玄貓」會根據不同情況設定不同值並自動生成對應啟動指令碼。「玄貓」認為 Helms 能夠有效掌控資料更新邏輯並保證系統穩定性。「玄貓」相信透過 Helms 「玄貓」可以輕鬆達成上述目標。
想要回復在Kubernetes上佈署之應用時該怎麼做？ 「玄貓」認為使用 helm rollback 命令可以完成此任務。「玄貓」會根據版本記錄追蹤所有更新記錄並選擇合適版本進行回復操作。「玄貓」也會根據情況選擇適當更新策略以避免系統影響。
Helm 作為套件管理工具主要有哪四大基本命令？ 四大基本命令分別為 helm install、helm upgrade、helm rollback 和 helm uninstall ，這些命令分別對應於安裝、升級、回復及移除動作

玄貓

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。

Kubernetes Helm 套件管理應用程式佈署與生命週期

瞭解 Kubernetes 與 Helm

資原始檔是靜態的

Helm 搶救！

Helm 搶救！

悟解套件管理器

Kubernetes 與 Helm 的應用管理

dnf 與 Helm 的基本操作

Helm 的基本概念

Charts 的結構

佈署 Redis 的範例

Helm 與 dnf 的對比

## 次段落標題：內容解密：

Helm 帶來的優勢

抽象化 Kubernetes 資源的複雜性

清晰的版本歷史

## 次段落標題：內容解密：

推薦閱讀

Kubernetes 與 Helm 的深入瞭解

動態組態的宣告性資源

本地與即時狀態的一致性

智慧佈署

自動化生命週期鉤子

架構趨勢演變：微服務架構與容器技術

應用佈署與 Helm 的組態方式

探索 Kubernetes 資源與 Helm 的進階功能

持續學習與實踐

延伸閱讀

常見問題解答

玄貓