Kubernetes は、次の 1.24 リリースで dockershim の非推奨化と削除を進めている。Kubernetes クラスタのコンテナランタイムとして Docker Engine を使用するワークフローとシステムは、1.24 リリースにアップグレードする前に移行する必要がある。1.23 リリースは dockershim を保持し、1年間サポートされる。
Docker は、Kubernetes で使用された最初のコンテナランタイムだった。元々、Docker サポートは Kubernetes にハードコードされていたが、プロジェクトが発展するにつれて、Kubernetes はより多くのランタイムのサポートを追加し始めた。Kubernetes コミュニティは、サードパーティのソリューションをコアコードに直接統合するのではなく、より構造化された標準化されたインターフェースに移行することを決定した。これにより、Container Runtime Interface (CRI)、Container Network Interface (CNI)、および Container Storage Interface (CSI) が作成された。
Mirantis の CTO である Adam Parco 氏は述べている:
ほとんどの人にとって、dockershim の非推奨化は問題ではありません。なぜなら、それに気付いていないとしても、実際に Docker 自体を使用していないためです。彼らは CRI に準拠した containered を使用しています。これらの人々にとって、何も変わらないでしょう。
Docker は CRI に準拠していないため、dockershim は kubelet と Docker 間の変換レイヤとして機能する。次に、Docker は containerd とインターフェースして、コンテナを実行する。Containerd は、自身のコンテナのコンテナランタイムとして Docker から抽出され、最初の CRI 準拠のランタイムになった。dockershim を非推奨にする変更により、kubelet は containerd などのコンテナランタイムと直接通信するようになる。
Kubernetes ブログの最近の投稿で指摘されたように、dockershim からの移行は、Kubernetes コードベースを新しいインターフェースモデルにより適切に調整することだ。cgroups v2 や user ネームスペースなどのいくつかの新機能は、dockershim とほとんど互換性がない。この最近のブログ投稿の著者は次のように述べている。「Docker と dockershim への依存は、CNCF エコシステムのさまざまなツールやプロジェクトに忍び込み、壊れやすいコードになっている。」
Docker をアプリケーションコンテナの構築に使用している場合でも、これらのコンテナは任意のコンテナランタイムで実行できる。代替コンテナランタイムを使用する場合、Docker コマンドが機能しないか、異なる結果が生成される可能性がある。たとえば、docker ps または docker inspect は、コンテナ情報を取得するためには使用できなくなり、docker exec は機能しなくなる。
dockershim への依存関係を判断するために注意すべき他の事項に、特権 Pod が docker ps などの Docker コマンドを実行したり、Docker サービスを再起動したり、Docker 固有のファイルを変更したりしないようにすることなどがある。Docker 構成ファイルで、プライベートレジストリまたはイメージミラー設定を確認する必要がある。それらが存在する場合、多くの場合、別のランタイム用に再構成する必要がある。
Docker コマンドを特定するために、Kubernetes インフラストラクチャの外側で実行されるスクリプトを確認する必要がある。これには、トラブルシューティングのためのノードへの SSH、ノード起動スクリプト、またはノードに直接インストールされる監視およびセキュリティエージェントなどだ。
Mirantis と Docker は、dockershim コードを Kubernetes の CRI インターフェースに準拠した、オープンソースのスタンドアロンとして維持するための提携に合意した。これは、Mirantis Container Runtime (MCR) が CRI 準拠になることを意味する。彼らの cri-dockerd は、dockershim をやめることが望ましくない、または実行可能でない場合に、dockershim の外部の代替品として活用することができる。
Kubernetes 1.24 リリースチームと CNCF は、現在4月に予定されているリリースに間に合うようにドキュメントを提供することを約束した。これには、ブログ投稿、コードサンプルの更新、チュートリアル、および移行ガイドなどがある。
チームは、移行を進める上で大きな障害はもうないと考えている。彼らは、延期に関する議論が最近11月11日に SIG Node で議論されたことと12月6日に Kubernetes運営委員会の会議で行われたことに注目している。ただし、現時点では、次の 1.24 リリースで dockershim の削除を進めることに同意している。