DockerがKubernetesのコードから消滅した理由、歴史的背景、ツールごとの対応方法総まとめ：Cloud Nativeチートシート（16）

Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Kubernetes 1.24でDockerサポートが削除された背景と対応方法について解説する。

[正野勇嗣, 岡本隆史，株式会社NTTデータ]

　2020年12月8日。ノストラダムスは予言した。「DockerはいずれKubernetesから消え去るだろう」と。そしてv1.20で非推奨になった。予言から1年5カ月たった2022年5月3日のv1.24のリリースによって、ついにDockerはKubernetesのコードから消滅した。一体これから何が起こるのだろうか……。

　Kubernetes信者の読者には既知の事実かもしれないが、改めてKubernetesに何が起こったのか、そしてわれわれはどうしていけばよいのか――。Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回は、その真相を究明する。

目次

• ついに削除されたDockerサポート
• KubernetesのDockerサポートの歴史と削除の背景
• コラム　 Docker Engineとcontainerdの関係
• dockershimがなくなることへの対処
  • 対処1：Docker Engineを使い続ける
  • 対処2：Docker Engineを使うのをやめる
• 他のコンテナランタイムを使う場合はどうすればよいか？
  • Build：Dockerイメージ
  • Ship：Dockerレジストリ
  • Run：コンテナの実行
• コラム　crictlコマンドとdockerコマンド
• 公式サイトのアナウンスを読みたい方
• まとめ（参考文献）

ついに削除されたDockerサポート

　Kubernetes 1.24でKubernetesからDockerをサポートするコードが削除されたことで、KubernetesやDockerが流行している今、次のように不安を抱えている方もいるかもしれません。

• え？　KubernetesでDockerが使えなくなるの？　何だか分からないけど不安
• 公式サイトで「Don't Panic: Kubernetes and Docker」という記事を見たが、「パニックになるな」と言われると余計パニックになる
• Docker好きだったのに、別のランタイムに変えないといけないのかな？　そもそも自分が使っている環境に影響があるのか分からない
• v1.20のリリースノートでdockershimが非推奨になったことは既に知っていたけど、「まだまだ先のことだ」と高をくくっていた。焦る

　本稿は、このような悩みや漠然とした不安感を解消するために執筆しました。読者の皆さんが気になる観点が書かれた章をつまみ食いしていただければ幸いです。なお、既に公開されている情報のまとめ的な記事になっているので、既にご存じの方はご了承ください。

KubernetesのDockerサポートの歴史と削除の背景

　KubernetesのDockerサポートの歴史と、「なぜ削除されたのか」の背景を見ていきます。

　「Docker Engine」（別称「Docker CE」）はKubernetesで最初にサポートされたコンテナランタイム（＝コンテナを実行する実行環境）でした。当時コンテナランタイムといえば、ほぼDockerのみだったので※1、当初はKubernetesにハードコーディングされていました。

※1：厳密には「OpenVz」「LXC」など先行するコンテナランタイムもありました。

　その後、Docker Engine以外のコンテナラインタイムが発表され、KubernetesにDocker Engine以外のコンテナランタイムを組み込みやすくするために、CRI（Container Runtime Interface）としてコンテナとKubernetesのインタフェースが標準化されました。

　それに伴い、Kubernetesのコードに直接組み込まれていたDocker Engineをサポートするコードは、「dockershim」というブリッジによってCRIを介してDocker Engineを利用するように変更されました。その後、Docker Engineも内部のリファクタリングが進み、Docker Engineの中で「containerd」というコンテナランタイムを利用し、containerd経由でコンテナを操作するように変更されました（図1の上側）。

図1　Docker Engineを使うために、dockershimが必要となる構造

