クラスタ間での Ingress のデプロイ

このページでは、GKE クラスタ間でアプリケーションにサービスを提供する Ingress をデプロイする方法について説明します。

デプロイのチュートリアル

以下のタスクでは、zoneprinter という名前の架空のアプリと Ingress for Anthos を 2 つのクラスタにデプロイします。Ingress は、アプリのデプロイ用に共有の仮想 IP アドレス(VIP)を提供します。

このページは、Ingress for Anthos を設定するで 2 つのクラスタを作成して登録した作業に基づいています。この時点で、2 つのクラスタはハブにも登録されていることになります。

$ gcloud container clusters list
NAME    LOCATION        MASTER_VERSION  MASTER_IP       MACHINE_TYPE   NODE_VERSION     NUM_NODES  STATUS
gke-eu  europe-west1-c  1.16.8-gke.9    ***             e2-medium      1.16.8-gke.9     2          RUNNING
gke-us  us-central1-a   1.16.8-gke.9    ***             e2-medium      1.16.6-gke.13 *  2          RUNNING

Namespace の作成

Environ には Namespace の同一性という特長があるため、クラスタ間で Namespace の作成と管理を調整して、同じグループでは同一の Namespace が所有され、管理されるようにすることをおすすめします。Namespace は、チームごと、環境ごと、アプリケーションごと、アプリケーション コンポーネントごとに作成できます。あるクラスタ内の Namespace ns1 の意味と使用法が別のクラスタ内の ns1 のものと同じである限り、必要に応じて細かく Namespaces を設定できます。

この例では、各クラスタでアプリケーションごとに zoneprinter Namespace を作成します。

  1. 次のマニフェストから namespace.yaml を作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: zoneprinter
    
  2. gke-us コンテキストに切り替えます。

    kubectl config use-context gke-us
    
  3. Namespace を作成します。

    kubectl apply -f namespace.yaml
    
  4. gke-eu コンテキストに切り替えます。

    kubectl config use-context gke-eu
    
  5. Namespace を作成します。

    kubectl apply -f namespace.yaml
    

アプリのデプロイ

  1. 次のマニフェストから deploy.yaml を作成します。

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: zone-ingress
      namespace: zoneprinter
      labels:
        app: zoneprinter
    spec:
      selector:
        matchLabels:
          app: zoneprinter
      template:
        metadata:
          labels:
            app: zoneprinter
        spec:
          containers:
          - name: frontend
            image: gcr.io/google-samples/zone-printer:0.2
            ports:
            - containerPort: 8080
    
  2. gke-us コンテキストに切り替えます。

    kubectl config use-context gke-us
    
  3. zoneprinter アプリをデプロイします。

    kubectl apply -f deploy.yaml
    
  4. gke-eu コンテキストに切り替えます。

    kubectl config use-context gke-eu
    
  5. zoneprinter アプリをデプロイします。

    kubectl apply -f deploy.yaml
    
  6. zoneprinter アプリが各クラスタに正常にデプロイされたことを確認します。

    kubectl get deployment --namespace zoneprinter
    

    出力は両方のクラスタで次のようになります。

    NAME           READY   UP-TO-DATE   AVAILABLE   AGE
    zone-ingress   2/2     2            2           12m
    

構成クラスタを使用したデプロイ

アプリケーションが gke-usgke-eu にデプロイされたので、構成クラスタに MultiClusterIngress(MCI)と MultiClusterService(MCS)のリソースをデプロイすることによって、ロードバランサをデプロイします。MCI と MCS は、Ingress と Service のリソースのマルチクラスタに相当するカスタム リソース(CRD)です。

設定ガイドで、gke-us クラスタを構成クラスタとして構成しました。構成クラスタは、すべてのクラスタに Ingress をデプロイして構成するために使用されます。

  1. コンテキストを構成クラスタに設定します。

    kubectl config use-context gke-us
    

MultiClusterService

  1. 次のマニフェストから mcs.yaml という名前のファイルを作成します。

    apiVersion: networking.gke.io/v1
    kind: MultiClusterService
    metadata:
      name: zone-mcs
      namespace: zoneprinter
    spec:
      template:
        spec:
          selector:
            app: zoneprinter
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
    
  2. zoneprinter アプリと一致する MultiClusterService リソースをデプロイします。

    kubectl apply -f mcs.yaml
    
  3. zone-mcs リソースが構成クラスタに正常にデプロイされたことを確認します。

    kubectl get mcs -n zoneprinter
    

    出力は次のようになります。

    NAME       AGE
    zone-mcs   9m26s
    

    この MCS は、app: zoneprinter と Pod を一致させるすべてのクラスタに派生ヘッドレス Service を作成します。Service が、gke-us クラスタ kubectl get service -n zoneprinter に存在することを確認できます。

    出力は次のようになります。

    NAME                                TYPE        CLUSTER-IP    EXTERNAL-IP   PORT(S)          AGE
    mci-zone-mcs-svc-lgq966x5mxwwvvum   ClusterIP   None          <none>        8080/TCP         4m59s
    

