從 YAML 到 Helm：掌握 Kubernetes 應用部署策略

– 8 分鐘閱讀

在雲端原生架構中，Kubernetes 作為容器編排的標準，其核心價值在於實現應用程式部署與管理的自動化。將應用程式容器化後，關鍵挑戰便是如何有效地將其部署至叢集並對外提供服務。此過程涉及對核心資源物件的理解，如定義應用程式期望狀態的 Deployment，以及建立穩定網路端點的 Service。初期，工程師需手動編寫 YAML 檔案定義資源，但隨應用複雜度提升，管理大量 YAML 檔案的困難度也隨之浮現。為解決此痛點，社群發展出如 Helm 的包管理器，將部署單元抽象化為可重用的 Chart，進一步實現應用程式生命週期管理的標準化，成為現代 DevOps 實踐的關鍵工具。

應用程式部署與服務暴露

本節將繼續探討如何將應用程式部署到 Kubernetes 集群，並將其暴露到集群外部以便訪問。

部署應用程式與驗證

在創建了 Deployment YAML 文件後，我們需要使用 kubectl 命令將其應用到 Kubernetes 集群。

  1. 應用 Deployment 配置: 在終端中，導航到包含 myapp-deployment.yml 文件的目錄，然後執行以下命令：

    kubectl apply -f myapp-deployment.yml

    此命令會讀取 YAML 文件中的定義，並指示 Kubernetes 集群創建相應的 Deployment 和 Pod。

  2. 驗證 Pod 狀態: 部署後，我們可以檢查 Pod 的狀態以確認應用程式是否成功運行。執行以下命令：

    kubectl get pods

    您應該會看到兩個名為 webapp-<uid> 的 Pod，它們的狀態顯示為 Running。這表明 Kubernetes 已成功創建了兩個應用程式副本，並且它們正在正常運行。

    您也可以通過 Kubernetes Dashboard 查看 Deployment 的狀態、使用的 Docker 映像以及創建的 Pods。點擊相關鏈接可以查看更詳細的信息。

將應用程式暴露到集群外部

目前，應用程式已經部署在 Kubernetes 集群中，但它只能在集群內部訪問。為了讓外部用戶能夠訪問該 Web 應用程式，我們需要創建一個 Kubernetes Service，並將其類型設置為 NodePort。

  1. 創建 Service YAML 文件: 在與 Deployment 文件相同的目錄 (k8sdeploy) 下，創建一個名為 myapp-service.yml 的文件，內容如下：

    ---
apiVersion: v1
kind: Service
metadata:
  name: webapp
  labels:
    app: webapp
spec:
  type: NodePort
  ports:
  - port: 80
    targetPort: 80
    nodePort: 31000
  selector:
    app: webapp

    此 YAML 文件定義了一個名為 webapp 的 Service：

    • apiVersion: v1 和 kind: Service: 指定了 API 版本和對象類型為 Service。
    • metadata.labels: 為 Service 標記標籤。
    • spec.type: NodePort: 將 Service 的類型設置為 NodePort。這意味著 Kubernetes 會在集群的每個節點上打開一個指定的端口（nodePort），並將外部流量轉發到後端的 Pod。
    • spec.ports: 定義端口映射。
      • port: 80: Service 在集群內部暴露的端口。
      • targetPort: 80: 將流量轉發到 Pod 內部暴露的端口。
      • nodePort: 31000: 在集群節點上暴露的外部端口。
    • spec.selector: 指定 Service 如何選擇要代理流量的 Pod，通過標籤 app: webapp 匹配 Deployment 創建的 Pod。

  2. 創建 Service: 在終端中執行以下命令來創建 Service：

    kubectl apply -f myapp-service.yml

    此命令會在 Kubernetes 集群中創建 Service 對象，並配置端口轉發。

  3. 訪問應用程式: 創建 Service 後，您就可以通過集群節點的 IP 地址和指定的 nodePort（在此例中是 31000）來訪問應用程式了。打開 Web 瀏覽器，訪問 http://<NodeIP>:31000。您應該能看到部署的 Web 應用程式頁面。

