KubeCon China：恒例の失敗談トークはスナップショットの実装について

IT業界のカンファレンスは「良い点」を見せて参加者を啓蒙するというのが一般的な感覚だろう。しかし「クラウドネイティブ」を謳うCNCF（Cloud Native Computing Foundation）が主催するKubeConは、少し違うようだ。もちろん、最新の技術とそれによって解決される問題を紹介するためのさまざまなセッションに参加すれば、確かにソフトウェアは進化していることを実感できるし、参加者はその情報を持ち帰って新たなソフトウェア開発やインフラストラクチャーの構築に励むだろう。しかし「どうしてこんなことが起こってしまったのか？」という失敗を振り返るという悪いニュースが、良いニュースを上回るインパクトを与えることも往々にして発生する。

KubeCon 2018 EUが開催されたコペンハーゲンではイギリスのインターネットバンクMonzo Bankの失敗談がキーノートで紹介され、翌2019年のバルセロナではSpotifyの失敗談がキーノートで紹介された。どうやらCNCFは、敢えてユーザー企業に失敗談を喋らせることの意味を正しく理解しているように思えるのだ。そんな中、KubeCon Chinaでは前述の「ユーザーが語る失敗談」というスタイルではないが、Kubernetesのコミュニティのメンバーに失敗談を語らせた。それが、2019年6月24日の夕方に行われたキーノート、「CRD, No Longer Second Class」と題されたセッションだ。

それぞれの失敗談のレポートについては、以下を参照されたい。

参考：KubeConで失敗を紹介したMonzo Bankのキーノート

参考：KubeCon Europe、2日目のキーノートはSpotifyの失敗事例とIBMのRazeeがポイント

これはGoogleのエンジニアとOpenSDSのエンジニアが「Kubernetesが利用するストレージのスナップショットをどうやって実装しようとしたのか？」について語ったセッションで、登壇したのはGoogleのJing Xu氏とOpenSDSのXing Yang氏だ。Xu氏もYang氏も、Kubernetes-SIG Storageに属するコントリビューターで、Snapshot Workgroup Leadという役割を担っており、今回のセッションで語られたスナップショット機能の開発リーダーである。

Yang氏（左）とXu氏（右）

当初、スナップショット機能はコアのAPIに追加しようとし、KubernetesのアーキテクチャーSIGにその追加仕様についてリクエストを送ったところ、SIGからは「それはCRD（Custom Resources Definition）で実装しろ」という拒否の返答が来たのだという。そしてネイティブなAPIをコアに追加するのではなく、CRDで実装することを検討したという。

APIのコアにスナップショット機能を実装したかった

その際に、これまでのKubernetesの過去を振り返った。2014年に誕生してから5年の間に1.0から1.15というリリースを経て、多くのAPIが追加され、Controllerも拡大してきたという経緯と、過去のリリースでAPIの数がどう変化してきたのかを見れば、このままではAPIがさらに増えてしまうことが予想されたという。

Kubernetesの過去の変遷

APIの点数の増加

そしてこのままKubernetesが肥大することに対する回答として、アーキテクチャーSIGはAPIでの実装を拒否したという流れになった。

Kubernetesが巨大化する？

そのため、Kubernetesをモジュール化し拡張可能にした上で、メンテナンスを可能にするためには別の実装方法、つまりCRDを使うというアーキテクチャーSIGが提案した実装方法を選択したことになる。

CRDとは

CRDは「Custom Resources Definition」という名称のとおり、Kubernetesが利用するリソースのうち、ユーザーやベンダーが個別に定義したものを表す。

左がCRD、右がその利用例としてのリソース

CRDはあくまでも定義であり、その定義に従って何を行うか？　についてはCustom Controllerが必要となるが、CRDとCustom Controllerが一緒に動くことで、宣言的に外部から使用できるAPIが完成する。

CRDとControllerがAPI Serverに対して働きかける

結果的にコアAPIで実装するのではなく、CRDで定義されたスナップショットのオブジェクトがKubernetesによって発見された結果、Create SnapshotやDelete Snapshotという動作が実行される形式になった。

スナップショットのオブジェクトは、その他のカスタムオブジェクトと同様にふるまい、コマンドラインからの使い勝手も近いため、デベロッパーにとっては馴染みの良いものになったという。

Podや永続的ボリュームなどと同じ操作になった

CRDはまだベータという扱いだが、1.16/1.17においてGA（General Availability、正式版）となることが予定されており、その段階ではスナップショットのCRDとCustom Controllerも安定した実装になるだろうというのが両氏の予想だ。

CRD対ネイティブAPIの比較

またスナップショットは、CRDで実装されたとしてもストレージSIGがオーナーとなって責任を持ってメンテナンスすること、エンドツーエンドのテストを行うこと、ドキュメンテーションも公式で用意されることなどが紹介された。

その後にスナップショットのCRDとCustom Controllerの作成を、コマンドラインからデモとして実行してみせ、簡単に実装が可能なことを実証した。

CRDの作成をデモで実行

その後はCRDの過去の経緯を紹介。ここでは発表当初には「Third Party Resource（TPR）」と呼ばれていたこと、アプリケーションに特化したCRDが出てきたこと、そしてコアのAPIを拡張するために利用されていることが紹介された。

CRDの開発の経緯

そしてAPIの数の変化については、1.10の110点と比較して1.15では113点と3つしか増えていないということを種明かしした。ここでは、Kubernetesのコアを肥大させないという努力が実を結んでいると言えよう。

1.15ではAPIの増加はわずかだ

そして最後に、「CRDを実行するもの以外はすべてCRDで記述するべき」というKubernetesの創始者の一人、GoogleのTim Hockin氏の言葉を紹介してプレゼンテーションを終えた。

Tim Hockinは『（CRD以外は）すべてをCRDで実装しろ』と言う

今回のセッションは、Monzo BankやSpotifyなどのユースケースほど失敗を振り返るというものではなかったが、それでも実装方法についての論点やKubernetesの将来を見据えての判断という辺りに関しては、は生々しい一面が垣間見えたセッションとなった。クラウドネイティブなコンピューティングでは、失敗は必ずしも拒絶するものではなく、失敗や後戻りから何を学ぶのか？　ということがより重要であるということを暗に示したセッションであるように思えた。