Change:
This is a Feature Request <!-- Please only use this template for submitting feature/enhancement requests --<!-- See for guidance on writing an actionable issue description. --What would you like to be <!-- Describe as precisely as possible how this feature/enhancement should work from the user perspective. What should be changed, etc. --Add japanese translations of the contents listed below: {{% dockershim-removal %}} block Why is this needed Comments <!-- Any additional related comments that might help. Drawings/mockups would be extremely helpful (if required). --ref.
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
/assign
/language ja

Discussion:
経験の多寡や難易度にかかわらず、どんなことでも質問してください。我々の目標は、全ての人が将来の変化について、可能な限りの知識と理解を得られることです。 このブログが多くの質問の答えとなり、不安を和らげることができればと願っています。 <del> 別の情報をお探してあれば、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)を参照してください。 </del> <ins> 別の情報をお探しであれば、[dockershimの削除に関するFAQ](/ja/dockershim)を参照してください。 </ins>

<ins> --- layout: blog title: "更新: dockershimの削除に関するFAQ" linkTitle: "dockershimの削除に関するFAQ" date: 2022-02-17 slug: dockershim-faq aliases: [ '/ja/dockershim' ] --- **この記事は2020年の後半に投稿されたオリジナルの記事[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)の更新版です。 この記事にはv1.24のリリースに関する更新を含みます。** --- この文書では、Kubernetesからの _dockershim_ の削除に関するよくある質問について説明します。 この削除はKubernetes v1.20リリースの一部としてはじめて[発表](/blog/2020/12/08/kubernetes-1-20-release-announcement/)されたものです。 Kubernetes [v1.24のリリース](/releases/#release-v1-24)においてdockershimは実際にKubernetesから削除されました。 これが何を意味するかについては、ブログ記事[Don't Panic: Kubernetes and Docker](/ja/blog/2020/12/02/dont-panic-kubernetes-and-docker/)をご覧ください。 [dockershim削除の影響範囲を確認する](/ja/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)をお読みいただくことで、 dockershimの削除があなたやあなたの組織に与える影響をご判断いただけます。 Kubernetes 1.24リリースに至るまでの間、Kubernetesコントリビューターはこの移行を円滑に行えるようにするために尽力してきました。 - 私たちの[コミットメントと次のステップ](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)を詳述したブログ記事。 - [他のコンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/#container-runtimes)への移行に大きな障害があるかどうかのチェック。 - [dockershimからの移行](/ja/docs/tasks/administer-cluster/migrating-from-dockershim/)ガイドの追加。 - [dockershimの削除とCRI互換ランタイムの使用に関する記事一覧](/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)の作成。 このリストには、上に示した文書の一部が含まれており、また、厳選された外部の情報(ベンダーによるガイドを含む)もカバーしています。 ### dockershimはなぜKubernetesから削除されたのですか？ Kubernetesの初期のバージョンは、特定のコンテナランタイム上でのみ動作しました。 Docker Engineです。その後、Kubernetesは他のコンテナランタイムと連携するためのサポートを追加しました。 オーケストレーター(Kubernetesなど)と多くの異なるコンテナランタイムの間の相互運用を可能にするため、 CRI標準が[作成](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/)されました。 Docker Engineはそのインターフェイス(CRI)を実装していないため、Kubernetesプロジェクトは移行を支援する特別なコードを作成し、 その _dockershim_ コードをKubernetes自身の一部としました。 dockershimコードは常に一時的な解決策であることを意図されていました(このためshimと名付けられています)。 コミュニティでの議論や計画については、[dockershimの削除によるKubernetes改良の提案][drkep]にてお読みいただけます。 実際、dockershimのメンテナンスはKubernetesメンテナーにとって大きな負担になっていました。 さらに、dockershimとほとんど互換性のなかった機能、たとえばcgroups v2やユーザーネームスペースなどが、 これらの新しいCRIランタイムに実装されています。Kubernetesからdockershimを削除することで、これらの分野でのさらなる開発が可能になります。 [drkep]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim ### Dockerとコンテナは同じものですか？ DockerはLinuxのコンテナパターンを普及させ、その基盤技術の発展に寄与してきましたが、 Linuxのコンテナ技術そのものはかなり以前から存在しています。 また、コンテナエコシステムはDockerを超えてより広範に発展してきました。 OCIやCRIのような標準は、Dockerの機能の一部を置き換えたり、既存の機能を強化したりすることで、 私達のエコシステムの多くのツールの成長と繁栄を助けてきました。 ### 既存のコンテナイメージは引き続き使えるのですか？ はい、`docker build`から生成されるイメージは、全てのCRI実装で動作します。 既存のイメージも全く同じように動作します。 ### プライベートイメージについてはどうでしょうか？ はい、すべてのCRIランタイムはKubernetesで使われているものと同一のpull secretsをサポートしており、 PodSpecまたはService Accountを通して利用できます。 ### Kubernetes 1.23でDocker Engineを引き続き使用できますか？ はい、1.20で変更されたのは、Docker Engineランタイムを使用している場合に警告ログが[kubelet]起動時に出るようになったことだけです。 この警告は、1.23までのすべてのバージョンで表示されます。 dockershimの削除はKubernetes 1.24で行われました。 Kubernetes v1.24以降を実行している場合は、[Docker Engineを引き続きコンテナランタイムとして利用できますか？](#can-i-still-use-docker-engine-as-my-container-runtime)をご覧ください。 (CRIがサポートされているKubernetesリリースを使用している場合、dockershimから切り替えることができることを忘れないでください。 リリースv1.24からはKubernetesにdockershimが含まれなくなったため、**必ず**切り替えなければなりません)。 [kubelet]: /docs/reference/command-line-tools-reference/kubelet/ ### どのCRIの実装を使うべきでしょうか？ これは難しい質問で、様々な要素に依存します。 もしDocker Engineがうまく動いているのであれば、containerdに移行するのは比較的簡単で、 性能もオーバーヘッドも確実に改善されるでしょう。 しかし、他の選択のほうがあなたの環境により適合する場合もありますので、 [CNCF landscape]にあるすべての選択肢を検討されることをおすすめします。 [CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category #### Docker Engineを引き続きコンテナランタイムとして利用できますか？ {#can-i-still-use-docker-engine-as-my-container-runtime} 第一に、ご自身のPCで開発やテスト用途でDockerを使用している場合、何も変わることはありません。 Kubernetesでどのコンテナランタイムを使っていても、Dockerをローカルで使い続けることができます。 コンテナではこのような相互運用性を実現できます。 MirantisとDockerは、Kubernetesから内蔵のdockershimが削除された後も、 Docker Engineの代替アダプターを維持することに[コミット][mirantis]しています。 代替アダプターの名前は[`cri-dockerd`](https://github.com/Mirantis/cri-dockerd)です。 `cri-dockerd`をインストールして、kubeletをDocker Engineに接続するために使用することができます。 詳細については、[Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)を読んでください。 [mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ ### 今現在でプロダクション環境に他のランタイムを使用している例はあるのでしょうか？ Kubernetesプロジェクトが生み出したすべての成果物(Kubernetesバイナリ)は、リリースごとに検証されています。 また、[kind]プロジェクトは以前からcontainerdを使っており、プロジェクトのユースケースにおいて安定性が向上してきています。 kindとcontainerdは、Kubernetesコードベースの変更を検証するために毎日何回も利用されています。 他の関連プロジェクトも同様のパターンを追っており、他のコンテナランタイムの安定性と使いやすさが示されています。 例として、OpenShift 4.xは2019年6月以降、CRI-Oランタイムをプロダクション環境で使っています。 他の事例や参考資料はについては、 containerdとCRI-O(Cloud Native Computing Foundation ([CNCF])の2つのコンテナランタイム)の採用例をご覧ください。 - [containerd](https://github.com/containerd/containerd/blob/master/ADOPTERS.md) - [CRI-O](https://github.com/cri-o/cri-o/blob/master/ADOPTERS.md) [CRI-O]: https://cri-o.io/ [kind]: https://kind.sigs.k8s.io/ [CNCF]: https://cncf.io ### OCIという単語をよく見るのですが、これは何ですか？ OCIは[Open Container Initiative]の略で、コンテナツールとテクノロジー間の数多くのインターフェースの標準化を行った団体です。 彼らはコンテナイメージをパッケージするための標準仕様(OCI image-spec)と、 コンテナを実行するための標準仕様(OCI runtime-spec)をメンテナンスしています。 また、[runc]という形でruntime-specの実装もメンテナンスしており、 これは[containerd]と[CRI-O]の両方でデフォルトの下位ランタイムとなっています。 CRIはこれらの低レベル仕様に基づいて、コンテナを管理するためのエンドツーエンドの標準を提供します。 [Open Container Initiative]: https://opencontainers.org/about/overview/ [runc]: https://github.com/opencontainers/runc [containerd]: https://containerd.io/ ### CRI実装を変更する際に注意すべきことは何ですか？ DockerとほとんどのCRI(containerdを含む)において、下位で使用されるコンテナ化コードは同じものですが、 いくつかの細かい違いが存在します。移行する際に考慮すべき一般的な事項は次のとおりです。 - ログ設定 - ランタイムリソースの制限 - ノード構成スクリプトでdockerコマンドやコントロールソケット経由でDocker Engineを使用しているもの - `kubectl`のプラグインで`docker` CLIまたはDocker Engineコントロールソケットが必要なもの - KubernetesプロジェクトのツールでDocker Engineへの直接アクセスが必要なもの(例:廃止された`kube-imagepuller`ツール) - `registry-mirrors`やinsecureレジストリなどの機能の設定 - その他の支援スクリプトやデーモンでDocker Engineが利用可能であることを想定していてKubernetes外で実行されるもの(モニタリング・セキュリティエージェントなど) - GPUまたは特別なハードウェア、そしてランタイムおよびKubernetesとそれらハードウェアの統合方法 あなたがKubernetesのリソース要求/制限やファイルベースのログ収集DaemonSetを使用しているのであれば、それらは問題なく動作し続けますが、 `dockerd`の設定をカスタマイズしていた場合は、それを新しいコンテナランタイムに適合させる必要があるでしょう。 他に注意することとしては、システムメンテナンスを実行するようなものや、コンテナ内でイメージをビルドするようなものが動作しなくなります。 前者の場合は、[`crictl`][cr]ツールをdrop-inの置き換えとして使用できます([docker cliからcrictlへのマッピング](https://kubernetes.io/ja/docs/tasks/debug/debug-cluster/crictl/#docker-cli%E3%81%8B%E3%82%89crictl%E3%81%B8%E3%81%AE%E3%83%9E%E3%83%83%E3%83%94%E3%83%B3%E3%82%B0)を参照)。 後者の場合は、[img]、[buildah]、[kaniko]、[buildkit-cli-for-kubectl]のようなDockerを必要としない新しいコンテナビルドの選択肢を使用できます。 [cr]: https://github.com/kubernetes-sigs/cri-tools [img]: https://github.com/genuinetools/img [buildah]: https://github.com/containers/buildah [kaniko]: https://github.com/GoogleContainerTools/kaniko [buildkit-cli-for-kubectl]: https://github.com/vmware-tanzu/buildkit-cli-for-kubectl containerdを使っているのであれば、[ドキュメント]を参照して、移行するのにどのような構成が利用可能かを確認するところから始めるといいでしょう。 [ドキュメント]: https://github.com/containerd/cri/blob/master/docs/registry.md containerdとCRI-OをKubernetesで使用する方法に関しては、[コンテナランタイム]に関するKubernetesのドキュメントを参照してください。 [コンテナランタイム]: /ja/docs/setup/production-environment/container-runtimes/ ### さらに質問がある場合どうすればいいでしょうか？ ベンダーサポートのKubernetesディストリビューションを使用している場合、彼らの製品に対するアップグレード計画について尋ねることができます。 エンドユーザーの質問に関しては、[エンドユーザーコミュニティフォーラム](https://discuss.kubernetes.io/)に投稿してください。 dockershimの削除に関する決定については、専用の[GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917)で議論することができます。 変更点に関するより詳細な技術的な議論は、[待ってください、DockerはKubernetesで非推奨になったのですか？][dep]という素晴らしいブログ記事も参照してください。 [dep]: https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m ### dockershimを使っているかどうかを検出できるツールはありますか？ はい！[Detector for Docker Socket (DDS)][dds]というkubectlプラグインをインストールすることであなたのクラスターを確認していただけます。 DDSは、アクティブなKubernetesワークロードがDocker Engineソケット(`docker.sock`)をボリュームとしてマウントしているかを検出できます。 さらなる詳細と使用パターンについては、DDSプロジェクトの[README][dds]を参照してください。 [dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket ### ハグしていただけますか？ はい、私達は引き続きいつでもハグに応じています。🤗🤗🤗 </ins>

Kubernetes 1.20で[dockershim deprecation](blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。 <del> この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。 </del> <ins> この問題をよりよく理解するために、[dockershimの削除に関するFAQ](/ja/dockershim)ブログが役に立つでしょう。 </ins> dockershimから代替のコンテナランタイムに移行することが推奨されます。 [コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)のセクションをチェックして、どのような選択肢があるかを確認してください。

<del> --- title: Dockershim非推奨の影響範囲を確認する content_type: task weight: 20 --- <!-- overview --> Kubernetesの`dockershim`コンポーネントは、DockerをKubernetesの{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}として使用することを可能にします。 Kubernetesの組み込みコンポーネントである`dockershim`はリリースv1.20で非推奨となりました。 このページでは、あなたのクラスターがどのようにDockerをコンテナランタイムとして使用しているか、使用中の`dockershim`が果たす役割について詳しく説明し、`dockershim`の廃止によって影響を受けるワークロードがあるかどうかをチェックするためのステップを示します。 ## 自分のアプリがDockerに依存しているかどうかの確認 {#find-docker-dependencies} アプリケーションコンテナの構築にDockerを使用している場合でも、これらのコンテナを任意のコンテナランタイム上で実行することができます。このようなDockerの使用は、コンテナランタイムとしてのDockerへの依存とはみなされません。 代替のコンテナランタイムが使用されている場合、Dockerコマンドを実行しても動作しないか、予期せぬ出力が得られる可能性があります。 このように、Dockerへの依存があるかどうかを調べることができます: 1. 特権を持つPodがDockerコマンド(`docker ps`など)を実行したり、Dockerサービスを再起動したり(`systemctl restart docker.service`などのコマンド)、Docker固有のファイル(`/etc/docker/daemon.json`など)を変更しないことを確認すること。 1. Dockerの設定ファイル(`/etc/docker/daemon.json` など)にプライベートレジストリやイメージミラーの設定がないか確認します。これらは通常、別のコンテナランタイムのために再設定する必要があります。 1. Kubernetesインフラストラクチャーの外側のノードで実行される以下のようなスクリプトやアプリがDockerコマンドを実行しないことを確認します。 - トラブルシューティングのために人間がノードにSSHで接続 - ノードのスタートアップスクリプト - ノードに直接インストールされた監視エージェントやセキュリティエージェント 1. 上記のような特権的な操作を行うサードパーティツール。詳しくは[Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) を参照してください。 1. dockershimの動作に間接的な依存性がないことを確認します。 これはエッジケースであり、あなたのアプリケーションに影響を与える可能性は低いです。ツールによっては、Docker固有の動作に反応するように設定されている場合があります。例えば、特定のメトリクスでアラートを上げたり、トラブルシューティングの指示の一部として特定のログメッセージを検索したりします。そのようなツールを設定している場合、移行前にテストクラスターで動作をテストしてください。 ## Dockerへの依存について解説 {#role-of-dockershim} [コンテナランタイム](/ja/docs/concepts/containers/#container-runtimes)とは、Kubernetes Podを構成するコンテナを実行できるソフトウェアです。 KubernetesはPodのオーケストレーションとスケジューリングを担当し、各ノードでは{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}がコンテナランタイムインターフェイスを抽象化して使用するので、互換性があればどのコンテナランタイムでも使用することができます。 初期のリリースでは、Kubernetesは1つのコンテナランタイムと互換性を提供していました: Dockerです。 その後、Kubernetesプロジェクトの歴史の中で、クラスター運用者は追加のコンテナランタイムを採用することを希望しました。 CRIはこのような柔軟性を可能にするために設計され、kubeletはCRIのサポートを開始しました。 しかし、DockerはCRI仕様が考案される前から存在していたため、Kubernetesプロジェクトはアダプタコンポーネント「dockershim」を作成しました。 dockershimアダプターは、DockerがCRI互換ランタイムであるかのように、kubeletがDockerと対話することを可能にします。 [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)ブログ記事で紹介されています。 ![Dockershim vs. CRI with Containerd](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png) コンテナランタイムとしてContainerdに切り替えることで、中間マージンを排除することができます。 これまでと同じように、Containerdのようなコンテナランタイムですべてのコンテナを実行できます。 しかし今は、コンテナはコンテナランタイムで直接スケジュールするので、Dockerからは見えません。 そのため、これらのコンテナをチェックするために以前使っていたかもしれないDockerツールや派手なUIは、もはや利用できません。 `docker ps`や`docker inspect`を使用してコンテナ情報を取得することはできません。 コンテナを一覧表示できないので、ログを取得したり、コンテナを停止したり、`docker exec`を使用してコンテナ内で何かを実行したりすることもできません。 {{< note >}} Kubernetes経由でワークロードを実行している場合、コンテナを停止する最善の方法は、コンテナランタイムを直接経由するよりもKubernetes APIを経由することです(このアドバイスはDockerだけでなく、すべてのコンテナランタイムに適用されます)。 {{< /note >}} この場合でも、イメージを取得したり、`docker build`コマンドを使用してビルドすることは可能です。 しかし、Dockerによってビルドまたはプルされたイメージは、コンテナランタイムとKubernetesからは見えません。 Kubernetesで使用できるようにするには、何らかのレジストリにプッシュする必要がありました。 </del>

<ins> --- title: dockershim削除の影響範囲を確認する content_type: task weight: 20 --- <!-- overview --> Kubernetesの`dockershim`コンポーネントは、DockerをKubernetesの{{< glossary_tooltip text="コンテナランタイム" term_id="container-runtime" >}}として使用することを可能にします。 Kubernetesの組み込みコンポーネントである`dockershim`はリリースv1.24で削除されました。 このページでは、あなたのクラスターがどのようにDockerをコンテナランタイムとして使用しているか、使用中の`dockershim`が果たす役割について詳しく説明し、`dockershim`の削除によって影響を受けるワークロードがあるかどうかをチェックするためのステップを示します。 ## 自分のアプリがDockerに依存しているかどうかの確認 {#find-docker-dependencies} アプリケーションコンテナの構築にDockerを使用している場合でも、これらのコンテナを任意のコンテナランタイム上で実行することができます。このようなDockerの使用は、コンテナランタイムとしてのDockerへの依存とはみなされません。 代替のコンテナランタイムが使用されている場合、Dockerコマンドを実行しても動作しないか、予期せぬ出力が得られる可能性があります。 このように、Dockerへの依存があるかどうかを調べることができます: 1. 特権を持つPodがDockerコマンド(`docker ps`など)を実行したり、Dockerサービスを再起動したり(`systemctl restart docker.service`などのコマンド)、Docker固有のファイル(`/etc/docker/daemon.json`など)を変更しないことを確認すること。 1. Dockerの設定ファイル(`/etc/docker/daemon.json` など)にプライベートレジストリやイメージミラーの設定がないか確認します。これらは通常、別のコンテナランタイムのために再設定する必要があります。 1. Kubernetesインフラストラクチャーの外側のノードで実行される以下のようなスクリプトやアプリがDockerコマンドを実行しないことを確認します。 - トラブルシューティングのために人間がノードにSSHで接続 - ノードのスタートアップスクリプト - ノードに直接インストールされた監視エージェントやセキュリティエージェント 1. 上記のような特権的な操作を行うサードパーティツール。詳しくは[Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents) を参照してください。 1. dockershimの動作に間接的な依存性がないことを確認します。 これはエッジケースであり、あなたのアプリケーションに影響を与える可能性は低いです。ツールによっては、Docker固有の動作に反応するように設定されている場合があります。例えば、特定のメトリクスでアラートを上げたり、トラブルシューティングの指示の一部として特定のログメッセージを検索したりします。そのようなツールを設定している場合、移行前にテストクラスターで動作をテストしてください。 ## Dockerへの依存について解説 {#role-of-dockershim} [コンテナランタイム](/ja/docs/concepts/containers/#container-runtimes)とは、Kubernetes Podを構成するコンテナを実行できるソフトウェアです。 KubernetesはPodのオーケストレーションとスケジューリングを担当し、各ノードでは{{< glossary_tooltip text="kubelet" term_id="kubelet" >}}がコンテナランタイムインターフェイスを抽象化して使用するので、互換性があればどのコンテナランタイムでも使用することができます。 初期のリリースでは、Kubernetesは1つのコンテナランタイムと互換性を提供していました: Dockerです。 その後、Kubernetesプロジェクトの歴史の中で、クラスター運用者は追加のコンテナランタイムを採用することを希望しました。 CRIはこのような柔軟性を可能にするために設計され、kubeletはCRIのサポートを開始しました。 しかし、DockerはCRI仕様が考案される前から存在していたため、Kubernetesプロジェクトはアダプタコンポーネント「dockershim」を作成しました。 dockershimアダプターは、DockerがCRI互換ランタイムであるかのように、kubeletがDockerと対話することを可能にします。 [Kubernetes Containerd integration goes GA](/blog/2018/05/24/kubernetes-containerd-integration-goes-ga/)ブログ記事で紹介されています。 ![Dockershim vs. CRI with Containerd](/images/blog/2018-05-24-kubernetes-containerd-integration-goes-ga/cri-containerd.png) コンテナランタイムとしてContainerdに切り替えることで、中間マージンを排除することができます。 これまでと同じように、Containerdのようなコンテナランタイムですべてのコンテナを実行できます。 しかし今は、コンテナはコンテナランタイムで直接スケジュールするので、Dockerからは見えません。 そのため、これらのコンテナをチェックするために以前使っていたかもしれないDockerツールや派手なUIは、もはや利用できません。 `docker ps`や`docker inspect`を使用してコンテナ情報を取得することはできません。 コンテナを一覧表示できないので、ログを取得したり、コンテナを停止したり、`docker exec`を使用してコンテナ内で何かを実行したりすることもできません。 {{< note >}} Kubernetes経由でワークロードを実行している場合、コンテナを停止する最善の方法は、コンテナランタイムを直接経由するよりもKubernetes APIを経由することです(このアドバイスはDockerだけでなく、すべてのコンテナランタイムに適用されます)。 {{< /note >}} この場合でも、イメージを取得したり、`docker build`コマンドを使用してビルドすることは可能です。 しかし、Dockerによってビルドまたはプルされたイメージは、コンテナランタイムとKubernetesからは見えません。 Kubernetesで使用できるようにするには、何らかのレジストリにプッシュする必要がありました。 </ins>

Kubernetes 1.20でdockershimは非推奨になりました。 <del> [Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)から、ほとんどのアプリがコンテナをホストするランタイムに直接依存しないことは既にご存知かもしれません。 </del> <ins> [dockershimの削除に関するFAQ](/ja/dockershim)から、ほとんどのアプリがコンテナをホストするランタイムに直接依存しないことは既にご存知かもしれません。 </ins> しかし、コンテナのメタデータやログ、メトリクスを収集するためにDockerに依存しているテレメトリーやセキュリティエージェントはまだ多く存在します。 この文書では、これらの依存関係を検出する方法と、これらのエージェントを汎用ツールまたは代替ランタイムに移行する方法に関するリンクを集約しています。

[deprecation_warning] other = " のドキュメントは積極的にメンテナンスされていません。現在表示されているバージョンはスナップショットです。最新のドキュメントはこちらです: " <ins> [dockershim_message] other = """dockershimは1.24のリリースをもってKubernetesプロジェクトから削除されました。詳しくは、<a href="/ja/dockershim">dockershimの削除に関するFAQ</a>をご覧ください。""" </ins> [docs_label_browse] other = "ドキュメントの参照"