pageKubernetesドキュメントタスククラスターの管理dockershimからの移行dockershim削除の影響範囲を確認するdockershim削除の影響範囲を確認するKubernetesのdockershimコンポーネントは、DockerをKubernetesのコンテナランタイムとして使用することを可能にします。Kubernetesの組み込みコンポーネントであるdockershimはリリースv1.24で削除されました。このページでは、あなたのクラスターがどのようにDockerをコンテナランタイムとして使用しているか、使用中のdockershimが果たす役割について詳しく説明し、dockershimの削除によって影響を受けるワークロードがあるかどうかをチェックするためのステップを示します。自分のアプリがDockerに依存しているかどうかの確認アプリケーションコンテナの構築にDockerを使用している場合でも、これらのコンテナを任意のコンテナランタイム上で実行することができます。このようなDockerの使用は、コンテナランタイムとしてのDockerへの依存とはみなされません。代替のコンテナランタイムが使用されている場合、Dockerコマンドを実行しても動作しないか、予期せぬ出力が得られる可能性があります。docker.serviceなどのコマンド)、Docker固有のファイル(/etc/docker/daemon.jsonなど)を変更しないことを確認すること。)にプライベートレジストリやイメージミラーの設定がないか確認します。これらは通常、別のコンテナランタイムのために再設定する必要があります。Kubernetesインフラストラクチャーの外側のノードで実行される以下のようなスクリプトやアプリがDockerコマンドを実行しないことを確認します。トラブルシューティングのために人間がノードにSSHで接続ノードのスタートアップスクリプトノードに直接インストールされた監視エージェントやセキュリティエージェント上記のような特権的な操作を行うサードパーティツール。dockershimの動作に間接的な依存性がないことを確認します。これはエッジケースであり、あなたのアプリケーションに影響を与える可能性は低いです。ツールによっては、Docker固有の動作に反応するように設定されている場合があります。特定のメトリクスでアラートを上げたり、トラブルシューティングの指示の一部として特定のログメッセージを検索したりします。そのようなツールを設定している場合、移行前にテストクラスターで動作をテストしてください。Podを構成するコンテナを実行できるソフトウェアです。KubernetesはPodのオーケストレーションとスケジューリングを担当し、各ノードではkubeletがコンテナランタイムインターフェースを抽象化して使用するので、互換性があればどのコンテナランタイムでも使用することができます。その後、Kubernetesプロジェクトの歴史の中で、クラスター運用者は追加のコンテナランタイムを採用することを希望しました。CRIはこのような柔軟性を可能にするために設計され、kubeletはCRIのサポートを開始しました。DockerはCRI仕様が考案される前から存在していたため、Kubernetesプロジェクトはアダプタコンポーネント「dockershim」を作成しました。dockershimアダプターは、DockerがCRI互換ランタイムであるかのように、kubeletがDockerと対話することを可能にします。GAブログ記事で紹介されています。コンテナランタイムとしてContainerdに切り替えることで、中間マージンを排除することができます。これまでと同じように、Containerdのようなコンテナランタイムですべてのコンテナを実行できます。今は、コンテナはコンテナランタイムで直接スケジュールするので、Dockerからは見えません。そのため、これらのコンテナをチェックするために以前使っていたかもしれないDockerツールや派手なUIは、もはや利用できません。inspectを使用してコンテナ情報を取得することはできません。execを使用してコンテナ内で何かを実行したりすることもできません。APIを経由することです(このアドバイスはDockerだけでなく、すべてのコンテナランタイムに適用されます)。buildコマンドを使用してビルドすることは可能です。Dockerによってビルドまたはプルされたイメージは、コンテナランタイムとKubernetesからは見えません。Kubernetesで使用できるようにするには、何らかのレジストリにプッシュする必要がありました。京ICP备17074266号-3。