サービス ステアリングについて

概要

GKE サービス ステアリングを使用すると、GKE クラスタ内のネットワーク トラフィックのフローを制御できます。クラスタにデプロイしたネットワーク関数に特定のタイプのトラフィックを転送するようにルールを定義できます。GKE サービス ステアリングは、ネットワーク トラフィックの通常のパスをオーバーライドするポリシーベースのルーティングに似ています。

用語とコンセプト

このページでは、次のコンセプトを使用します。

サービス機能（SF）

サービス機能は、受信したデータパケットを処理するソフトウェア コンポーネントです。サービスレイヤは、レイヤ 2（データリンク レイヤ）から OSI モデルの任意のレイヤで動作できます。

サービス機能は、大きく次のカテゴリに分類できます。

  • セキュリティ用のファイアウォール
  • アクセス制御用のプロキシ
  • 速度を向上させる WAN アクセラレーション
  • コンテンツ分析のためのディープ パケット インスペクション（DPI）
  • 監視と調査のための合法的な傍受（LI）
  • プライベート IP アドレスとパブリック IP アドレスのネットワーク アドレス変換（NAT）
  • ヘッダー拡充用の HTTP
  • トラフィックを効率的に分散するロードバランサ

サービス機能には、次のような別の用語もあります。

  • コンテナ アプライアンス
  • 仮想アプライアンス
  • 仮想化されたネットワーク機能（NFV）
  • コンテナ化されたネットワーク機能（CNF）
  • クラウドネイティブ ネットワーク機能（CNF）

サービス ステアリングでは、Service オブジェクトはサービス関数（SF）を表します。

サービス機能チェーン（SFC）

サービス機能チェーン（SFC）は、ファイアウォール、プロキシ、ロードバランサなどの一連のサービス機能をリンクして、ネットワーク トラフィックを特定の順序で処理するものです。このチェーンはパイプラインのように機能し、各サービス機能はトラフィックに対して特定のタスクを実行してから、次の機能に引き継ぎます。

サービス機能チェーン（SFC）は、サービス チェーン（SC）とも呼ばれます。

サービス ステアリングでは、ServiceFunctionChain オブジェクトはサービス機能チェーン（SFC）を表します。

サービス機能は、サービス機能チェーンとは独立して動作します。通常、サービス機能は、どのサービス機能チェーンの一部であるかを認識していません。

サービス ステアリング

サービス ステアリングは、送信元と宛先に対して完全に透過的な方法で、選択したサービス機能にパケットを転送します。このコンセプトは、「ポリシーベースのルーティング」、「トラフィック リダイレクト」、「サービス機能転送」とも呼ばれます。サービス ステアリングは、Geneve + NSH カプセル化を使用して透過的なルーティングを実現します（RFC 8926、RFC 8300、Geneve + NSH IETF のドラフトをご覧ください）。

サービス ステアリングの主な特徴は次のとおりです。

  • サービス機能のバックエンド Pod 間のロード バランシング: サービス機能は、スケーラビリティと信頼性を確保するために、多くの場合、複数の Pod で実行されます。サービス ステアリングは、これらの Pod に受信ネットワーク トラフィックを均等に分散し、単一の Pod が過負荷状態になるのを防ぎます。
  • 5 タプルフロー アフィニティのサポート（特定のフローに対してすべての中間ホップが安定している必要があります）: 5 タプルフローは、送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルに基づいてネットワーク トラフィックの特定のストリームを識別する方法です。サービス ステアリングにより、同じフロー内のすべてのパケットが同じ一連のサービス機能（ホップ）に同じ方法で転送されます。
  • 対称リターン データパスを有効にする: 対称リターン データパスとは、レスポンス トラフィックが元のリクエスト トラフィックと同じパスをたどって送信元に戻ることを意味します。サービス ステアリングは、この対称性を保証します。これは、一部のネットワーク プロトコルとアプリケーションにとって重要です。

サービス ステアリングされている特定のネットワーク トラフィックの場合、中間サービス機能 Pod がその特定のネットワーク トラフィックのすべてのパケットを処理し、一貫した中間ホップと予測可能なルートを確保します。同じサービス機能 Pod が戻りトラフィックを受信し、対称的なトラフィック フローを実現します。元のトラフィックが同じクラスタ内の宛先に送信された場合、戻りトラフィックは同じサービス チェーンを経由して自動的に戻るルートを探します。元のトラフィックがクラスタ外にある場合、チェーン内の最後のサービス機能は、送信元ネットワーク アドレス変換（SNAT）または仲介として機能するプロキシを使用して、トラフィックを引き受けます。

ユースケース

GKE サービス ステアリングは、ポリシーベースのルーティングをクラスタに統合します。これにより、次のようなユースケースが可能になります。

セルフマネージド セキュリティ サービス:

組織は、仮想ファイアウォール（vFW）、仮想次世代ファイアウォール（vNG-FW）、仮想侵入検知システム（vIDS）などのコンテナ化されたネットワーク機能（CNF）を使用して、独自のセキュリティ インフラストラクチャを構築できます。サービス ステアリングにより、トラフィックが目的の宛先に到達する前にこれらの CNF を経由するようにルーティングすることで、保護と制御のレイヤを追加できます。

マネージド セキュリティ プロバイダ（MSP）:

MSP は GKE サービス ステアリングを使用して、クラウドベースのセキュリティ サービス チェーン経由でトラフィックを転送できます。これにより、Secure Web Gateways（SWG）、SASE（Secure Access Service Edge）、SD-WAN（ソフトウェア定義の広域ネットワーク）などの包括的なセキュリティ ソリューションを提供できます。

通信と 5G ネットワーク:

