kubebuilder と Operator SDK の重複を一本化する取り組み。しかし Operator SDK 側のプロポーザルをよく見ると kubebuilder 側とは微妙に論調が異なる印象も受けます。

もともと kubebuilder と Operator SDK は、Custom Controller を作成するという意味では目的を同じくしていますが、今まで別々に開発されてきた経緯により、コマンド体系や生成されるディレクトリ構造が異なっていました。

これは不便なので、Operator SDK が kubebuilder に合わせる形で v0.19.0 で再編が行われています。

https://github.com/operator-framework/operator-sdk/releases/tag/v0.19.0

kubebuider 側としては「これで無駄な重複も無くなるので、今後は協力して管理していきます」という論調に終始しています。一方で Operator SDK 側では、上記の変更について述べつつ「今後は Operator SDK 独自の強みにフォーカスしていきます」という点のアピールも外せないようです。

kubebuilder 側のプロポーザル https://github.com/kubernetes-sigs/kubebuilder/blob/master/designs/integrating-kubebuilder-and-osdk.md

ちなみに「kubebuilder ではサポートされない Operator SDK 独自の機能」としては、Operator Lifecycle Management (OLM) や Scorecard が挙げられています。OLM は Operator 一揃いのインストールを管理し、リソースの依存関係に矛盾が出ないようにアップデートを行うツール。また Scorecard は一種の E2E テストツールで、作成されるリソースが正しいフィールドを持つことを検査できたりします。興味のある方は以下の資料も参考になるのでどうぞ。

そーいうことね。Operator Lifecycle Manager完全に理解した。 https://speakerdeck.com/shkitayama/operatorlifecyclemanager-101

Scorecard https://sdk.operatorframework.io/docs/advanced-topics/scorecard/scorecard/