.png)
Kubernetes クラスタの I/O はめちゃくちゃだが、支援は間近に迫っている
Kubernetes の入力と出力のインターフェイス、API、および抽象化の普及により、コンテナオーケストレーションの世界ではさまざまな課題が生じています。
Kubernetes クラスターでは、入出力 (I/O) とも呼ばれる) ネットワークトラフィックを制御するためのインターフェースと抽象化が急増していることを説明する方法は他にありません。めちゃくちゃです。
幸いなことに、コミュニティはこれを認識しており、状況を改善するための取り組みを行っています。
このブログでは、拡散と状況を簡素化するために行われている取り組みについて説明します。
どうやってここに来たの？Kubernetes クラスタ I/O の簡単な歴史
当初、Kubernetes 用の公式なアップストリーム・イングレス・コントロール・リソースは、単に「イングレス」と呼ばれていたのは 1 つだけでした。そのリソースはシンプルで、最小限の機能しか備えていなかったため、さまざまな機能と API を使用して操作するための他の Ingress コントローラーリソースを作成し、デプロイする必要がありました。
元のKubernetes Ingressリソースは、現在非推奨の段階にあります。これは、Kubernetes SIG Networkワーキンググループで開発された新しいゲートウェイリソースとAPIを採用するためです。これらのリソースとAPIは、特に類似しているが異なる入力機能の実装の急増に対処するためにKubernetes SIG Networkワーキンググループで開発されました。
API ゲートウェイとサービスメッシュは入力機能を共有します
API管理ソリューションがAPIゲートウェイの形でクラウドとKubernetesソリューションに移行するにつれて、機能的には入力コントローラーである別のコントロールが追加されました。Kubernetes の入力コントローラーのほかにも、Kubernetes API ゲートウェイは、Kubernetes ユーザーに新たな次元の複雑さと混乱をもたらす 12 種類ほどあります。
また、サービスメッシュの実装やAPIも多数存在し、これらは事実上、（分散プロキシによって実装されたメッシュネットワークへの）別の入力インターフェースとなっています。多くのプロダクション・ネットワークでクラスター I/O が発生するサービス・メッシュ・ゲートウェイに出入りするトラフィックを制御するには、イングレス・コントローラーと API ゲートウェイと同じ機能要件をすべて満たす必要があります。
まとめると、クラスタ IO をめぐるインターフェイスと API の普及の現状は、さまざまなカテゴリのソリューションにおけるこれらすべての異なる実装の合計です。
拡散の欠点
この急増には、次の 2 つの大きな欠点があります。
- インターフェースとAPIの急速な成長により、APIの脆弱性を伴う攻撃対象領域が拡大しています ますます普及しています。
- Ingress コントローラー、API ゲートウェイ、サービスメッシュ機能向けに利用可能なソリューションの数が膨大なため、エンドユーザーは混乱と複雑化を招きます。そのため、セキュリティポリシーを Kubernetes で包括的にサポートするには、ベンダーとユーザーが複数の「言語」を話さなければならない環境になっています。
Kubernetes エコシステムでより多くのソリューションが登場するにつれて、さまざまな入力カテゴリと出力カテゴリの機能がますます重複しています。この重複は、ツールを選ぶ人々を混乱させ、すでに困難な状況に複雑さを増しています。
複雑な Kubernetes エコシステムにポリシーの標準化が必要な理由
Container Network Interface（CNI）は、ポッド間でクラスター内ネットワークトラフィックを送信するためのAPIを定義し、OVN、Calico、Ciliumなど、一般的な相互運用可能な実装が多数あります。製品によって独自の拡張がいくつかありますが、プラットフォームオペレーターがネットワーク対応エンティティと通信方法を指定できるネットワークポリシー機能のコアは共通しています。
ネットワークポリシーは、ラベル、名前空間、デプロイメント、およびその他のクラウドネイティブメタデータ属性に基づいてトラフィックを識別することに基づいて、許可ルールがその動作の例外となるデフォルト拒否環境を提供するように最適化されています。これらはまさに、Kubernetes クラスターに出入りするトラフィックをフィルタリングするための優れた基盤となるプリミティブ関数です。ただし、CNI にはクラスターの範囲外がないため、イングレス・コントローラーや API ゲートウェイの世界では、この標準化されたアプローチは共有されていません。
サービスメッシュには、CNI用に定義されたネットワークポリシーと比較して標準化されたアプローチのない、同様のトラフィックフィルタリングポリシーツールが採用されている傾向があります。サービスメッシュでは、CNI API の対象とは見なされず、CNI ワーキンググループでの採用もまだ進んでいないレイヤー 7 フィルタリングと許可リストも導入されています。
Kubernetes コミュニティによる標準化の取り組み
これらの問題に対処するために、グループは入力側と出力側のインターフェイスとAPIを標準化するためのさまざまな取り組みを行っています。その中には、ネットワーク・ポリシー・ワーキング・グループ、ゲートウェイ・ワーキング・グループ、GAMMA イニシアティブなど、Kubernetes Network Special Interest Group (SIG) の指導のもとで行われているいくつかの重要な取り組みが含まれます。
ゲートウェイワーキンググループ
Gateway ワーキンググループは、Kubernetes クラスターの受信トラフィックと出力トラフィックを管理するための統合 API の開発を担当しています。グループの主なプロジェクトは クベルネテス・ゲートウェイ API これは、Kubernetes の入力トラフィックと出力トラフィックを設定するための、より柔軟で表現力豊かなAPIを提供するように設計されています6]]。Gateway ワーキンググループは、標準化された API を提供することで、Kubernetes ネットワークコンポーネントのデプロイと管理のプロセスを簡素化することを目指しています。
Gateway ワーキンググループは、標準化された API を提供することで、Kubernetes ネットワークコンポーネントのデプロイと管理のプロセスを簡素化することを目指しています。
クベルネテスゲートウェイ API V1.0
Kubernetes Gateway APIは、元の入力リソースに関連するいくつかの制限と問題に対処するように設計されています。これらの機能強化により、元の Ingress リソースの制限が解消され、Kubernetes 環境のネットワークトラフィックをより効率的かつユーザーフレンドリーな方法で管理できるようになりました。
グループの主な改善点について詳しくは、以下のリソースをご覧ください。
ガンマ・イニシアチブ
ザの GAMMA (ゲートウェイ API、メッシュ、ミドルウェア) イニシアチブ は、さまざまな Kubernetes SIG と業界の利害関係者との共同作業です。その目標は、Kubernetes の入出力トラフィックに使用される API とインターフェースを統合して標準化することです。この取り組みは、エンドユーザーの混乱と複雑さを軽減し、Kubernetes ネットワークコンポーネントのデプロイと管理を容易にすることを目的としています。
ネットワークポリシーワーキンググループ
ネットワークポリシーワーキンググループは、Kubernetes クラスタ内のポッド、サービス、その他のネットワークエンティティ間のセキュリティと分離を強化するために、Kubernetes のネットワークポリシーの定義と実装に焦点を当てています。現在、ネットワークトラフィックを指定するための豊富なツールセットをサポートしています。一般的な CNI で広く実装されているため、クラスターの入出力トラフィックに適用されるツールではありません。
グループは現在、いくつかのプロジェクトに取り組んでいます。
- 管理ネットワークポリシー:より高いレベルの抽象化を導入することで、クラスター管理者がネットワークポリシーをより細かく制御できるようになります。これにより、管理者は、名前空間全体に一貫して適用できるグローバルなクラスター全体のポリシーを定義できます。
- Network Policy V2: 出力トラフィックフィルタリングのサポート、ポリシー照合機能の強化、セキュリティ向上のためのポリシー適用の強化など、新機能を導入し、既存の API を拡張することで、現在のネットワークポリシー実装の制限に対処します。
- NetworkPolicy++: 既存のネットワークポリシー API を拡張することにより、高度なネットワークポリシー機能を導入します。これにより、トラフィック管理、セキュリティ、分離をよりきめ細かく制御できるようになり、ユーザーは特定のニーズに合わせた高度なポリシーを作成できます。
コミュニティによる採用が標準化組織に取って代わっている
このブログの前半で、抽象化やAPIを標準化する取り組みについて言及していますが、それは必ずしもIETF、ITU、IEEEなどの従来の標準化団体を通じてそれを支持しているわけではありません。オープンソースコミュニティは、開発者の時間とコードベースで投票します。そのため、コミュニティが広く展開されているために事実上の「標準化」を達成することが成功の最も重要な尺度です。
Kubernetes Gateway APIの導入とIngressリソースの廃止は、投資から競争上の優位性を得ることなく、インフラストラクチャプラットフォームを改善して広範囲にわたる変更を行うことに専念しているコミュニティの一例です。
このブログの公開時点で、19のオープンソースの入力コントローラーおよびサービスメッシュプロジェクトが、ゲートウェイAPI実装の開発のさまざまな段階にあり、以前の特注実装に取って代わるゲートウェイAPI実装の開発段階がありました。これらの大半は現在ベータリリース中で、いくつかは一般公開 (GA) 段階にあります。
コミュニティ開発のスピードに合わせてソフトウェアインターフェースを標準化する新しい方法は、迅速な共有実装です。Network SIGで行われている作業は学術的な研究ではありません。コミュニティは、ワーキンググループで定義されている共通のインターフェースやAPIに貢献し、その後採用する意欲を示しています。誰でも好きなように参加し、貢献することができます。
まだ改善の余地はありますか？
ネットワークSIG内で現在進行中の作業により、クラスタI/Oに関連して現在存在する拡散の混乱の多くが解消されるはずですが、コミュニティが調整の対象としていない混乱や複雑さの側面は他にもあります。
GAMMA Initiative による Ingress の機能と API の共有、ゲートウェイ API ワークグループの作業は、サービスメッシュの機能要件が CNI の機能要件と、非サービスメッシュで従来のイングレスが発生する 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 ユーザーに影響が及ぶでしょう。
.webp)
.webp)
