マルチクラスタ Ingress

マルチクラスタ Ingress(MCI)は、Anthos GKE クラスタ用のクラウドホスト型のマルチクラスタ Ingress コントローラです。Ingress for Anthos は Google がホストするサービスであり、クラスタ間やリージョン間で共有された負荷分散のリソースのデプロイが可能になります。複数のクラスタにマルチクラスタ Ingress をデプロイするには、マルチクラスタ Ingress の設定を完了してから、マルチクラスタに Ingress をデプロイするをご覧ください。

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

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

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

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

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

料金とトライアル

マルチクラスタ Ingress を使用するには、MCI バックエンドとして参加するすべてのクラスタに対して Anthos on Google Cloud ライセンスが必要です。登録された各クラスタは、vCPU の容量に基づいて課金されます。

MCI は従量課金制ベースまたは Anthos サブスクリプション ライセンスによって使用できます。Ingress で作成された上り(内向き)トラフィックと転送ルールには、標準の Compute Engine ロードバランサ料金が適用されます。

Anthos を初めてご利用の場合は、GKE on Google Cloud を最大で $900 に相当する分量の使用、または 30 日間のうち、期限が早いほうで使用できます。トライアル中は該当する料金が請求されますが、同時に同額のクレジット(最大 $900)を差し上げます。登録するには、Cloud Marketplace の Anthos ページにアクセスして [試用を開始] をクリックします。

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

マルチクラスタ Ingress は外部 HTTP(S) 負荷分散のアーキテクチャに基づいて構築されています。HTTP(S) 負荷分散は、プロキシを使用してグローバルに分散されたロードバランサであり、Google の世界中の 100 を超える接続拠点(PoP)でデプロイされています。これらのプロキシは Google Front End(GFE)と呼ばれ、Google のネットワークのエッジにあり、クライアントの近くに配置されています。プレミアム ティアでは、マルチクラスタ Ingress は外部 HTTP(S) ロードバランサを作成します。これらのロードバランサは、エニーキャストを使用してアドバタイズされたグローバル外部 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 クラスタを構成クラスタとして使用できます。構成クラスタでは、MultiClusterIngressMultiClusterService の 2 つのカスタム リソースタイプが使用されます。これらのリソースを構成クラスタにデプロイすることにより、Anthos Ingress コントローラによる複数のクラスタへのロードバランサのデプロイが実現されます。

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

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

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

  • フリート(旧 Environ) - フリートは、クラスタとインフラストラクチャをグループ化してリソースを管理し、それらの間で一貫したポリシーを維持するドメインです。MCI では、異なるクラスタ間での Ingress の適用にフリートのコンセプトが使用されます。フリートに登録されたクラスタは、Ingress のバックエンドとして使用できるように、MCI に対して可視化されます。

  • メンバー クラスタ - フリートに登録されたクラスタは、メンバー クラスタと呼ばれます。フリート内のメンバー クラスタは、MCI が認識しているすべてのバックエンドから構成されます。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(MCS)は、複数のクラスタにまたがる Service の論理表現であるマルチクラスタ Ingress で使用されるカスタム リソースです。MCS は主な Service のタイプと似ていますが、大きく異なります。MCS は構成クラスタ内にのみ存在し、ターゲット クラスタ内に派生 Service を生成します。MCS は、ClusterIP、LoadBalancer、NodePort Service のようにはルーティングしません。MCI が単一の分散リソースを参照できるようにするだけです。foo アプリケーションの単純な MCS の例を次に示します。

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

MCS は、Service と同じく Pod のセレクタです。ただし、ラベルとクラスタを選択する機能も備えています。選択されたクラスタのプールはメンバー クラスタと呼ばれます。メンバー クラスタは、フリートに登録されたすべてのクラスタです。この MCS は、セレクタ app: foo を使用してすべてのメンバー クラスタに派生 Service をデプロイします。そのクラスタに app: foo Pod が存在する場合、それらの Pod IP は MCI のバックエンドとして追加されます。

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

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 として作成されます。MCS 仕様から派生 Service 仕様に引き継がれるのは、Selector フィールドと Ports フィールドのみです。
  • Anthos Ingress コントローラによってライフサイクルが管理されます。

MultiClusterIngress リソース

MultiClusterIngress(MCI)リソースは、多くの点でコア Ingress リソースと同様に動作します。いずれにも、ホスト、パス、プロトコルの終了、バックエンドの定義に同じ仕様が使用されます。次は、HTTP ホストヘッダーに応じてトラフィックを foo と bar のバックエンドにルーティングする MCI リソースの簡単な例です。

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

