なぜKubernetesはDockerを捨てたのか？

現在、kubeletのDockerサポート機能は非推奨となっており、将来的には削除される予定です。kubeletは以前、DockerのCRIサポートを実装するためにdockershimというモジュールを使用していました。しかし、Kubernetesコミュニティはこれに関連したメンテナンス上の問題を発見したため、CRIの完全な実装を含む利用可能なコンテナランタイムの使用を検討するようにと推奨しています（v1alpha1またはv1と互換性があります）。

つまり、DockerはKubernetesのランタイムAPIであるCRI（Container Runtime Interface）に対応しておらず、Kubernetesユーザーは「dockershim」という*ブリッジングサービスを利用していました。DockershimはDocker APIとCRIを変換することができますが、それ以降のバージョンではKubernetesはこのブリッジングサービスを提供することはありません。

もちろん、Docker自体も開発環境を構築する上では非常に強力なツールです。しかし、現状を把握するためには、既存のKubernetesアーキテクチャにおけるDockerの役割を十分に分析する必要があります。

Kubernetesは、さまざまな異なるコンピューティングリソース（仮想/物理マシンなど）をグループ化して統一された巨大なコンピューティングリソースとして出現させ、アプリケーションで使用したり、他の人と共有したりすることができるインフラストラクチャツールです。このようなアーキテクチャでは、Docker（またはコンテナランタイム）は、実際のホストでアプリケーションを実行するために、Kubernetesのコントロールプレーンを介してスケジューリングするためにのみ使用されます。

上記のアーキテクチャのダイヤグラムを見れば、各Kubernetesノードがコントロールプレーンと通信していることがわかります。各ノード上のkubeletはメタデータを取得し、CRIを実行してノード上でコンテナの作成/削除を実行しています。

しかし、なぜDockerは非推奨なのでしょうか？

前述の通り、KubernetesはCRIとしか通信できないので、Dockerと通信するにはブリッジサービスを利用する必要があります。これが一つ目の理由です。

次の理由を説明するには、Dockerのアーキテクチャを少し説明する必要があります。まずは以下の図を見てください。