サービス ステアリングは、通信および 5G インフラストラクチャ内のさまざまなネットワーク機能のトラフィック フローを管理します。仮想ルーター（vRouter）、仮想セッション境界コントローラ（vSBC）、5G コア ネットワーク機能をオーケストレートして、効率的なトラフィック管理、ロード バランシング、特定のセキュリティ ポリシーまたはサービス品質ポリシーの適用を実現できます。

サービス ステアリングの仕組み

このセクションでは、サービス ステアリングのさまざまなコンポーネントの仕組みについて説明します。

サービス機能

  1. ネットワーク トラフィック フローを識別する: GKE サービス ステアリングは、一意のフロー ID（パケットの送信元 IP アドレス、送信元ポート、宛先 IP アドレス、宛先ポート、プロトコルの 5 タプルハッシュ）を使用して、各ネットワーク接続を識別します。

  2. フロー アフィニティを確保する: サービス ステアリングは、同じフロー ID を持つすべてのパケットを同じサービス関数（SF）パスに転送することで、フロー アフィニティを確保します。

  3. パケットを変更して新しいフローを作成する: サービス機能がパケット内の 5 タプル フィールドのいずれかを変更する場合。たとえば、NAT が送信元 IP アドレスを変更すると、新しいフローが作成されます。

  4. 新しいフローのトラフィックを選択する: トラフィック選択プロセスは、新しいフローを評価して、残りの Service Functions を通過するパスを決定します。元のフローと異なるルートを取る可能性があります。

  5. プロキシと NAT を 2 つのフローとして処理する: プロキシまたは NAT を通過するトラフィックは、送信元からプロキシ / NAT とプロキシ / NAT から宛先の 2 つの別個のフローと見なされます。サービス ステアリングでは、これらの 2 つのフローで同じパスが保証されるわけではありません。

  6. 送信元アドレスを検証する: SF は、サービス ステアリングによって転送されないトラフィックでも、常に送信元アドレスの検証の対象となります。サービス機能が、送信元 IP アドレスの一致しない新しいフローを開始した場合、明示的に許可されていない限り、それらのパケットは破棄されます。

  7. カプセル化の透明性を維持する: サービス ステアリングは、SF 間のトラフィックに Geneve カプセル化を使用しますが、サービス機能 Pod 自体は認識しません。パケットは Pod に入る前にカプセル化解除されるため、サービス機能の開発が簡素化されます。

既存の接続

TrafficSelector を作成すると、サービス ステアリングによって、セレクタの条件に一致する既存の接続に自動的に適用されます。これらの接続からパケットを適切なサービス機能にリダイレクトします。これらの接続の管理は、サービス機能自体が行います。一般的なアプローチは、パケットをドロップし、クライアントが新しい接続を開始して、最初からサービス チェーンにシームレスに統合する方法です。

リソースのライフサイクル

TrafficSelector リソースと ServiceFunctionChain リソースは、削除対象としてマークされるとすぐに削除されます。リソースの削除を妨げたり遅らせる Webhook やファイナライザはありません。

Pod から Service へのトラフィック

サービス ステアリングは、サービス仮想 IP アドレスを解決した後にトラフィック選択を実行します。仮想 IP アドレスが解決された後、宛先 Pod の IP アドレスが .egress.to.ipBlock フィールドで指定された CIDR 範囲内にある場合、ClusterIP を使用して Service に送信されるトラフィックは、サービス ステアリング用に選択できます。

NetworkPolicy の適用

サービス ステアリングは NetworkPolicy をバイパスしません。送信元 Pod の下り（外向き）ポリシーと宛先 Pod の上り（内向き）ポリシーは、サービス ステアリング用に選択されたトラフィックに引き続き適用されます。ただし、サービス機能の Ingress または Egress での NetworkPolicy 適用の対象ではありません。これは、NetworkPolicy の上り（内向き）ルールまたは下り（外向き）ルールは、送信元 Pod と宛先 Pod に対して明確に定義されていますが、パケット フォワーダーに対しては明確に定義されていないためです。

利点

GKE サービス ステアリングを導入し、クラウドネイティブ テクノロジーに移行すると、次のようなメリットがあります。

  • Marketplace サービス: サードパーティは、Google Cloud Marketplace でコンテナ化されたプロダクトを提供し、Service Steering API を使用できます。GKE によって提供および管理される Kubernetes 組み込み API に基づくデプロイガイドを提供できます。
  • Kubernetes の粒度: Kubernetes クラスタ内のトラフィックを制御できます。ステアリングするトラフィックを分類できます。サービス ステアリングを適用するワークロードを選択できます。
  • 双方向性: GKE のサービス ステアリングは本質的に双方向です。つまり、特定のフローでは、リターンパスはフォワードパスと対称になります。これは、サービス機能（SF）がレプリカのグループとしてデプロイされる場合に重要です。ステートフルな状態を維持するために、同じフローが同じセットのレプリカを通過するようにします。
  • マルチネットワークのサポート: ほとんどのサービス機能では、データプレーンをコントロール プレーンと管理プレーンから分離するために、複数の Pod インターフェースが必要になります。一部のサービス機能には、アーキテクチャの一部として複数のインターフェースがあります。GKE のサービス ステアリングには、Pod でのマルチネットワークとの統合が含まれています。これにより、ユーザーは特定の Pod ネットワークにサービス ステアリングを作成できます。
  • アプリケーションへの未加工パケットの配信: GKE のサービス ステアリングは、元のパケットをカプセル化して Pod に直接配信します。これにより、カプセル化解除を行う必要がなくなり、アプリケーションは元のパケットを直接操作できます。

次のステップ