この MCI では、トラフィックを foo と bar という名前の MultiClusterService(MCS)リソースに送信することにより、foo.example.combar.example.com の VIP 宛のトラフィックを一致させています。この MCI には、その他のすべてのトラフィックを一致させるデフォルトのバックエンドがあります。トラフィックは、この MCI によりデフォルトのバックエンド MCS に送信されます。

ホストヘッダーの一致

クラスタ全体の Ingress リソース

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

Ingress リソースモデルの図

名前空間の同一性

登録された GKE クラスタはフリート のメンバーになります。

フリートには、名前空間の同一性という特長があります。これにより、クラスタ間で同じ名前と同じ名前空間を持つリソースが、同じリソースのインスタンスと見なされます。つまり、マルチクラスタ Ingress から見ると、異なるクラスタ間でラベル app: foo を持つ ns1 Namespace の Pod はすべて、同じアプリケーション バックエンドのプールの一部と見なされます。

これにより、クラスタのグループ全体でさまざまな開発チームがどのように動作するかが決まります。Namespace を使用してクラスタ境界をまたいでワークロードをセグメント化することで、さまざまなチームで同じクラスタを活用できます。ただし、チームごとに、フリート内のすべてのクラスタにおいて、それぞれの Namespace を明示的または暗黙的に予約することが重要です。

次の例では、blue チームに対して、フリート内のすべてのクラスタ上で blue という Namespace のすべてにデプロイするアクセス権が付与されています。blue は、各クラスタにおいて同じ Namespace と見なされています。この blue という Namespace は、マルチクラスタ Ingress 構成クラスタにも存在しています。blue チームによってデプロイされた MultiClusterService リソースは、さまざまなクラスタ上で blue という Namespace に存在する Pod 上でのみ選択できます。異なるクラスタ上の Namespace では、MCI や MCS のリソースの可視性やアクセス権が付与されないため、リソースの意味や「同一性」がクラスタ間で維持されます。

Namespace の同一性を示す図

Namespace の同一性は、設計からの影響を受けます。ユーザーを成功に導く原則は次のとおりです。

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

構成クラスタの設計

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

構成クラスタの可用性

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

構成クラスタの使用方法と管理方法の設計の原則は次のとおりです。

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

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

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

次の図では、一元化された CI / CD システムによって、MCI リソースと MCS リソースが構成クラスタ(gke-us)とバックアップ クラスタ(gke-eu)の GKE API サーバーに常に適用されます。そのため、2 つのクラスタ間でリソースは同じになります。MCI リソースと MCS リソースが同じであるため、緊急時や計画的ダウンタイムの際に構成クラスタを変更する必要がある場合も影響を受けません。

MCI および MCS リソースを適用する一元化された CI / CD システム

クラスタの選択

MCS リソースには、クラスタを明示的に選択する機能があります。デフォルトでは、MCS はすべてのターゲット クラスタで派生 Service をスケジュールします。クラスタの選択では、派生 Service がスケジュールされる特定の MCS のクラスタの明示的なリストを定義します。その他のターゲット クラスタはすべて無視されます。クラスタの選択を構成するには、マルチクラスタ Ingress の設定をご覧ください。

次のように、上り(内向き)ルールを特定のクラスタに適用するユースケースが多数あります。

  • 構成クラスタを分離して、MCS がそれらを選択しないようにする。
  • アプリ移行のための Blue / Green とよく似た方法でクラスタ間のトラフィックを制御する。
  • クラスタのサブセットにのみ存在するアプリケーション バックエンドにルーティングする。
  • 異なるクラスタに存在するバックエンドへのホスト / パスのルーティングに単一の L7 VIP を使用する。

クラスタの選択は、MCS の clusters フィールドを介して行われます。クラスタは <region | zone>/<name> によって明示的に参照されます。同じフリートとリージョン内のメンバー クラスタには、名前の競合が発生しないように一意の名前を付ける必要があります。

次の例では、foo MCS に europe-west1-c/gke-euasia-northeast1-a/gke-asia を参照する clusters フィールドが含まれています。その結果、gke-asia クラスタと gke-eu クラスタ上の一致するラベルを持つ Pod を特定の MCI のバックエンドとして含めることができます。これにより、app: foo ラベルが付いた Pod が存在する場合でも、Ingress から gke-us クラスタが除外されます。これは、新しいクラスタへのオンボーディングや移行、Pod のデプロイとは独立したトラフィックの制御に利用できます。

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-eu、gke-asia-1、gke-asia-2 の 3 つのクラスタを示しています。一致するラベルを持つ Pod がすでに配置されていても、gke-asia-2 はバックエンドとして除外されます。これにより、クラスタをメンテナンスなどのオペレーションに関するトラフィックの受信から除外できます。MCS で「clusters」フィールドを省略すると、すべてのメンバー クラスタが暗黙的に選択されます。

除外されたバックエンドを示す図

次のステップ