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チートシート」。今回は、その真相を究明する。
Kubernetes 1.24でKubernetesからDockerをサポートするコードが削除されたことで、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の上側)。
Copyright © ITmedia, Inc. All Rights Reserved.