視覺化 Service 配置與訪問

以下圖示展示了 Service 的配置結構以及如何通過 NodePort 訪問應用程式。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

title Kubernetes Service (NodePort) Configuration and Access

component "Kubernetes Cluster" {
  artifact "kubectl Client" as KUBECTL
  artifact "Deployment (webapp)" as DEPLOYMENT
  artifact "Pods (2 replicas of webapp)" as PODS
  artifact "Service (webapp)" as SERVICE {
    type: NodePort
    port: 80
    targetPort: 80
    nodePort: 31000
    selector: app=webapp
  }
  artifact "Node 1" as NODE1
  artifact "Node 2" as NODE2
}

component "External Access" {
  artifact "Web Browser" as BROWSER
  artifact "External IP Address" as EXTERNAL_IP
}

KUBECTL --> DEPLOYMENT : `kubectl apply -f myapp-deployment.yml`
DEPLOYMENT --> PODS : Creates Pods based on template

KUBECTL --> SERVICE : `kubectl apply -f myapp-service.yml`
SERVICE --> PODS : Selects Pods with label app=webapp
SERVICE --> NODE1 : Exposes port 31000
SERVICE --> NODE2 : Exposes port 31000

BROWSER --> EXTERNAL_IP : Accesses http://<NodeIP>:31000
EXTERNAL_IP --> NODE1 : Forwards traffic to port 31000
EXTERNAL_IP --> NODE2 : Forwards traffic to port 31000

NODE1 --> SERVICE : Routes traffic to port 80
NODE2 --> SERVICE : Routes traffic to port 80
SERVICE --> PODS : Routes traffic to targetPort 80 on selected Pods

@enduml

看圖說話：

此圖示說明了 Kubernetes Service 的 NodePort 配置以及外部訪問流程。首先，Deployment 將應用程式部署為兩個 Pod。接著，一個 Service 對象被創建，其類型為 NodePort。

這個 Service 配置了 port: 80（內部端口）、targetPort: 80（容器端口）以及 nodePort: 31000（外部節點端口）。selector: app=webapp 確保 Service 將流量導向標籤為 app=webapp 的 Pod。

當外部用戶通過 Web 瀏覽器訪問集群節點的 IP 地址加上 31000 端口時，流量會到達集群中的任一節點。節點上的 kube-proxy（未直接顯示，但其功能在此）會將流量轉發給 Service。Service 再根據其配置，將流量導向到後端標籤匹配的 Pod 的 targetPort。這樣，應用程式就成功地從集群外部被訪問到了。

使用 Helm 包管理器

到目前為止，我們已經學會了如何使用 kubectl 和 YAML 配置文件來部署應用程式和創建 Service。然而，在一個複雜的微服務架構中，管理大量的 YAML 文件可能會變得非常困難。

為了簡化這個過程，Kubernetes 提供了 Helm，這是一個強大的包管理器。Helm 使用戶能夠將 Kubernetes 應用程式及其所有相關資源打包成一個稱為「Chart」的單元，方便分發、安裝、升級和刪除。

Helm Charts 提供了模板化的 YAML 文件，允許用戶通過自定義值來配置應用程式的部署，而無需直接修改大量的 YAML 文件。這極大地提高了部署的效率和可維護性。

Helm 包管理器與公共 Chart 使用

本節將深入探討 Helm，作為 Kubernetes 的包管理器，以及如何利用公共 Helm Chart 來簡化應用程式的部署。

Helm 客戶端安裝

