Kubernetes クラスターの I/O は大混乱ですが、支援は近づいています

Kubernetes のイングレスとエグレスのためのインターフェイス、API、抽象化の急増により、コンテナ オーケストレーションの世界ではさまざまな課題が生じています。  

Kubernetesクラスターに出入りするネットワークトラフィック(入出力(I/O)とも呼ばれる)を制御するためのインターフェイスと抽象化の膨大な急増を説明する方法は他にありません。大混乱です。  

良いニュースは、コミュニティがこのことを認識しており、状況を改善するための活動を行っていることです。

このブログでは、拡散と景観を簡素化するために行われている取り組みについて説明します。  

どうやってここまで来たのでしょうか?KubernetesクラスタI/Oの簡単な歴史

当初、Kubernetesの公式のアップストリーム・イングレス制御リソースは、単に「イングレス」と呼ばれる1つだけでした。これはシンプルで最小限の機能しか持っていなかったため、さまざまな機能と対話するための API を備えた他のいくつかのイングレス コントローラー リソースの作成とデプロイにつながりました。  

元の Kubernetes イングレス リソースは現在、類似しているが異なるイングレス機能の実装の急増に対処するために、特に Kubernetes SIG Network ワーキング グループで開発された新しいゲートウェイ リソースと API を優先して非推奨化中です。  

API ゲートウェイとサービス メッシュはイングレス機能を共有します

API 管理ソリューションが API ゲートウェイの形式でクラウドおよび Kubernetes ソリューションに移行すると、機能的にイングレス コントローラーである別のコントロールが追加されました。12 個ほどの Kubernetes イングレス コントローラーに加えて、12 個ほどの Kubernetes API ゲートウェイがあり、Kubernetes ユーザーに別の次元の複雑さと混乱を加えています。  

そして、さまざまなサービスメッシュ実装とAPIがあり、これらは事実上別のイングレスインターフェイス(分散プロキシによって実装されたメッシュネットワークへの)です。イングレスコントローラとAPIゲートウェイを構成するのと同じ機能ニーズは、多くの本番ネットワークでクラスタI/Oが発生するサービス内およびサービス外メッシュゲートウェイのトラフィックを制御するために必要です。  

要約すると、クラスター IO に関するインターフェイスと API の急増の現状は、ソリューションのさまざまなカテゴリすべてにおけるこれらすべての異なる実装の合計です。

拡散のマイナス面

この急増には2つの大きな欠点があります。

• インターフェイスと API の急速な成長により、攻撃対象領域が拡大し、API の脆弱性が より蔓延しています。
• イングレスコントローラ、APIゲートウェイ、サービスメッシュ機能に利用可能なソリューションは膨大で、エンドユーザーに混乱と複雑さをもたらします。これにより、ベンダーとユーザーがセキュリティポリシーの包括的なKubernetesサポートを提供するために複数の「言語」を話さなければならない環境が生まれました。

Kubernetes エコシステムにさらに多くのソリューションが登場するにつれて、さまざまなイングレスおよびエグレス カテゴリの機能がますます重複しています。この重複は、ツールを選択する人々に混乱をもたらし、すでに困難な状況に複雑さを加えます。

複雑なKubernetesエコシステムにポリシーの標準化が必要な理由

コンテナーネットワークインターフェイス (CNI) は、Pod 間でクラスター内ネットワークトラフィックを送信するための API を定義しており、OVN、Calico、Cilium など、相互運用可能な一般的な実装が多数あります。さまざまな製品にはいくつかの固有の拡張機能がありますが、プラットフォーム オペレーターが通信できるネットワーク対応エンティティとその方法を指定できるネットワーク ポリシー機能の共通のコアを共有しています。  

ネットワークポリシーは、ラベル、名前空間、デプロイ、およびその他のクラウドネイティブメタデータ属性に基づいてトラフィックを識別することに基づいて、許可ルールがその動作の例外であるデフォルトの拒否環境を提供するように最適化されています。これらはまさに、Kubernetesクラスタに出入りするトラフィックのフィルタリングのための優れた基盤となるプリミティブ関数のタイプです。ただし、CNI にはクラスター外のスコープがないため、イングレス コントローラーと API ゲートウェイの世界では、この標準化されたアプローチの共有はありませんでした。  

