DockerがKubernetesのコードから消滅した理由、歴史的背景、ツールごとの対応方法総まとめ：Cloud Nativeチートシート（16）
Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する連載。今回は、Kubernetes 1.24でDockerサポートが削除された背景と対応方法について解説する。
この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。
2020年12月8日。ノストラダムスは予言した。「DockerはいずれKubernetesから消え去るだろう」と。そしてv1.20で非推奨になった。予言から1年5カ月たった2022年5月3日のv1.24のリリースによって、ついにDockerはKubernetesのコードから消滅した。一体これから何が起こるのだろうか……。
Kubernetes信者の読者には既知の事実かもしれないが、改めてKubernetesに何が起こったのか、そしてわれわれはどうしていけばよいのか――。Kubernetesやクラウドネイティブをより便利に利用する技術やツールの概要、使い方を凝縮して紹介する本連載「Cloud Nativeチートシート」。今回は、その真相を究明する。
目次
ついに削除された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の上側）。
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の機能
- コンテナランタイム
- containerd
- コンテナランタイム以外
- 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）。
インストールの詳細は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のバージョンにマイグレーションするタイミングなどでノードの再作成が必要になります。
以降、お使いの環境に該当するパートをご参照ください。
ただし、ノードにログインしてコンテナの動作状況を確認する場合、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 | コンテナの更新 |
| 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に一部制限事項がある（参考） - Linuxの場合はKubernetes v1.19以降はデフォルトコンテナランタイムがcontainerdになっており、対応不要
- Windowsの場合Kubernetes v1.21以降はデフォルトランタイムがcontainerdになっており、対応不要
- AKS
LinuxノードプールとWindows Serverノードプールそれぞれで扱いが異なる - Linuxノードプールの場合、Kubernetes1.19以降はデフォルトコンテナランタイムがcontainerdになっており、対応不要
- 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サポートを引き継ぎます
関連記事
MicrosoftによるMirantis Container Runtimeのサポートは「2022年9月」に終了
MicrosoftはWindows Server 2016でWindowsコンテナのサポートを開始し、コンテナランタイムとしてのDocker Enterprise Edition（現在のMirantis Container Runtime）のライセンスと、Microsoftによるサポートを提供してきました。このランタイムのMicrosoftによる提供とサポートは2022年9月末で終了し、Mirantisに完全に移管されます。
Azure Kubernetes ServiceのWindows Serverノードで「containerd」が正式にサポート
Microsoftは2022年1月20日、2021年5月からプレビュー提供していたWindowsノードプールにおける「containerd」のサポートの一般提供開始を発表しました。
AWSでNomadクラスタを構築――クラスタやジョブ管理の仕組みと内部構造を知る
コンテナオーケストレーションツールとして知られる「Kubernetes」とHashiCorpが提供する「Nomad」を比較検証する本連載。第3回はNomadを用いたクラスタ構築の手順やNomadの内部構造、ジョブ管理を中心に解説します。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。