Kubernetes が Docker を放棄するのはなぜですか?

[[403553]]

画像はPexelsより

しかし、2020 年 12 月に、Kubernetes コミュニティはリポジトリ内の Dockershim 関連コードを削除することを決定しました。これは、Kubernetes コミュニティと Docker コミュニティの両方にとって大きな意味を持ちます。

図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 は、次の一連のインターフェースを通じてさまざまなモジュールの拡張性を提供します。

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

Kubernetes は以前のバージョンで CRD、CNI、CRI、CSI などのインターフェースを導入しました。スケジューラを拡張するためのスケジューリング フレームワークだけが、Kubernetes の比較的新しい機能です。

ここでは他のインターフェースや拡張機能については分析しませんが、コンテナ ランタイム インターフェースについて簡単に紹介します。

Kubernetes 1.3 の時点では、コード リポジトリで rkt ランタイムと Docker ランタイムの両方がサポートされていました。

ただし、これらのコードは Kubelet コンポーネントのメンテナンスに大きな困難をもたらします。異なるランタイムを維持する必要があるだけでなく、新しいランタイムに接続することも困難です。

Container Runtime Interface (CRI) は、Kubernetes 1.5 で導入された新しいインターフェースです。 Kubelet は、この新しいインターフェースを通じてさまざまなコンテナ ランタイムを使用できます。

実際、CRI のリリースは、Kubernetes がリポジトリから Dockershim コードを確実に削除することを意味します。

CRI は、コンテナのランタイムとイメージを管理するための一連の gRPC インターフェースです。その定義には、RuntimeService と ImageService という 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 を実装し、すべてのリクエストは処理のためにコンテナ ランタイムに転送されます。

図3: KubernetesとCRI

宣言型インターフェースは Kubernetes で非常に一般的です。宣言型インターフェースの支持者として、CRI が宣言型インターフェースを使用しないというのは「非常に奇妙」に思えます。

ただし、Kubernetes コミュニティは、コンテナ ランタイムが Pod リソースを再利用できるようにすることを検討しています。これにより、コンテナ ランタイムはコンテナを管理するためのさまざまな制御ロジックを実装できるようになり、Kubelet とコンテナ ランタイム間のインターフェースが大幅に簡素化されます。

ただし、コミュニティは次の 2 つの考慮事項により、宣言型インターフェースを選択しませんでした。

• 多くの Pod レベルの機能とメカニズムをサポートするには、すべてのランタイムで同じロジックを再実装する必要があります。
• CRI が設計されたとき、Pod の定義は非常に急速に進化し、コンテナの初期化などの機能は実行時に連携する必要があります。

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

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

コンテナ ランタイムと比較すると、Docker は、ビルドから実行までの完全な機能セットを提供する複雑な開発ツールに似ています。

開発者は Docker をすぐに使い始め、いくつかの Docker コンテナをローカルで実行および管理できます。ただし、クラスターで実行されるコンテナ ランタイムでは、このような複雑な機能が必要になることはあまりありません。 Kubernetes には、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 は、特定のコンテナ ランタイムへの依存をなくし、基盤となる実装の詳細の多くを隠蔽して、Kubernetes がコンテナ オーケストレーションにさらに集中できるようにするために、初期バージョンで CRI を導入しました。

Docker自体はCRIインターフェースと互換性がなく、公式にはCRIを実装する予定はありません。また、コンテナに対するいくつかの新しい要件もサポートされていないため、Dockershim のメンテナンスはコミュニティが取り除きたい負担となっています。

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

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

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

著者: Draveness

編集者：タオ・ジアロン

出典: 公開アカウントから転載「本当に論理がない」(ID: draveness)