マルチクラスタ Ingress

マルチクラスタ Ingress は、Google Kubernetes Engine（GKE）クラスタ用のクラウドホスト型コントローラです。Ingress for Anthos は Google がホストするサービスであり、クラスタ間やリージョン間で共有されたロード バランシングのリソースをデプロイできます。複数のクラスタにマルチクラスタ Ingress をデプロイするには、マルチクラスタ Ingress の設定を完了してから、マルチクラスタに Ingress をデプロイするをご覧ください。

マルチクラスタ Ingress（MCI）、マルチクラスタ Gateway（MCG）、スタンドアロン ネットワーク エンドポイント グループを使用するロードバランサ（LB とスタンドアロン NEG）の詳細な比較については、GKE のマルチクラスタ ロード バランシング API を選択するをご覧ください。

マルチクラスタ ネットワーキング

アプリケーションに対するユーザーの近接性、クラスタとリージョンの高可用性、セキュリティと組織の分離、クラスタの移行、データの局所性など、多数の要因によってマルチクラスタのトポロジが機能します。これらのユースケースが単独で発生することはほとんどありません。複数のクラスタを使用する理由が増えるほど、正式で製品化されたマルチクラスタ プラットフォームの必要性が高まります。

マルチクラスタ Ingress は、マルチクラスタ、マルチリージョン環境の負荷分散に関するニーズを満たすように設計されています。これは、1 つまたは複数のクラスタ間でインターネットからのトラフィックの Ingress を提供する外部 HTTP(S) ロードバランサのコントローラです。

マルチクラスタ Ingress では複数のクラスタがサポートされているため、次のような多数のユースケースに対応できます。

  • アプリがグローバルにデプロイされている場所に影響を受けない、アプリ用の単一で一貫した仮想 IP（VIP）。
  • ヘルスチェックとトラフィック フェイルオーバーによるマルチ リージョン、マルチクラスタの可用性。
  • クライアントの低レイテンシ用のパブリック Anycast VIP を介した近接性ベースのルーティング。
  • アップグレードやクラスタの再構築のための透過的なクラスタ移行。

デフォルトの割り当て

マルチクラスタ Ingress には、次のデフォルトの割り当てがあります。

  • フリートのメンバー制限の詳細については、フリートでサポートされているメンバー数に関するフリート管理の割り当てをご覧ください。
  • プロジェクトあたり 100 個の MultiClusterIngress リソースと 100 個の MultiClusterService リソース。プロジェクトごとのクラスタの最大数に達するまで、任意の数のバックエンド クラスタに対して、構成クラスタで最大 100 個の MultiClusterIngress リソースと 100 個の MultiClusterService リソースを作成できます。

料金とトライアル

マルチクラスタ Ingress の料金については、マルチクラスタ Ingress の料金をご覧ください。

マルチクラスタ Ingress の仕組み

マルチクラスタ Ingress は、グローバル外部アプリケーション ロードバランサのアーキテクチャ上に構築されています。グローバル外部アプリケーション ロードバランサは、プロキシを使用してグローバルに分散されたロードバランサであり、世界中にある 100 を超える Google の接続拠点（PoP）でデプロイされています。これらのプロキシは Google Front End（GFE）と呼ばれ、Google のネットワークのエッジにあり、クライアントの近くに配置されています。マルチクラスタ Ingress は、プレミアム ティアで外部アプリケーション ロードバランサを作成します。これらのロードバランサは、エニーキャストを使用してアドバタイズされたグローバル外部 IP アドレスを使用します。リクエストは、GFE と、クライアントに最も近いクラスタによって処理されます。インターネット トラフィックは最も近い Google PoP に向かい、Google バックボーンを使用して GKE クラスタに到達します。この負荷分散構成では、クライアントから GFE へのレイテンシは低くなります。また、クライアントに最も近いリージョンで GKE クラスタを実行することで、GKE クラスタと GFE の処理の間のレイテンシを短くすることもできます。

