聊聊 Kubernetes 應用程式的三種配置管理方式

從虛擬機時代走到容器化的世界，很多過去習以為常的做法都行不通了。以前在 VM 上，設定檔丟到對應目錄就搞定，雖然不太規範但勉強能用。到了容器環境就不是這麼回事了——容器一重啟，裡面改過的東西全部消失，這是容器本身的設計哲學所決定的。所以我們得用更聰明的方式來處理應用程式的配置。

在 Kubernetes 的生態中，主流的配置管理做法大致有三種：

1. 使用 ConfigMap 來管理配置
2. 把設定檔直接打包進容器映像檔
3. 透過 Sidecar 模式注入配置

接下來我分別聊聊每種方式的實作思路和適用場景。

ConfigMap：K8s 原生的配置管理利器

ConfigMap 是 Kubernetes 自帶的配置管理機制，核心概念很直觀——把 ConfigMap 裡的內容映射成容器內的檔案或環境變數，讓應用程式直接讀取。

用法也不複雜，建立 ConfigMap 之後，在 Pod 規格中透過 volumeMounts 把配置掛載到容器指定路徑，或者用 configMapRef 注入為環境變數。以下用一個 Nginx 的範例來展示：

# 建立檔案類型的 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: nginx-vhost
data:
  vhost1.com.conf.template: |
    server {
        listen 80;
        server_name vhost1.com;
        location / {
            return 200 "hello, you are accessing vhost1.com by ${AUTHOR}@${REGION}";
        }
    }
  vhost2.com.conf.template: |
    server {
        listen 80;
        server_name vhost2.com;
        location / {
            return 200 "hello, you are accessing vhost2.com by ${AUTHOR}@${REGION}";
        }
    }
---
# 建立環境變數類型的 ConfigMap
apiVersion: v1
kind: ConfigMap
metadata:
  name: env-from-config
data:
  APP_NAME: nginx
  APP_VER: latest
  REGION: ap-shenzhen
  AUTHOR: ********
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          envFrom:
            # 以環境變數形式注入
            - configMapRef:
                name: env-from-config
          # 以檔案形式掛載到指定路徑
          volumeMounts:
            - mountPath: /etc/nginx/templates/
              name: vhosts-template
      volumes:
        - configMap:
            defaultMode: 420
            name: nginx-vhost
          name: vhosts-template
---
# 建立 ClusterIP Service 方便測試
apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  selector:
    app: nginx
  ports:
    - port: 80
      targetPort: 80

部署後實際測試，設定檔和環境變數都能正確生效。

不過要注意，如果團隊已經有成熟的配置發布系統，但還沒跟 K8s 整合，那用 ConfigMap 反而會增加管理負擔。

設定檔打包進映像檔：簡單暴力但有效

這個方式最直白——在 CI 建置流程中，把應用程式依賴的配置一起打包進容器映像檔。整個流程大致是：

這種做法的好處是映像檔拉下來就能直接跑，可移植性極佳（甚至直接用 docker run 就能啟動），而且灰度發布時如果發現配置有問題，直接回滾映像版本就行。缺點也很明顯：改個配置就要重新走一遍建置發布流程，完全不支援熱載入。所以這個方案特別適合配置不常變動的應用。

Sidecar 模式：當你需要即時下發配置

如果團隊有獨立的配置發布平台，而且平台有客戶端能做到即時下發和回滾，那 Sidecar 模式就是你的菜。原理是在同一個 Pod 裡多跑一個配置客戶端容器，透過 emptyDir 共享目錄讓主應用容器和配置客戶端容器共用同一個路徑。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:alpine
          volumeMounts:
            - mountPath: /etc/nginx/config.d/
              name: config-volume
        - name: config-client
          image: config-client:1.0
          volumeMounts:
            - mountPath: /data/config-client
              name: config-volume
      volumes:
        - name: config-volume
          emptyDir:
            sizeLimit: 10Mi

當配置平台下發新配置時，config-client 容器會寫入 /data/config-client。因為 nginx 容器的 /etc/nginx/config.d/ 跟它是同一個 Volume，所以 nginx 也能讀到最新的配置。

這個方案雖然有一定的複雜度，但能實現即時下發和回滾，在需要配置熱更新的場景下非常好用。

最後來個總結

如果你的應用配置不常改動，我會推薦用「配置打包進映像檔」的方式，不管是易用性還是部署彈性都很出色。即使面對多地域部署（每個地域配置不同），也可以把所有地域的配置都打包進去，再搭配環境變數來載入對應地域的設定。

Sidecar 模式則適合有配置熱載入需求的場景，而且可以跟「打包進映像檔」搭配使用，一個做兜底、一個做即時更新。

ConfigMap 對於還沒有統一配置中心的團隊算是不錯的起步方案，但隨著微服務模組越來越多，配置會分散在各個 Namespace 的 ConfigMap 中，不利於統一管理。建議前期先用 ConfigMap 撐著，後期可以考慮用 Git 託管的方式統一管理。