Kustomize如何輕松解決多環(huán)境及yaml 編排文件的管理

前言

18年那會、我學(xué)習(xí)了 docker，它利用集裝箱的思想，將依賴和運行環(huán)境打包成自包含、輕量級、可移植的容器，它給開發(fā)人員帶來的切實好處就是一次構(gòu)建、到處運行，消除了開發(fā)、測試、生產(chǎn)環(huán)境不一致性?？赐曛螅灰詾槿?，真的可以完全消除各個環(huán)境的不一致性嗎？時至今日，Kubernetes 已經(jīng)上生產(chǎn)，但是各個環(huán)境的不一致性，仍然沒有解決，大致問題就是，所有服務(wù)全部容器化不太現(xiàn)實，比如 MySql、Redis 等，這些服務(wù)本身已經(jīng)存在現(xiàn)有的、穩(wěn)定的部署方式，且這些服務(wù)是不怎么變動的，當(dāng)然可以使用 Kubernetes 把數(shù)據(jù)庫打成鏡像，通過有狀態(tài)服務(wù)資源對象編排，納入到 Kubernetes 集群管理當(dāng)中，實現(xiàn)動態(tài)擴(kuò)縮容。但對于中小企業(yè)來說，最急切的還是自己業(yè)務(wù)，對于數(shù)據(jù)庫服務(wù)還是使用原有服務(wù)器部署，最大程度上降低研發(fā)成本。這就帶來了如下幾個問題：

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

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

• 其三、yaml 配置較多，要么一個個執(zhí)行，或者單獨維護(hù)腳本批量執(zhí)行 yaml。

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

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

Kustomize 設(shè)計理念

Kustomize 允許用戶以一個應(yīng)用描述文件 （YAML 文件）為基礎(chǔ)（Base YAML），然后通過 Overlay 的方式生成最終部署應(yīng)用所需的描述文件。兩者都是由 kustomization 文件表示?；A(chǔ)（Base）聲明了共享的內(nèi)容（資源和常見的資源配置），Overlay 則聲明了差異。它的設(shè)計目的是給 kubernetes 的用戶提供一種可以重復(fù)使用同一套配置的聲明式應(yīng)用管理，從而在配置工作中用戶只需要管理和維護(hù)kubernetes的API對象，而不需要學(xué)習(xí)或安裝其它的配置管理工具，也不需要通過復(fù)制粘貼來得到新的環(huán)境的配置。

Kustomize 概念介紹

kustomize 中工具的聲明與規(guī)范是由名為 kustomization.yaml 的文件定義，確保這三個文件與 kustomization.yaml 位于同一目錄下。示例如下：

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

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

開發(fā)、測試和生產(chǎn)yaml配置舉例說明

具體目錄如下所示：

 

• 配置修改示例

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

 

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

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

• 副本數(shù)量修改示例

deployment 運行 nginx 一個副本。

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

 

添加 patch 策略，如下：

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

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

本文主要講解通過使用 kustomize 就可以管理任意數(shù)量的 Kubernetes 定制配置。kustomize 的每個產(chǎn)物都是純 YAML 的，這些文件可以存儲到 SVN 或者 github，甚至結(jié)合 helm 進(jìn)行管理，最后通過自動化工作流自動拉取配置，完成這個過程的執(zhí)行。