Helm 是一個強大的工具，用於管理 Kubernetes 應用程式的生命週期。自 Helm 3.0 版本以來，它已不再需要 Tiller 插件，而是以一個獨立的客戶端二進制文件形式存在，專注於打包、分發和部署 Kubernetes 應用程式。

  1. 安裝 Helm 客戶端: 建議參考 Helm 官方網站上的安裝文檔，該文檔提供了針對不同操作系統的詳細安裝步驟。例如，在 Windows 上，可以使用 Chocolatey 包管理器進行安裝：

    choco install kubernetes-helm -y

  2. 驗證 Helm 安裝: 安裝完成後，通過執行以下命令來驗證 Helm 客戶端是否已成功安裝：

    helm --help

    如果命令執行並顯示 Helm 的幫助信息，則表示安裝成功。

使用公共 Helm Chart

Helm Chart 是打包好的 Kubernetes 應用程式模板，其中包含了部署應用程式所需的所有 YAML 規格文件。使用 Chart 可以極大地簡化部署過程，無需手動編寫複雜的 YAML 文件。

  1. 搜索公共 Helm Chart: Helm Chart 可以在公共倉庫中找到，例如 Artifact Hub。要搜索 Chart，可以使用 helm search hub 命令。

    • 搜索所有 Chart: 
      helm search hub
    • 搜索特定應用程式的 Chart (例如 WordPress): 
      helm search hub wordpress

    這些命令會列出 Artifact Hub 中可用的 Chart。您可以通過指定應用程式名稱來縮小搜索範圍。

  2. 查看 Chart 詳細信息: 找到感興趣的 Chart 後，可以點擊其名稱查看詳細信息，包括當前版本、技術規格和安裝指南。

  3. 安裝 WordPress 應用程式: 為了演示，我們將使用 Bitnami 提供的 WordPress Chart 在本地 Kubernetes 集群中部署一個 WordPress 實例。

    • 添加 Bitnami Chart 倉庫: 首先，需要將 Bitnami 的 Helm Chart 倉庫添加到本地配置中： 
      helm repo add bitnami https://charts.bitnami.com/bitnami
    • 安裝 WordPress Chart: 然後，使用 helm install 命令來安裝 WordPress。<release name> 是您為此應用程式實例指定的名稱（例如 wpdemo），<package name> 是 Chart 的名稱（例如 bitnami/wordpress）。 
      helm install wpdemo bitnami/wordpress
      此命令會下載 Bitnami 的 WordPress Chart，並根據 Chart 中的模板生成 Kubernetes 資源（如 Deployment、Service、StatefulSet 等），然後將它們應用到您的 Kubernetes 集群中。

  4. 管理已安裝的 Chart:

    • 列出已安裝的 Chart: 要查看當前集群中已安裝的所有 Helm Release（即應用程式實例），可以使用： 
      helm ls
    • 刪除已安裝的 Chart: 如果您想移除一個應用程式及其所有相關 Kubernetes 組件，可以使用 helm delete 命令，後跟 Release 名稱： 
      helm delete wpdemo
      此命令會自動清理由該 Release 創建的所有 Kubernetes 資源。

視覺化 Helm Chart 安裝流程

以下圖示展示了使用 Helm 安裝 WordPress 應用程式的流程。

@startuml
!define DISABLE_LINK
!define PLANTUML_FORMAT svg
!theme _none_

skinparam dpi auto
skinparam shadowing false
skinparam linetype ortho
skinparam roundcorner 5
skinparam defaultFontName "Microsoft JhengHei UI"
skinparam defaultFontSize 16
skinparam minClassWidth 100

title Helm Chart Installation Workflow

component "Local Machine" {
  artifact "Terminal" as TERMINAL
  artifact "Helm Client" as HELM
  artifact "Kubernetes Cluster" as K8S
  artifact "Helm Repository (Bitnami)" as BITNAMI_REPO
}

component "Kubernetes Cluster" {
  artifact "API Server" as APISERVER
  artifact "Controller Manager" as CONTROLLER_MGR
  artifact "Scheduler" as SCHEDULER
  artifact "etcd" as ETCD
  artifact "Nodes" as NODES
}

TERMINAL --> HELM : `helm repo add bitnami ...`
HELM --> BITNAMI_REPO : Fetches Chart Index

