はじめに
今朝に書いたブログが思ったより反響が大きくて、「Dockerが死んだ」という勘違いをされている方も多かったので追加でエントリーを書きました。
決してそんなことはないので、対応が必要なケースを見ていこうと思います。
対応が必要ではないケース
Kubernetesを使わない人たち
今回の騒動はKubernetesにおけるDocker依存排除が目的なのでDockerしか使わない人には関係ありません。
本番はKubernetesでも、開発にDocker Composeを使っているデベロッパーの開発環境
これも特に問題ありません。本番を動かす基盤側は影響があるかもしれませんが、手元の開発は変わらないと思ってください。
対応が必要なケース
開発環境でも手元でKubernetesを利用する人たち
- Docker DesktopのKubernetes環境
- どうなるんでしょう？全くわかりません
- Docker社の対応を待つしかなさそう
- Minikubeをホストで直接動かす場合や、Microk8sなどを利用している場合
- Dockerではなくcontainerdのsockを今後利用していくことになると思います
- MinikubeなどではRuntimeを指定するオプション(
--container-runtime='containerdまたはcri-o':)があるので、それをいじればよさそう
- kindを動かしてる場合？
- 関係ないとの公式アナウンス。かわいい。
NVIDIA DockerをKubernetesで使っている人たち
GPUをKubernetesで動かす場合、NVIDIAのDevice plugin + NVIDIA Container Toolkit(いわゆるNVIDIA Docker)が内部的に使われます。これに関しては完全に移行の検討が必要ですが、調べたところ、下記のnvidia-container-runtimeをcontainerdの設定で有効にできるようなので、そちらの利用をすすめるのがよさそうです。
また、NVIDIAのgpu-operatorがcontainerdのサポートを検討しているようです。
Kubernetesワークロードの中で「Docker in Docker」や「Docker APIに依存した処理」を動かしている場合
おそらくこれが一番たいへんです。Docker in DockerについてはcontainerdのAPIに切り替えるか、Kubernetes上でDockerのDockerイメージ(語彙力)を動かしてさらにハックが必要みたいなことが起こりそう。
特に、Kubernetes上でDocker builderを使っている場合などの影響が大きいので、CIでイメージビルドする際などは色々検討事項がありそう。
Dockerの機能を使ってこれまでやっていたことについて
上記でも書いたようにDocker CLIやDocker APIに依存したものをどこまで使い続けるかという検討が必要です。特に
- Dockerコンテナのメタデータ取得
Kubernetesの上で動くアプリケーションについては、できる限りKubernetes APIを使って取得すべきです。どうしても取れないものはCRIのAPIでなにかできないか検討するくらいにしておくと良いでしょう。
- Dockerイメージのビルド処理
こちらは、イメージビルダーを別で選定する必要がありそうです。NTTの須田さんが発表されている資料が非常にわかりやすくまとまっているので別途ご参照ください。
他にもDockerじゃないと動かないケースが有る人だれか教えて下さい。
