K8s は Docker を廃止すると発表しましたが、慌てる必要はありません。

最近、Kubernetes はバージョン 1.20 以降で Docker のサポートを中止することを正式に発表しました。その時点で、ユーザーは Docker の非推奨警告を受け取り、他のコンテナ ランタイムに切り替える必要があります。

[[355838]]

画像はPexelsより

ただし、コンテナ イメージ構築ツールとしての Docker の役割は影響を受けず、Docker を使用して構築されたコンテナ イメージは、すべてのコンテナ ランタイムを使用してクラスター内で引き続き正常に実行されます。

KubernetesはDockerを廃止する

はい、本当です。Kubernetes は現在 Docker で非推奨になっています。

参考リンク:

 https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

現在、Kubelet での Docker サポートは非​​推奨となっており、将来のバージョンでは削除される予定です。

Kubelet は以前、Docker の CRI サポートを実装するために dockershim というモジュールを使用していました。

ただし、Kubernetes コミュニティではこれに関連するメンテナンスの問題が特定されているため、CRI の完全な実装 (v1alpha1 または v1 と互換性がある) を含む利用可能なコンテナ ランタイムの使用を検討することをお勧めします。

[[355839]]

つまり、Docker は CRI (Container Runtime Interface) や Kubernetes ランタイム API をサポートしておらず、Kubernetes ユーザーは「dockershim」と呼ばれるブリッジ サービスを使用してきました。

Dockershim は Docker API と CRI を変換できますが、以降のバージョンでは Kubernetes はこのブリッジ サービスを提供しなくなります。

もちろん、Docker 自体も開発環境を作成するための非常に強力なツールです。しかし、現状の理由を理解するには、既存の Kubernetes アーキテクチャにおける Docker の役割を完全に分析する必要があります。

Kubernetes は、複数の異なるコンピューティング リソース (仮想マシンや物理マシンなど) をグループ化し、アプリケーションで使用したり他のユーザーと共有したりできる、統合された大規模なコンピューティング リソースとして表示するインフラストラクチャ ツールです。

このようなアーキテクチャでは、Docker (またはコンテナ ランタイム) は、Kubernetes コントロール プレーンを介したスケジュールを通じて実際のホスト上でアプリケーションを実行するためにのみ使用されます。

上記のアーキテクチャ図から、各 Kubernetes ノードがコントロール プレーンと通信していることがわかります。各ノード上の kubelet はメタデータを取得し、CRI を実行してそのノード上のコンテナの作成/削除を実行します。

Docker が廃止されるのはなぜですか?

前述したように、Kubernetes は CRI とのみ通信できるため、Docker と通信するにはブリッジ サービスを使用する必要があります。これが第一の理由です。

次の理由を説明するには、Docker アーキテクチャについて少し説明する必要があります。まず次の図を参照してください。

はい、Kubernetes は実際には赤いボックス内に留まる必要があります。 Docker ネットワークとボリュームは除外されます。

これらの未使用の機能自体がセキュリティ上のリスクをもたらす可能性があります。実際、機能が少ないほど、攻撃対象領域は小さくなります。したがって、代替手段である CRI ランタイムの使用を検討する必要があります。

CRI ランタイムには主に 2 つの実装があります。

①コンテナ

Docker から移行したいだけであれば、containerd が最適です。なぜなら、これは実際には Docker 内で動作し、上記のようにすべての「ランタイム」作業を実行できるからです。さらに重要なのは、提供される CRI が実際には Docker によって 100% 提供されることです。

Containerd は完全にオープンソースのソフトウェアなので、GitHub でドキュメントを閲覧したり、プロジェクトに貢献したりすることもできます。

 https://github.com/containerd/containerd/

②クリオー

CRI-O は、主に Red Hat の従業員によって開発された CRI ランタイムです。最大の違いは、Docker に依存せず、現在 Red Hat OpenShift で使用されていることです。

興味深いことに、RHEL 7 も Docker を公式にはサポートしていません。代わりに、コンテナ環境向けに Podman、Buildah、CRI-O のみを提供します。

 https://github.com/cri-o/cri-o

CRI-O の利点は、ミニマリスト スタイルを採用していること、つまり、「CRI」ランタイムとして存在するように設計されていることです。