サービス メッシュには、CNI に定義されているネットワーク ポリシーと比較して、標準化されたアプローチがない同様のトラフィック フィルタリング ポリシー ツールが搭載される傾向があります。サービスメッシュには、CNI API の範囲内とは見なされておらず、CNI ワーキンググループでの採用がまだ進んでいないレイヤー 7 フィルタリングと許可リストも導入されています。  

Kubernetesコミュニティによる標準化の取り組み

これらの課題に対処するため、グループでは、イングレス・エグレス・インターフェースやAPIを標準化するためのさまざまな取り組みが行われています。これらには、ネットワークポリシーワーキンググループ、ゲートウェイワーキンググループ、GAMMAイニシアチブなど、Kubernetesネットワーク特別利益グループ(SIG)のリーダーシップの下でのいくつかの重要な取り組みが含まれます。

ゲートウェイワーキンググループ

ゲートウェイ・ワーキング・グループは、Kubernetesクラスタのイングレスおよびエグレス・トラフィックを管理するための統合APIの開発を担当しています。このグループの主なプロジェクトは、Kubernetes のイングレスおよびエグレス トラフィックを構成するための、より柔軟で表現力豊かな API を提供するように設計された Kubernetes Gateway API です6]]。標準化された API を提供することで、Gateway Working Group は Kubernetes ネットワーキング コンポーネントのデプロイと管理のプロセスを簡素化することを目指しています。

標準化された API を提供することで、Gateway Working Group は Kubernetes ネットワーキング コンポーネントのデプロイと管理のプロセスを簡素化することを目指しています。

Kubernetes ゲートウェイ API V1.0

Kubernetes Gateway API は、元のイングレスリソースに関連するいくつかの制限と問題に対処するように設計されています。これらの機能強化により、元のイングレス リソースの制限が解消され、Kubernetes 環境でのネットワーク トラフィックを管理するためのより効率的でユーザーフレンドリーなアプローチが提供されます。

グループの主な改善点の詳細については、次のリソースにアクセスしてください。

• Kubernetes Gateway API Overview
• 新しいKubernetes APIゲートウェイのクイックガイド

GAMMAイニシアチブ

GAMMA (Gateway API, Mesh, and Middleware) Initiative は、さまざまな Kubernetes SIG と業界関係者間の協力的な取り組みです。その目標は、Kubernetesのイングレスおよびエグレストラフィックに使用されるAPIとインターフェイスを統合および標準化することです。この取り組みは、エンドユーザーの混乱と複雑さを軽減し、Kubernetes ネットワーク コンポーネントの展開と管理を容易にすることを目的としています。

ネットワークポリシーワーキンググループ

ネットワークポリシーワーキンググループは、Kubernetesクラスター内のポッド、サービス、およびその他のネットワークエンティティ間のセキュリティと分離を強化するために、Kubernetesのネットワークポリシーの定義と実装に重点を置いています。現在、ネットワークトラフィックを指定するための豊富なツールセットをサポートしています。これは一般的な CNI によって広く実装されているため、クラスタの入力/出力トラフィックに適用されるツールではありません。  

このグループは現在、いくつかのプロジェクトに取り組んでいます。

• 管理ネットワークポリシー: より高いレベルの抽象化を導入することで、クラスター管理者がネットワークポリシーをより詳細に制御できるようにします。これにより、管理者は、名前空間間で一貫して適用できるグローバルなクラスター全体のポリシーを定義できます。
• ネットワーク ポリシー V2: エグレス トラフィック フィルタリングのサポート、ポリシー マッチング機能の強化、セキュリティ向上のためのポリシー適用の改善など、新機能を導入し、既存の API を拡張することで、現在のネットワーク ポリシー実装の制限に対処します。

• NetworkPolicy++: 既存のネットワークポリシーAPIを拡張することで、高度なネットワークポリシー機能を導入します。これにより、トラフィック管理、セキュリティ、分離をよりきめ細かく制御できるようになり、ユーザーは特定のニーズに合わせた高度なポリシーを作成できるようになります。  

コミュニティの採用が標準化団体に取って代わっている

このブログの前半では、抽象化とAPIを標準化する取り組みについて言及していますが、それは必ずしもIETF、ITU、IEEEなどの従来の標準化団体を通じてそうすることを支持するものではありません。オープンソースコミュニティは開発者の時間とコードベースで投票するため、コミュニティが広く展開されるため、事実上の「標準化」を達成することが成功の最も重要な尺度です。  

Kubernetes Gateway API の導入とイングレス リソースの廃止は、インフラストラクチャ プラットフォームの改善に専念するコミュニティが団結して、その投資から競争上の優位性を得ることなく広範な変更を加える一例です。  

