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 は、特定のランタイム実装に依存しない新しいコンテナ ランタイム インターフェイスを導入することで、コンテナ管理を特定のランタイムから分離します。初期の段階では、多くのオープンソース プロジェクトは、ユーザーのコスト削減のために、すぐに使用できるエクスペリエンスを提供しています。ユーザーベースが拡大するにつれて、より多くのカスタマイズされたニーズを満たし、より高いスケーラビリティを提供するために、より多くのインターフェースが導入されることになります。 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つのサービスがあります。それぞれの機能の名前は、次のように非常によく表れています。
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-O と Containerd に加えて、他にどのようなコンテナ ランタイムが CRI をサポートしていますか? 記事の内容についてご質問がある場合、またはソフトウェア エンジニアリングにおける設計上の決定の理由について詳しく知りたい場合は、ブログの下にメッセージを残してください。著者はこの記事に関連する質問に速やかに回答し、フォローアップコンテンツとして適切なトピックを選択します。 参考文献
[^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 のタグベースの権限制御の実装
>>: ベストプラクティスを使用してクラウドリカバリ戦略を構築する方法
数十億のウェブサイトの中で、ユーザーがあなたのウェブサイトをすぐに見つけ、クリックし、閲覧し、取引を...
Windows VPS を専門とする cheapwindowsvps は現在、世界中の 8 つのデー...
2002 年当時、Apple の iMac G4 は市場で最も軽量、最薄、そして最も洗練されたコンピ...
はじめに:KOL の「大きな」時代は過ぎ去り、「小さな」時代が到来しました。先月のゴールデンアイ賞で...
CoNoov LLC は、米国ニューヨークに登録された新設会社で、米国ロサンゼルス、日本、シンガポー...
モバイルインターネット業界の急速な発展に伴い、APPのプロモーションチャネルはますます多様化していま...
昨年 11 月 25 日、欧州の RIPE NCC は、利用可能なプールに残っている最後のアドレスか...
2、3年にわたって活況を呈している高級品電子商取引業界は、新たな投資ラウンドを獲得するために、より新...
地元の小売市場に新たな参入者が加わった。 Pinduoduo は、地元の小売店を開拓するための入り口...
今日のデジタル世界では、あらゆるアプリケーションやデバイスがクラウドでデータを保存または処理している...
ウェブサイトナビゲーションとは何ですか?一般的に、当サイトのコラムや記事のカテゴリーなどをウェブサイ...
クラウド コンピューティングの場合、サービスとしてのソフトウェアとモバイル デバイスの爆発的な増加が...
前回の記事では、Zabbix のネットワーク検出機能について学び、アクションと組み合わせて自動ホスト...
月収10万元の起業の夢を実現するミニプログラム起業支援プランインターネットマーケティングには、ますま...
インターネットへの関心が高まるにつれ、ますます多くの伝統的な業界がインターネット マーケティングに関...