Google ロードバランサは、HTTP 接続と HTTPS 接続をエッジで終端させることにより、トラフィックがデータセンターやリージョンに入る前に、バックエンドの可用性を判別して、ルーティングする場所を決定します。これにより、トラフィックは、バックエンドの健全性と容量を考慮しながら、クライアントからバックエンドへの最も効率的なパスをたどることができます。

マルチクラスタ Ingress は、ネットワーク エンドポイント グループ（NEG）を使用して外部 HTTP(S) ロードバランサをプログラミングする Ingress コントローラです。デベロッパーが MultiClusterIngress リソースを作成する際には、GKE によって Compute Engine のロードバランサ リソースがデプロイされ、クラスタ間でバックエンドとして適切な Pod が構成されます。NEG は、Google ロードバランサが正常なバックエンドの適切なセットを使用できるように、Pod のエンドポイントを動的にトラッキングするために使用されます。

マルチクラスタ Ingress のトラフィック フロー

GKE でアプリケーションをクラスタ間でデプロイすると、マルチクラスタ Ingress によって、クラスタ内で発生している以下のイベントとロードバランサが同期されているかが確認されます。

  • 適切に一致するラベルで Deployment が作成される。
  • Pod のプロセスが停止し、ヘルスチェックに失敗する。
  • クラスタがバックエンドのプールから削除される。

マルチクラスタ Ingress によってロードバランサが更新され、Kubernetes リソースの環境と目的の状態が維持されます。

マルチクラスタ Ingress のアーキテクチャ

マルチクラスタ Ingress は、集中型 Kubernetes API サーバーを使用して複数のクラスタに Ingress をデプロイします。この一元化された API サーバーは、構成クラスタと呼ばれます。任意の GKE クラスタを構成クラスタとして使用できます。構成クラスタでは、MultiClusterIngress と MultiClusterService の 2 つのカスタム リソースタイプが使用されます。これらのリソースを構成クラスタにデプロイすることで、マルチクラスタ Ingress コントローラによって、複数のクラスタ全体にロードバランサがデプロイされます。

マルチクラスタ Ingress は、次のコンセプトとコンポーネントから構成されます。

  • マルチクラスタ Ingress コントローラ - グローバルに分散されたコントロール プレーンであり、クラスタの外部でサービスとして実行されます。これにより、コントローラのライフサイクルとオペレーションを GKE クラスタから分離できます。

  • 構成クラスタ - MultiClusterIngress リソースと MultiClusterService リソースがデプロイされている Google Cloud で実行される選択された GKE クラスタです。これは、マルチクラスタ リソースを一元的に管理する場所になります。マルチクラスタ リソースが単一の論理 API 内に存在し、そこからアクセスできるようになるため、すべてのクラスタにわたる整合性の維持が実現されます。Ingress コントローラによって、構成クラスタがモニタリングされ、ロード バランシング インフラストラクチャが調整されます。

  • フリートを使用すると、GKE クラスタを論理的にグループ化して正規化できるため、インフラストラクチャの管理が容易になり、マルチクラスタ Ingress をはじめとするマルチクラスタ機能を利用できるようになります。フリートの利点と作成方法について詳しくは、フリート管理のドキュメントをご覧ください。1 つのクラスタがメンバーになれるフリートは 1 つだけです。

  • メンバー クラスタ - フリートに登録されたクラスタは、メンバー クラスタと呼ばれます。フリートのメンバー クラスタは、マルチクラスタ Ingress が認識しているすべてのバックエンドで構成されます。Google Kubernetes Engine クラスタ管理ビューは、登録されているすべてのクラスタの状態を表示するセキュアなコンソールを提供します。

マルチクラスタ Ingress アーチ

デプロイのワークフロー

