https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
の日本語訳です。仕事で読む機会があったので、せっかくなので残しておきます。
なお、私は翻訳のプロではなく、またわかりやすさのため直訳ではなく意訳する場合があります。
疑問点があれば、公式サイトを参照してください。
K8sはv1.20より新しいバージョンでDockerをサポートしません。 (deprecating Docker
パニックを起こす必要はありません。想像するような抜本的なものではないのです。
TL;DR
RuntimeとしてのDockerは、Kubernetesのために開発されたCRI（Container Runtime Interface）を利用しているRuntimeを選んだ結果として使用出来なくなります。しかし、Dockerによって生成されたImageはこれからも、今までもそうだったように、みなさんのClusterで使用可能です。
もし、あなたがKubernetesのエンドユーザーであるならば、多くの変化はないでしょう。これはDockerの死を意味するものではありませんし、開発ツールとしてDockerを使用するべきでない、使用することは出来ないと言っているのでもありません。Dockerはコンテナを作成するのに便利なツールですし、docker buildコマンドで作成されたImageはKubernetesクラスタ上でこれからも動作可能なのです。
もし、GKE、EKS、AKSといったマネージドK8sサービスを使っているのなら、Workerノードがサポート対象のRuntimeを使用しているか、Dockerのサポートが将来のK8sバージョンで切れる前に確認しておく必要があるでしょう。
もし、ノードをカスタマイズしているのなら、環境やRuntimeの仕様に合わせて更新する必要があるでしょう。サービスプロバイダと確認し、アップグレードのための適切なテストと計画を立ててください。
もし、ご自身でClusterを管理しているのなら、やはり問題が発生する前に必要な対応を行う必要があります。v1.20の時点で、Dockerの使用についての警告メッセージが表示されるようになります。将来のK8sリリースでDockerのRuntimeとしての使用がサポートされなくなれば、containerdやCRI-Oといった他の適切なRuntimeに切り替える必要があります（現時点では、v1.22を予定しています。）。切り替える際、そのRuntimeが現在使用しているDockerDaemonの設定をサポートすることを確認してください。（Loggingなど）
###では、なぜ混乱が生じ、誰もが恐怖に駆られているのか。
ここで議論になっているのは2つの異なる場面についてであり、それが混乱の原因になっています。Kubernetesクラスタの内部では、Container runtimeと呼ばれるものがあり、それはImageをPullし起動する役目を持っています。Dockerはその選択肢として人気があります（他にはcontainerdやCRI-Oが挙げられます。）が、しかしDockerはそれ自体がKubernetesの一部として設計されているわけではありません。これが問題の原因となっています。
お分かりかと思いますが、ここで”Docker”と呼んでいるものは、ある1つのものではなく、その技術的な体系の全体であり、その一部には"containerd"と呼ばれるものもあり、これはそれ自体がハイレベルなContainer runtimeとなっています。Dockerは素晴らしいもので、便利です。なぜなら、多くのUXの改善がされており、それは人間が開発を行うための操作を簡単にしているのです。しかし、それらはKubernetesに必要なものではありません。Kubernetesは人間ではないからです。
このhuman-friendlyな抽象化レイヤが作られてために、結果としてはKubernetesクラスタはDockershimと呼ばれるほかのツールを使い、必要な要件を満たす必要が出てきました。このツールはcontainerdと呼ばれます。これは素晴らしいとは言えません。なぜなら、我々がメンテする必要のあるものが増えますし、それは問題が発生する要因ともなります。ここで実際に怒っているものは、Dockershimを（最も早い場合で）v1.23でkubeletから除外することです。そのため、結果としてDockerのサポートがなくなるということなのです。
ここで、containersがDockerに含まれているなら、なぜDockershimが必要なのかと疑問に思われるかたもいるでしょう。
DockerはCRI（Container Runtime Interface）に準拠していません。もしそうであればShimは必要ないのですが、現実はそうでありません。
しかし、これは世界の終わりでありません、心配しないでください。みなさんがしなければならないことはContainer runtimeをDockerから他のRuntimeに切り替えるだけなのです。
1つ注意すべきことは、クラスタで行われる処理のなかでDocker socket(/var/run/docker.sock)
に依存する部分がある場合、他のRuntimeへ切り替えるとこの部分が働かなくなるでしょうか。このパターンはDocker in Dockerと呼ばれます。このような場合の対応方法はたくさんあります。kaniko、img、buildahなどです。
###開発者にとって、この変更は何を意味するのか。Dockerfileはこれからも有効なのか。これからもDockerでビルドを行ってよいのか。
この変更は、Dockerを直接操作している多くのみなさんとは別の場面に影響を与えるでしょうか。
みなさんが開発を行う際に使用しているDockerと、Kubernetesクラスタの内部で使われているDocker runtimeは関係ありません。これがわかりにくいかもしれません。開発者にとって、Dockerはこれからも便利なものであり、このアナウンスがあった前と変わらないでしょう。DockerでビルドされたImageは、決してDockerでだけ動作するというわけではありません。それはOCI Image(Open Container Initiative)と呼ばれるものです。あらゆるOCI準拠のImageは、それを何のツールでビルドしたかは問題ではなく、Kubernetesから見れば同じものなのです。containerdもCRI-Oも、そのようなImageをPullし、起動することが出来ます。
これがコンテナの仕様について、共通の仕様を策定している理由なのです。
さて、この変更は決定しています。いくつかの問題は発生するかもしてませんが、決して壊滅的なものではなく、ほとんどの場合は良い変化となるでしょうか。Kubernetesをどのように使用しているかによりますが、この変更が特に何の影響も及ぼさない人もいるでしょうし、影響がとても少ない場合もあります。長期的に見れば、物事を簡単にするのに役立つものです。
もし、この問題がまだわかりにくいとしても、心配しないでください。Kubernetesでは多くのものが変化しており、その全てに完璧に精通している人など存在しません。
経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。
このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。