KubernetesのDockershim非推奨化に騒ぐ必要がない理由

　ことはひっそりと始まった。きっかけは、近くリリース予定の「Kubernetes 1.20」のリリースノートに「kubeletでのDockerのサポートは非推奨になった。将来のリリースでは削除される」という文言が入っていたことだ。これを見て、KubernetesでDockerが使えなくなるのではと動揺した人が多いようだ。しかし安心してほしい。

　たしかに、kubeletは「dockershim」モジュールをサポートするのをやめる。dockershimは、Dockerのコンテナーランタイムインターフェース（CRI）を実装するモジュールだ。だが、これはさして大きな問題ではない。

　Dockerは多くの役割を持っている。「Don't Panic: Kubernetes and Docker」と題したブログ記事で説明されているように、今回の変更は、v1.20以降のKubernetesでは、コンテナーランタイムとしてのDockerが非推奨になることを意味しているだけだ。心配しなくても、これまで通りにコンテナーをビルドして構わないし、レジストリーでコンテナーを使用することも、コンテナーをプッシュ／プルすることもできる。今回の話は、ランタイムとしてのDockerが非推奨になり、CRIのランタイムが使用されるようになるということだ。Dockerで生成されたイメージは、これまでと同じように実行できる。

　混乱が起きた原因の1つは、「Docker」という言葉がさまざまな意味で使われていることだろう。Kubernetesクラスターの内部におけるコンテナーランタイムの仕事は、コンテナーイメージをプルして実行することだ。Dockerはコンテナーランタイムとして人気があるが、Dockerは元々Kubernetesに組み込んで使われるように設計されたものではなく、そのことが幾つかの問題を引き起こしている。

　前掲の記事でも述べられているように、私たちが「Docker」と呼んでいるものは、1つの技術スタックだ。Dockerにはプログラマーのためのさまざまな拡張機能が含まれているが、Kubernetesはそれらを必要としていない。dockershimの仕事は、ランタイムの部分だけを取り出すことだけだ。残りの部分は不要であるばかりでなく、ありがたくない面もあり、攻撃対象範囲が大きくなってしまうだけでなく、余計なメンテナンスも必要になる。

　今回のDockerランタイムに関する変更は、以前から進められてきたものだ。今日では、ランタイムの選択と言えば、「containerd」と「CRI-O」のどちらを選ぶかという話になっている。実際、containerdもCRI-Oも、中身はDockerのオープンなランタイムである「runc」だ。

　Google Cloud Platformの開発者であり、Kubernetesについて詳しいことで知られているKelsey Hightower氏は、「何も変わらない。そのままDockerを使い続ければいい。Kubernetesは、ランタイム時にはDockerの機能のほんの一部しか使用していない。実際、どちらも、containerdとruncの両方を基盤となるプロセスの管理に使用することができる。コンテナーのイメージはポータブルだ。どう構築し、どう実行するかはユーザー次第だ」と述べている。

　Dockerもこれに同意している。Dockerの製品管理担当シニアディレクターであるDieu Cao氏は、ある投稿で「Dockerを使っていれば、既にcontainerdを使っているはずだ」と述べているほか、「2016年に、今回の移行を念頭にGoogleやIBMと一緒にcontainerdを作ったのはDockerだ。dockershim（およびランタイムとしてのDocker Engine）の非推奨化は、Kubernetesに最新のランタイムを提供するという長期的な取り組みが完了したことを意味している」と説明している。

　理解できただろうか？何も焦る必要はない。今後も、今まで通りDockerを使ってKubernetesで使うコンテナーを作成できる。唯一変わるのは、Kubernetesでコンテナーを実行するときに、containerdかCRI-Oを使用するようになるという点だけだ。自分が気づいていないだけで、既にこれらを使用している可能性も高い。

　いずれにせよ、何が起こるのかを理解するための時間は十分にある。dockershimは、2021年後半に予定されているKubernetes 1.23まではなくならない。