承接前一篇我們對 Helm values.yaml 的討論，今天我們要真正把平台實戰落地，就必須從 Helm Chart 開始說起。
不可避免地，我們先簡單介紹 Helm Chart。本質上，它是 Kubernetes 生態中的一個重要抽象，但切入點會依讀者背景有所不同：

• 如果你對 DevOps 或容器技術還陌生，可以從「什麼是容器」開始理解。
• 如果你已經操作過容器，也接觸過雲平台，下一步是理解 Kubernetes（k8s）。
• 如果你熟悉 k8s，甚至寫過 YAML 資源定義，那麼，相信 Helm Chart 對你並不陌生。

容器是什麼？

容器是一種建構在 Linux 核心機制上的「輕量虛擬機」，它讓我們能在同一台伺服器上高效地運行多個獨立的服務，彼此隔離卻又共享硬體資源。

Kubernetes 是什麼？

當容器數量快速增加，單靠人力與腳本管理資源、網路、調度就非常困難，這時候需要一個「中央管理平台」來統籌，Kubernetes 因此誕生。

Helm Chart 又是什麼？

Kubernetes 的操作核心是 YAML 檔案，用來描述各種「資源」（Resource）。
但當一個服務需要數十甚至上百個 YAML 才能完整部署時，維護就容易混亂。

Helm Chart 的出現，就是將這些資源「打包成套件」，並依規則自動部署，既避免衝突，又能實現一鍵安裝。

經過這層鋪墊，相信你已對容器、k8s 與 Helm Chart 的關係有初步感覺。接下來，我們重點來看 從宣告式配置角度理解 Helm 的運作。

一旦你實際寫過 k8s，你會發現：

• 配置檔裡充滿大量重複內容
• 很容易陷入縮排地獄
• 幾十、上百個 YAML 檔案需要協調管理

這時候自然會問：我能不能只關心「重要的部分」？ 例如，我只想決定服務名稱、需要的資源配額，剩下的細節能否交給模板處理？

範例：一個簡單的 K8s Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-service
  template:
    metadata:
      labels:
        app: my-service
    spec:
      containers:
      - name: my-service
        image: nginx:1.25
        resources:
          limits:
            cpu: "500m"
            memory: "256Mi"

這份檔案已超過 20 行，還只是最基本的 Deployment。

如果透過 Helm values.yaml 簡化

我們可以把核心關鍵抽出來：

replicaCount: 2
image:
  repository: nginx
  tag: "1.25"
resources:
  limits:
    cpu: "500m"
    memory: "256Mi"

此時，我只需要關注服務要有幾個 副本、要用哪個 容器映像檔、以及分配多少 資源。 至於那些繁瑣又重複的內容——例如符合 k8s 規範的欄位、層層縮排——全部都交由 Helm 自動生成。

• replicaCount：部署幾個副本做備援或負載平衡
• image：服務運行所需的容器鏡像
• resources：CPU 與 Memory 配額

很有趣，對吧？我們將「必要的資訊」提取出來，用它來驅動整個部署流程。 而在實作層面，Helm template 就像是一個 填空題，會把你的設定值逐一套進去。

範例：Helm template (簡化版)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ .Chart.Name }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ .Chart.Name }}
  template:
    metadata:
      labels:
        app: {{ .Chart.Name }}
    spec:
      containers:
      - name: {{ .Chart.Name }}
        image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
        resources:
          limits:
            cpu: {{ .Values.resources.limits.cpu }}
            memory: {{ .Values.resources.limits.memory }}

Helm template 就像一個 填空題，把你的設定值套入，省去繁瑣縮排與格式調整，確保部署穩定。
透過這種方式，Helm Chart 讓我們不必將心智消耗在那些繁瑣卻無須過度關注的細節上。
它能在前期就替我們把縮排與格式打好基礎，確保預設的結構穩固，即使後續因管理需求而調整設定，也不至於因格式錯誤而陷入混亂。

說回到我們的主題: 從宣告式配置理解helm的運作。
在工程領域，許多設定檔都是透過「宣告式配置」來完成的。這個概念在一般程式設計語言中不一定明顯，但如果你曾經寫過網頁，就會發現 HTML 本身也是一種宣告式標記語言。(兩者都是 ML 即 Markup Language )

這邊對兩者作一些比較:

這樣的對比可以讓曾寫過 HTML 的朋友一下子就感到親切。
此外，Helm 的運作還涉及渲染階段，以及輸入內容通常被限定為文字等特性，這些細節會在後續章節進一步探討。

結尾與展望

今天我們主要掌握了：

• 容器、Kubernetes 與 Helm Chart 的基本概念
• 如何用 Helm values.yaml 提取核心設定，簡化 Deployment
• Helm template 的宣告式運作方式，以及它與 HTML 的類比

透過這些理解，相信大家已經對 Helm 的運作有初步概念。
下一篇，我們將進一步探討 Helm 的 渲染流程與進階模板技巧，學習如何更靈活地設計變數，以更優雅的方式管理服務。

感謝各位閱讀，我們明天見！