同様のヘッドレス Service が gke-eu にも存在します。これらのローカル Service は、Pod エンドポイントを動的に選択して、グローバルな Ingress ロードバランサをバックエンドでプログラムするために使用されます。

MultiClusterIngress

  1. 次のマニフェストから mci.yaml という名前のファイルを作成します。

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: zone-ingress
      namespace: zoneprinter
    spec:
      template:
        spec:
          backend:
            serviceName: zone-mcs
            servicePort: 8080
    

    この構成では、すべてのトラフィックが、zoneprinter 名前空間に存在する zone-mcs という名前の MultiClusterService にルーティングされます。

  2. zone-mcs をバックエンドとして参照する MultiClusterIngress リソースをデプロイします。

    kubectl apply -f mci.yaml
    

    出力は次のようになります。

    multiclusteringress.networking.gke.io/zone-mci created
    

    MultiClusterIngress のスキーマは Kubernetes Ingress と同じです。Ingress リソースのセマンティクスも、backend.serviceName フィールドを除き同じです。

MultiClusterIngressbackend.serviceName フィールドは、Kubernetes クラスタの Service ではなく、Hub API の MultiClusterService を参照します。つまり、TLS の終端など、Ingress の設定はすべて同じ方法で構成できます。

デプロイの成功ステータスを検証する

