Kubernetes の適用、置換、パッチの適切な比較

Kubernetes には、リソースを更新するためのいくつかのオプション (適用、編集、パッチ、置換) があります。 それぞれが何をするのか、いつ使用するのかについては混乱があります。 それを理解しましょう。

もし Googleで検索する 「kubernetes apply vs replace」というフレーズが見つかりました StackOverflow への返信、これは正しくありません。 検索時 「kubernetes apply vs patch」最初のリンクは、次のドキュメントです。 kubectl patch、比較は含まれません apply и patch。 この記事では、さまざまなオプションとそれぞれの適切な使用方法について説明します。

Kubernetes リソースのライフサイクル (サービス、デプロイ、イングレスなど) 中に、このリソースの一部のプロパティを変更、追加、削除する必要がある場合があります。 たとえば、メモを追加したり、レプリカの数を増減したりします。

Kubernetes CLI

すでに CLI 経由で Kubernetes クラスターを操作している場合は、すでに慣れているはずです。 apply и edit. チーム apply ファイルからリソース仕様を読み取り、Kubernetes クラスターに対して「upsert」を実行します。 リソースが存在しない場合は作成し、存在する場合は更新します。 チーム edit API を介してリソースを読み取り、リソース仕様をローカル ファイルに書き込み、そのファイルをテキスト エディタで開きます。 ファイルを編集して保存したら、 kubectl は行われた変更を API 経由で送り返し、これらの変更をリソースに慎重に適用します。

誰もがコマンドを知っているわけではありません patch и replace. チーム patch リソース仕様の一部を変更し、変更された部分のみをコマンドラインに指定できます。 チーム replace と同じように機能します editただし、すべてを手動で行う必要があります。たとえば、次のようにしてリソース仕様の現在のバージョンをダウンロードする必要があります。 kubectl get -o yaml編集してから使用してください replace 変更された仕様に従ってリソースを更新します。 チーム replace リソースの読み取りと置換の間に変更が発生した場合、機能しません。

Kubernetes API

あなたはおそらくその方法に精通しているでしょう CoreV1().Pods().Update(), replaceNamespacedService または patch_namespaced_deployment、クラスターを使用して作業する場合は、 Kubernetes API のクライアント ライブラリ 何らかのプログラミング言語を使用して。 ライブラリは、次のメソッドを使用して HTTP リクエスト経由でこれらのメソッドを処理します。 PUT и PATCH。 この場合は、 update и replace 使用する PUTと patchたとえそれがどんなに些細なことであっても、 PATCH.

これは、ことは注目に値します kubectl API 経由でクラスターとも連携します。 言い換えると、 kubectlは Go 言語のクライアント ライブラリ上のラッパーであり、標準の API 機能に加えて、よりコンパクトで読みやすい形式でサブコマンドを提供する機能を主に提供します。 たとえば、すでにお気づきかもしれませんが、このメソッドは apply 前の段落では言及されていませんでした。 現在（2020年XNUMX月） 約。 翻訳者) すべてのロジック kubectl apply、つまり存在しないリソースの作成と既存のリソースの更新は、完全にコード側で機能します kubectl。 取り組みが行われています ロジック転送時 apply API 側ですが、まだベータ版です。 以下に詳しく書きます。

デフォルトでパッチを適用する

最もよく使われる patch、リソースを更新する場合。 このようにして、両方のクライアント ライブラリが Kubernetes API 上で動作し、 kubectl (これはクライアント ライブラリのラッパーなので当然のことですが、 約。 翻訳者).

戦略的に取り組む

すべてのチーム kubectl apply, edit и patch 方法を使う PATCH HTTP リクエストで既存のリソースを更新します。 コマンドの実装をさらに詳しく調べると、すべてのコマンドで次のアプローチが使用されます。 戦略的マージパッチ適用 リソースを更新するには、コマンド patch 他のアプローチを使用することもできます (これについては以下で詳しく説明します)。 戦略的マージ パッチ適用アプローチでは、提供された仕様を既存の仕様とマージすることで「正しく理解する」ことを試みます。 より具体的には、オブジェクトと配列の両方を結合しようとします。これは、変更が追加的になる傾向があることを意味します。 たとえば、次のコマンドを実行すると、 patch ポッド コンテナー仕様に新しい環境変数を使用すると、その環境変数は既存の環境変数を上書きするのではなく、既存の環境変数に追加されます。 このアプローチを使用して削除するには、指定された仕様でパラメータ値を強制的に null にする必要があります。 どのチームが kubectl アップデートに使用するのが最適ですか?

