Kubernetes Kubernetes v1.20.0-rc.0 の最新バージョンが利用可能になりました。 Kubernetesプロジェクトは、kubeletでの Docker Engineのサポートを非推奨 にする予定であり、dockershimのサポートは将来のリリースで、おそらく来年後半に削除される予定です。 net/net is は、Docker ツールで構築されたコンテナー イメージのサポートが非推奨ではなく、以前と同じように機能します。
しかし、さらに良いニュースは、MirantisとDockerが、Docker Engineの準拠CRIインターフェイスとして、Kubernetesの外部でshimコードをスタンドアロンで維持するために提携することに合意したことです。 https://github.com/dims/cri-dockerd 、 Dims の素晴らしい初期プロトタイプから始めますそして、 https://github.com/Mirantis/cri-dockerd でオープンソースプロジェクトとして利用できるようにし続けます。 つまり、組み込みの Dockershim から外部に切り替えるだけで、以前と同様に Docker Engine に基づいて Kubernetes を引き続き構築できます。 DockerとMirantisは、以前と同じように機能し続け、すべてのコンフォーマンステストに合格し、組み込みバージョンと同じように機能することを確認するために協力します。 Dockerは、優れた開発者エクスペリエンスを提供するため、Docker Desktopでこのシムを出荷し続け、MirantisはこれをMirantis Kubernetes Engineで使用します。
Docker と Kubernetes を使用している場合、これはどのような意味がありますか?
最初です 焦らないで下さい 🙂 開発者は引き続き Docker プラットフォームを使用して、Kubernetes 上でコンテナーを構築、共有、実行できます。 この変更は主に Kubernetes のオペレーターと管理者に影響し、開発者のワークフローには影響しません。 Docker がビルドするイメージは OCI (Open Container Initiative) に準拠しており、コンテナで完全にサポートされており、引き続き Kubernetes で適切に実行されます。
Docker を使用している場合は、既にコンテナー型を使用しています。 Dockerのランタイムはコンテナ化に基づいて構築され、その周りで優れた開発者エクスペリエンスを提供します。 Kubernetes などの最小限のコンテナー ランタイムの恩恵を受け、Docker の優れた開発者エクスペリエンスを必要としない可能性がある運用環境では、containerd などの軽量ランタイムを直接使用するのが妥当です。
Dockerは、完全に相互運用可能なコンテナ標準をサポートし、すべてのコンテナがあらゆる環境で実行できるようにするために、2015年に オープンコンテナイニシアチブ (OCI)を設定しました。 これは、相互運用性を維持しながらイノベーションを促進する上で大きな成功を収めています。
Dockerは、この移行を念頭に置いて、2016年にGoogleおよびIBMとともにコンテナプロジェクトを作成しました。 docker-shim (およびランタイムとしての Docker Engine) の廃止は、Kubernetes に最新のランタイムを提供するという長期的な取り組みの完了を示しています。 Containerd は、Docker と Kubernetes の両方をそれぞれ最も適切な方法で使用するためのコアの低レベルで拡張可能なランタイムとして作成されました。
Containerdは 2017年にCNCFに寄付され、Kubernetesとのインターフェースにコンテナ化されたCRIプロジェクトを組み込むまでに成長し、Amazon、Google、Microsoft、IBMを含む業界全体から多くのイノベーションと投資が見られました。
2019年には、最高のプロジェクトレベルである段階的なCNCFプロジェクトになり、その成熟度を示し、このステータスを持つ唯一のコンテナランタイムであり続けています。 ここ数年、AWSやGoogleなどの主要なKubernetesサービスプロバイダーは、KubernetesランタイムとしてContainerdに移行してきました。 この減価償却のプロセスは、この作業とコンテナ周辺の繁栄しているコミュニティの大きな成功を反映しています。
Docker ツールでビルドされたコンテナー イメージのサポートは非推奨ではありません。
Docker ツールを使用してビルドしたコンテナー イメージは、引き続き Kubernetes で実行されます。 次世代ビルドインフラストラクチャであるBuildkitは柔軟なアーキテクチャを備えているため、Dockerのビルダーとして使用できますが、Dockerが利用できない可能性のあるインフラストラクチャで使用するために、代わりにコンテナまたはruncと直接通信することもできます。
Dockerはコンテナ開発に取り組んでいます:インフラストラクチャがホストされている場所と方法に関係なく、Dockerビルドを使用できるように、成長するビルドキットコミュニティとともに、さらなる投資を続けていきます。
Docker イメージをローカルおよび Kubernetes クラスターで引き続きビルドして実行できますが、この非推奨はそのエクスペリエンスには影響しません。
では、Kubernetesプロジェクトは何を非推奨にしていますか?
Kubernetesは、Docker Engineと通信するKubernetesのkubelet実装のコンポーネントである dockershimを非推奨にします。 アルノー・ポルテリーは、 彼がここで共有したこれについていくつかの素晴らしい考えを持っていました。
Kubernetes プロジェクトでもこの FAQ が公開されています。 Kat Cosgroveは、 ここで変更を非常に簡単に説明してくれました。
これは開発者と管理者にとって何を意味しますか?
現在、および Kubernetes v1.20 では、Kubernetes 管理者は引き続き docker コマンドと kubectl コマンドを使用して Kubernetes クラスターを管理できます。
Kubernetes 管理者は、 今後 dockershim を使用できるようになります。 MirantisとDockerのブログで、dockershimの将来とスタンドアロンのshimのインストール方法に関する最新情報を入手してください。
Kubernetes の将来のリリース (今後いくつかのマイナー リリース) では、内部 Dockershim のサポートが最終的に Kubernetes の kubelet から削除されるとき、Kubernetes 管理者は、Kubernetes クラスターを検査するための Docker コマンドが引き続き機能するように、いくつかの変更を加える必要があります。 開発者は引き続き Docker ツールを使用して docker build、 docker push docker run Kubernetes 上のコンテナーとコンテナー イメージを使用できます。
さらなる背景
KEP-1985: Kubelet から Dockershim を削除するための Kubernetes 拡張提案
問。 フィードバック。
質問やその他のフィードバックがある場合は 、DockerのSlack にお問い合わせください。