Google Cloud ロードバランサのデプロイでは、新しいロードバランサのデプロイに数分かかることがあります。新しいリソースをデプロイする必要がないため、既存のロードバランサの更新は、より短時間で完了します。MCI リソースは、MCI の代わりとして作成された、基盤となる Compute Engine リソースの詳細を示します。

  1. デプロイが成功したことを確認します。

    kubectl describe mci zone-ingress -n zoneprinter
    

    出力は次のようになります。

    Name:         zone-ingress
    Namespace:    zoneprinter
    Labels:       <none>
    Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                    {"apiVersion":"networking.gke.io/v1","kind":"MultiClusterIngress","metadata":{"annotations":{},"name":"zone-ingress","namespace":"zon...
    API Version:  networking.gke.io/v1
    Kind:         MultiClusterIngress
    Metadata:
      Creation Timestamp:  2020-04-10T23:35:10Z
      Finalizers:
        mci.finalizer.networking.gke.io
      Generation:        2
      Resource Version:  26458887
      Self Link:         /apis/networking.gke.io/v1/namespaces/zoneprinter/multiclusteringresses/zone-ingress
      UID:               62bec0a4-8a08-4cd8-86b2-d60bc2bda63d
    Spec:
      Template:
        Spec:
          Backend:
            Service Name:  zone-mcs
            Service Port:  8080
    Status:
      Cloud Resources:
        Backend Services:
          mci-8se3df-8080-zoneprinter-zone-mcs
        Firewalls:
          mci-8se3df-default-l7
        Forwarding Rules:
          mci-8se3df-fw-zoneprinter-zone-ingress
        Health Checks:
          mci-8se3df-8080-zoneprinter-zone-mcs
        Network Endpoint Groups:
          zones/europe-west1-c/networkEndpointGroups/k8s1-e4adffe6-zoneprint-mci-zone-mcs-svc-lgq966x5m-808-88670678
          zones/us-central1-a/networkEndpointGroups/k8s1-a6b112b6-zoneprint-mci-zone-mcs-svc-lgq966x5m-808-609ab6c6
        Target Proxies:
          mci-8se3df-zoneprinter-zone-ingress
        URL Map:  mci-8se3df-zoneprinter-zone-ingress
      VIP:        ingress-vip
    Events:
      Type    Reason  Age                    From                              Message
      ----    ------  ----                   ----                              -------
      Normal  ADD     3m35s                  multi-cluster-ingress-controller  zoneprinter/zone-ingress
      Normal  UPDATE  3m10s (x2 over 3m34s)  multi-cluster-ingress-controller  zoneprinter/zone-ingress
    

この Ingress デプロイのステータスを示すフィールドがいくつかあります。

  • Events は最初に見るべき場所です。エラーが発生した場合は、ここに表示されます。
  • Cloud Resource は、Anthos Ingress コントローラによって作成された転送ルール、バックエンド サービス、ファイアウォール ルールなどの Compute Engine リソースを一覧表示します。これらが一覧表示されない場合は、まだ作成されていない状態です。Console または gcloud コマンドを使用して、個々の Compute Engine リソースを調べ、そのステータスを取得できます。
  • VIP は、割り当てられた IP アドレスをリストします。VIP が存在しても、ロードバランサがまだトラフィックを処理していない可能性があります。数分経っても VIP が表示されない場合や、10 分以内にロードバランサが 200 レスポンスを返さない場合は、トラブルシューティングとオペレーションをご覧ください。

出力イベントが Normal の場合、MCI のデプロイが成功している可能性はありますが、完全なトラフィック パスが機能していることを判断する唯一の方法は、テストを行うことです。

  1. アプリケーションが /ping エンドポイントを使用して VIP で機能していることを確認します。

    curl ingress-vip/ping
    

    出力は次のようになります。

    {"Hostname":"34.98.102.37","Version":"1.0","GCPZone":"us-central1-a","Backend":"zone-ingress-5554bb95b4-svv5d"}
    

    出力にアプリケーションのリージョンとバックエンドが表示されます。

  2. ブラウザで http://ingress-vip の URL にアクセスして、アプリケーションへのサービス提供元のリージョンが表示された、グラフィカル バージョンのアプリケーションを確認できます。

    トラフィックの転送先のクラスタは、ロケーションによって異なります。GCLB は、クライアント トラフィックを、容量のある最も近いバックエンドに転送するように設計されています。

リソースの仕様

MultiClusterService の仕様

MultiClusterService 定義は次の 2 つで構成されます。

  1. Kubernetes クラスタで作成される Service を定義する template セクション。template セクションには一般的な Service でサポートされているフィールドがありますが、MultiClusterService でサポートされているフィールドは selectorports の 2 つのフィールドだけが存在します。他のフィールドは無視されます。

  2. 各クラスタでトラフィックを受信するクラスタを定義するセクションと、各クラスタの負荷分散プロパティを定義するセクションである、オプションの clusters セクション。clusters セクションが指定されていない場合、またはクラスタがリストされていない場合は、デフォルトですべてのクラスタが使用されます。

次のマニフェストは、標準の MCS を記述しています。

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

ここで

  • name は、MCS の名前です。この名前は、MCI リソースの serviceName フィールドで参照されます。
  • namespace は、MCS がデプロイされている Kubernetes の Namespace です。Environ 内のすべてのクラスタにわたり、MCI および Pod と同じ Namespace にある必要があります。
  • pod-label は、Environ 内のすべてのクラスタでこの MCS のバックエンドとして選択される Pod を決定するラベルです。
  • port は、この MCS を参照する MCI によって参照されるポートと一致する必要があります。
  • target-port は、GCLB から Pod にトラフィックを送信するために使用されるポートです。このポートをサービスポートとして使用し、各クラスタに NEG が作成されます。

MultiClusterIngress の仕様

次の mci.yaml は、ロードバランサのフロントエンドを記述します。

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: name
  namespace: namespace
spec:
  template:
    spec:
      backend:
       serviceName: default-service
       servicePort: port
      rules:
        - host: host-header
          http:
            paths:
            - path: path
              backend:
                serviceName: service
                servicePort: port

ここで

  • name は、MCI リソースの名前です。
  • namespace は、MCI がデプロイされている Kubernetes の Namespace です。Environ 内のすべてのクラスタにわたり、MCS および Pod と同じ Namespace にある必要があります。
  • default-service は、ホストルールまたはパスルールに一致しないすべてのトラフィックのデフォルトのバックエンドとして機能します。これは必須フィールドであり、他のホストまたはパスの一致が構成されている場合でも、MCI でデフォルトのバックエンドを指定する必要があります。
  • port は有効なポート番号です。これは、MCS リソースの port フィールドと一致する必要があります。
  • host-header は、HTTP ホストヘッダー フィールドによってトラフィックを照合します。host フィールドは省略可能です。
  • path は、HTTP URL のパスによってトラフィックを照合します。path フィールドは省略可能です。
  • service は、この MCI と同じ Namespace と構成クラスタにデプロイされる MCS の名前です。

Ingress for Anthos の機能

このセクションでは、Ingress for Anthos の追加機能を構成する方法について説明します。

クラスタの選択

デフォルトでは、Ingress for Anthos から派生した Service は、すべてのメンバー クラスタでスケジュール設定されます。ただし、特定のクラスタに Ingress ルールを適用することもできます。ユースケースには、次のようなものがあります。

  • 構成クラスタを分離するために、構成クラスタ以外のすべてのクラスタに Anthos for Ingress を適用する。
  • クラスタ間でワークロードを青緑色に移行する。
  • クラスタのサブセットにのみ存在するアプリケーション バックエンドにルーティングする。
  • 異なるクラスタに存在するバックエンドへのホスト / パスのルーティングに単一の L7 VIP を使用する。

クラスタの選択では、MultiClusterService オブジェクト内のリージョン / 名前でクラスタを選択できます。これにより、Ingress for Anthos が指すクラスタと派生した Service がスケジュールされる場所を制御できます。クラスタが一意に参照されるように、同じ Hub とリージョン内のクラスタに同じ名前を使用することはできません。

  1. mcs.yaml を開く

    apiVersion: networking.gke.io/v1
    kind: MultiClusterService
    metadata:
      name: zone-mcs
      namespace: zoneprinter
    spec:
      template:
        spec:
          selector:
            app: zoneprinter
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
    

    この仕様では、デフォルトで現在すべてのクラスタで派生した Service が作成されています。

  2. クラスタ セクションに次の行を追加します。

    apiVersion: networking.gke.io/v1
    kind: MultiClusterService
    metadata:
      name: zone-mcs
      namespace: zoneprinter
    spec:
      template:
        spec:
          selector:
            app: zoneprinter
          ports:
          - name: web
            protocol: TCP
            port: 8080
            targetPort: 8080
      clusters:
      - link: "us-central1-a/gke-us"
      - link: "europe-west1-c/gke-eu"
    

    この例では、gke-us クラスタと gke-eu クラスタでのみ派生した Service のリソースを作成します。Ingress ルールを個別に適用するには、クラスタを選択する必要があります。MultiClusterService の「クラスタ」セクションが指定されていない場合、またはクラスタが一覧表示されていない場合は、デフォルトで「すべて」のクラスタと解釈されます。

HTTPS サポート

Kubernetes Secret は HTTPS をサポートしています。HTTPS サポートを有効にする前に、静的 IP アドレスを作成する必要があります。この静的 IP では、HTTP と HTTPS で同じ IP アドレスを共有できます。詳細については、静的 IP の作成をご覧ください。

静的 IP アドレスを作成したら、Secret を作成できます。

  1. Secret を作成します。

    kubectl -n prod create secret tls secret-name --key /path/to/keyfile --cert/path/to/certfile
    

    ここで、secret-name は Secret の名前です。

  2. 静的 IP と Secret を持つ mci.yaml ファイルを更新します。

    apiVersion: networking.gke.io/v1
    kind: MultiClusterIngress
    metadata:
      name: zone-ingress
      namespace: zoneprinter
      annotations:
        networking.gke.io/static-ip: static-ip-address
    spec:
      template:
        spec:
          backend:
            serviceName: zone-mcs
            servicePort: 8080
          tls:
          - secretName: secret-name
    

BackendConfig のサポート

BackendConfig CRD では、Compute Engine の BackendService リソースの設定をカスタマイズできます。サポートされている仕様は次のとおりです。

apiVersion: cloud.google.com/v1beta1
kind: BackendConfig
metadata:
  name: zone-health-check-cfg
  namespace: zoneprinter
spec:
  healthCheck:
    checkIntervalSec: [int]
    timeoutSec: [int]
    healthyThreshold: [int]
    unhealthyThreshold: [int]
    type: [HTTP | HTTPS | HTTP2]
    port: [int]
    requestPath: [string]
  timeoutSec: [int]
  connectionDraining:
    drainingTimeoutSec: [int]
  sessionAffinity:
    affinityType: [CLIENT_IP | CLIENT_IP_PORT_PROTO | CLIENT_IP_PROTO | GENERATED_COOKIE | HEADER_FIELD | HTTP_COOKIE | NONE]
    affinityCookieTtlSec: [int]
  cdn:
    enabled: [bool]
    cachePolicy:
      includeHost: [bool]
      includeQueryString: [bool]
      includeProtocol: [bool]
      queryStringBlacklist: [string list]
      queryStringWhitelist: [string list]
  securityPolicy:
    name: ca-how-to-security-policy
  logging:
    enable: [bool]
    sampleRate: [float]
  iap:
    enabled: [bool]
    oauthclientCredentials:
      secretName: [string]

BackendConfig を使用するには、アノテーションを使用して MultiClusterService リソースに接続します。

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: zoneprinter
  annotations:
    beta.cloud.google.com/backend-config: '{"ports": {"8080":"zone-health-check-cfg"}}'
spec:
 template:
   spec:
     selector:
       app: zoneprinter
     ports:
     - name: web
       protocol: TCP
       port: 8080
       targetPort: 8080

BackendConfig セマンティクスの詳細については、Service ポートと BackendConfig の関連付けをご覧ください。

gRPC のサポート

Ingress for Anthos で gRPC アプリケーションを構成するには、かなり詳細な設定を行う必要があります。ロードバランサを適切に構成するには、次のヒントを参考にしてください。

  1. ロードバランサからアプリケーションへのトラフィックが HTTP/2 かを確認します。アプリケーション プロトコルを使用してこれを構成します。
  2. アプリケーションが SSL 用に正しく構成されているかを確認します。これは、HTTP/2 の要件です。なお、自己署名証明書も使用できます。
  3. L7 外部ロードバランサでは mTLS がサポートされていないため、アプリケーションで mTLS をオフにする必要があります。

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

構成の変更

MultiClusterIngress リソースと MultiClusterService リソースは標準の Kubernetes オブジェクトとして動作するため、オブジェクトへの変更は非同期でシステムに反映されます。変更が無効な構成になった場合、関連付けられた Google Cloud オブジェクトは変更されず、オブジェクトのイベント ストリームでエラーが発生します。構成に関連付けられたエラーは、イベントとして報告されます。

Kubernetes リソースの管理

Ingress オブジェクトを削除すると、HTTP(S) ロードバランサが破棄され、トラフィックは定義済みのどの MultiClusterService にも転送されなくなります。

MultiClusterService を削除すると、各クラスタ内の関連する派生サービスが削除されます。

クラスタの管理

ロードバランサの対象となる一連のクラスタは、メンバーシップを追加または削除することで変更できます。

たとえば、gke-eu クラスタを Ingress のバックエンドとして削除するには、次のコマンドを実行します。

gcloud container hub memberships unregister cluster-name \
  --gke-uri=uri

ここで

  • cluster-name はクラスタの名前です。
  • uri は GKE クラスタの URI です。

ヨーロッパのクラスタを追加するには、次のコマンドを実行します。

gcloud container hub memberships register europe-cluster \
  --context=europe-cluster --service-account-key-file=/path/to/service-account-key-file

クラスタの登録または登録解除を行うと、すべての Ingress のバックエンドとしてのステータスが変更されることにご注意ください。上記の場合、gke-eu クラスタを登録解除すると、作成したすべての Ingress の利用可能なバックエンドとして削除されます。新しいクラスタを登録する場合は、その逆です。

Ingress for Anthos を無効にする

ベータ版で Ingress for Anthos を無効にすると、ネットワーク リソースが孤立します。これを回避するには、MultiClusterIngress リソースと MultiClusterService リソースを削除し、関連付けられたネットワーキング リソースが削除されたこと確認します。

Ingress for Anthos を無効にします。

gcloud alpha container hub ingress disable

アノテーション

静的 IP の作成

  1. 静的 IP を割り振ります。

    gcloud compute addresses create address-name --global
    

    ここで、address-name は作成するアドレスの名前です。

    出力は次のようになります。

    Created [https://www.googleapis.com/compute/v1/projects/project-id/global/addresses/address-name].
    
  2. 作成したばかりの IP アドレスを確認します。

    gcloud compute addresses list
    

    出力は次のようになります。

    NAME          ADDRESS/RANGE  TYPE      STATUS
    address-name  34.102.201.47  EXTERNAL  RESERVED
    
  3. mci.yaml を更新して静的 IP を適用します。

    kubectl get mci zone-mci -o yaml
    

    出力は次のようになります。

    kind: MultiClusterIngress
    metadata:
      name: shopping-service
      namespace: prod
      annotations:
        networking.gke.io/static-ip: static-ip-address
    spec:
      template:
        spec:
           backend:
             serviceName: shopping-service
              servicePort: 80
    

事前共有証明書

事前共有証明書は、Kubernetes Secret に保存されている証明書ではなく、TLS 解除のためにロードバランサで使用できる Google Cloud にアップロードされる証明書です。これらの証明書は GKE から Google Cloud に帯域外でアップロードされ、Ingress for Anthos のオブジェクトによって参照されます。事前共有証明書または Kubernetes Secret を介した複数の証明書もサポートされています。

Ingress for Anthos の証明書を使用するには、networking.gke.io/pre-shared-certs アノテーションと証明書の名前が必要です。Ingress for Anthos のオブジェクトに複数の証明書が指定されている場合、証明書は事前定義された順序でクライアントに提示されます。

次のコマンドを実行して、使用可能な SSL 証明書を一覧表示できます。

gcloud compute ssl-certificates list

次の例では、事前共有証明書の共通名と一致する特定のホストへのクライアント トラフィックを記述し、ドメイン名と一致する証明書が提示されます。

kind: MultiClusterIngress
metadata:
  name: shopping-service
  namespace: prod
  annotations:
    networking.gke.io/pre-shared-certs: "domain1-cert, domain2-cert"
spec:
  template:
    spec:
      rules:
      - host: my-domain1.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain1-svc
              servicePort: 443
      - host: my-domain2.gcp.com
        http:
          paths:
          - backend:
              serviceName: domain2-svc
              servicePort: 443

アプリケーション プロトコル

ロードバランサ プロキシからアプリケーションへの接続は、デフォルトで HTTP を使用します。networking.gke.io/app-protocols アノテーションを使用して、ロードバランサがリクエストをアプリケーションに転送するときに HTTPS または HTTP/2 を使用するようにロードバランサを構成できます。

kind: MultiClusterService
metadata:
  name: shopping-service
  namespace: prod
  annotations:
    networking.gke.io/app-protocols: '{"http2":"HTTP2"}'
spec:
  template:
    spec:
      ports:
      - port: 443
        name: http2

BackendConfig

アノテーションの構成方法については、上記のセクションをご覧ください。

既知の問題、サービスの制限、ガイダンス

以下は、Ingress for Anthos の動作に関する重要な制限または通知であり、安全で許容される使用法を示しています。ご不明な点がある場合は、アカウント チームまたは gke-mci-feedback@google.com までお問い合わせください。

  • Compute Engine ロードバランサのリソースは、mci-[6 char hash] という接頭辞を含む名前で作成されます。プロジェクト内のすべての Ingress for Anthos マネージド リソースは、同じ接頭辞を使用します。この接頭辞は、Compute Engine リソースの Ingress for Anthos デプロイを管理して、ガーベッジ コレクションするために使用されます。この接頭辞には生成されたハッシュが含まれているため、同じ接頭辞を持つ Ingress for Anthos のレルムの外に Compute Engine リソースがプロジェクトに含まれている可能性は低くなります。ただし、Ingress for Anthos で管理されていない同じプロジェクト内の Compute Engine ロードバランサでは、この接頭辞を使用しないでください。そうしなければ、削除されます。

  • Ingress for Anthos は、同じプロジェクト内のクラスタのみをサポートします。クラスタごとにデプロイできる Ingress for Anthos のインスタンスは 1 つのみです。ただし、クラスタのスコープはクラスタの選択で制御できます。これにより、MultiClusterService リソースをプロジェクト内の特定のクラスタのサブセットにのみデプロイできます。

  • Ingress for Anthos と Hub には、プロジェクトごとに最大で 15 個のクラスタの割り当てが事前構成されています。この割り当ては必要に応じて増やすことができます。追加のクラスタを登録する必要がある場合は、アカウント チームに連絡してプロジェクトごとのクラスタの上限を増やすようにリクエストしてください。

  • Ingress for Anthos には、プロジェクトごとに 50 個の MultiClusterIngress と 100 個の MultiClusterService リソースという割り当てが事前構成されています。これにより、プロジェクトごとのクラスタ最大数まで、任意の数のバックエンド クラスタに対して、構成クラスタで最大で 50 個の MCI と 100 個の MCS リソースを作成できます。この割り当ては必要に応じて増やすことができます。より大きな規模の要件がある場合は、アカウント チームにお問い合わせのうえ、プロジェクトごとの MCI と MCS の割り当てを増やすようにご依頼ください。

  • HTTPS を構成するには、事前に割り当てられた静的 IP アドレスが必要です。現在、HTTPS はエフェメラル IP アドレスではサポートされていません。

次のステップ