以下の手順は、複数のクラスタ間のマルチクラスタ Ingress を使用するための大まかなワークフローを示しています。

  1. 選択したプロジェクトのフリートに GKE クラスタを登録します。

  2. GKE クラスタを中央構成クラスタとして構成します。このクラスタは、専用のコントロール プレーンにすることも、他のワークロードを実行することもできます。

  3. アプリケーションを実行する GKE クラスタにアプリケーションをデプロイします。

  4. 1 つ以上の MultiClusterService リソースをラベルとクラスタが一致する構成クラスタにデプロイして、指定した Service のバックエンドと見なされるクラスタ、名前空間、Pod を選択します。これにより、Compute Engine で NEG が作成され、サービス エンドポイントの登録と管理が開始されます。

  5. ロードバランサのバックエンドとして 1 つ以上の MultiClusterService リソースを参照する構成クラスタに MultiClusterIngress リソースをデプロイします。これにより、Compute Engine の外部ロードバランサ リソースがデプロイされ、単一のロードバランサ VIP を介して、エンドポイントがクラスタ間で公開されます。

Ingress のコンセプト

マルチクラスタ Ingress は、集中型 Kubernetes API サーバーを使用して複数のクラスタに Ingress をデプロイします。以下のセクションでは、マルチクラスタ Ingress リソースモデル、Ingress のデプロイ方法、高可用性のネットワーク コントロール プレーンの管理の重要なコンセプトについて説明します。

MultiClusterService リソース

MultiClusterService は、マルチクラスタ Ingress で使用されるカスタム リソースで、クラスタ間でのサービスの共有を表します。MultiClusterService リソースによって、Service リソースと同様に Pod が選択されますが、MultiClusterService はラベルとクラスタも選択できます。MultiClusterService によって選択されるクラスタのプールは、メンバー クラスタと呼ばれます。フリートに登録されているクラスタはすべてメンバー クラスタです。

MultiClusterService は構成クラスタ内にのみ存在し、ClusterIP、LoadBalancer、NodePort Service のようにはルーティングしません。代わりに、マルチクラスタ Ingress コントローラが 1 つの分散リソースを参照できるようにします。

次のサンプル マニフェストでは、foo という名前のアプリケーションの MultiClusterService を記述しています。

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

このマニフェストは、セレクタ app: foo を使用して、すべてのメンバー クラスタに Service をデプロイします。そのクラスタに app: foo Pod が存在する場合、それらの Pod IP アドレスは MultiClusterIngress のバックエンドとして追加されます。

次の mci-zone1-svc-j726y6p1lilewtu7 は、ターゲット クラスタのいずれかで生成された派生 Service です。この Service は、このクラスタ内の指定されたラベルセレクタに一致するすべての Pod の Pod エンドポイントをトラッキングする NEG を作成します。派生 Service と NEG は、すべての MultiClusterService のすべてのターゲット クラスタに存在するようになります（クラスタ セレクタを使用する場合を除く）。ターゲット クラスタに一致する Pod が存在しない場合、Service と NEG は空になります。派生 Service は MultiClusterService によって完全に管理されます。ユーザーが直接管理することはありません。

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

派生 Service に関する注意事項は次のとおりです。

  • マルチクラスタ Ingress のバックエンドとしてのエンドポイントの論理グループとして機能します。
  • 特定のクラスタとアプリケーションに対する NEG のライフサイクルを管理します。
  • ヘッドレス Service として作成されます。Selector フィールドと Ports フィールドだけが、MultiClusterService から派生 Service に引き継がれます。
  • Ingress コントローラによってライフサイクルが管理されます。

MultiClusterIngress リソース

MultiClusterIngress リソースは、多くの点でコア Ingress リソースと同様に動作します。いずれにも、ホスト、パス、プロトコルの終端、バックエンドの定義に同じ仕様が使用されます。

次のマニフェストでは、HTTP ホストヘッダーに応じてトラフィックを foo バックエンドと bar バックエンドに転送する MultiClusterIngress を記述しています。

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

この MultiClusterIngress リソースは、foo と bar という MultiClusterService リソースにトラフィックを送信することで、foo.example.com と bar.example.com の仮想 IP アドレスへのトラフィックを一致させています。この MultiClusterIngress には、その他のすべてのトラフィックを一致させるデフォルトのバックエンドがあります。トラフィックはデフォルトのバックエンド MultiClusterService に送信されます。

次の図では、Ingress からクラスタにトラフィックがどのように流れるかを示します。