Docker の一部である containerd とは異なり、CRI-O は本質的に純粋な CRI ランタイムであるため、CRI 以外は何も含まれていません。

Docker から CRI-O への移行はより困難になることが多いですが、いずれにしても、CRI-O は少なくとも Kubernetes 上の Docker コンテナの通常の操作をサポートできます。

もう 1 つ、コンテナ ランタイムについて話すときは、どのような種類のランタイムについて話しているかに注意してください。

ランタイムには 2 つの種類があります。

• CRI ランタイム
• OCI ランタイム

CRI ランタイム

前述したように、CRI は、コンテナ ランタイムと通信してコンテナ化されたアプリケーションを作成/削除するために Kubernetes によって提供される API です。

コンテナ化された各アプリケーションは、kubelet として IPC 経由で gRPC で通信し、ランタイムも同じホスト上で実行されます。 CRI ランタイムは、kubelet からのリクエストを受け取り、OCI コンテナ ランタイムを実行してコンテナを実行する役割を担います。

少し複雑なので、図で説明しましょう。

したがって、CRI ランタイムは次のことを実行します。

• kubelet から gRPC リクエストを取得します。
• 仕様に従って OCI json 構成を作成します。

OCI ランタイム

OCI ランタイムは、cgroup や名前空間などの Linux カーネル システム コールを使用してコンテナを作成する役割を担います。 runC や gVisor について聞いたことがあるかもしれませんが、それがこれです。

CRI は Linux システム コールを通じてバイナリを実行し、runC はコンテナーを作成します。これは、runC が Linux コンピュータで実行されているカーネルに依存していることを示しています。

これは、runC にホスト上でルート権限を与える脆弱性が見つかった場合、アプリケーションをコンテナ化するとルート権限も付与されることを意味します。

明らかに、悪意のあるハッカーはホストを侵害する機会を捉え、悲惨な結果をもたらすでしょう。そのため、コンテナ化されたアプリケーション自体だけでなく、Docker (またはその他のコンテナ ランタイム) を継続的に更新する必要があります。

gVisor は、もともと Google の従業員によって作成された OCI ランタイムです。実際には、さまざまな Google Cloud サービス（Google Cloud Run、Google App Engine、Google Cloud Functions など）をホストする同じインフラストラクチャ上で実行されます。

興味深いことに、gVisor には「ゲスト カーネル」レイヤーが含まれており、コンテナ化されたアプリケーションはホスト カーネル レイヤーに直接アクセスできません。

アプリケーションが「アクセスしている」と「考えている」場合でも、実際にアクセスしているのは gVisor のゲスト カーネルのみです。

gVisor のセキュリティ モデルは非常に興味深いです。公式ドキュメントを参照することをお勧めします:

ドキュメント

gVisor と runC の主な違いは次のとおりです。

• パフォーマンスの低下
• Linux カーネル レイヤーは 100% 互換性がありません。公式ドキュメントの互換性セクションを参照してください。

 https://gvisor.dev/docs/user_guide/compatibility/

• デフォルトではサポートされていません

要約:

• Docker は確かに非推奨であり、containerd や CRI-O などの CRI ランタイムの使用を検討する必要があります。 containerd は Docker と互換性があり、同じコア コンポーネントを共有します。 Kubernetes の最小限の機能オプションを主に使用している場合は、CRI-O の方が適している可能性があります。
• CRI ランタイムと OCI ランタイムの機能と範囲の違いを明確に理解します。

実際のワークロードやビジネス ニーズによっては、runC が常に最適な選択であるとは限りませんので、必要に応じて検討してください。

Docker を放棄しますが、慌てる必要はありません。

[[355840]]

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

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

PS: ここで 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 はどちらもこれらのイメージを認識し、正常に実行できるため、統一されたコンテナ標準を確立しました。

したがって、変更が行われ、一部のユーザーには問題が発生するものの、その影響は大きくありません。そして、長い目で見れば、これは実は良いことなのです。

つまり、誰もが抵抗やパニックを脇に置いて、この変化を冷静に受け入れることができることを願っています。

参考リンク:

• https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
• https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m

出典: コンテンツソース公開アカウント Distributed Laboratory (ID: dockerone)