TERMINAL --> HELM : `helm install wpdemo bitnami/wordpress`
HELM --> BITNAMI_REPO : Downloads WordPress Chart
HELM --> APISERVER : Submits Kubernetes Manifests (generated from Chart)

APISERVER --> ETCD : Stores Cluster State
CONTROLLER_MGR : Manages Deployment, StatefulSet, etc.
SCHEDULER : Assigns Pods to Nodes
NODES : Runs Application Pods (WordPress, Database)

HELM --> TERMINAL : `helm ls` (Lists Releases)
HELM --> TERMINAL : `helm delete wpdemo` (Deletes Release)

@enduml

看圖說話：

此圖示描繪了使用 Helm 安裝 WordPress Chart 的整個流程。首先，用戶在本地終端通過 helm repo add 命令將 Bitnami 的 Helm Chart 倉庫添加到本地配置中，Helm 客戶端從該倉庫獲取 Chart 的索引信息。

接著，用戶執行 helm install wpdemo bitnami/wordpress 命令。Helm 客戶端從 Bitnami 倉庫下載 WordPress Chart，並根據 Chart 中的模板和用戶提供的配置（如果有的話）生成一系列 Kubernetes 資源的 YAML 文件。隨後，Helm 將這些 YAML 文件提交給 Kubernetes API Server。

Kubernetes 的控制平面組件（API Server, Controller Manager, Scheduler）協同工作，根據這些 YAML 文件創建相應的 Kubernetes 對象，例如 Deployment、StatefulSet、Service 等，並最終在集群的節點上運行 WordPress 和其依賴的數據庫 Pod。

最後，用戶可以使用 helm ls 命令查看已安裝的 Release，並通過 helm delete 命令來移除應用程式及其所有關聯的 Kubernetes 組件。這個流程展示了 Helm 如何抽象化 Kubernetes 的部署細節，提供了一個更高效、更易於管理的應用程式部署方式。

結論

縱觀現代技術管理的演進軌跡，從手動編寫 YAML 到運用 Helm 包管理器，清晰地反映了從「執行細節」到「策略抽象」的價值躍遷。這不僅是工具的轉換，更是工程思維成熟度的體現，對於追求高效能與規模化的技術領導者而言，其中蘊含的管理智慧值得深思。

深入剖析這兩種部署路徑可以發現，直接使用 kubectl 與 YAML 文件，如同精通一門語言的基礎語法，它提供了最徹底的控制權與透明度，是理解系統運作原理的基石。然而，當面對複雜應用與多環境部署時，這種方式的重複勞動與潛在的人為失誤，將迅速累積為組織的「管理債」。Helm 的出現，則相當於提供了成熟的「文法框架」與「標準範本」。它將最佳實踐封裝為可重用的 Chart，使團隊能將精力從「如何部署」轉向「交付何種價值」，顯著提升了交付速度與一致性。這兩者並非對立，而是互補：對底層 YAML 的深刻理解，是駕馭與客製化 Helm Chart 的前提，避免將其用成一個無法掌控的黑盒子。

展望未來，技術領導的焦點將不僅是利用公共 Chart，而是建立組織內部的 Chart 倉庫，將團隊的部署經驗與安全規範沉澱為標準化的內部資產。這將是建構內部開發者平台（IDP）、降低開發團隊認知負荷的關鍵一步，也是技術管理從被動響應走向主動賦能的轉捩點。

綜合評估後，玄貓認為，對於高階技術管理者與架構師而言，真正的挑戰並非在 kubectl 與 Helm 之間做出非黑即白的選擇。核心任務應是建立一個分層的技術實踐體系：確保團隊具備紮實的底層知識，同時大力推動並投資於如 Helm 這類能實現標準化與規模化的抽象工具。唯有如此，才能在確保系統穩健的基礎上，最大化組織的創新動能與交付效率。

玄貓

玄貓

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