Kubernetes 1.20からDockerが非推奨になる件について、頭の整理をしてみます。
目次
- KubernetesとDockerは最強の組み合わせかと思ってた
- 整理にあたって、まず、言葉のおさらいから
- DockerはCRI非対応なのに特別扱いされてきた
- containerdの切り出しでDockerを特別扱いする意味がなくなった
- 公式ブログのパニックになるな！の真意
- とても参考になった記事のリンク
Kubernetesと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のエキスパートではありませんから、まずは、言葉のおさらいからはいります。
クーべネティスまたはクーバーネティスと読みます。
複数のコンテナを関連するリソース(e.g. 永続化ボリューム)とともに一元管理します。
コンテナ
想環境のことですが、ハードウェアまでエミュレートする「仮想マシン」と違って、OSのカーネルの機能で論理的に隔離された環境上でアプリケーションプロセスを動かすだけなので、軽量（起動時間やリソース消費量が小さいな）のが特徴です。
Pod
Kubernetes上のワークロードの最小単位です。
Kubernetes上でPodごとに論理リソースが隔離され、IPアドレスが割り当てられます。
ちょうど、Kubernetes上の仮想マシンみたいな感じで、Podの中で一つないし複数のコンテナが動くことになります。
コンテナランタイム
コンテナを実行するためのプログラムです。
Kubernetes自身がコマンドを実行する機能を持っているわけでなく、kubeletというコンポーネントがコンテナランタイムのAPIやコマンドをたたいて、コンテナを実行するわけですが、このコンテナランタイムのひとつが「Docker」ということになります。
DockerはCRI非対応なのに特別扱いされてきた
kubeletには、コンテナランタイム間のインターフェースの標準化仕様[Container Runtime Interface (CRI)]があります。
原則、この仕様に対応しているコンテナランタイムを推奨、それ以外は非推奨です。
でも、Dockerは、このCRIに非対応ですが、例外的に扱われてきました。
なぜかというと、コンテナ技術は、最初Dockerありきであり、Kubernetesも、初期はコンテナランタイムはDocker一択だったという歴史があるからです。
Dockerは特別扱いされ、kubeletに「dockershim」を別途、組み込むことで扱えるようにしていたわけです。
現時点でKubernetesからDockerをコンテナランタイムとして、コンテナを扱う場合は、ざっくり以下の図のようなイメージになっています。
普通に考えても、かなり無駄が多いことがわかります。
containerdの切り出しでDockerを特別扱いする意味がなくなった
ポイントは、上記でDockerの皇族にでてくる「containerd」や「runC」です。
containerdもrunCも、Docker社が開発しており、コンテナ管理やコンテナイメージ管理などのDockerのメインどころの機能をきりだして標準化したものになっていて、最近のDockerはそのへんの処理をほぼ、このcontainerdに丸投げしている構造です。
しかも。
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ソケットとか？）とこがあれば、それを代替えする方法を考える必要はあるけど、単に、コンテナを動かすというだけなら、それほど心配することはなさそうかな・・って感じです。
よしよし。
とても参考になった記事のリンク
最後に、今回調べるにあたって、すごく参考になった記事のリンクを張っておきます。
今回はこんなところで。
ではでは。