v1.20以降、KubernetesはDockerをコンテナランタイムとして削除しています。
しかし、慌てる必要はありません。すべてが一見したほど悪いわけではありません。
TL; DR。 Kubernetesは、Kubernetes専用に設計されたContainer Runtime Interface（CRI）ランタイムを優先してDockerを廃止しています。 Dockerイメージは、すべてのランタイムで通常どおり機能し続けます。
Kubernetesエンドユーザーの場合、ほとんど変更されません。これはすべて、Dockerが「死ぬ」ことや、開発に使用すべき/使用すべきでないことを意味するものではありません。 Dockerは引き続きコンテナーを構築するための優れたツールであり、Dockerで構築されたイメージ
docker build
は引き続きK8sクラスターで実行されます。
GKEやEKSなどのマネージドKubernetesサービスを使用している場合は、ワーカーがサポートされているバージョンのランタイムを使用していることを確認し、K8の将来のリリースでDockerサポートが削除される前に使用する必要があります。ノードに特定の構成がある場合は、適切な環境とランタイムの要件を満たすためにアップグレードする必要があります。サービスプロバイダーに連絡して、すべてのテストおよびアップグレード計画の問題について話し合うことをお勧めします。
自分でクラスターを展開する場合は、問題を回避するために適切な変更を加える必要もあります。v1.20にアップグレードすると、Dockerの非推奨警告が表示されます。開発者はバージョン1.23でDockerを完全に放棄することを計画しており、そのリリースは2021年の終わりに予定されています。そのリリースでは、互換性のある実行可能環境の1つ（たとえば、containeredまたはCRI-O）に切り替える必要があります。選択した環境が、使用しているDockerデーモン構成（ロギングなど）をサポートしていることを確認してください。
このすべての混乱は何ですか、そしてなぜ誰もがそんなに心配しているのですか？
実際、2つのまったく異なる環境について話しているため、混乱が生じます。 Kubernetesクラスター内には、コンテナーイメージのロードと実行を担当する、いわゆるコンテナーランタイムがあります。また、Dockerは、この環境を整理するためのツールとして非常に人気があります（containerdとCRI-Oも広く知られています）。ただし、DockerはKubernetesに組み込まれるように設計されていないため、これには多くの問題があります。
「Docker」は独立したツールではなく、テクノロジースタック全体であり、そのコンポーネントの1つは「containerd」と呼ばれます（これについては、ここで詳しく説明します-約Transl。）コンテナの高レベルのランタイムとして機能します。 Dockerは、開発中にこのツールを操作するプロセスを大幅に簡素化するユーザー向けのアドオンが多数あるため、人気があり便利です。ただし、Kubernetesは人間ではないため、これらすべてのUX拡張機能は必要ありません。
このユーザーフレンドリーなレベルの抽象化により、Kubernetesクラスターは別のツールであるDockershimを使用して、本当に必要なものであるコンテナーに到達する必要があります。そして、これは悪いことです。なぜなら、そのような追加のレイヤーはサービスが必要であり、「壊れる」可能性もあるからです。実際には、次のことがわかります。Kubernetesv1.23では、DockershimがKubeletから削除されます。したがって、Dockerはコンテナランタイムとしてのサポートを失います。疑問が生じます：containerdがすでにDockerスタックに含まれている場合、KubernetesがDockershimを必要とするのはなぜですか？
重要なのは、DockerはContainer RuntimeInterfaceと互換性がないということです。（CRI）。互換性があれば、追加のレイヤーは必要なく、すべてが素晴らしいでしょう。しかし、これは世界の終わりではなく、パニックの理由でもありません。Dockerランタイムをサポートされているランタイムに置き換えるだけです。通常のワークフローの一部として
Dockerのソケット（
/var/run/docker.sock
）を使用する場合、別の環境に切り替えた後は、Dockerのソケットを使用できなくなることに注意してください。このパターンは、「DockerinDocker」と呼ばれることがよくあります。この問題を回避するためのさまざまなツールがあります。たとえば、kaniko、img、buildahなどです。
この変更は開発者にどのように影響しますか？それでもDockerfilesを作成しますか？Dockerを使用してイメージを作成しますか？
この話題の変更は、ほとんどの人がDockerと対話するために使用する環境とはまったく異なる環境に関するものです。開発用のDockerのインストールは、Kubernetesクラスター内のランタイムとは何の関係もありません。はい、これは紛らわしいです、私は知っています...
革新の後でも、Dockerは開発者にとって同じ便利なツールであり続けます。 Dockerで生成されたイメージは、Docker以外のものでも機能します。これらは完全なOCIイメージです。 OCI準拠のイメージは、構築されたツールに関係なく、Kubernetesで同じように見えます。containerdとCRI-Oは、これらのイメージをフェッチして実行するのに優れています。これが、コンテナ標準が作成された理由です。
だから、変化が来ています。もちろん、特定の問題に遭遇する人もいます。しかし、進歩はクールなことなので、後悔したり心配したりすることは何もありません。 Kubernetesの使用方法に応じて、これは完全に何もしないか、最小限の労力で済むことを意味します。長期的には、そのような革新は物事を容易にするだけです。
今後の変更でまだ混乱している場合は、問題ありません。 Kubernetesには多くの可動部品があり、100％専門家は誰もいません。経験レベルや難易度に関係なく、お気軽にご質問ください！私たちの目標は、今後の変更に向けて可能な限りすべての人を準備することです。 <3この投稿があなたの質問のほとんどに答え、すべての懸念や懸念を払拭したことを願っています！
もっと答えが必要ですか？Dockershimの非推奨に関するFAQを確認してください。
翻訳者からのPS
また、Redditのこのトピックに関するディスカッションで、Kubernetes開発者の1人であるTimHockinからの詳細な回答を見つけることができます。
私たちのブログも読んでください：