慌てないで: Kubernetes と Docker

バージョン 1.20 以降、Kubernetes はコンテナ ランタイムとして Docker を使用することをサポートしなくなります。

慌てないでください。大きな影響はありません。

[[355749]]

要約: ここでは、基盤となるランタイムとして Docker を使用することは推奨されません。 Kubernetes 専用に作成された Container Runtime Interface (CRI) を使用して、これまでどおりクラスター内で Docker イメージを実行できます。

Kubernetes エンドユーザーにとっても、この調整による影響はそれほど大きくありません。 Docker はなくなるわけではなく、開発ツールとして引き続き Docker を使用できます。 Docker は今後も無数のコンテナを構築し続け、docker build コマンドを実行して生成されたイメージは Kubernetes クラスター内で引き続き正常に実行できます。

GKE や EKS などのマネージド Kubernetes サービスを使用している場合は、将来の Kubernetes バージョンで Docker サポートが完全に削除される前に、ワーカー ノードにサポートされているコンテナ ランタイムがあることを確認する必要があります。ノードにカスタマイズが含まれている場合は、現在の環境とランタイム要件に基づいてそれらを更新する必要がある場合があります。サービス プロバイダーと協力して、アップグレードのテストと計画が適切に完了するようにしてください。

クラスターが継続的にロールアウトされる場合は、サービスの中断を回避するために変数を使用する必要があります。バージョン 1.20 では、Docker の非推奨警告が表示されます。 Kubernetes の将来のバージョン (バージョン 1.23、2021 年後半にリリース予定) では、Docker ランタイムは完全に削除され、サポートされなくなります。その後、containerd や CRI-O などの互換性のある他のコンテナ ランタイムに切り替える必要があります。選択したランタイムが、使用している Docker デーモン構成 (ログ記録など) をサポートしていることを確認してください。

問題は深刻ではないのに、なぜ人々はパニックに陥っているのでしょうか?彼らは何を恐れているのでしょうか?

ここでは 2 つの異なる環境を調査する必要がありますが、パニックの原因はここにあります。まず、Kubernetes クラスター内にはコンテナ ランタイムと呼ばれるものがあり、コンテナ イメージの抽出と実行を担当します。 Docker は現在最も人気のあるランタイム オプションです (他の一般的なオプションには containerd と CRI-O があります)。しかし、Docker は Kubernetes に組み込むように設計されていないため、問題が発生する可能性があります。

明らかに、ここで言及した「Docker」は同じものではありません。これはテクノロジー スタック全体を表し、containerd 高度なコンテナー ランタイムは Docker の一部です。 Docker はクールで便利であり、開発プロセス中に簡単に共同作業できるさまざまなユーザー エクスペリエンス強化を提供します。ただし、Kubernetes は人間の協力者になることを目的としていないため、Kubernetes ではユーザー エクスペリエンスの強化は必要ありません。

その結果、人間に優しい抽象化レイヤーである containerd が機能するためには、Kubernetes クラスターに Dockershimi と呼ばれる別のツールを導入する必要があります。しかし、このツールの導入により、追加のメンテナンスを行う必要があり、そうしないとセキュリティ上の問題が発生する可能性があるため、新たな問題が発生しました。実際、Dockershim は Kubelet バージョン 1.23 の時点ですでに削除されており、言い換えれば、Kubelet は Docker をコンテナ ランタイムとして使用する機能をかなり早い段階でキャンセルしました。この時点で、Docker スタックにはすでに containerd が含まれているのに、なぜ Kubernetes が Dockershim を作成する必要があるのか​​と疑問に思う人も多いでしょう。

これは、Docker が CRI (Container Runtime Interface) と互換性がないためです。まさに互換性がないために、これをバッファリングするために Dockershim が必要なのです。しかし、これは大したことではなく、慌てる必要はありません。コンテナ ランタイムを Docker からサポートされている別のオプションに切り替えるだけです。

基盤となる Docker ソケット (/var/run/docker.sock) がクラスター ワークフローの一部としてセットアップされている場合、別のランタイムに切り替えると、ビジネスの通常の運用が中断されることに注意してください。このパターンは Docker in Docker として知られており、幸いなことに、Kaniko、Img、Buildah など、この特定のユースケースを解決するためのオプションが多数あります。

しかし、この変更は開発者にとって何を意味するのでしょうか?まだ Dockerfile を書く必要がありますか?今後も Docker を使い続けるべきでしょうか?

この変更は、ほとんどの人が Docker を操作するために使用する環境とは異なる環境に影響することに注意してください。開発で使用する Docker インストールは、Kubernetes クラスター内の Docker ランタイムとはまったく関係ありません。そうですね、ちょっとわかりにくいですね。要約すると、開発者にとって、この変更を発表する前に Docker が提供していたすべてのオプションは引き続き適用されます。 Docker によって生成されるイメージは実際には Docker に固有のものではなく、より正確には OCI (Open Container Initiative) イメージに属するものと言えます。 OCI 互換イメージは、ビルドに使用されたツールに関係なく、Kubernetes にとっては同じに見えます。 Containerd と CRI-O はどちらもこれらのイメージを認識し、正常に実行できるため、統一されたコンテナ標準を確立する意義があります。

したがって、変更が行われ、一部のユーザーには問題が発生するものの、その影響は大きくありません。そして、長い目で見れば、これは実は良いことなのです。つまり、誰もが抵抗やパニックを脇に置いて、この変化を冷静に受け入れることができることを願っています。