　dockershimによってKubernetesは引き続きDocker Engineをサポートしてきたわけですが、dockershimは「cgroups v2」「user namespaces」などの新しいKubernetesの機能と互換性がないという問題が出てきました。また、dockershimに関連するコードは、Cloud Native Computing Foundation（CNCF）のコードやツールに影響を与え、壊れやすいコードになっていました。これらの理由によってdockershimは、Kubernetesの開発に足かせとなっていました。

　そこで、Kubernetesの開発の速度を上げるために、dockershimに関するコードがKubernetesから削除されました（図1の下側）。

　containerd（もしくは、他のコンテナランタイム）を、CRIを介して直接呼び出す方式に移行することで、dockershimが不要になりますし、Docker Engineのオーバーヘッドもなくなります。

コラム　 Docker Engineとcontainerdの関係

　Docker Engine、dockershim、containerdといった用語が出てきましたが、これらの関係について構造的に理解していきましょう。

　Docker Engineで使われているコンテナランタイムはcontainerdです。つまり、Docker Engineをcontainerdに置き換えた場合、結局コンテナエンジンとしてはcontainerdが使われるわけです。

　Docker Engineにはコンテナランタイム以外にも、「Docker Swarm」など、Kubernetesで必ずしも利用しないものも含まれます。dockershimを削除し、Docker Engineに依存しない構造になり、下記の2.を意識しなくてよくなります。

• Docker Engineの機能
  1. コンテナランタイム
     • containerd
  2. コンテナランタイム以外
     • Docker Swarm
     • Docker CLI
     • Docker REST API
     • ネットワーク
     • ストレージ

　これによって、Kubernetesプロダクトのメンテナンス性の向上につながることは容易に想像できることでしょう。

dockershimがなくなることへの対処

　KubernetesからDockerサポートするモジュールdockershimが削除された後、どうしていけばよいのでしょうか？　以下の2つの対処があるので、順に説明します。

• 対処1：Docker Engineを使い続ける
• 対処2：Docker Engineを使うのをやめる

対処1：Docker Engineを使い続ける

　Docker Engineを使い続けるには、dockershimの代わりに、Mirantisから提供されるCRI準拠の「cri-dockerd」を図2のようにインストールすることになります。cri-dockerdが「kubelet」からCRIでコンテナ操作を仲介し、Docker Engineを操作します（図2）。

図2　dockershimからcri-dockerdへの移行イメージ

　インストールの詳細はMirantisの記事「Mirantis to take over support of Kubernetes dockershim」をご参照ください。

　マイグレーション方法については、公式サイト「Migrate Docker Engine nodes from dockershim to cri-dockerd」をご参照ください。

　なお、後述のDocker Desktopはcri-dockerdを利用して、Docker Engineを使い続けています。

対処2：Docker Engineを使うのをやめる

　Docker Engineを使うのをやめる場合は、containerdやcri-oをランタイムとして使います。後述の「Amazon Elastic Kubernetes Service」（EKS）、「Google Kubernetes Engine」（GKE）、「Azure Kubernetes Service」（AKS）、「Microk8s」「kind」は特定のバージョンからcontainerdを採用しています。

他のコンテナランタイムを使う場合はどうすればよいか？

　Docker Engineを使うのをやめて、他のコンテナランタイムを利用する場合、本当に影響はないのでしょうか？

　結論としては、Build、Ship、RunのBuildとShipは無影響。影響はRunの一部のケースのみです。つまり、「Dockerイメージ」「Dockerレジストリ」は利用可能です。もちろん、そもそもKubernetes経由でDocker Engineを使っていない場合は影響がありません。

　以降、Build、Ship、Runについて解説します。

Build：Dockerイメージ

　他のコンテナランタイムを利用した場合でも、従来のDockerイメージを利用できるので、従来のイメージはそのまま使い続けることができます。

　イメージの作成を「docker build」などで行っている場合も、そのままdocker buildや他のコマンドでそのままイメージをビルドします。

Ship：Dockerレジストリ

　既存のDockerレジストリは原則そのまま使えます。

