1クール続けるブログ読者になる1クール続けるブログとりあえず1クール続けるソフトウェアエンジニアの備忘録この広告は、90日以上更新していないブログに表示しています。背景・モチベーション以前に記事を書いて、kustomizeでbuildする時にCRDでpatchesStrategicMergeが利用できない悲しみを文字に起こしました。(紛らわしいので当該記事は非公開にしてあります)ところが、v4.1.0のリリースで可能になったようです!うれしいですね...!ということで早速試してみた記事です。Applykube-openapi/generator/extension.goどのようにCRDでpatchesStrategicMergeを実現するのかCRDでのpatchesStrategicMergeはkustomizeでどのように実現されるのか確認していきますKubernetes本体ではv1.16からCRDのapplyがJMPからSMPに変わっているkubernetesのv1.15までは、CRDをapplyしたときの挙動がkubernetes/kustomizeで足並み揃っていて、下記のような挙動になっていました。kubernetesのnativeオブジェクトはstrategicMergePatch(SMP)を使うCRDはjsonMergePatch(JMP)を使う例えば、PodTemplateのコンテナのリストをマージする時などはその違いが顕著です。SMPであれば、各要素のnameをキーとして利用して、同一のキーが存在すれば更新し、無ければ配列に追加するという挙動を取ります。対して、JMPの場合には配列ごと置き換えます。Applyのリリースによって変わります。Strategyを参照いただければと思うのですが、API開発者がList/Map/structのマージ方法をOpenAPIスキーマで定義できるmarker(extension)が追加されました。mapとx-kubernetes-list-map-keysとして解釈されます。Applyを利用したCRDで定義されたリソース更新では、markerが存在すれば、その定義に基づいてフィールドの更新を行うようになりました。v1.16のリリース時からkubernetesとkustomizeの間で挙動の違いが生まれることになってしまいました。Strategyはその定義を参照することで確定することができます。対してCRDの定義はバンドルしていません。kustomize自体がどうにかしてCRDの定義を知る必要があります。そこで、kustomizeはkustomization.yamlファイルにopenapiフィールドを追加して、そのフィールドを読み込んでスキーマを取得するように機能追加を行いました。openapiフィールドが指定されていれば指定されたスキーマを読み込み、そうでなければビルトインの定義を利用するような動きをするようになっています。この機能追加により、CRDを含む全体のスキーマファイルが手元にあれば、より柔軟なマージ戦略を行うことができるようになりました。スキーマの取得が必要になってきます。これはKuberneteのAPIサーバに対して、/openapi/v2のパスでリクエストすることで可能です。fetchというサブコマンドの内部でそれを実行することでスキーマの取得をサポートしています。流れとしては下記のような流れとなります。際の内部処理で/openapi/v2にリクエストしていると先ほど言及させていただきました(参考)。これはOpenAPIのv2での公開です。v3で定義されたCRDはv2でサポートされていないフィールドを含んだり、表現できないnullableを利用したりします(参考)。v1.13より前のバージョンでは解釈できないため、互換性を守るために公開時に削除されます。buildで影響を及ぼす可能性があります。実際にCRDでpatchesStrategicMergeできるか確かめてみる自前のGKEクラスタで確認していきます。バージョンは1.18.16です。CRDのマニフェストのmergeStrategyを確認する事前の準備としてCRDのマニフェストのmergeStrategyを確認しておく必要があります。今回はArgoCDのRolloutリソースで確認していきますが、2つのキーの組み合わせで一意に解釈させたい.spec.template.spec.containers.portsなどは既にmarkerが利用されていますが、.spec.template.spec.containersのarrayはそうなっていません。今回、自分の方でmarkerを追加して試してみたいと思います。.spec.template.spec.containersのarrayのみにmarkerを追加いたしました。ちなみにkustomizeの実装を見ていると、x-kubernetes-list-typeを確認せずにx-kubernetes-patch-strategyのmarkerを確認しに行きます。そのmarkerが見つからないとx-kubernetes-list-map-keysを確認してくれないみたいなので注意してください(該当コード)。Applyでもこうなっているのかな...?後で確認してみようと思います。CRDのリファレンスを確認すると、x-kubernetes-patch-strategyが許容するフィールドに存在しないため、schemaをfetchした後に追加してあげる必要があります。利用するファイル群はこちらにまとめています。github.com自前のGKEクラスタで試してみます。expected.yaml上手く動くところまで確認できましたが、仕様の問題なのか自分のドキュメントの読み込みが甘いのかわかりませんが、まだ実用に持っていくのは難しいような要素を感じました。細かいところを確認して必要そうならIssue挙げてみようと思います。3はてなブログをはじめよう!jrywm121さんは、はてなブログを使っています。ブログを報告する引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。