筆記。 翻譯。:本文由 Scott Lowe 撰寫,他是一位在 IT 領域擁有豐富經驗的工程師,也是七本印刷書籍的作者/合著者(主要是關於 VMware vSphere)。 他現在任職於VMware子公司Heptio(2016年被收購),專門從事雲端運算和Kubernetes。 文本本身就是對 Kubernetes 使用技術進行設定管理的簡潔易懂的介紹
Kustomize 是一個工具,允許使用者「為不同的目的自訂簡單、無模板的 YAML 文件,使原始 YAML 保持完整和可用」(描述直接借自 kubectl -k
存取其功能(儘管從 Kubernetes 1.15 開始,單獨的二進位檔案比 kubectl 中內建的功能更新)。 (筆記。 翻譯。: 隨著最近的發布
在最簡單的形式/應用程式中,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 圖表 .
筆記。 翻譯。:您也可以推薦發佈為的連結區塊
如果您對改進本資料有疑問或建議,我隨時歡迎回饋。 您可以透過以下方式聯絡我
譯者PS
另請閱讀我們的博客:
- «
為 Kubernetes 上運行的應用程式開發人員提供的工具 “; - «
Kubernetes 1.14:主要創新概述 “; - «
2019 年阿姆斯特丹 Helm 高峰會的五項主要成果 “; - «
Kubernetes 套件管理器實用介紹 - Helm “。
來源: www.habr.com