この図には、gke-us と gke-eu の 2 つのクラスタがあります。両方のクラスタ間で、foo.example.com から app:foo というラベルの Pod にトラフィックが送信されます。両方のクラスタ間で、bar.example.com から app:bar というラベルの Pod にトラフィックが送信されます。

クラスタ全体の上り（内向き）リソース

構成クラスタは、MultiClusterIngress リソースと MultiClusterService リソースを持つことができる唯一のクラスタです。MultiClusterService ラベルセレクタに一致する Pod がある各ターゲット クラスタにも、対応する派生 Service がスケジュールされます。MultiClusterService でクラスタが明示的に選択されていない場合は、対応する派生 Service はそのクラスタには作成されません。

Namespace の同一性

Namespace の同一性は、Kubernetes クラスタのプロパティであり、Namespace はクラスタをまたがって拡張され、同じ Namespace と見なされます。

次の図では、Namespace の blue は GKE クラスタ gke-cfg、gke-eu、gke-us にまたがっています。Namespace の同一性により、Namespace の blue がすべてのクラスタで同一であるとみなされます。つまり、あるユーザーはすべてのクラスタの blue Namespace のリソースに対して同じ権限を持つことになります。また、Namespace の同一性は、Namespace blue の複数のクラスタで同じ名前の Service リソースが同じサービスとみなされることも意味します。

Gateway は、Service を 3 つのクラスタにまたがるエンドポイントの単一のプールとして扱います。ルートと MultiClusterIngress リソースは、同じ Namespace 内の Service にのみルーティングできるため、フリート内のすべてのクラスタ間で構成に整合性のあるマルチテナンシーを実現できます。フリートを使用すると、構成を変更することなくリソースをクラスタ間でデプロイまたは移動できるため、高度なポータビリティを実現できます。同じフリートの Namespace にデプロイすると、クラスタ間で一貫性を維持できます。

Namespace の同一性には、次の設計原則を考慮してください。

  • クラスタ間で異なる目的の Namespace に同じ名前を付けない。
  • Namespace の予約は、Namespace の割り当てによって明示的に行うか、フリート内のチームやクラスタに対して帯域外ポリシーを介して暗黙的に行う。
  • クラスタ間で同じ目的の Namespace は必ず同じ名前にする。
  • クラスタ全体の Namespace に対するユーザー権限は、不正アクセスを防ぐために厳しく管理する。
  • 通常のアプリケーションのデプロイには、デフォルトの Namespace や、「prod」や「dev」などの汎用的な Namespace を使用しない。ユーザーが誤ってデフォルトの Namespace にリソースをデプロイし、Namespace のセグメンテーションの指針に違反してしまうことがありますが、このような違反は容易に発生します。
  • 特定のチームまたはユーザー グループがリソースをデプロイする必要がある場合は、クラスタ間で同じ Namespace を作成する必要があります。

構成クラスタの設計

マルチクラスタ Ingress 構成クラスタは、MultiClusterIngress と MultiClusterService のリソースをホストする単一の GKE クラスタで、ターゲット GKE クラスタ全体で Ingress の単一のコントロール ポイントとして機能します。マルチクラスタ Ingress を有効にする場合は、構成クラスタを選択します。任意の GKE クラスタを構成クラスタとして選択できます。また、構成クラスタはいつでも変更が可能です。

構成クラスタの可用性

構成クラスタは一元的に管理する場所であるため、構成クラスタ API を使用できない場合、マルチクラスタ Ingress リソースの作成または更新ができなくなります。ロードバランサとロードバランサによって処理されるトラフィックに対しては、構成クラスタの停止による影響はありません。しかし、MultiClusterIngress リソースと MultiClusterService リソースの変更に対しては、構成クラスタが再び使用可能になるまで、コントローラによる調整は行われません。

