KubernetesがDockerに取って代わる理由

[[387817]]

Why's THE Design は、コンピュータ分野におけるプログラミングの決定に関する一連の記事です。このシリーズの各記事では、特定の問題を取り上げ、この設計の利点と欠点、および特定の実装への影響についてさまざまな観点から説明します。

Kubernetes は現在、コンテナ オーケストレーションの分野における事実上の標準であり、Docker は誕生以来コンテナにおいて重要な役割を果たしており、Kubernetes のデフォルトのコンテナ エンジンでもあります。しかし、2020年12月にKubernetesコミュニティはDockershim関連のコードをリポジトリから削除することを決定しました[^1]。これはKubernetesとDockerの両方のコミュニティにとって大きな意味を持ちます。

kubelet とコンテナ

図1 - Dockershim

ほとんどの開発者は Kubernetes と Docker について聞いたことがあり、Kubernetes を使用して Docker コンテナを管理できることも知っていると思いますが、Dockershim または Docker shim については聞いたことがないかもしれません。上の図に示すように、Kubernetes のノード エージェント Kubelet は、Docker が提供するサービスにアクセスするために、コミュニティによって管理されている Dockershim を経由する必要があります。 Dockershim は、コンテナを管理する Docker サービスにリクエストを転送します。

実際、上記のアーキテクチャ図から、Kubernetes コミュニティがコード リポジトリから Dockershim を削除した理由を推測できます。

• Kubernetes では、さまざまなコンテナ ランタイムの実装メカニズムを分離するために、Container Runtime Interface (CRI) が導入されています。コンテナ オーケストレーション システムは、特定のランタイム実装に依存してはなりません。
• Docker は Kubernetes CRI インターフェースをサポートしておらず、サポートする予定もありません。Kubernetes コミュニティはリポジトリで Dockershim を維持する必要があります。

スケーラビリティ

Kubernetes は、特定のランタイム実装に依存しない新しいコンテナ ランタイム インターフェイスを導入することで、コンテナ管理を特定のランタイムから分離します。初期の段階では、多くのオープンソース プロジェクトは、ユーザーのコスト削減のために、すぐに使用できるエクスペリエンスを提供しています。ユーザーベースが拡大するにつれて、より多くのカスタマイズされたニーズを満たし、より高いスケーラビリティを提供するために、より多くのインターフェースが導入されることになります。 Kubernetes は、次の一連のインターフェースを通じてさまざまなモジュールの拡張性を提供します。

Kubernetes 拡張機能

図 2 - Kubernetes インターフェースと拡張性

Kubernetes は以前のバージョンで CRD、CNI、CRI、CSI などのインターフェースを導入しました。スケジューラを拡張するためのスケジューリング フレームワークだけが、Kubernetes の比較的新しい機能です。ここでは他のインターフェースや拡張機能については分析しませんが、コンテナ ランタイム インターフェースについて簡単に紹介します。

Kubernetes 1.3 の時点では、コード リポジトリで rkt ランタイムと Docker ランタイムの両方がサポートされていました。しかし、これらのコードは Kubelet コンポーネントのメンテナンスに大きな困難をもたらしました。異なるランタイムを維持する必要があるだけでなく、新しいランタイムに接続することも困難でした。コンテナ ランタイム インターフェース (CRI) は、Kubernetes 1.5 で導入された新しいインターフェースです。 Kubelet は、この新しいインターフェースを通じてさまざまなコンテナ ランタイムを使用できます。実際、CRI のリリースは、Kubernetes がリポジトリから Dockershim コードを確実に削除することを意味します。

CRI は、コンテナのランタイムとイメージを管理するための gRPC インターフェースのセットです。その定義には、RuntimeServiceとImageService[^2]という2つのサービスがあります。それぞれの機能の名前は、次のように非常によく表れています。