　ただし、ローカル環境にキャッシュレジストリを作成したり、オンプレミス環境でDockerレジストリのミラーを作成したりしている場合、「/etc/docker/daemon.json」などの設定の中でミラーを設定していると思いますが、移行先のコンテナランタイムでレジストリミラーの再設定などが必要になります。

　詳しくは、Kubernetesの公式サイトをご参照ください。

Run：コンテナの実行

　環境によって異なりますが、Kubernetesをバージョンアップしない場合、多くの場合はノードをそのまま使えます。Kubernetesの古いバージョンを使っている場合で、かつ新しいKubernetesのバージョンにマイグレーションするタイミングなどでノードの再作成が必要になります。

　以降、お使いの環境に該当するパートをご参照ください。

• マネージド環境
• PC環境

　ただし、ノードにログインしてコンテナの動作状況を確認する場合、dockerコマンドが利用できなくなり、代わりに「crictl」コマンドを利用することになります。詳細は下記のコラムをご覧ください。

コラム　crictlコマンドとdockerコマンド

　Dockerの代わりにCRI対応のコンテナエンジンを利用すると、dockerコマンドが使えなくなります。代わりにcrictlコマンドが提供されており、crictlを利用することで、コンテナを操作できます。crictlコマンドはほぼdockerコマンドと同じサブコマンドを持っていますが、Podに関する操作など、若干異なるコマンドもあります。

　下記にdockerコマンドをcrictlコマンドの対応を掲載しておくので、crictlコマンドの使い方に迷った人は参考にしてください。

イメージ操作

docker	crictl	説明
docker pull	crictl pull	コンテナイメージの取得
docker images	crictl images	コンテナイメージの一覧
docker rmi	crictl rmi	コンテナイメージの削除
docker image inspect	crictl inspecti	コンテナのイメージ情報を表示

コンテナ操作

docker	crictl	説明
docker create	crictl create	コンテナの作成
docker run	crictl run	コンテナの実行
docker ps	crictl ps	コンテナの一覧
docker inspect	crictl inspect	コンテナの詳細情報を表示
docker stats	crictl stats	コンテナのリソース消費情報を表示
docker attach	crictl attach	コンテナにコンソールをアタッチ
docker exec	crictl exec	コンテナでプロセスを実行
docker logs	crictl logs	コンテナのログ表示
docker rm	crictl rm	コンテナの削除
docker kill/stop	crictl stop	コンテナの停止
docker start	crictl start	コンテナの開始
docker update	crictl update	コンテナの更新

Pod操作

docker	crictl	説明
-	crictl runp	Pod実行
-	crictl rmp	Pod削除
-	crictl inspectp	Pod情報表示
-	crictl stopp	Pod停止
-	crictl port-forward	Podのポートフォワード

・マネージド環境

　以下の通りKubernetesのバージョンに応じて対応が異なります。

ツール	どのバージョンからcontainerdがデフォルトか	containerdの有効化方法
EKS	v1.22	containerd ランタイムブートストラップフラグを有効にする
GKE	v1.19（Linux）、v1.21（Windows）	ノード自動プロビジョニングのデフォルトのノードイメージを変更する
AKS	v1.19（Linux）、v1.23（Windows）	create a new node pool with containerd enabled

　containerdがデフォルトになっているバージョンをお使いの方は、自然体でcontainerdを使っているので、今回のdockershimの削除の影響を受けません。それ以前のバージョンについては、containerdを有効化する手順が提供されています。

• EKS（Amazon EKS AMIの対応状況）
  Kubernetes v1.22以降はデフォルトランタイムがcontainerdになっており対応不要。Kubernetes v1.17〜1.21では、containerdの有効化が可能
• GKE
  LinuxとWindowsそれぞれで扱いが異なる。GKEのv1.23に一部制限事項がある（参考）
