Dockershim は必要ありません: Docker Desktop with Kubernetes 1.24+

Docker Desktop には Kubernetes が含まれており、高速で気を散らすことのない開発者エクスペリエンスのために最適化および調整されています。 アップストリームの Kubernetes の変更を追跡し、Kubernetes のアップグレードを管理するため、開発者はクラスターの管理ではなくコードに集中できます。 多くの人々が、アップストリームのKubernetesから「dockershim」と呼ばれるコンポーネントを削除することと、これがDocker Desktopにどのように影響するかについて私たちに尋ねてきました。 誰にも影響しません最近の4.7.0リリースでは、Kubernetesを「dockershim」から「cri-dockerd」にすでに切り替えているためです。 

Docker Desktop を使用している開発者として、何かする必要がありますか?

いいえ、何もする必要はありません、すべてが以前と同じように機能し続けます。 画像や開発者のワークフローを変更する必要はありません。 昨日 Kubernetes で dockershim を使用して実行したイメージは、dockershim なしで Kubernetes 1.24 で変更されずに実行されます。

Docker Desktop を使用する開発者として、運用環境で使用されるコンテナー ランタイムの実装に注意する必要がありますか?

いいえ、コンテナの「ランタイム」はKubernetesの実装の詳細であり、それについて考える必要はありません。 イメージやコンテナーを再構築する必要はありません。 Dockerは、業界標準のOCI仕様を開拓して、コンテナが任意のランタイムのどこでも実行できるようにしました。 

リモート Kubernetes クラスター内のコンテナーに Docker ソケットをバインドマウントする必要がある場合はどうすればよいですか?

Docker エンジンがまだ Kubernetes ワーカー ノードにインストールされている場合は、以前と同様に Docker ソケットをバインド マウントできます。 リモート Kubernetes クラスターで Docker ランタイムを使用する必要はありません。

港湾労働者は正確に何をしましたか?

Kubernetesの初期のバージョンでは、「dockershim」(「shim」はKubernetes内部APIとDocker APIの間の小さな接着剤レイヤーを意味する)と呼ばれる内部Kubernetesパッケージを介して、Docker APIを使用して直接コンテナを作成していました。 その後、Kubernetesプロジェクトは、と呼ばれる新しいインターフェイスを介してコンテナを作成する機能を獲得しました。 コンテナー ランタイム インターフェイス (CRI) .バージョン1.24まで、KubernetesはDockerエンジンを使用して、古い「dockershim」を使用する方法と新しい「dockershim」を使用する2つの異なる方法でコンテナを管理することができました。 ドッカーCRIの実装 差出人 ミランティス (投稿を参照してください 「ドッカーシムの未来はクリドッカードです」). Kubernetes の管理と保守を容易にするために、古い "dockershim" が削除され、すべてのコンテナー管理が新しい CRI を介して行われるようになりました。

Docker Desktop は、既に古い dockershim から新しい Docker CRI 実装にバージョンで切り替えられています 4.7.0そのため、Kubernetes から dockershim を削除しても、Docker Desktop には影響しません。

コンテナ化はどうですか?

2016年に、Dockerは「containerd」(DockerとKubernetesの両方で共有できるコンテナランタイム)でGoogleとの協力を開始しました。 dockerdの低レベル部分はコンテナに移動されました。 今日、DockerデスクトップのすべてのインスタンスにDockerdとコンテナが並んでいます。 ここDockerでは、開発者に優れた新機能を提供するために、dockerdとcontainerdの両方を改善することに取り組んでいます。

Docker に組み込まれている Kubernetes ディストリビューションの利点

Docker Desktop は、最新の Kubernetes の最適化されたディストリビューションを含めることで、開発者の時間と労力を節約します。 1 つのチェックボックスで有効になります。

開発者は、Dockerの共有イメージストアと クリドッカード.

Docker Desktop は、ホスト上のネットワーク ポートを自動的にバインドし、トラフィックを Kubernetes にトンネリングするため、開発者は内部 IP アドレスを覚えたり、DNS を再構成したりすることなく、アプリケーションをすぐに操作できます。

Docker Desktop は、コンテナーと Kubernetes の実行に伴う複雑さをすべて管理し、開発者がクラスター管理ではなくコードに集中できるようにします。 ローカルクラスタのアップグレードについて心配したり、CNIプラグインやコンテナランタイムを選択したりする必要はありません。 Docker に組み込まれている Kubernetes について詳しく知りたい場合は、ブログ記事をご覧ください 「Kubernetes が Docker Desktop で内部でどのように機能するか」.

カスタム Kubernetes インストールの管理は複雑な作業です。 ザ DIYソリューションよりもDockerデスクトップを使用する利点 複雑さはあなたのために処理されるということです。 Kubernetes からの dockershim の削除はその一例です。 DIYソリューションでは、移行を自分で整理してから、すべての開発者のデスクトップにソリューションを展開する必要があります。 そのため、開発者は開発に集中できます。 Docker Desktop が管理者の面倒を見ます. 

落ち着いて、自信を持ってDockerデスクトップを更新してください: 最新の Kubernetes を最新の Docker ツールと統合し、すべて完全にテストしてすぐに使用できます。