Kubernetes部署救星：用Kustomize管理多環境設定的實戰指南

Kustomize如何拯救了關鍵部署日——一位DevOps工程師的實戰紀錄

## 生死時速的部署任務
那個週一早晨，Alex端著咖啡走進辦公室，正準備迎接新的一週。作為CloudSpeed這家快速成長科技公司的新任DevOps工程師，Alex還在熟悉工作節奏。"Alex！出大事了！"資深開發工程師Jamie慌張地衝進走廊，臉色發青："我們今天必須把應用程式部署到三個不同環境——開發、預發和生產環境，而且每個環境都需要不同的設定！執行長的產品演示四小時後就要開始了！"

Alex感覺背脊冒出冷汗。在CloudSpeed他們確實都用Kubernetes做部署，但Alex之前只接觸過基礎的YAML檔案。要在短時間內處理不同環境的差異化設定，還不能把配置搞得一團亂？這時Alex突然想起前陣子技術研討會聽到的神器——Kustomize。"別擔心Jamie，我大概知道用什麼工具能搞定..."

## Kustomize到底是什麼？
在我們揭曉Alex如何化解危機前，先來簡單理解這個救命工具：Kustomize是內建在Kubernetes裡的配置管理工具（透過`kubectl`指令就能呼叫），它最厲害的地方在於能用"基底配置+環境覆寫"的聰明方式，讓工程師不必為了不同環境維護多套幾乎相同的YAML檔案。

「這工具能幫你針對不同環境調整 Kubernetes 的 YAML 檔案，不用每次都複製貼上又手動修改。想像你在做菜——原本有個基礎食譜（就是你的原始 YAML），但可能A朋友喜歡重辣、B團體要減鹽、C場合需要雙倍份量。Kustomize 讓你只要在原始食譜旁註明各版本修改處，不用重寫三份完全不同的食譜。」

### Alex 的 Kustomize 探險記
#### 第一步：整理檔案結構
Alex 在電腦上建了個簡單的資料夾架構：

k8s-deploy/  

  base/  

    deployment.yaml  

    service.yaml  

    kustomization.yaml  

  overlays/  

    dev/  

      kustomization.yaml  

    staging/  

      kustomization.yaml  

    production/  

      kustomization.yaml  

「搞這麼多資料夾是要幹嘛啦？」Jamie 盯著螢幕一臉困惑。

（補充說明：Kustomize 的核心概念在於「基礎配置」與「環境疊加層」的分離——base 目錄存放原始設定，而 overlays 下的 dev/staging/production 則像透明投影片，一層層疊加修補參數。常見操作包含替換 ConfigMap 數值、動態生成 Secret，或用前綴標記區分不同環境的資源名稱，讓管理多套設定像換調味料一樣直覺。）

Alex 解釋道：「『base』資料夾會放我們標準的部署檔案，就像是適用所有環境的基礎配方。至於『overlays』資料夾嘛，我們只要針對不同環境疊加調整就好，比方說『多加點香料』或『把份量加大』這種小修改。」

### 第二步：建立基底設定
Alex 先從建立基礎部署檔案開始，這些設定在所有環境都會保持一致：

在 `base/deployment.yaml` 裡：

apiVersion: apps/v1

kind: Deployment

metadata:

  name: cloudspeed-app

spec:

  replicas: 1

  selector:

    matchLabels:

      app: cloudspeed

  template:

    metadata:

      labels:

        app: cloudspeed

    spec:

      containers:

      - name: app

        image: cloudspeed/app:latest

        ports:

        - containerPort: 8080

        env:

        - name: LOG_LEVEL

          value: "info"

在 `base/service.yaml` 中：

apiVersion: v1

kind: Service

metadata:

  name: cloudspeed-service

spec:

  selector:

    app: cloudspeed

  ports:

  - port: 80

    targetPort: 8080

  type: ClusterIP

最後在 `base/kustomization.yaml` 裡加上這段：

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

resources:

- deployment.yaml

- service.yaml

「這些就是我們的基底配置啦，」Alex邊操作邊說明，「這邊定義了一個使用最新版映像檔的單副本部署，還有負責導流量的基本服務。」### 第三步：針對不同環境客製化接著重頭戲來了。Alex開始建立覆蓋層檔案來調整各環境設定。先來看開發環境的 `overlays/dev/kustomization.yaml`：

apiVersion: kustomize.config.k8s.io/v1beta1

kind: Kustomization

bases:

- ../../base

namePrefix: dev-

patches:

- patch: |-

    - op: replace

      path: /spec/template/spec/containers/0/image

      value: cloudspeed/app:dev

  target:

    kind: Deployment

「這個設定檔的意思是：沿用基底配置的所有內容，但要把資源名稱前面都加上『dev-』前綴，」Alex停頓了一下補充道，「還有映像檔也要改用開發版標籤，別用預設的 latest 版。」

在 `overlays/staging/kustomization.yaml` 中，Alex 指出：「對於暫存環境，我們使用兩個副本而不是一個，並且映像檔為 'staging'。」相對地，在生產環境的 `overlays/production/kustomization.yaml` 中，他補充說道：「在生產環境，我們有三個副本，使用我們的 'stable' 映像，同時將日誌設置為 'warn' 而不是 'info'，並使服務可以通過 LoadBalancer 從外部訪問。」

### 第四步：部署到不同環境

這一刻終於來了。Alex 準備好要部署到所有三個環境。對於 **開發** 環境，他執行了：

kubectl apply -k overlays/dev

而對於 **暫存** 環境則是：

kubectl apply -k overlays/staging

最後是 **生產** 環境：

kubectl apply -k overlays/production

「就這樣？」Jamie 詢問道，有些驚訝。「你不需要為每個環境修改文件嗎？」

「不用！」Alex 露出了微笑。「Kustomize 自動處理這些。我們只需將基礎文件與覆蓋層結合起來，再應用結果。如果想先查看更改，可以運行 `kubectl kustomize overlays/dev` 來確認。」

## Kustomize 的優勢場景

隨著部署成功完成，Alex 和 Jamie 開始走回他們的桌子。在路上，Alex 更進一步解釋了 Kustomize 能幫助解決的各種情況。

### 情境一：針對不同區域的配置設定
「假設我們需要在美國、歐洲和亞洲這些不同區域部署應用程式，」Alex解釋道，「每個區域可能需要不同的資料庫連線或API端點設定。」

overlays/  

  us/  

    kustomization.yaml  

  europe/  

    kustomization.yaml  

  asia/  

    kustomization.yaml  

在每個區域的覆蓋層中，可以加入指向當地服務的環境變數：

patches:  

- patch: |-  

    - op: add  

      path: /spec/template/spec/containers/0/env/-  

      value:  

        name: DATABASE_URL  

        value: "db.us-east.example.com"  

  target:  

    kind: Deployment  

### 情境二：差異化的資源需求
「那如果我們的應用在不同環境需要不同的CPU和記憶體配置呢？」Jamie提出疑問。

這時候可以透過覆蓋層調整資源限制，例如在生產環境的配置中增加資源請求量，同時為測試環境保留較寬鬆的設定。這種做法不僅能讓每個環境獲得適配的運算資源，還能避免開發階段過度消耗基礎設施成本。

「這根本是 Kustomize 的絕佳應用場景嘛！」Alex 興奮地回應道，「我們可以在每個 overlay 裡設定不同的資源請求與限制。」

舉例來說，在 **開發環境** 的設定中：

patch:

- patch: |-

    - op: add

      path: /spec/template/spec/containers/0/resources

      value:

        requests:

          memory: "256Mi"

          cpu: "100m"

        limits:

          memory: "512Mi"

          cpu: "200m"

  target:

    kind: Deployment

至於 **正式環境** 則會這樣配置：

patch:

