Help us understand the problem. What is going on with this article?

【Kubernetes Operator】operator-sdkとkubebuilder統合に関する注意点

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に沿った形になったとのこと。
Untitled.png

そのために、0.19.0からコマンド体系が変わり、以前のコマンド体系はLegacyになったと考えられる。

特に注意したいのは、operator-sdkコマンドで生成されるファイル群が、全体的に変わってしまっておりLegacyなoperator-sdkを一度忘れた方が話が早いレベルのため、Operatorをこれから触ろうとする人にとっては、現存の書籍を読むのは辛くなると思われる。

特定の書籍名を出すのは避けた方が無難だが、下記の書籍を昨日ポチったので統合に関する背景を噛みしめながら読む。
実践入門 Kubernetesカスタムコントローラーへの道
ステマ感が増すが、Kubernetes完全ガイド第2版もなつやすみの課題図書として読む。

まとめ

  • Kubernetes Operatorを使う場面がさらに広まっていく中で、同様のフレームワークが統合されることで初学者がツール選びに悩む時間が軽減される流れはかなり好ましい状況と思える。
  • 正確には、Go-basedのoperator作成部分の統合であるため完全な統合ではないが、 実質operator-sdk>kubebuilderという機能関係になるため、operator-sdk側を使用させたいという狙いが透けて見える。
  • ともかく、ユーザサイドとしてはコマンド体系がガチャガチャ変わると困るので、今後も動きを注視していきたい。

kubebuilderとoperator-sdkの統合に関する進捗状況やマイルストンを確認したい。
また、デザインドキュメントに記載されていることと、実際のPRがでていることから、ある程度統合が進んでいると思ってはいるが
実際のところどのような課題がありどのように落ちつくのか、さらに整理が必要。

iaoiui
SIerでDocker, Kubernetes使って遊んでる人
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした