Operatorのパブリックレジストリ "OperatorHub.io"って知ってる？

はじめに

本稿は，Kubernetes Advent Calendar 2019 その1 の24日目と OpenShift Advent Calendar 2019 の24日目のクロスポストです。
さて，まずは，メリークリスマス。

おすすめのケーキは，恵比寿本店レザネフォールのシャンティーフレーズです。(甘すぎず上品かつ口溶け最高のショートケーキ)

※「はじめに」まで読んで閉じようとされてるアナタへ
※2019年もあと少し。たくさんのヒトにお世話になりました。
※また来年も楽しくやりましょー！良いお年を！

背景と主旨

昨今，Operator というワードを聞かなくなるレベルまで当たり前になってきました。

Why?
自作Controllerは当たり前に作られている場合がある。あるいは既に使っているテクノロジーはKubernetes拡張を前提にしたコンポーネント(つまりOperator)だったりする。ベンダーが提供する新サービス・機能は当然のごとくOperatorとして実装されている。などなど
このため，わざわざKubernetesと連携する機能に対して「〜〜Operator って言ってないかも？」という意味

Kubernetesの先人達は，自分たちの運用をラクにするControllerを「必要に応じて創ってきた」と話されています。(Z Lab，CyberAgent, Cybozu, etc.) そして今現在も，自社のサービス維持のために「創る」，あるいは「活用する」などしています。

そう，創れば良い。
...
...
...
これが現実です。

実は今，Operatorのエコシステムが回りつつあります。
例えば，OperatorHub はご存知でしょうか。本稿ではOperatorHubについてカンタンに紹介しようかなと思います。

これからやろう！って思ってるヒトにも，既にOperator自作しまくってんだけど！？ってヒトにも何かしらお役に立てると嬉しいです。

なんでこの記事を書いたかと言うと，
・Kubernetes=しんどい。とか
・Kubernetes=もうキライ。とか
・導入したのに本番失敗したやんけ！前(手動でゴリゴリ時間かけてやるやり方)の方がシンプルで良かったわ。とか。

クラウドネイティブの意義以前にツライ話が出てくるのは悲しいので，Kubernetes界隈の盛り上げはもちろんのこと，
ソースコードの公開や，OperatorHub.ioのようなパブリックレジストリへの登録に拍車がかかるように色んな情報整理などしていきたいな〜と思ったりする今日この頃だったりするためです。

Operatorとは

※Operatorを知らないヒト向け

「Operatorを適用することによってKubernetesを拡張することができます。」

すこしだけ説明すると，
標準のKubernetesでは定義されていない独自リソースをK8sの管理下に置くことができる ようになります。例えば，ステートフルなアプリケーション特有の運用手順をOperator(=Custom ContollerとCustom Resource)によってコード化できます。

なんとなくK8sやっていて，「Why / What is Operator?」をさくっと知りたい場合は以下を参照頂ければと思います。
(自分の資料を紹介なんて何かアレやし・・・しかもIntro的な位置づけやし・・・。あれ？イントロか。ちょうどいいな。という流れで決まりました。)

https://twitter.com/capsmalt/status/1208541057874456576?s=20

Operatorユースケース

より分かりやすいのは，データストア自体の運用面です。

【データストア】
例えば「PostgreSQLクラスターを新アプリケーション用に組んで，運用する」といった場合に，Postgres Operatorを利用すると以下のような動作をOperator Podに任せることが出来ます。
・複数台でクラスターを構成(マスターx1,レプリカxN)
・リクエストタイプ(Read or Write)に応じた振分け
・マスターが死んだ場合の候補選出
・バックアップ・リストア
・etc.
(参考: Crunchy PostgreSQL Enterprise)

というか，皆さん Rook 知ってますよね。アレです。
Operator無くしてCephクラスター運用します？しませんよね。

詳細を知りたい方は，RookだらけのAdvent Calendar 2019 を参照くださいませ。

【K8sクラスター運用(データストアも含む。etcdとか)】
Kubernetes経験のある方はクラスター運用に苦労したこともあるでしょう。
そんな方には分かりやすいと思います。例えば
・クラスターのバージョンアップ
・ノードのOSバージョンアップ
・ノードレベル，クラスターレベルのスケーリング
・障害対応(メンバーからの除外，追加，復旧)
・etcdクラスターのバックアップ・リストア
・etc.
クラスターに係るメンテナンス負荷は一見複雑なK8sだとより大変に感じる場合があるかもしれません。
クラスターが多かったり，プロジェクトごとに異なるバージョンのクラスターを使ってる場合などバリエーションも増えるとさらに大変です。実はこれらは既に多くの方が経験されているのも事実です。

そこで，
「Kubernetes Operatorを自作・活用して運用をラクにした Z Lab さんの登壇資料」があります。興味のある方は参照ください。

(参考: Kubernetes Operator で実現する NoOps の世界)

わたしの手元のクラスターの場合だと，クラスター構築時点で27個のCluster Operatorが動作しています。
他にKnative，ServiceMesh，Tektonなどを使う場合は，Operatorを使って追加インストール・運用していくスタイルです。

OperatorHub.io

OperatorHub.ioは，Kubernetes Operatorのパブリックレジストリです。
Red Hat，Google，Microsoft，AWSが主な貢献者であり，共同でスタートし，K8s上でのソフトウェア運用機能をコンテナライズして提供しています。

わたしの手元のクラスターの場合だと，クラスター構築時点で27個のCluster Operatorが動作しています。
他にKnative，ServiceMesh，Tektonなどを使う場合は，Operatorを使って追加インストール・運用していくスタイルです。

本稿でさきほど上記のように述べました。

DockerHubに様々なコンテナイメージがあるように，Operatorとして既に多数のプロジェクトが公開されています。
OperatorHub.io では，PostgreSQLやMySQLといったデータベースなど特定のミドルウェアだけでなく，JenkinsやSpinnaker，Spark，Jaeger，Prometheus，Sysdig，Eclipse Che，etc.などあらゆる種類のOperatorが用意されています。このため，一から自作する必要は無く，利用できる場合もあります。

現時点(2019/12/24)では，95個のOperatorが登録されており，68の団体(オープンソースコミュニティやCNCF，ソフトウェアベンダー，クラウドベンダーなど)がOperatorHubに協力しています。

Operatorのカテゴリ

• AI/Machine Learning
• Application Runtime
• Big Data
• Cloud Provider
• Database
• Developer Tools
• Integration & Delivery
• Logging & Tracing
• Monitoring
• Networking
• OpenShift Optional
• Security
• Storage
• Streaming & Messaging

Operator成熟度モデル

Operatorの成熟度モデル(Capabilityモデル)は，以下図のように5段階のフェーズで構成されています。
フェーズ1(Basic Install)の場合は，"設定値やコンテナをまとめて一括デプロイできるようなパッケージ"のOperatorが多いです。 フェーズが進むにつれて，高度な運用に対応できるようになるように区分けされています。

成熟度のカテゴライズによる実装差異については，Operatorのコードや，定義されているリソース(CRD)を見るとだいたい分かります。

OperatorHub.io内の左下のチェックボックスを利用することで， 成熟度モデルのレベルを選択してフィルタリング することができます。
下図の場合は，"Full Lifecycle(フェーズ3)" にチェックを入れた状態です。etcd(by CNCF)やIstio(by Banzai Cloud)などのOperatorが確認できます。

Operatorの認定レベルとサポート

• Community Operator
  • Community(Github)でメンテナンスされる
  • サポート無し
• Certified Operator
  • ISV(独立系ソフトウェアベンダー)のプロダクト
  • Red HatとISVが連携
  • ISVからのサポート付き (原則)
• Red Hat Operator
  • Red Hat社がパッケージし，リリースを行う
  • Red Hat社からのサポート付き

Operatorエコシステム

既にオープンソースのプロジェクトだけではなく，多種多様なソフトウェアベンダーが自社コンテンツをOperator化しています。日本国内においてもエンタープライズ向けのサポート付きミドルウェア・ソフトウェアのOperatorや，SIerのノウハウをアセット化したOperatorなどの取組みが進んできており，このムーブメントによって，K8sならびにOperator活用を強力にサポートできるエコシステムが出来上がりそうです。

思い切って誤解を恐れずに言うと・・・「K8s上での運用機能を備えたソフトウェア・ミドルウェアをOperatorHubから利用できる」ということです。

OperatorHubには多数のOperatorが存在していますが，上述のOperator成熟度モデルや，認定レベル&サポートなど，調査の際にはひとつの指標として確認することをオススメします。

OperatorのOperatorHub.io上への登録

乞うご期待っ (OLMとか絡んでくるよ)

さいごに

Kubernetes活用の未来を一緒に考えつつ，K8sプラットフォームそのものや，Operatorのようなテクノロジー活用について，あるべき リーズナブルな選択 について皆で議論していけると良いなと思います。

2019年もあと少し。たくさんのヒトにお世話になりました。
また来年も楽しくやりましょー！良いお年を！