在上一篇文章中，我們介紹了 Kubernetes 中的 CNI 網路插件（Calico、Flannel、Cilium），並討論了不同網路模型的差異與應用。今天，我們將進一步探討 多環境部署 的實務需求，特別是 如何隔離 Dev、Staging、Prod，並以 Kubernetes 的工具（Namespace、ConfigMap、Kustomize）來展示一個實作範例。這篇文章的目標是讓你在日常開發到正式上線的過程中，能夠清楚地劃分環境，避免「一個指令誤刪正式環境」的悲劇。

為什麼需要多環境部署？

在 DevOps 流程中，常見的環境分層如下：

Dev（開發環境）

• 目的：快速開發、迭代，允許不穩定。
• 特點：高變動性、可能每天多次更新。

Staging（測試/驗證環境）

• 目的：模擬真實情境，驗證系統是否能正常運作。
• 特點：配置與 Prod 越接近越好，用來做壓測、整合測試。

Prod（正式環境）

• 目的：對外提供穩定服務。
• 特點：高可用性、安全性，強調穩定性。

常見問題場景

• 不同環境的 API endpoint、資料庫、憑證不同。
• 測試人員誤用了 Prod 資料。
• 沒有隔離的環境容易造成跨環境干擾。

多環境隔離方式

1. 基礎設施層級

不同 Cluster

• 完全獨立，最高安全性，但維運成本高。
  同一 Cluster 的不同 Namespace
• 較低成本，透過 Namespace 達到資源隔離。

2. 應用層級

• ConfigMap / Secret
  • 儲存不同環境的變數，例如 API_URL、DB_HOST。
• K8s Context
  • 使用 kubectl config use-context 切換，避免誤操作。
• ResourceQuota 與 LimitRange
  • 控制不同環境的資源用量。

3. 部署策略

• GitOps Branching
  • main → Prod
  • develop → Dev
  • release/* → Staging
• Helm / Kustomize
  • values-dev.yaml / values-staging.yaml / values-prod.yaml
  • overlays 隔離不同環境設定

Kubernetes 中的實作方式

使用 Namespace 隔離

建立三個 namespace：

kubectl create namespace dev
kubectl create namespace staging
kubectl create namespace prod

設定 RBAC 權限，避免開發者對 Prod 有過多操作權限。

使用 ConfigMap 與 Secret

不同環境的 API endpoint：

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: dev
data:
  API_URL: "http://dev.api.local"
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
  namespace: prod
data:
  API_URL: "https://api.prod.com"

使用 Kustomize overlays

資料夾結構

my-app/
├── base/
│   ├── deployment.yaml
│   └── service.yaml
└── overlays/
    ├── dev/
    │   └── kustomization.yaml
    ├── staging/
    │   └── kustomization.yaml
    └── prod/
        └── kustomization.yaml

base/deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  template:
    spec:
      containers:
      - name: my-app
        image: my-app:latest
        env:
        - name: API_URL
          value: "http://default"

overlays/dev/kustomization.yaml

bases:
  - ../../base
patchesStrategicMerge:
  - dev-env.yaml

overlays/dev/dev-env.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: my-app
        env:
        - name: API_URL
          value: "http://dev.api.local"

overlays/prod/prod-env.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 5
  template:
    spec:
      containers:
      - name: my-app
        env:
        - name: API_URL
          value: "https://api.prod.com"

部署指令

kubectl apply -k overlays/dev
kubectl apply -k overlays/staging
kubectl apply -k overlays/prod

小結

• 多環境部署的核心是 隔離 與 一致性管理。
• Cluster 隔離 安全但昂貴，Namespace 隔離 成本低但要搭配 RBAC。
• ConfigMap / Secret 管理環境變數，避免硬編碼。
• Kustomize / Helm 幫助管理多環境 YAML，配合 GitOps 自動化最佳。

在下一篇文章中，我們將延伸探討 ConfigMap 的細節與實務應用，並示範如何更有效率地管理設定檔。