介紹 kustomize；適用於 Kubernetes 的免範本配置自訂

如果您執行 Kubernetes 環境，很可能已經自訂了 Kubernetes 設定 — 您複製了一些 API 物件 YAML 檔案，並編輯它們以符合您的需求。

但這種方法存在缺點 — 可能難以回到原始素材並納入對其所做的任何改進。今天，Google 宣布 kustomize，這是一個命令列工具，作為 子專案 貢獻於 SIG-CLI。該工具提供了一種新的、純粹宣告式的方法來進行組態自訂，這種方法符合並利用了熟悉且經過精心設計的 Kubernetes API。

這是一個常見的場景。在網路上某處，您找到某人針對內容管理系統的 Kubernetes 設定。它是一組包含 Kubernetes API 物件 YAML 規格的檔案。然後，在您自己公司的某個角落，您找到一個用於支援該 CMS 的資料庫設定 — 您偏好該資料庫，因為您很熟悉它。

您想要以某種方式一起使用它們。此外，您想要自訂檔案，以便您的資源實例在叢集中顯示一個標籤，將它們與在同一個叢集中做同樣事情的同事的資源區分開來。您還想要為 CPU、記憶體和副本計數設定適當的值。

此外，您還想要整個組態的多個變體：一個用於測試和實驗的小型變體（就使用的運算資源而言），以及一個用於為外部生產使用者提供服務的更大變體。同樣地，其他團隊也會想要他們自己的變體。

這引發了各種問題。您是否將組態複製到多個位置並獨立編輯它們？如果您有數十個開發團隊需要堆疊的略有不同的變體，該怎麼辦？您如何維護和升級它們共用的組態方面？使用 kustomize 的工作流程為這些問題提供了答案。

自訂即是重複使用

Kubernetes 組態不是程式碼（作為 API 物件的 YAML 規格，它們更嚴格地被視為資料），但組態生命週期與程式碼生命週期有許多相似之處。

您應該將組態保留在版本控制中。組態擁有者不一定是與組態使用者相同的一群人。組態可以用作較大整體的一部分。使用者會想要為了不同目的重複使用組態。

與程式碼重複使用一樣，一種組態重複使用的方法是簡單地複製所有組態並自訂副本。與程式碼一樣，切斷與原始素材的連線會使其難以從原始素材的持續改進中受益。對於許多團隊或環境，每個團隊或環境都有其自己的組態變體，採用這種方法會使簡單的升級變得棘手。

另一種重複使用的方法是將原始素材表示為參數化範本。工具處理範本 — 執行任何嵌入式腳本並將參數替換為所需的值 — 以產生組態。重複使用來自於將不同的值集與相同的範本一起使用。此處的挑戰在於範本和值檔案不是 Kubernetes API 資源的規格。它們必然是新的事物、一種新的語言，封裝了 Kubernetes API。是的，它們可能很強大，但會帶來學習和工具成本。不同的團隊想要不同的變更 — 因此幾乎所有您可以包含在 YAML 檔案中的規格都會變成需要值的參數。因此，值集變得很大，因為必須指定所有參數（沒有可信任的預設值）以進行替換。這破壞了重複使用的一個目標 — 在沒有完整資源宣告的情況下，保持變體之間的差異尺寸小且易於理解。

組態自訂的新選項

將其與 kustomize 進行比較，其中工具的行為由名為 kustomization.yaml 的檔案中表示的宣告式規格決定。

kustomize 程式讀取檔案及其引用的 Kubernetes API 資源檔案，然後將完整的資源發送到標準輸出。此文字輸出可以由其他工具進一步處理，或直接串流到 kubectl 以應用於叢集。

例如，如果名為 kustomization.yaml 的檔案包含

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

位於目前的工作目錄中，以及它提及的三個資源檔案，然後執行

kustomize build

發出一個 YAML 串流，其中包含三個給定的資源，並為每個資源新增一個通用標籤 app: hello。

同樣地，您可以使用 commonAnnotations 欄位為所有資源新增註解，並使用 namePrefix 欄位為所有資源名稱新增通用前綴。這種微不足道但常見的自訂僅僅是開始。

更常見的用例是，您需要一組常見資源的多個變體，例如開發、預備和生產變體。

為此，kustomize 支援覆蓋和基礎的概念。兩者都由一個 kustomization 檔案表示。基礎宣告變體共用的事物（資源和對這些資源的通用自訂），而覆蓋宣告差異。

以下是管理給定叢集應用程式的預備和生產變體的文件系統佈局

   someapp/
   ├── base/
   │   ├── kustomization.yaml
   │   ├── deployment.yaml
   │   ├── configMap.yaml
   │   └── service.yaml
   └── overlays/
      ├── production/
      │   └── kustomization.yaml
      │   ├── replica_count.yaml
      └── staging/
          ├── kustomization.yaml
          └── cpu_count.yaml

檔案 someapp/base/kustomization.yaml 指定通用資源和對這些資源的通用自訂（例如，它們都獲得一些標籤、名稱前綴和註解）。

someapp/overlays/production/kustomization.yaml 的內容可能是

   commonLabels:
    env: production
   bases:
   - ../../base
   patches:
   - replica_count.yaml

此 kustomization 指定一個修補程式檔案 replica_count.yaml，它可能是

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: the-deployment
   spec:
     replicas: 100

修補程式是部分資源宣告，在本例中是 someapp/base/deployment.yaml 中部署的修補程式，僅修改 replicas 計數以處理生產流量。

修補程式是部分部署規格，具有明確的上下文和目的，即使從剩餘組態中隔離讀取，也可以進行驗證。它不僅僅是一個無上下文的 {參數名稱、值} 元組。

若要建立生產變體的資源，請執行

kustomize build someapp/overlays/production

結果作為一組完整資源列印到 stdout，準備應用於叢集。類似的命令定義了預備環境。

總結

使用 kustomize，您可以使用僅 Kubernetes API 資源檔案管理任意數量的不同自訂 Kubernetes 組態。kustomize 使用的每個構件都是純 YAML，並且可以像這樣進行驗證和處理。kustomize 鼓勵 fork/modify/rebase 工作流程。

若要開始使用，請嘗試 hello world 範例。如需討論和意見回饋，請加入 郵件列表 或 開啟問題。歡迎提交提取請求。

• ←上一篇
下一篇→