サービス RuntimeService {
    rpc Version(VersionRequest) は (VersionResponse)を返します{} 
 
    rpc RunPodSandbox(RunPodSandboxRequest) は (RunPodSandboxResponse)を返します{}
    rpc StopPodSandbox(StopPodSandboxRequest) は (StopPodSandboxResponse)を返します{}
    rpc RemovePodSandbox(RemovePodSandboxRequest) は (RemovePodSandboxResponse)を返します{}
    rpc PodSandboxStatus(PodSandboxStatusRequest) は (PodSandboxStatusResponse)を返します{}
    rpc ListPodSandbox(ListPodSandboxRequest) は (ListPodSandboxResponse)を返します{} 
 
    rpc CreateContainer(CreateContainerRequest) は (CreateContainerResponse)を返します{}
    rpc StartContainer(StartContainerRequest) は (StartContainerResponse)を返します{}
    rpc StopContainer(StopContainerRequest) は(StopContainerResponse) {}を返します
    rpc RemoveContainer(RemoveContainerRequest) は (RemoveContainerResponse)を返します{}
    rpc ListContainers(ListContainersRequest) は (ListContainersResponse)を返します{}
    rpc ContainerStatus(ContainerStatusRequest) は (ContainerStatusResponse)を返します{}
    rpc UpdateContainerResources(UpdateContainerResourcesRequest) は (UpdateContainerResourcesResponse)を返します{}
    rpc ReopenContainerLog(ReopenContainerLogRequest) は (ReopenContainerLogResponse)を返します{} 
 
    ...
 } 
 
サービス ImageService {
    rpc ListImages(ListImagesRequest) は (ListImagesResponse)を返します{}
    rpc ImageStatus(ImageStatusRequest) は (ImageStatusResponse)を返します{}
    rpc PullImage(PullImageRequest) は (PullImageResponse)を返します{}
    rpc RemoveImage(RemoveImageRequest) は (RemoveImageResponse)を返します{}
    rpc ImageFsInfo(ImageFsInfoRequest) は (ImageFsInfoResponse)を返します{}
 }

Kubernetes について少し知識のある人なら、上記の定義からいくつかの馴染みのあるメソッドを見つけることができます。これらはすべて、コンテナの実行時に Kubelet に公開する必要があるインターフェースです。 Kubernetes は、Kubelet 内のクライアントと通信するための gRPC サーバーとして CRI shim を実装し、すべてのリクエストは処理のためにコンテナ ランタイムに転送されます。

CRI とコンテナ ランタイム

図3 - KubernetesとCRI

宣言型インターフェースは Kubernetes で非常に一般的です。宣言型インターフェースの支持者として、CRI が宣言型インターフェースを使用しないことは「非常に奇妙」に思えます[^3]。しかし、Kubernetes コミュニティは、コンテナ ランタイムが Pod リソースを再利用できるようにすることを検討しました。これにより、コンテナ ランタイムはコンテナを管理するためのさまざまな制御ロジックを実装できるようになり、Kubelet とコンテナ ランタイム間のインターフェースが大幅に簡素化されます。しかし、コミュニティは次の 2 つの理由から宣言型インターフェースを選択しませんでした。

多くの Pod レベルの機能とメカニズムをサポートするには、すべてのランタイムで同じロジックを再実装する必要があります。

CRI が設計されたとき、Pod の定義は急速に進化し、コンテナの初期化などの機能にはランタイムの協力が必要になりました。

コミュニティは最終的に CRI に命令型インターフェースを選択しましたが、Kubelet は Pod の状態が目的の状態に移行し続けることを保証します。

互換性のないインターフェース

コンテナ ランタイムと比較すると、Docker は、ビルドから実行までの完全な機能セットを提供する複雑な開発ツールに似ています。開発者は Docker をすぐに使い始め、いくつかの Docker コンテナをローカルで実行および管理できます。ただし、クラスターで実行されるコンテナ ランタイムでは、このような複雑な機能が必要になることはあまりありません。 Kubernetes には、CRI で定義されたインターフェースのみが必要です。