構成クラスタには、次の設計原則を考慮してください。

  • 構成クラスタは、可用性が高くなるように選択する必要があります。リージョン クラスタは、ゾーンクラスタよりも優先されます。
  • マルチクラスタ Ingress を有効にする場合、構成クラスタが専用のクラスタである必要はありません。構成クラスタは、管理ワークロードやアプリケーション ワークロードをホストできますが、ホストされたアプリケーションが構成クラスタの API サーバーの可用性に影響を与えないようにする必要があります。構成クラスタは、MultiClusterService リソースのバックエンドをホストするターゲット クラスタにできますが、追加の予防措置が必要な場合は、クラスタ選択でバックエンドとして除外することもできます。
  • 構成クラスタには、ターゲット クラスタのバックエンドで使用されるすべての Namespace が必要です。MultiClusterService リソースはクラスタ間で同じ Namespace 内の Pod のみを参照できるため、Namespace が構成クラスタ内に存在する必要があります。
  • ユーザーが複数のクラスタに Ingress をデプロイする場合、MultiClusterIngress リソースと MultiClusterService リソースをデプロイするために、構成クラスタへのアクセスが可能である必要があります。ただし、ユーザーがアクセスできるのは、使用権限のある Namespace のみです。

構成クラスタの選択と移行

マルチクラスタ Ingress を有効にする場合は、構成クラスタを選択する必要があります。フリートの任意のメンバー クラスタを構成クラスタとして選択できます。構成クラスタはいつでも更新できますが、中断を発生させないように注意してください。Ingress コントローラは、構成クラスタ内に存在するすべてのリソースを調整します。現在のクラスタから次のクラスタに移行する場合、MultiClusterIngress と MultiClusterService のリソースは同じにする必要があります。リソースが同一でない場合は、構成クラスタの更新後に Compute Engine ロードバランサが更新または破棄される可能性があります。

次の図は、一元化された CI / CD システムにより、MultiClusterIngress リソースと MultiClusterService リソースが構成クラスタ（gke-us）とバックアップ クラスタ（gke-eu）の GKE API サーバーに常に適用されます。これにより、2 つのクラスタ間でリソースは同じになります。MultiClusterIngress リソースと MultiClusterService リソースが同一であるため、緊急のダウンタイムや計画的なダウンタイムの際に、いつでも構成クラスタを変更できます。

クラスタの選択

MultiClusterService リソースはクラスタ間で選択できます。デフォルトで、コントローラはターゲット クラスタごとに派生 Service をスケジュールします。派生 Service がすべてのターゲット クラスタで必要ない場合は、MultiClusterService マニフェストの spec.clusters フィールドを使用して、クラスタのリストを定義できます。

次の操作が必要な場合は、クラスタのリストを定義することをおすすめします。

  • 構成クラスタを分離して、MultiClusterService リソースが構成クラスタ全体で選択されないようにする。
  • アプリケーション移行のために、クラスタ全体のトラフィックを制御する。
  • クラスタのサブセットにのみ存在するアプリケーション バックエンドにルーティングする。
  • 異なるクラスタに存在するバックエンドへのルーティングに単一の HTTP(S) 仮想 IP アドレスを使用する。

名前の競合を防ぐため、同じフリートで同じリージョン内のメンバー クラスタには、一意の名前を付ける必要があります。

クラスタの選択を構成する方法については、マルチクラスタ Ingress の設定をご覧ください。

次のマニフェストでは、europe-west1-c/gke-eu と asia-northeast1-a/gke-asia を参照する clusters フィールドを持つ MultiClusterService を記述しています。

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

このマニフェストは、gke-asia クラスタと gke-eu クラスタに一致するラベルを持つ Pod を MultiClusterIngress のバックエンドとして含めることができることを指定しています。他のクラスタは、app: foo ラベルの Pod がある場合でも除外されます。

次の図は、前述のマニフェストを使用した MultiClusterService 構成の例を示しています。

この図には、gke-eu、gke-asia-1、gke-asia-2 の 3 つのクラスタがあります。gke-asia-2 クラスタは、一致するラベルを持つ Pod があっても、マニフェストの spec.clusters リストに含まれていないため、バックエンドとして含まれません。クラスタは、メンテナンスやその他のオペレーションのトラフィックを受信しません。

次のステップ