を使用してリソースを作成および管理する場合、 kubectl apply、更新するときは常に使用することをお勧めします kubectl applyに kubectl 構成を管理し、アプリケーションごとに要求された変更を適切に追跡できます。 常に使用する利点 apply それは、以前に適用された仕様を追跡し、仕様のプロパティと配列要素がいつ明示的に削除されたかを知ることができるということです。 これにより、使用できるようになります apply プロパティと配列要素を削除するには、通常の戦略的マージは機能しません。 チーム edit и patch ノートを更新しないでください kubectl apply を使用して変更を追跡するため、変更は Kubernetes API を通じて追跡および行われますが、コマンドを通じて行われます。 edit и patch、後続のコマンドには表示されません applyつまり、 apply の入力仕様に現れない場合でも、それらは削除されません。 apply (ドキュメントにはこう書いてあります) edit и patch 使用したメモを更新する apply、しかし実際には - いいえ）。

コマンドを使用しない場合 apply、として使用できます editと patch、行われている変更に最も適したコマンドを選択します。 BOM プロパティを追加および変更する場合、どちらのアプローチもほぼ同じです。 仕様プロパティまたは配列要素を削除する場合 edit XNUMX回限りの起動のように動作します applyこれには、仕様が編集される前後でどのようになっていたかを追跡することも含まれます。これにより、リソースからプロパティや配列要素を明示的に削除できます。 の仕様でプロパティ値を明示的に null に設定する必要があります。 patchリソースから削除します。 戦略的マージ パッチを使用して配列要素を削除する場合は、マージ ディレクティブを使用する必要があるため、より複雑になります。 より実行可能な代替案については、以下の他のアップグレード アプローチを参照してください。

上記のコマンドと同様に動作する更新メソッドをクライアント ライブラリに実装するには kubectl、リクエストで設定する必要があります content-type в application/strategic-merge-patch+json。 仕様内のプロパティを削除したい場合は、同様の方法でそれらの値を明示的に null に設定する必要があります。 kubectl patch。 配列要素を削除する必要がある場合は、更新仕様にマージ ディレクティブを含めるか、更新に別のアプローチを使用する必要があります。

アップデートに対するその他のアプローチ

Kubernetes は、他の XNUMX つの更新アプローチをサポートしています。 JSONマージパッチ и JSONパッチ。 JSON マージ パッチ アプローチは、部分的な Kubernetes 仕様を入力として受け取り、戦略的マージ パッチ適用アプローチと同様のオブジェクトのマージをサポートします。 XNUMX つの違いは、ポッド仕様のコンテナ配列を含む配列の置換のみをサポートしていることです。 これは、JSON マージ パッチを使用する場合、コンテナーのプロパティが変更された場合に備えて、すべてのコンテナーに完全な仕様を提供する必要があることを意味します。 したがって、このアプローチは、BOM 内の配列から要素を削除する場合に役立ちます。 コマンドラインで、次を使用して JSON マージ パッチを選択できます。 kubectl patch --type=merge。 Kubernetes API を使用する場合は、リクエスト メソッドを使用する必要があります。 PATCH そしてインストール content-type в application/merge-patch+json.

JSON パッチのアプローチでは、リソースの部分仕様を提供するのではなく、リソースに加えたい変更を配列として提供します。配列の各要素は、リソースに加えられた変更の説明を表します。 このアプローチは、行われた変更を表現するためのより柔軟で強力な方法ですが、部分的なリソース仕様を送信するのではなく、行われた変更を別の非 Kubernetes 形式でリストするというコストがかかります。 で kubectl を使用してJSONパッチを選択できます kubectl patch --type=json。 Kubernetes API を使用する場合、このアプローチはリクエスト メソッドを使用して機能します。 PATCH そしてインストール content-type в application/json-patch+json.

自信が必要です - replace を使用してください

場合によっては、リソースが読み取られてから更新されるまでの間にリソースに変更が加えられていないことを確認する必要があります。 言い換えれば、すべての変更が次のように行われることを確認する必要があります。 原子。 この場合、リソースを更新するには次を使用する必要があります replace。 たとえば、複数のソースによって更新されるカウンターを含む ConfigMap がある場合、XNUMX つのソースが同時にカウンターを更新して、更新が失われることがないようにする必要があります。 実証するには、次のアプローチを使用して一連のイベントを想像してください。 patch:

• A と B は API からリソースの現在の状態を取得します
• それぞれがカウンターを XNUMX つインクリメントし、「更新者」メモにそれぞれ「A」または「B」を追加することで仕様をローカルに更新します。
• そして、リソースの更新が少し速くなります
• B はリソースを更新します