dockerとcri

図4 - DockerとCRI

Docker の公式ドキュメントは、本と同じくらいの厚さになる場合があります。 Docker が提供するすべての機能を巧みに使いこなせる開発者はいないと思います。開発者ツールとして、Docker には CRI に必要なすべての機能が含まれていますが、CRI と互換性を持たせるにはパッケージングのレイヤーを実装する必要があります。さらに、cgroups v2 やユーザー名前空間など、コミュニティによって提案された多くの新機能は Dockershim では実装できません。

Kubernetes は比較的緩やかなオープンソース コミュニティです。各メンバー、特に各 SIG のメンバーは、オープンソース コミュニティに限られた時間しか費やしません。 Kubelet の sig-node の保守は特に忙しいです。メンテナーのエネルギーが足りないため、多くの新機能が棚上げになっています。したがって、Docker コミュニティは Kubernetes の CRI インターフェースをサポートする予定がないようであり、Dockershim の維持には多大な労力が必要であるため、Kubernetes が Dockershim を削除する理由は理解できます。

要約する

現在、Kubernetes はすでに非常に成熟したプロジェクトであり、さまざまなシナリオや企業のカスタマイズされたビジネス ニーズを満たすために、その重点は、より完全な機能の提供からより優れたスケーラビリティの提供へと徐々に移行しています。かつて Kubernetes は人気のため Docker を選択しましたが、現在ではメンテナンスコストが高いため Docker を放棄しています。このプロセスからコンテナ分野の発展と進歩を体感することができます。

Docker を削除するというアイデアは、実は CRI がリリースされたときに生まれました。 Dockershim は、市場で Docker との互換性を確保するために Kubernetes が下した一時的な決定でした。現在市場を席巻している Kubernetes にとって、Docker サポートは非​​常に役に立たないと思われるため、コードを削除するのは当然のことです。 Kubernetes がリポジトリから Docker サポートを削除した 2 つの理由を確認しましょう。

• 初期のバージョンでは、Kubernetes は CRI を導入して特定のコンテナ ランタイムへの依存を取り除き、基盤となる実装の詳細の多くを隠蔽し、Kubernetes がコンテナ オーケストレーションにさらに集中できるようにしました。
• Docker自体はCRIインターフェースと互換性がなく、公式にはCRIを実装する予定はありません。また、コンテナの新しい要件もいくつかサポートされていないため、Dockershim のメンテナンスはコミュニティが取り除きたい負担となっています。

最後に、関連するいくつかの未解決の質問を見てみましょう。興味のある読者は、次の質問について慎重に考えてみてください。

Kubernetes の他のモジュールには優れた拡張性を提供するものはありますか?

この記事で言及されている CRI-O と Containerd に加えて、他にどのようなコンテナ ランタイムが CRI をサポートしていますか?

記事の内容についてご質問がある場合、またはソフトウェア エンジニアリングにおける設計上の決定の理由について詳しく知りたい場合は、ブログの下にメッセージを残してください。著者はこの記事に関連する質問に速やかに回答し、フォローアップコンテンツとして適切なトピックを選択します。

参考文献

• Dockershim 廃止に関する FAQ https://kubernetes.io/blog/2020/12/02/dockershim-faq/
• 慌てないでください: Kubernetes と Docker https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/

[^1]: kubelet から dockershim を削除 #1985 https://github.com/kubernetes/enhancements/pull/1985

[^3]: Kubernetes でのコンテナ ランタイム インターフェース (CRI) の紹介 https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes/

[^2]: コンテナ ランタイム インターフェース (CRI) – kubelet がさまざまなコンテナ ランタイムを使用できるようにするプラグイン インターフェース。 https://github.com/kubernetes/cri-api/blob/master/pkg/apis/runtime/v1/api.proto

この記事はWeChatの公開アカウント「本当に論理がない」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は「There is No Logic」公式アカウントまでご連絡ください。