- patch: |-

    - op: add

      path: /spec/template/spec/containers/0/resources

      value:

        requests:

          memory: "1Gi"

          cpu: "500m"

        limits:

          memory: "2Gi"

          cpu: "1000m"

  target:

    kind: Deployment

透過這種分層配置的方式，Kustomize 讓我們能輕鬆管理不同環境的細微差異。像這樣用 patch 功能來調整資源配置，既保持基礎設定的統一性，又能針對特定環境做精細調校，實際操作起來真的挺方便的。

### 情境三：添加環境特定組件
「有時候我們會需要在特定環境多加些組件，」Alex接著說明，「比方說在生產環境可能需要監控工具，但開發環境就不必了。」

在**生產環境**的 overlay 中，你可以這樣設定：

apiVersion: kustomize.config.k8s.io/v1beta1  

kind: Kustomization  

bases:  

- ../../base  

resources:  

- monitoring.yaml  

同時別忘了在生產環境的 overlay 資料夾裡新增一個 `monitoring.yaml` 檔案，用來定義監控相關的配置。

### 情境四：不同環境的密鑰管理方式
「安全性也很重要，」Jamie 補充道，「那在不同環境中該怎麼處理敏感資訊呢？」

"「我們可以用 Kustomize 的 secretGenerator 來處理，」Alex 一邊解釋，一邊快速寫了個範例：\n

\nsecretGenerator:\n- name: app-secrets\n  literals:\n  - api_key=dev-dummy-key\n

\n至於生產環境嘛，這邊會有點不同：\n

\nsecretGenerator:\n- name: app-secrets\n  literals:\n  - api_key=${PRODUCTION_API_KEY}\n

\n「生產環境的金鑰可以從環境變數注入，這樣原始碼庫裡就不會殘留敏感資料，」Alex 補充道。\n## 圓滿收工\n時間接近下午兩點 CEO 演示的時刻，Alex 和 Jamie 靠著椅背，盯著監控儀表板。三套環境都運作得很順暢，各自掛載著符合環境特性的設定檔。"

「我真不敢相信這麼簡單。」傑米說。「之前我們每個環境都要複製和粘貼YAML檔案，還得記住所有的差異。」 「這就是Kustomize的美妙之處。」亞歷克斯回應道。「它內建於Kubernetes中，我們不需要額外的工具。它讓我們的基本配置保持整潔，也讓各環境之間的差異變得清晰易管理。」 首席執行官的演示非常成功。他能在一個早上展示開發版本（帶有最新功能）、正在測試的預備版本，以及客戶正在使用的生產版本。「亞歷克斯，」傑米在演示結束後慶祝時說，「你剛剛改變了我們部署的方式，永遠地。」

## Kustomize 與 Helm 的比較

### 可以同時使用嗎？可以！許多團隊會選擇：
- **Helm** 用於第三方應用程序和打包解決方案
- **Kustomize** 則用於自己的應用或自定義Helm圖表

你甚至可以使用Kustomize來自定義Helm圖表輸出的結果，以便充分利用兩者的優勢。
- **Kustomize**：簡單、內建、使用補丁，適合自己的應用及特定環境中的變更
- **Helm**：強大、基於包裝，包括模板化和版本控制，非常適合第三方應用與複雜部署

根據你的具體需求、團隊專業知識以及要部署的應用類型進行選擇，沒有放之四海而皆準的方法！

## 重要要點：為何 Kustomize 對 DevOps 有利

1. **避免重複**：只需編寫一次基本YAML，只需指定每個環境中的差異。
2. **內建工具**：Kustomize隨 Kubernetes附帶 - 無需安裝額外軟件。
3. **易於理解**：資料夾結構讓標準內容與特定環境內容一目瞭然。
4. **友好於Git**：對某一環境所做的更改不會影響其他環境文件，使版本控制更加乾淨。
5. **良好的擴展性**：無論你有三個還是三十個環境，都能採取相同的方法。

下次當你發現自己在不同環境中復制粘貼Kubernetes YAML文件時，不妨想起亞歷克斯的故事。Kustomize正等待著幫助你拯救部署日！