Customize の簡単な紹介

ノート。 翻訳。: この記事は、IT 分野で豊富な経験を持つエンジニア、Scott Lowe によって執筆されました。彼は 2016 冊の書籍 (主に VMware vSphere) の著者/共著者です。 彼は現在、VMware の子会社である Heptio (XNUMX 年に買収) で働いており、クラウド コンピューティングと Kubernetes を専門としています。 テキスト自体は、テクノロジを使用した Kubernetes の構成管理についての簡潔でわかりやすい入門書として機能します。 カスタマイズ、最近 K8 の一部になりました。

KusTOMize は、ユーザーが「元の YAML をそのままにして使用可能なままにして、さまざまな目的に合わせてシンプルでテンプレートのない YAML ファイルをカスタマイズする」ことを可能にするツールです (説明は次から直接借用しました) GitHub 上のリポジトリをカスタマイズする）。 KusTOMize は直接実行することも、Kubernetes 1.14 以降では使用することもできます。 kubectl -k その機能にアクセスするには (ただし、Kubernetes 1.15 の時点では、別個のバイナリは kubectl に組み込まれている機能よりも新しいです)。 (ノート。 翻訳。：そして最近のリリースでは Kubernetes 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。 したがって、デプロイメントが 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 -

カスタマイズ機能には、次からもアクセスできます。 kubectl -k (Kubernetes バージョン 1.14 以降)。 ただし、スタンドアロンの kusTOMize パッケージは、統合された kubectl パッケージよりも速く更新されることに注意してください (少なくとも Kubernetes 1.15 リリースの場合はこれに当てはまります)。

読者は、「ファイルを直接編集できるのに、なぜこんなに複雑になるのですか?」と疑問に思うかもしれません。 素晴らしい質問です。 私たちの例では、確かに 1ことができます ファイルを変更する deployment.yaml и service.yaml 直接的にはそうなりますが、他の人のプロジェクトのフォークである場合はどうなるでしょうか? ファイルを直接変更すると、オリジン/ソースに変更が加えられたときにフォークをリベースすることが (不可能ではないにしても) 困難になります。 kusTOMize を使用すると、これらの変更をファイルに一元管理できます。 kustomization.yaml、元のファイルはそのまま残るため、必要に応じて元のファイルをリベースするのが簡単になります。

kusTOMize の利点は、より複雑なユースケースで明らかになります。 上の例では kustomization.yaml リソースは同じディレクトリにあります。 ただし、kusTOMize は、基本構成とその多くのバリアント (別名: とも呼ばれる) が存在するユースケースをサポートします。 オーバーレイ。 たとえば、あるユーザーは、例として使用した nginx のデプロイメントとサービスを取り上げ、それらのファイルの開発、ステージング、および運用バージョン (またはバリアント) を作成したいと考えています。 これを行うには、上記のオーバーレイと、実際には基本的なリソース自体が必要です。

オーバーレイと基礎となるリソースの概念を説明するため (基本リソース)では、ディレクトリが次のような構造になっていると仮定します。

- 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 でテンプレートを作成する正しい方法;
• Customize を使用した Kubernetes オブジェクトの宣言的管理;
• Customize を使用したアップストリーム Helm チャートのカスタマイズ.

ノート。 翻訳。: として公開されているリンクのブロックを推奨することもできます。 リソース このユーティリティの Web サイトでは、kusTOMize に関する最新レポートを含むビデオのコレクションが続きます。

この資料を改善するための質問や提案がある場合は、いつでもフィードバックをお待ちしています。 までご連絡ください。 Twitter または Kubernetes Slack チャネル。 kusTOMize を使ってマニフェストを楽しく変更してください。

翻訳者からの追伸

私たちのブログもお読みください:

• «Kubernetes 上で実行されるアプリケーションの開発者向けのツール";
• «Kubernetes 1.14: 主なイノベーションの概要";
• «アムステルダムで開催された Helm Summit 2019 の XNUMX つの主な成果";
• «Kubernetes のパッケージ マネージャーの実践的な紹介 - Helm'。

出所： habr.com