Kustomize 簡介

筆記。 翻譯。：本文由 Scott Lowe 撰寫，他是一位在 IT 領域擁有豐富經驗的工程師，也是七本印刷書籍的作者/合著者（主要是關於 VMware vSphere）。 他現在任職於VMware子公司Heptio（2016年被收購），專門從事雲端運算和Kubernetes。 文本本身就是對 Kubernetes 使用技術進行設定管理的簡潔易懂的介紹 客製化，最近成為 K8s 的一部分。

Kustomize 是一個工具，允許使用者「為不同的目的自訂簡單、無模板的 YAML 文件，使原始 YAML 保持完整和可用」（描述直接借自 GitHub 上的 kustomize 儲存庫）。 Kustomize 可以直接運行，或從 Kubernetes 1.14 開始使用 kubectl -k 存取其功能（儘管從 Kubernetes 1.15 開始，單獨的二進位檔案比 kubectl 中內建的功能更新）。 (筆記。 翻譯。: 隨著最近的發布 庫伯內斯 1.16 客製化 支持 也在 kubeadm 實用程式中。） 在這篇文章中，我想向讀者介紹 kustomize 的基礎。

在最簡單的形式/應用程式中，kustomize 只是資源的集合（定義 Kubernetes 物件的 YAML 檔案：部署、服務等）以及需要對這些資源進行更改的指令清單。 正如 make 使用包含在中的指令集一樣 Makefile，並且 Docker 根據以下指令建構容器 Dockerfile,客製化用途 kustomization.yaml 儲存有關使用者想要對一組資源進行哪些變更的說明。

這是一個範例文件 kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

我不會嘗試討論文件中所有可能的字段。 kustomization.yaml （這寫得很好 這裡），但我會用一個具體的例子來簡單解釋：

• 領域 resources 指示 kustomize 的內容（哪些資源）將會改變。 在這種情況下，它將在文件中找到資源 deployment.yaml и service.yaml 在您的目錄中（如有必要，您可以指定完整或相對路徑）。
• 領域 namePrefix 指示 kustomize 新增特定前綴（在本例中 - dev-) 屬性 name 字段中定義的所有資源 resources。 因此，如果 Deployment 有 name 有意義 nginx-deployment，客製化就可以了 dev-nginx-deployment.
• 領域 namespace 指示 kustomize 將給定命名空間新增至所有資源。 在這種情況下，Deployment和Service將落入命名空間 development.
• 最後是田野 commonLabels 包含一組將新增至所有資源的標籤。 在我們的範例中，kustomize 將為具有名稱的資源分配一個標籤 environment 和意義 development.

如果用戶這樣做 kustomize build . 在包含該檔案的目錄中 kustomization.yaml 以及必要的資源（即文件 deployment.yaml и service.yaml），然後在輸出處它將收到一個文本，其中指定的更改 kustomization.yaml.

筆記。 翻譯。：專案文件中有關 kustomize「簡單」使用的插圖

如果需要提交更改，可以重定向輸出：

kustomize build . > custom-config.yaml

輸出資料是確定性的（相同的輸入資料將產生相同的輸出結果），因此您不必將結果儲存到檔案中。 相反，它可以直接傳遞給另一個命令：

kustomize build . | kubectl apply -f -

還可以透過以下方式存取 kustomize 功能 kubectl -k （自 Kubernetes 版本 1.14 起）。 但是，請記住，獨立的 kustomize 套件的更新速度比整合的 kubectl 套件更快（至少 Kubernetes 1.15 版本是這樣）。

讀者可能會問：“如果可以直接編輯文件，為什麼還要這麼複雜？” 很好的問題。 在我們的例子中，確實 人們可以 修改文件 deployment.yaml и service.yaml 直接，但如果它們是其他專案的分支怎麼辦？ 當對來源/來源進行更改時，直接更改檔案會使重新設定分支變得困難（如果不是不可能的話）。 使用 kustomize 允許您將這些變更集中在一個檔案中 kustomization.yaml，保持原始文件完整，從而在必要時更容易重新調整原始文件的基礎。

kustomize 的好處在更複雜的用例中變得顯而易見。 在上面的例子中 kustomization.yaml 且資源都在同一個目錄下。 但是，kustomize 支援存在基本配置及其許多變體的用例，也稱為 覆蓋。 例如，使用者想要採用我用作範例的 nginx 的部署和服務，並建立這些文件的開發、暫存和生產版本（或變體）。 為此，他需要上述覆蓋層，實際上還需要基本資源本身。

來說明overlays和底層資源的思想 （基礎資源），我們假設目錄具有以下結構：

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

在文件中 base/kustomization.yaml 使用該欄位的用戶 resources 只需聲明 kustomize 應包含的資源即可。

在每個文件中 overlays/{dev,staging,prod}/kustomization.yaml 使用者參考現場基本配置 resources，然後指出具體更改 給定環境。 例如，文件 overlays/dev/kustomization.yaml 可能類似前面給出的範例：

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

在這種情況下，文件 overlays/prod/kustomization.yaml 可能完全不同：

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

當用戶運行時 kustomize build . 在目錄中 overlays/dev, kustomize 將產生開發選項。 如果你跑 kustomize build . 在目錄中 overlays/prod - 您可以獲得生產選項。 而這一切——無需對原始內容進行任何更改 （根據） 文件，全部以聲明性和確定性的方式。 您可以將基本配置和覆蓋目錄直接提交到版本控制，因為您知道基於這些文件您可以隨時重現所需的配置。

筆記。 翻譯。：專案文件中有關在 kustomize 中使用疊加層的插圖

客製化即可 戈拉澤多 比本文涵蓋的內容還要多。 不過，我希望它能作為一個很好的介紹。

其他資源

有很多關於 kustomize 的好文章和出版物。 以下是我發現特別有用的內容：

• 使用 Kustomize 變更不同環境生產/測試的基本 YAML 配置;
• Kustomize－在 Kubernetes 中進行模板化的正確方法;
• 使用自訂對 Kubernetes 物件進行聲明式管理;
• 使用 Customize 自訂上游 Helm 圖表.

筆記。 翻譯。：您也可以推薦發佈為的連結區塊 資源 在該實用程式的網站上，隨後是一系列視頻，其中包含有關 kustomize 的最新報告。

如果您對改進本資料有疑問或建議，我隨時歡迎回饋。 您可以透過以下方式聯絡我 Twitter 或 Kubernetes Slack 頻道。 享受使用 kustomize 修改清單的樂趣！

譯者PS

另請閱讀我們的博客：

• «為 Kubernetes 上運行的應用程式開發人員提供的工具“;
• «Kubernetes 1.14：主要創新概述“;
• «2019 年阿姆斯特丹 Helm 高峰會的五項主要成果“;
• «Kubernetes 套件管理器實用介紹 - Helm“。

來源： www.habr.com