このブログの公開時点では、19のオープンソースのイングレスコントローラーおよびサービスメッシュプロジェクトが、以前のオーダーメイド実装を置き換えるゲートウェイAPI実装の開発のさまざまな段階にあります。これらの大部分は現在ベータ版リリースであり、一部は一般提供 (GA) 中です。  

高速で共有された実装は、コミュニティ開発のスピードでソフトウェア インターフェイスを標準化する新しい方法です。ネットワークSIGで行われている作業は学術的な作業ではありません。コミュニティは、ワーキンググループで定義されている共通のインターフェイスとAPIに貢献し、その後採用する意欲を示しています。誰でも好きなように参加し、貢献できます。  

まだ改善の余地がありますか?

ネットワーク SIG 内で現在進行中の作業は、クラスター I/O に関連して現在存在する拡散の混乱の多くをクリーンアップします。ただし、コミュニティによって調整の対象となっていない混乱と複雑さの他の側面があります。  

ゲートウェイ API ワークグループの作業とイングレス機能と API を共有するという GAMMA イニシアチブの作業は、サービスメッシュの機能要件が、従来のイングレスが非サービスメッシュに対して発生する CNI の要件と非常によく似ている可能性があることを認識するのに大いに役立ちます。  

この作業にもかかわらず、CNI とサービス メッシュの間には、調整されていない機能の重複が引き続き存在します。初期の頃、CNI はレイヤー 3 と 4 でトラフィックをフィルタリングするレイヤー ネットワーク ポリシーを実装し、サービス メッシュはレイヤー 7 プロトコル要素のみを調べてそのトラフィックのサブセットを排他的にフィルタリングしていました。  

ネットワーク ポリシー ワーキング グループは、さまざまな CNI プロバイダーすべてで採用される API を進化させ、標準化していますが、一般的なサービス メッシュ ソリューションのほとんどには、レイヤ 3 および 4 フィルタリング ポリシー API の非標準化された形式もあります。これをネットワークポリシーワーキンググループの作業と一致させる予定はありません。  

同時に、サービスメッシュごとに異なる方法で実装されるレイヤー7フィルタリングのAPIを標準化しようとしている同等のグループはありません(ただし、フィルタリングの適用のためにオープンソースのEnvoy Proxyを共有することで、多くの均一性が得られます)。組織的には、異なるソフトウェアアーティファクト(CNIとサービスメッシュ)間の抽象化を統合することは、これを気にして実装するプロジェクトがないため、難しい場合があります。アーキテクチャの観点からはこれは理にかなっていますが、統合にはプロジェクト中心の観点ではなく、CNCF リーダーシップの観点が取られる可能性があります。  

これはすべてどこに行き着くのでしょうか?

CNI とサービス メッシュ間の継続的な機能重複は避けられないことを受け入れることは、ネットワーク SIG の目標は、CNI、サービス メッシュ、または仮想ネットワーク抽象化を提供する他の方法としてパッケージ化されたものに実装されているかどうかに関係なく、関連するセキュリティ、トラフィック管理、およびルーティング機能の共通の API を定義することであるべきであることを意味します。  

Kubernetesインフラストラクチャの専門家は、CNIをサービスメッシュと区別し、機能と標準の論理的な分離を規定するアーキテクチャの原則に基づいて、いくつかの良い異議を唱えるでしょう。しかし、UXの観点から見ると、音痴になり、システムユーザーをシステム開発者中心のボトムアップのインターフェースにさらし、「オタクのノブ」を露出させるリスクがあります。  

ユーザーが CNI プロバイダーとサービス メッシュの両方をネットワーク スタックと機能の実装として考えるのが自然であれば、より一般的な抽象化と API を共有することでプラットフォームの魅力が向上する可能性があります。ネットワークポリシーには、トラフィックを選択し、条件付きアクションを実行するためのフィルタリングプリミティブの豊富なセットがあります。クラスター内、クラスター間、クラスター外のネットワークに関する抽象化された Kubernetes 対応の一致/アクション ルールをすべて処理できるように拡張および改善できます。  

すべてのトラフィック処理のユースケースで共通の抽象化の価値についてどう思うか教えてください。このトピックに関心がある場合は、急速に進行しており、多くのKubernetesユーザーに影響を与えるこの作業に注目してください。  

イルミオの詳細については、今すぐお問い合わせください。