Ingress for Anthos

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

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

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

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

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

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

Ingress for Anthos の仕組み

Ingress for Anthos は、外部 HTTP(S) 負荷分散のアーキテクチャ上に構築されています。HTTP(S) 負荷分散は、プロキシを使用してグローバルに分散されたロードバランサであり、Google の世界中の 100 を超える接続拠点(PoP)でデプロイされています。これらのプロキシは、Google のネットワークのエッジに配置されており、クライアントに近い場所に位置しています。ロードバランサの VIP は、Anycast IP としてアドバタイズされます。クライアントからのリクエストはコールドポテトで Google PoP にルーティングされます。つまり、インターネット トラフィックは、最も近い PoP に転送され、最速で Google バックボーンに達します。

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

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

Ingress for Anthos のトラフィック フロー

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

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

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

Ingress for Anthos のアーキテクチャ

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

Ingress for Anthos は、次のコンセプトとコンポーネントから構成されます。

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

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

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

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

Ingress for Anthos のアーキテクチャ

デプロイのワークフロー

以下の手順は、複数のクラスタ間で Ingress for Anthos を使用する高レベルのワークフローを示しています。

  1. GKE クラスタをメンバー クラスタとして登録します。

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

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

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

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

Ingress のコンセプト

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

MultiClusterService リソース

MultiClusterService(MCS)は、複数のクラスタにまたがる Service の論理表現である Ingress for Anthos で使用されるカスタムリソースです。MCS は主な Service のタイプと似ていますが、大きく異なります。MCS は構成クラスタ内にのみ存在し、ターゲット クラスタ内に派生 Service を生成します。MCS は、ClusterIP、LoadBalancer、NodePort Service のようにはルーティングしません。MCI が単一の分散リソースを参照できるようにするだけです。foo アプリケーションの単純な MCS の例を次に示します。

apiVersion: networking.gke.io/v1alpha1
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 のセレクタです。ただし、ラベルやクラスタを選択する機能もあります。選択されたクラスタのプールはメンバー クラスタと呼ばれます。メンバー クラスタは、Environ に登録されたすべてのクラスタです。この 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-frontend
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

派生 Service に関する注意事項: - Ingress for Anthos のバックエンドとしてのエンドポイントの論理グループとして機能します。- 特定のクラスタとアプリケーションに対する NEG のライフサイクルを管理します。 - ヘッドレス Service として作成されます。MCS 仕様から派生 Service 仕様に引き継がれるのは、Selector フィールドと Ports フィールドのみです。 - Anthos Ingress コントローラによってライフサイクルが管理されます。

MultiClusterIngress リソース

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

apiVersion: networking.gke.io/v1alpha1
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 リソースモデルの図

Namespace の同一性

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

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

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

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

Namespace の同一性を示す図

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

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

構成クラスタの設計

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

構成クラスタの可用性

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

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

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

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

Ingress for Anthos を有効にするときには、構成クラスタを選択する必要があります。environ のメンバー クラスタは構成クラスタとして選択できます。構成クラスタはいつでも更新できますが、中断を発生させないように注意してください。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 for Anthos の設定をご覧ください。

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

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

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

次の例では、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/v1beta1
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」フィールドを省略すると、すべてのメンバー クラスタが暗黙的に選択されます。

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

料金とトライアル

Ingress for Anthos では、Ingress のバックエンドとして参加するすべてのクラスタに対して、Anthos on GCP ライセンスが必要になります。ライセンスは、vCPU 単位または時間単位のサブスクリプションとしてご購入いただけます。Inthos for Anthos の料金は 2020 年 8 月 1 日から有効になります。それまでは、Ingress for Anthos は無料でご利用いただけます。Ingress で作成された上り(内向き)トラフィックと転送ルールには、標準の Compute Engine ロードバランサ料金が適用されます。

Ingress for Anthos は、2020 年 8 月 1 日を過ぎた後も、無料で、最大 30 日間、任意の数のクラスタにわたる最大 100 個の vCPU でご試用になれます。試用を開始または終了するには、Google Cloud プロジェクト内で Anthos API を有効または無効にします。これにより、Google Cloud プロダクト上で Anthos へのアクセスが可能になります。より長い試用期間が必要な場合は、アカウント チームにお問い合わせください。

次のステップ