Kubernetes 1.20からDockerが非推奨・・と聞くと、世の中の変化の速さ・激しさを思いしらされます。
2018年に自分が記事に書いたときは、Kubernetes とDockerって、開発や保守の両面でメリットがある将来的にも有望な「最強・最良の組み合わせ」みたいに自分には見えてましたし、周囲の人間も、ほぼ１００％そういう見解でした。
ところがどっこい、その2年後に、こんなニュースを聞くことになるとは。
上記には
Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]
kubeletでのDockerサポートは非推奨になり、将来のリリースで削除される予定です。kubeletは、DockerのCRIサポートを実装する「dockershim」と呼ばれるモジュールを使用しており、Kubernetesコミュニティでメンテナンスの問題が発生しています。CRI（v1alpha1またはv1準拠）が利用可能になったら、本格的な実装であるコンテナーランタイムへの移行を評価することをお勧めします。（＃94624、@ dims）[SIGノード]
なんてことが、v1.20.0-beta.1以降の変更点として、しれっと書いてあります。
自分は KubernetesやDockerのエキスパートではありません。
それらを仕事で運用・管理する担当者でもありません。
ただ、会議などでそういう話題がでたときに、話についていけるようにはしておきたいので整理していくことにします。
まずは、言葉のおさらいから。
Kubernetesはクーべネティスまたはクーバーネティスと読みます。
複数のコンテナを関連するリソース(e.g. 永続化ボリューム)とともに一元管理します。
コンテナとは仮想環境のことです。
ハードウェアまでエミュレートする「仮想マシン」と違って、OSのカーネルの機能で論理的に隔離された環境上でアプリケーションプロセスを動かすだけなので、仮想マシンと比べて軽量（起動時間やリソース消費量が小さい）のが特徴です。
PodとはKubernetes上のワークロードの最小単位です。
Kubernetes上でPodごとに論理リソースが隔離され、IPアドレスが割り当てられます。
ちょうど、Kubernetes上の仮想マシンみたいな感じで、Podの中で一つないし複数のコンテナが動くことになります。
コンテナランタイムはコンテナを実行するためのプログラムです。
Kubernetes自身がコマンドを実行する機能を持っているわけでなく、kubeletというコンポーネントがコンテナランタイムのAPIやコマンドをたたいて、コンテナを実行するわけですが、このコンテナランタイムのひとつが「Docker」ということになります。
言葉のおさらいは、こんなところです。
kubeletには、コンテナランタイム間のインターフェースの標準化仕様[Container Runtime Interface (CRI)]があり、この仕様に対応しているコンテナランタイムを推奨、それ以外は非推奨となってました。
Dockerは、このCRIに非対応です。
でも、コンテナ技術は、最初Dockerありきであり、Kubernetesも、初期はコンテナランタイムはDocker一択だったという歴史から、Dockerを特別扱いせざるをえず、kubeletに「dockershim」を別途、組み込んで扱えるようにしていました。
現時点でKubernetesからDockerをコンテナランタイムとして、コンテナを扱う場合は、ざっくり以下の図のようなイメージになっています。
普通に考えても、かなり無駄が多いことがわかります。
しかも、上記にでてくる「containerd」はコンテナ管理やコンテナイメージ管理というメインどころを受け持つ機能をDockerからきりだして標準化したもので、最近のDockerはそのへんの処理をほぼ、このcontainerdに丸投げしている構造になってます。
（dockerもcontainerdもrunCも、Docker社が開発したものです）
しかも。
containerdは、Container Runtime Interface (CRI)に対応しているのです。
Dockerがなくても、kubeletからcontainerdを直接たたいてコンテナを扱うことはできます。
そう考えれば、最終的にはcontainerdに処理をゆだねているにすぎないDockerを通すためだけに「dockershim」を開発・保守するコストをかけるなんて、無駄以外の何物でもありません。
だから、1.20からDockerを非推奨にする＝dockershimを非推奨にする・・ということにしたということなんですね。
やっと、つながりました。
やれやれ。
ここまで理解できると、公式の「Kubernetesブログ」に「パニックになるなよ」と書いてあった以下の文章の真意がわかりました。
引用すると
Docker-produced images will continue to work in your cluster with all runtimes, as they always have.
If you’re an end-user of Kubernetes, not a whole lot will be changing for you. This doesn’t mean the death of Docker, and it doesn’t mean you can’t, or shouldn’t, use Docker as a development tool anymore. Docker is still a useful tool for building containers, and the images that result from running docker build can still run in your Kubernetes cluster.
Dockerで生成されたイメージは、常にそうであるように、すべてのランタイムでクラスター内で引き続き機能します。
Kubernetesのエンドユーザーの場合、大きな変化はありません。
これは、Dockerの死を意味するものではなく、Dockerを開発ツールとして使用できない、または使用すべきではないという意味でもありません。
Dockerは引き続きコンテナーを構築するための便利なツールであり、実行によって生成されたイメージdocker buildは引き続きKubernetesクラスターで実行できます。
あと、ここと。
What’s actually happening here is that Dockershim is being removed from Kubelet as early as v1.23 release, which removes support for Docker as a container runtime as a result.
ここで実際に起きていることは、v1.23リリースの時点でKubeletからDockershimが削除され、結果としてコンテナランタイムとしてのDockerのサポートが削除されるということです。
なるほど・・です。
Docker自体の機能を使ってなんかしてる（Dockerソケットとか？）とこがあれば、それを代替えする方法を考える必要はあるけど、単に、コンテナを動かすというだけなら、それほど心配することはなさそうかな・・って感じです。
よしよし。
最後に、今回調べるにあたって、すごく参考になった記事のリンクを張っておきます。
今回はこんなところで。
ではでは。