Operator-sdkのコマンド体系がv0.19.0(2020/7 release)から変わった
Go向けのOperatorのコマンド体系がkubebuilderに沿った形式となったために、既存のコマンドは通らなくなっている。
operator-sdk new osushi-operator --repo github.com/iaoiui/osushi
Error: unknown flag: --repo
operator-sdkのバージョンは下記
❯ operator-sdk version
operator-sdk version: "v0.19.2", commit: "4282ce9acdef6d7a1e9f90832db4dc5a212ae850", kubernetes version: "v1.18.2", go version: "go1.14.5 darwin/amd64"
下記のOperatorframeworkのドキュメントを確認すると、v0.19.0以前はLegacyと呼ばれ別のドキュメントを参照するように指示されていた。
いろいろ変わっている部分はありそうだが、どうやら最初の雛形を作るサブコマンドがnewからinitに変わっているために、—repoというオプションがないというエラーが出ているようだ。
Golang Based Operator Quickstart
そのため、new部分をinitに置き換えることで対応できた。
operator-sdk init osushi-operator --repo github.com/iaoiui/osushi
Operator-sdkのリリース情報をみると、2020/7にv0.19.0がリリースされているためほぼすべての書籍類において、この部分の読み替えが必要になると思われる。
https://github.com/operator-framework/operator-sdk/releases/tag/v0.19.0
Operator-sdkとkubebuilderのGo-based Operato統合の背景
Kubernetes Operatorを作成するためのフレームワークとして大きく、operator-sdkとkubebuilderの2つがありそれぞれ異なるコミュニティによりメンテナンスされてきた。
両方のツールではGoを用いたOperatorのscaffolding(テンプレート生成)が可能であり、作成されるディレクトリやファイル群はは違うものの実現できる目的としては同じであった。
両方のツールで同じようなことをしていることもあり、そのメンテナンス体系を統合することでメンテナンスコストを減らし、開発スピードをあげることが、モチベーションとしてあがってきた。
具体的な方法としては、operator SDK側にはGo Operatorに関する様々な機能があるため、operator SDK側のコントリビュータがそれらの機能を、kubebuilder側にマージしていく作業を先導していく。
つまり、kubebuilder側をアップストリームとし、operator sdk側はkubebuilderのラッパーとして動作するというような、若干の政治の匂いがする形で決着したのだと推測される。
またドキュメントに関しても、operator sdk側のドキュメントをkubebuilder側にマージしていき、kubebuilder側をメンテしていくとのこと。
上記に記載した内容は、kubebuilder側の設計資料に記載されている内容を意訳したものである。
kubebuilderとoperator-sdkの統合に関するkubebuilderのデザインドキュメント
Operator-sdkのCLI体系変更に関するPR
operator-sdkのPR(#3190)で示されている通り、Go向けのOperatorはKubebuilder CLIに沿った形になったとのこと。
そのために、0.19.0からコマンド体系が変わり、以前のコマンド体系はLegacyになったと考えられる。
特に注意したいのは、operator-sdkコマンドで生成されるファイル群が、全体的に変わってしまっておりLegacyなoperator-sdkを一度忘れた方が話が早いレベルのため、Operatorをこれから触ろうとする人にとっては、現存の書籍を読むのは辛くなると思われる。
特定の書籍名を出すのは避けた方が無難だが、下記の書籍を昨日ポチったので統合に関する背景を噛みしめながら読む。
実践入門 Kubernetesカスタムコントローラーへの道
ステマ感が増すが、Kubernetes完全ガイド第２版もなつやすみの課題図書として読む。
まとめ
- Kubernetes Operatorを使う場面がさらに広まっていく中で、同様のフレームワークが統合されることで初学者がツール選びに悩む時間が軽減される流れはかなり好ましい状況と思える。
- 正確には、Go-basedのoperator作成部分の統合であるため完全な統合ではないが、 実質operator-sdk>kubebuilderという機能関係になるため、operator-sdk側を使用させたいという狙いが透けて見える。
- ともかく、ユーザサイドとしてはコマンド体系がガチャガチャ変わると困るので、今後も動きを注視していきたい。
kubebuilderとoperator-sdkの統合に関する進捗状況やマイルストンを確認したい。
また、デザインドキュメントに記載されていることと、実際のPRがでていることから、ある程度統合が進んでいると思ってはいるが
実際のところどのような課題がありどのように落ちつくのか、さらに整理が必要。