Cloud Native Computing Foundation(CNCF)とKubernetes Release Teamは先頃、Kubernetes 1.20のリリースを発表した。今回のリリースは、ボリュームスナップショット操作が安定版(stable)になり、kubectlデバッグがベータ版に移行するなど、長大な拡張機能リストを持った最大級のリリースのひとつになっている。dockershimの非推奨化が通告されたことで、コミュニティ内には多くの議論もあった。
今回のKubernetes 1.20リリースに関して、リリースリーダであるVMwareスタッフエンジニアのJeremy Rickard氏から話を聞くことができた。最初に氏は、初のインド出身のリリースリーダなど、リリースチームの多様性を強調し、サブチームの半数が女性によって主導されていたことにも言及した。
Kubernetesの最新リリースでは、フレームワークのエンドツーエンドテストの改善や、テスト結果の視覚化など、引き続きプロジェクトの安定性に重きが置かれている。プロジェクトのリリースケイデンスを意識的に遅らせる取り組みも行われており、これまでは大半が年4回のリリースであったものが、今年は年3回になっている。
今回のリリースでのdockershimの非推奨化に関して、Rickard氏によるアドバイスの中心は、"慌てるな"、というものだった。ソーシャルメディア上には困惑の声が数多く見受けられるが、先日公開されたKubernetesブログの記事には、非推奨プロセスの正式なガイドが掲載されている。
InfoQ: 1.20のリリースと、リリースリーダであることの課題について、具体的に教えて頂けますか？
Jeremy Rickard: 1.20は非常にエキサイティングなリリースだったと思いますね。私は"The Raddest Release (最高のリリース)"と呼んでいます。マスコットは最終的に、変なポーズをした私の猫になりました。この猫はいつも舌を出すという習慣を持っていて、周りの人たちを笑わせています。2020年は人々にとって、個人的な意味でも、仕事の上でも、本当に大変な年になりました。せめて最後はユーモアで1年を締め括りたかったのです。
今年起こったCOVID-19やその他の出来事を考慮し、コントリビュータやKubernetesユーザの方々の負担を軽減するため、1.19リリースではスケジュールの大幅な延長が行われました。その影響でカレンダー上の日程が押されたことと、"KubeCon + CloudNativeCon North America 2020"や米国の感謝祭に重なったため、1.20リリースは極めて短期間に感じられました。これらの制約にも関わらず、(機能)拡張という面において、長い歴史の中で最大のリリースを実現できたのです！比較として、2019年のほぼ同じ時期に実現された1.17リリースについて説明しましょう。この時の機能拡張数は22でしたが、今回のリリースではそれが40以上になっています。
1.21リリースで私が特に感銘を受けているのは、Nabarun Pal氏がインド出身者として初めてリリースリーダを務める、という点です。コミュニティの健全性という面において、非常に素晴らしい兆候だと思っています。しかも、サブチームの半数以上が女性によってリードされる予定なのです！リリースチームの達成したこの多様性を、私は誇りに思っています。
InfoQ: dockershimの非推奨化に関する論争についてはどう思われますか？具体的に言うと、アプリケーション開発者たちが自身のアプリケーションをKubernetes 1.20以降でも動作させるためには、これまでとは何か違うことをする必要があるのでしょうか？
Rickard: リリースで議論が起きるのはよいことですが、まず言いたいのは、"慌てるな！"ということです。
Dockerコンテナは今後も実行可能です。TwitterやReddit、Hacker Newsでの議論はコントロール不能に陥るように思えたので、コミュニティが集まって素晴らしいブログ記事をまとめました。ぜひご一読ください — https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/。
ここでの重要な違いは、今回の非推奨が対象を非常に特定している点にあります — それはDockerランタイムであって、Dockerイメージやコンテナではありません。
実際に起きているのは、Kubelet(ノード上で実行されるコンポーネント)がContainer Runtime Interface(CRI)を使用するように、何年か前のリリースでスイッチされた、ということです。DockerエンジンはCRIを実装せず、dockershimと呼ばれるものによる特別なサポートを受けていました。この特殊ケースが非推奨となり、将来的にはどこかのポイントで、最速であればおそらく1.23で、削除されるということです。Kubernetesの立場から言えば、containerdのようなCRI実装のひとつを使用してくれれば非常に好都合です。
Dockerエンジンの運用を今後も続けたいのであれば、MirantisとDockerが提携して、Dockerエンジンを使用したCRIフルコンパチブルな実装を開発しています — https://github.com/Mirantis/cri-dockerd
InfoQ: Kubernetesのテストや継続的インテグレーションに関して、技術的にできるだけ詳しく説明して頂けますか？
Rickard: 1.19リリースの作業中に発生した問題のひとつは、多くのことをマージした結果、コードベースの全体的な安定性や健全性のデグレーションを招いたことです。これはテストのトレンドからも見て取れるのですが、軌道に戻るまでに本当に多くの調査が必要でした。今回に関しては、この全体的なトレンドの監視を重点的に行って十分な事前対策を行うと同時に、その結果をリリースの健全性に関する全体像として活用するようにしました。
1.20では、エンドツーエンドのテストに大きな労力を割いて全体的な品質改善を重視しました。実は、リリースの終わり近くになって多数のエラーが発生し始めて、チームとしては本当に心配していたのですが、調査の結果、リリースのある機能に関して追加した新しいエンドツーエンドテストの中に、リソース制約によるエラーの非常に多い、一般論としてよいテストではないものがいくつかあることが判明したのです。テストの観点から、Kubernetesプロジェクトに関して非常に感謝していることは、さまざまな自動化テストの実行結果を可視化したり、https://testgrid.k8s.io/経由で掘り下げたりすることが非常に簡単な点です。一般的なトレンドを確認するためのビジュアルなランディングページがあるのは素晴らしいことです。私の作業チームでも、そのような機能を組み込む方法について検討しているところです。例えば1.20ブランチを切れば、ブロッキングジョブと考えられるもののトレンドを可視化することが可能になるのです — https://testgrid.k8s.io/sig-release-1.20-blocking。これによって、問題となっているテストを掘り下げて特定し、それがいつ開始されるかを把握し、原因を特定して、対応策を立案することが可能になります。
InfoQ: 最後になりますが、Kubernetesリリース一般において、四半期リリースを今後も継続することは可能なのでしょうか？
Rickard: 四半期リリースに戻すことは非常に簡単ですが、ケイデンスを少し落として3リリースを永続するように調整できないか、という要求もあると思っています。これについて議論するイシューがGitHub上にオープンされているので、レビューやコメントをお願いしたいと思います — https://github.com/kubernetes/sig-release/issues/1290。
1.21リリースは通常の"四半期"スケジュールで行われると思います。まだ決定はされていませんが、そのサイクル内で将来のリリースに関するニュースがあるでしょう。1.21の機能や拡張がどのうように落ち着くのか、まだはっきりとは分かっていません。もうひとつ言いたいのは、リリースチームやKubernetesプロジェクト一般に関心があれば、それを始める方法はたくさんある、ということです。一般的なリソースをhttps://github.com/kubernetes/sig-release/blob/master/release-team/shadows.mdで見つけたり、sig-releaseミーティングに参加するなどしてみてください。ミーティングでは新たな情報が見つかるでしょう。
Kubernetes 1.20リリースに関するその他については、Kubernetes.blogで見ることができる。