その結果、更新 A は失われます。 最後の操作 patch 勝利すると、カウンターは XNUMX ではなく XNUMX ずつ増加し、「更新者」ノートの値は「B」で終わり、「A」は含まれません。 上記を、このアプローチを使用して更新が行われた場合に何が起こるか比較してみましょう。 replace:

• A と B は API からリソースの現在の状態を取得します
• それぞれがカウンターを XNUMX つインクリメントし、「更新者」メモにそれぞれ「A」または「B」を追加することで仕様をローカルに更新します。
• そして、リソースの更新が少し速くなります
• B はリソースを更新しようとしましたが、リソースのバージョンが仕様に含まれているため、更新は API によって拒否されました。 replace リソースのバージョンは A の置換操作によって増加されたため、Kubernetes のリソースの現在のバージョンと一致しません。

上記の場合、B はリソースを再フェッチし、新しい状態に変更を加えて再試行する必要があります。 replace。 これにより、カウンターが XNUMX つ増加し、「更新者」ノートの最後に「AB」が含まれます。

上記の例は、実行時に replace リソース全体が完全に置き換えられます。 使用される仕様 replace、部分的または部分的であってはなりません。 apply、ただし追加も含めて完了 resourceVersion 仕様メタデータに組み込まれます。 有効にしていない場合 resourceVersion または、提供されたバージョンが最新ではない場合、交換は拒否されます。 したがって、使用する最良のアプローチは次のとおりです replace – リソースを読み取り、更新し、すぐに置き換えます。 使用する kubectl、次のようになります。

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

次の XNUMX つのコマンドを順番に実行すると、正常に実行されることに注意してください。 deployment.yaml プロパティが含まれていません .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

これは上で述べたことと矛盾しているように見えます。 「追加 resourceVersion 仕様のメタデータに追加します。」という言い方は間違っていますか? いいえ、そうではありません。 kubectl 指定していないことに気づきました resourceVersion、リソースからそれを読み取り、指定した仕様に追加してから実行します。 replace。 アトミック性に依存すると潜在的に危険なため、魔法は完全にサイドで機能します。 kubectl、API で動作するクライアント ライブラリを使用する場合は、これに依存しないでください。 この場合、現在のリソース仕様を読み取り、更新してから実行する必要があります。 PUT リクエスト。

パッチを適用することはできません。交換を行います

場合によっては、API では処理できない変更を加える必要がある場合があります。 このような場合、リソースを削除して再作成することで、リソースを強制的に置き換えることができます。 これは次を使用して行われます kubectl replace --force。 コマンドを実行すると、リソースがただちに削除され、提供された仕様からリソースが再作成されます。 API には「強制置換」ハンドラーがありません。API を通じてこれを行うには、XNUMX つの操作を実行する必要があります。 まず、リソースを設定して削除する必要があります gracePeriodSeconds ゼロ (0) と propagationPolicy 「バックグラウンド」でこのリソースを再作成し、必要な仕様でこのリソースを再作成します。

警告: このアプローチは潜在的に危険であり、未定義の状態につながる可能性があります。

サーバー側で適用する

前述したように、Kubernetes 開発者はロジックの実装に取り​​組んでいます。 apply の kubectl Kubernetes API で。 ロジック apply Kubernetes 1.18 で利用可能 kubectl apply --server-side またはメソッドを使用して API 経由で PATCH с content-type application/apply-patch+YAML.

注: JSON も有効な YAML であるため、次のような場合でも仕様を JSON として送信できます。 content-type 意志 application/apply-patch+yaml.

そのロジックのほかに kubectl API経由で誰でも利用できるようになり、 apply サーバー側では、仕様内のフィールドの責任者を追跡し、競合のない編集のための安全な複数アクセスを可能にします。 言い換えれば、もし apply サーバー側での機能がさらに普及すると、さまざまなクライアント (kubectl、Pulumi または Terraform、GitOps、クライアント ライブラリを使用した自己作成スクリプトなど) 用のユニバーサルで安全なリソース管理インターフェイスが登場するでしょう。

結果

クラスター内のリソースを更新するさまざまな方法に関するこの短い概要がお役に立てば幸いです。 適用と置換だけではなく、適用、編集、パッチ、または置換を使用してリソースを更新できることを知っておくと便利です。 結局のところ、原則として、各アプローチには独自の適用分野があります。 アトミックな変更の場合は、置換することをお勧めしますが、それ以外の場合は、適用による戦略的マージ パッチを使用する必要があります。 少なくとも、「kubernetes apply vs replace」を検索する場合、Google や StackOerflow を信頼できないことは理解していただけると思います。 少なくともこの記事が現在の回答を置き換えるまでは。

出所： habr.com