1. Linuxの場合はKubernetes v1.19以降はデフォルトコンテナランタイムがcontainerdになっており、対応不要
2. Windowsの場合Kubernetes v1.21以降はデフォルトランタイムがcontainerdになっており、対応不要
• AKS
  LinuxノードプールとWindows Serverノードプールそれぞれで扱いが異なる
1. Linuxノードプールの場合、Kubernetes1.19以降はデフォルトコンテナランタイムがcontainerdになっており、対応不要
2. Windows Server 2019ノードプールの場合、Kubernetes v1.23以降はデフォルトランタイムがcontainerdになっており、対応不要。Kubernetes v1.22までの場合はcontainerdの有効化が可能

・PC環境

　containerdがデフォルトになっているバージョンを使っている場合、自然体でcontainerdを使っているので、今回のdockershimの削除の影響を受けません。

ツール	対応状況	影響バージョン
Docker Desktop	（Docker Engineの継続利用のためv4.7.0でdockershimからcri-dockerdに変更）	なし
Minikube	（2022年5月18日時点でDocker Engine）	現時点ではなし（2022年5月18日時点でKubernetesのバージョンが1.24より前なので）
Microk8s	v1.14でcontainerdに変更	v1.13まで
kind	v0.3.0でcontainerdに変更	v0.2.0まで

• Docker Desktop
  v4.7.0からcri-dockerdに変更されたので、Docker Desktopに同梱されているKubernetesを使っている場合、特段影響はない。詳しくはDockerの公式サイト「Dockershim not needed: Docker Desktop with Kubernetes 1.24+」を参照。ちなみに、Docker Desktop 4.8.0において、Kubernetes v1.24が採用された
• Minikube
  コンテナランタイムは「--container-runtime」オプションで指定でき、Docker Runtime、containerd、cri-oが利用可能。詳しくはMinikubeの公式サイト「Runtime configuration」を参照。リリースノートを見ると、2022年5月18日時点で「v1.26.0-beta.0」が最新で、Kubernetesのデフォルトバージョンは1.23.6
• Microk8s
  コンテナランタイムはcontainerdが使われている。リリースノートを見ると、2019年3月25日リリースのv1.14でdockerdからcontainerdに変更された。従って、v1.14以降のユーザーには影響はない。なお、2022年5月18日時点でv1.24が最新で、Kubernetesのバージョンは1.24
• kind
  コンテナランタイムはcontainerdが使われている。リリースノートを見ると、2019年5月17日リリースのv0.3.0でcontainerdが採用され、dockershimが利用されなくなった。従って、v0.3.0以降のユーザーには影響はない。なお、2022年5月18日時点でv0.13.0が最新で、Kubernetesのバージョンは1.24

公式サイトのアナウンスを読みたい方

　「Web記事で概観をつかみ、正確なところは一次情報（公式サイト）から得たい」という方のために、ご参考として主要なページを列挙しておきます。

• Don't Panic: Kubernetes and Docker
• Migrating from dockershim
• Check whether dockershim removal affects you
• Dockershim Deprecation FAQ
• Container Runtimes

まとめ

　ここまで読むことで、「Dockerが使えなくなる！」という抽象的な理解から脱し、一歩踏み込んだ理解が得られたのではないでしょうか。ご自身の環境で「Kubernetesのバージョンアップなど適切に対応できる状態になった！」と自信を持っていただけたなら幸いです。

参考

• Dockerからcontainerdへの移行 (NTT Tech Conference 2022発表レポート) by Akihiro Suda nttlabs Apr, 2022 | Medium
• Dockerからcontainerdへの移行
• Dockerは非推奨じゃないし今すぐ騒ぐのをやめろ
• Kubernetes 1.20から始まるDockerランタイムの非推奨化に備えよう！我々が知っておくべきこと・すべきこと
• コンテナランタイムの動向を整理してみた件
• Kubernetesは次の1.24リリースでDockershimの非推奨化を進める
• Mirantis社はKubernetesのdockershimサポートを引き継ぎます