介紹 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 中部署的補丁，僅修改副本計數以處理生產流量。

補丁作為部分部署規範，具有清晰的上下文和目的，即使它與其餘配置隔離讀取也可以進行驗證。它不僅僅是一個沒有上下文的{引數名，值}元組。

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

kustomize build someapp/overlays/production

結果以一組完整資源的形式列印到標準輸出，可隨時應用於叢集。類似的命令定義了暫存環境。

總結

使用 kustomize，您可以使用 Kubernetes API 資原始檔管理任意數量的獨特自定義 Kubernetes 配置。kustomize 使用的每個工件都是純 YAML，可以進行驗證和處理。kustomize 鼓勵 fork/modify/rebase 工作流。

要開始使用，請嘗試 hello world 示例。如需討論和反饋，請加入郵件列表或提交問題。歡迎提交拉取請求。

• ←上一篇
• 下一篇→