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

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つのサービスがあります。それぞれの機能の名前は、次のように非常によく表れています。

  1. サービス RuntimeService {
  2. rpc Version(VersionRequest) は (VersionResponse)を返します{}
  3.  
  4. rpc RunPodSandbox(RunPodSandboxRequest) は (RunPodSandboxResponse)を返します{}
  5. rpc StopPodSandbox(StopPodSandboxRequest) は (StopPodSandboxResponse)を返します{}
  6. rpc RemovePodSandbox(RemovePodSandboxRequest) は (RemovePodSandboxResponse)を返します{}
  7. rpc PodSandboxStatus(PodSandboxStatusRequest) は (PodSandboxStatusResponse)を返します{}
  8. rpc ListPodSandbox(ListPodSandboxRequest) は (ListPodSandboxResponse)を返します{}
  9.  
  10. rpc CreateContainer(CreateContainerRequest) は (CreateContainerResponse)を返します{}
  11. rpc StartContainer(StartContainerRequest) は (StartContainerResponse)を返します{}
  12. rpc StopContainer(StopContainerRequest) は(StopContainerResponse) {}を返します
  13. rpc RemoveContainer(RemoveContainerRequest) は (RemoveContainerResponse)を返します{}
  14. rpc ListContainers(ListContainersRequest) は (ListContainersResponse)を返します{}
  15. rpc ContainerStatus(ContainerStatusRequest) は (ContainerStatusResponse)を返します{}
  16. rpc UpdateContainerResources(UpdateContainerResourcesRequest) は (UpdateContainerResourcesResponse)を返します{}
  17. rpc ReopenContainerLog(ReopenContainerLogRequest) は (ReopenContainerLogResponse)を返します{}
  18.  
  19. ...
  20. }
  21.  
  22. サービス ImageService {
  23. rpc ListImages(ListImagesRequest) は (ListImagesResponse)を返します{}
  24. rpc ImageStatus(ImageStatusRequest) は (ImageStatusResponse)を返します{}
  25. rpc PullImage(PullImageRequest) は (PullImageResponse)を返します{}
  26. rpc RemoveImage(RemoveImageRequest) は (RemoveImageResponse)を返します{}
  27. rpc ImageFsInfo(ImageFsInfoRequest) は (ImageFsInfoResponse)を返します{}
  28. }

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」公式アカウントまでご連絡ください。

<<:  Webhook を使用した Kubernetes のタグベースの権限制御の実装

>>:  ベストプラクティスを使用してクラウドリカバリ戦略を構築する方法

推薦する

企業ウェブサイトの最新ナビゲーションマーク——SEO最適化

数十億のウェブサイトの中で、ユーザーがあなたのウェブサイトをすぐに見つけ、クリックし、閲覧し、取引を...

図: インターネットは過去10年間で私たちの世界に完全な革命を起こした

2002 年当時、Apple の iMac G4 は市場で最も軽量、最薄、そして最も洗練されたコンピ...

素晴らしい時代は終わり、KOLは衰退しています!

はじめに:KOL の「大きな」時代は過ぎ去り、「小さな」時代が到来しました。先月のゴールデンアイ賞で...

CoNoov LLC: 香港の 1Gbps 帯域幅 VPS、月額 2.4 ドルから、月間 1T トラフィック、毎日 5 回「無料」

CoNoov LLC は、米国ニューヨークに登録された新設会社で、米国ロサンゼルス、日本、シンガポー...

高品質なAPPプロモーションチャネルを選択するには?

モバイルインターネット業界の急速な発展に伴い、APPのプロモーションチャネルはますます多様化していま...

高級電子商取引のフィフスアベニューが変身:オフライン体験ショールームをオープン

2、3年にわたって活況を呈している高級品電子商取引業界は、新たな投資ラウンドを獲得するために、より新...

Pinduoduoが地元の小売店に参入

地元の小売市場に新たな参入者が加わった。 Pinduoduo は、地元の小売店を開拓するための入り口...

IoT ソリューションを導入する企業にとってクラウド コンピューティングが重要なのはなぜですか?

今日のデジタル世界では、あらゆるアプリケーションやデバイスがクラウドでデータを保存または処理している...

SEO のためにウェブサイトのナビゲーションを最適化するにはどうすればよいでしょうか?

ウェブサイトナビゲーションとは何ですか?一般的に、当サイトのコラムや記事のカテゴリーなどをウェブサイ...

モノのインターネットはエッジコンピューティングの最も強力なアプリケーションです

クラウド コンピューティングの場合、サービスとしてのソフトウェアとモバイル デバイスの爆発的な増加が...

分散監視システムのZabbixアクティブ、パッシブ、Web監視

前回の記事では、Zabbix のネットワーク検出機能について学び、アクションと組み合わせて自動ホスト...

「早くて、速くて、良くて、経済的」Yisoubaiying Shangcibaoが伝統的なSEOマーケティングの認識を覆す

月収10万元の起業の夢を実現するミニプログラム起業支援プランインターネットマーケティングには、ますま...

有能なSEO担当者は4つのコア知識を習得する必要がある

インターネットへの関心が高まるにつれ、ますます多くの伝統的な業界がインターネット マーケティングに関...