Kustomize 輕鬆解決多環境 yaml 編排文件的管理

前言

18年那會、我學習了 docker，它利用集裝箱的思想，將依賴和運行環境打包成自包含、輕量級、可移植的容器，它給開發人員帶來的切實好處就是一次構建、到處運行，消除了開發、測試、生產環境不一致性。看完之後，不以爲然，真的可以完全消除各個環境的不一致性嗎？時至今日，Kubernetes 已經上生產，但是各個環境的不一致性，仍然沒有解決，大致問題就是，所有服務全部容器化不太現實，比如 MySql、Redis 等，這些服務本身已經存在現有的、穩定的部署方式，且這些服務是不怎麼變動的，當然可以使用 Kubernetes 把數據庫打成鏡像，通過有狀態服務資源對象編排，納入到 Kubernetes 集羣管理當中，實現動態擴縮容。但對於中小企業來說，最急切的還是自己業務，對於數據庫服務還是使用原有服務器部署，最大程度上降低研發成本。這就帶來了如下幾個問題：

• 其一、開發環境和測試環境連接的數據庫地址不是同一個，線上環境更是不同，每次上線都需要維護三份，甚至更多配置即 Kubernetes ConfigMap。

• 其二、通過鏡像解決了各個環境的打包問題，但是隨之而來的是大量 yaml 編排文件，編排文件如何管理？各個環境雖然鏡像一樣，但是配置參數可能不同，比如：開發一個副本，但是生產可能需要三個等等。

• 其三、yaml 配置較多，要麼一個個執行，或者單獨維護腳本批量執行 yaml。

爲了解決不同應用在不同環境中存在使用不同配置參數的複雜問題，容器的生態系統出現了 helm，它大大簡化了應用管理的難度，簡單來說，helm 類似於 Kubernetes 程序包管理器，用於應用的配置、分發、版本控制、查找等操作。它的核心功能是把 Kubernetes 資源對象（Deployment、ConfigMap、Service）打包到一個 Charts 中，製作完成各個 Charts 保存到 Chart 倉庫進行存儲和轉發，雖然 helm 可以解決 Kubernetes 資源對象生命週期管理以及通過模板的版本控制，但是 helm 使用起來複雜，只想管理幾個不同環境 yaml 配置，helm 搞了很多模板渲染等概念，且不支持多租戶，現在出了 helm v3 拋棄了tiller，同時引入了 lua，本想簡單解決 yaml 編排文件問題，卻引入更高的複雜度。

但云原生社區從來不會讓我們失望，隨之而來的，就是 Kustomize，只有一個 cli 工具，通過這個工具可以打包不同環境的配置，在 Kubernetes 1.14 版本之後，直接集成到 kubectl 命令中，通過執行 kubectl apply -k 命令就可以完成不同環境應用的打包，可以說相當簡單。下面對 Kustomize 進行介紹。

Kustomize 設計理念

Kustomize 允許用戶以一個應用描述文件 （YAML 文件）爲基礎（Base YAML），然後通過 Overlay 的方式生成最終部署應用所需的描述文件。兩者都是由 kustomization 文件表示。基礎（Base）聲明瞭共享的內容（資源和常見的資源配置），Overlay 則聲明瞭差異。它的設計目的是給 kubernetes 的用戶提供一種可以重複使用同一套配置的聲明式應用管理，從而在配置工作中用戶只需要管理和維護kubernetes的API對象，而不需要學習或安裝其它的配置管理工具，也不需要通過複製粘貼來得到新的環境的配置。

Kustomize 概念介紹

kustomize 中工具的聲明與規範是由名爲 kustomization.yaml 的文件定義，確保這三個文件與 kustomization.yaml 位於同一目錄下。示例如下：

commonLabels:
    app: hello
    resources:
    - deployment.yaml
    - configMap.yaml
    - service.yaml

kustomize 將會讀取聲明文件和 Kubernetes API 資源文件，將其組合然後將完整的資源進行標準化的輸出。輸出的文本可以被其他工具進一步處理(kustomize build)，或者直接通過 kubectl (kubectl apply -k .) 應用於集羣，兩種方式均可，不過 kubectl 要求 kubernetes 1.14 之上的版本。如果需要使用 kustomize 需要安裝 cli 命令行，安裝方式簡單https://github.com/kubernetes-sigs/kustomize/releases、自行下載二進制命令即可。

開發、測試和生產yaml配置舉例說明

具體目錄如下所示：

• 配置修改示例

其中 base 中存放的 deployment、service 就是我們平時常見 Kubernetes 資源對象，這部分通常是不變化的部分。除了這兩個之外，再加上 kustomization，它的作用是指定那些文件需要合併到一起，如下所示：

運行到 dev 目錄，如下所示：dev 目錄多出一個配置文件 yaml 這個配置適用於開發環境，執行[root@k8s-master dev]# kubectl apply -k . 既可以完成各個環境的配置和執行。其中 kustomization.yaml 內容如下所示：

其中 namePrefix 適用於資源名稱前綴，根據情況自行選擇是否添加。同樣的道理，測試和線上環境也可以通過這個過程完成配置的執行。

• 副本數量修改示例

deployment 運行 nginx 一個副本。

通過增加patch yaml 修改副本數量，如下所示：

添加 patch 策略，如下：

執行如下命令，從一個副本變成三個副本,如下所示：

kustomize 基本能夠滿足常用配置功能，具體特性如下所示：

總結

本文主要講解通過使用 kustomize 就可以管理任意數量的 Kubernetes 定製配置。kustomize 的每個產物都是純 YAML 的，這些文件可以存儲到 SVN 或者 github，甚至結合 helm 進行管理，最後通過自動化工作流自動拉取配置，完成這個過程的執行。更多文檔請參考 ^[1]

參考資料

[1]

更多文檔: https://github.com/kubernetes-sigs/kustomize

推薦閱讀

---

如何使用 Ingress-nginx 進行前後端分離？

深入探究 K8S ConfigMap 和 Secret

Kubernetes入門培訓（內含PPT）

從Ice到Kubernetes容器技術，微服務架構經歷了什麼？

---

原創不易，隨手關注或者”在看“，誠摯感謝！