Como implantar o Ingress em clusters

Nesta página, mostraremos como implantar um Ingress que exibe um aplicativo em vários clusters do GKE.

Tutorial de implantação

Nas tarefas abaixo, você implantará um aplicativo fictício chamado zoneprinter e o Ingress for Anthos em dois clusters. O Ingress fornece um endereço IP virtual (VIP, na sigla em inglês) compartilhado para as implantações do aplicativo.

Esta página se baseia no trabalho feito em Como configurar o Ingress for Anthos, em que você criou e registrou dois clusters. Neste momento, você precisa ter dois clusters que também estão registrados em um environ:

$ 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

Como criar o namespace

Como os ambientes têm a propriedade de semelhança de namespace, recomendamos coordenar a criação e o gerenciamento de namespaces em clusters para que os namespaces idênticos sejam de propriedade e gerenciados pelo mesmo grupo. É possível criar namespaces por equipe, por ambiente, por aplicativo ou por componente do aplicativo. Os namespaces podem ser tão granulares quanto necessário, desde que um namespace ns1 em um cluster tenha o mesmo significado e uso de ns1 em outro cluster.

Neste exemplo, você cria um namespace zoneprinter para cada aplicativo em cada cluster.

  1. Crie namespace.yaml com base no seguinte manifesto:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: zoneprinter
    
  2. Alterne para o contexto do gke-us:

    kubectl config use-context gke-us
    
  3. Crie o namespace:

    kubectl apply -f namespace.yaml
    
  4. Alterne para o contexto do gke-eu:

    kubectl config use-context gke-eu
    
  5. Crie o namespace:

    kubectl apply -f namespace.yaml
    

Como implantar o app

  1. Crie deploy.yaml com base no seguinte manifesto:

    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. Alterne para o contexto do gke-us:

    kubectl config use-context gke-us
    
  3. Implante o aplicativo zoneprinter:

    kubectl apply -f deploy.yaml
    
  4. Alterne para o contexto do gke-eu:

    kubectl config use-context gke-eu
    
  5. Implante o aplicativo zoneprinter:

    kubectl apply -f deploy.yaml
    
  6. Verifique se o aplicativo zoneprinter foi implantado com sucesso em cada cluster:

    kubectl get deployment --namespace zoneprinter
    

    A saída será semelhante a esta nos dois clusters:

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

Como implantar com o cluster de configuração

Agora que o aplicativo foi implantado em gke-us e gke-eu, você implantará um balanceador de carga implantando recursos MultiClusterIngress (MCI) e MultiClusterService (MCS) no cluster de configuração. MCI e MCS são recursos personalizados (CRDs, na sigla em inglês) equivalentes a vários clusters de recursos de entrada e serviço.

No guia de configuração, você configurou gke-us como o cluster de configuração. O cluster de configuração é usado para implantar e configurar o Ingress em todos os clusters.

  1. Defina o contexto como o cluster de configuração.

    kubectl config use-context gke-us
    

MultiClusterService

  1. Crie um arquivo chamado mcs.yaml com base no seguinte manifesto:

    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. Implante o recurso MultiClusterService que corresponde ao aplicativo zoneprinter:

    kubectl apply -f mcs.yaml
    
  3. Verifique se o recurso zone-mcs foi implantado no cluster de configuração:

    kubectl get mcs -n zoneprinter
    

    A saída é semelhante a esta:

    NAME       AGE
    zone-mcs   9m26s
    

    Esse MCS cria um serviço sem comando derivado em cada cluster que corresponde a pods com app: zoneprinter. É possível ver que existe um no cluster gke-us kubectl get service -n zoneprinter

    A saída é semelhante a esta:

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

Um serviço sem comando semelhante também existirá em gke-eu. Esses serviços locais são usados para selecionar dinamicamente os endpoints do pod para programar o balanceador de carga global do Ingress com back-ends.

MultiClusterIngress

  1. Crie um arquivo chamado mci.yaml com base no seguinte manifesto:

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

    Essa configuração encaminha todo o tráfego para o MultiClusterService chamado zone-mcs que existe no namespace zoneprinter.

  2. Implante o recurso MultiClusterIngress que se refere ao zone-mcs como um back-end:

    kubectl apply -f mci.yaml
    

    A saída é semelhante a esta:

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

    Observe que MultiClusterIngress tem o mesmo esquema que do Kubernetes Ingress. A semântica de recursos do Ingress também é a mesma, com exceção do campo backend.serviceName.

O campo backend.serviceName em um MultiClusterIngress que se refere a um MultiClusterService na API environ em vez de um serviço em um cluster do Kubernetes. Isso significa que qualquer uma das configurações do Ingress, como o encerramento do TLS, pode ser definida da mesma maneira.

Como validar um status de implantação bem-sucedido

A implantação de novos balanceadores de carga do Google Cloud pode levar vários minutos. A atualização dos balanceadores de carga atuais é concluída mais rapidamente porque novos recursos não precisam ser implantados. O recurso MCI detalha os recursos básicos do Compute Engine que foram criados em nome do MCI.

  1. Verifique se a implantação foi bem-sucedida:

    kubectl describe mci zone-ingress -n zoneprinter
    

    A saída é semelhante a esta:

    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
    

Há vários campos que indicam o status dessa implantação do Ingress:

  • Events é o primeiro lugar para procurar. Se ocorrer um erro, ele será listado aqui.
  • Cloud Resource lista os recursos do Compute Engine, como regras de encaminhamento, serviços de back-end e regras de firewall que foram criados pelo Anthos Ingress Console. Se eles não estiverem listados, significa que ainda não foram criados. Inspecione recursos individuais do Compute Engine com o console ou o comando gcloud para receber o status.
  • VIP lista um endereço IP quando ele é alocado. Observe que o balanceador de carga ainda não está processando o tráfego, embora o VIP exista. Se você não vir um VIP após alguns minutos ou se o balanceador de carga não exibir uma resposta 200 em 10 minutos, consulte Solução de problemas e operações.

Se os eventos de saída forem Normal, a implantação do MCI provavelmente será bem-sucedida, mas a única maneira de determinar se o caminho de tráfego completo é funcional é testá-lo.

  1. Valide se o aplicativo está sendo exibido no VIP com o endpoint /ping:

    curl ingress-vip/ping
    

    A saída é semelhante a esta:

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

    A saída deve indicar a região e o back-end do aplicativo.

  2. Também é possível acessar o URL http://ingress-vip no seu navegador para ver uma versão gráfica do aplicativo que mostra a região de origem.

    O cluster que recebe o tráfego encaminhado depende do seu local. O GCLB foi projetado para encaminhar o tráfego do cliente para o back-end mais próximo disponível com capacidade.

Especificações de recursos

Especificação MultiClusterService

A definição MultiClusterService consiste em duas partes:

  1. Uma seção template que define o serviço a ser criado nos clusters do Kubernetes. Embora a seção template contenha campos aceitos em um serviço típico, há apenas dois campos compatíveis em MultiClusterService: selector e ports. Os outros campos serão ignorados.

  2. Uma seção clusters opcional que define quais clusters recebem tráfego e as propriedades de balanceamento de carga de cada cluster. Se nenhuma seção clusters for especificada ou se nenhum cluster estiver listado, todos os clusters serão usados por padrão.

O manifesto a seguir descreve um MCS padrão:

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

em que:

  • name é o nome do MCS. Esse nome é indicado pelo campo serviceName nos recursos do MCI;
  • namespace é o namespace do Kubernetes em que o MCS é implantado. Ele precisa corresponder ao mesmo namespace que o MCI e os pods em todos os clusters no ambiente;
  • pod-label é o rótulo que determina quais pods são selecionados como back-ends para esse MCS em todos os clusters do ambiente;
  • port precisa corresponder à porta referenciada pelo MCI que faz referência a esse MCS;
  • target-port é a porta usada para enviar tráfego para o pod a partir do GCLB. Um NEG é criado em cada cluster com essa porta como porta de veiculação.

Especificação MultiClusterIngress

O mci.yaml a seguir descreve o front-end do balanceador de carga:

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

em que:

  • name é o nome do recurso do MCI;
  • namespace é o namespace do Kubernetes em que o MCI está implantado. Ele precisa estar no mesmo namespace que o MCS e os pods em todos os clusters no ambiente;
  • default-service atua como o back-end padrão para todo o tráfego que não corresponde a nenhuma regra de host ou caminho. Esse é um campo obrigatório, e um back-end padrão precisa ser especificado no MCI, mesmo que haja outras correspondências de host ou caminho configuradas;
  • port é qualquer número de porta válido. Ele precisa corresponder ao campo port dos recursos do MCS;
  • host-header corresponde ao tráfego pelo campo de cabeçalho do host HTTP. O campo host é opcional;
  • path corresponde ao tráfego pelo caminho do URL de HTTP. O campo path é opcional;
  • service é o nome de um MCS implantado no mesmo namespace e cluster de configuração que o MCI.

Recursos do Ingress for Anthos

Nesta seção, mostramos como configurar recursos do Ingress for Anthos.

Seleção de cluster

Por padrão, os serviços derivados do Ingress for Anthos são programados em cada cluster de membro. No entanto, convém aplicar regras de entrada a clusters específicos. Alguns casos de uso incluem:

  • aplicar o Ingress for Anthos a todos os clusters, exceto ao cluster de configuração para isolamento do cluster de configuração;
  • migrar cargas de trabalho entre clusters de uma forma "azul/verde";
  • rotear para back-ends de aplicativos que existem apenas em um subconjunto de clusters;
  • usar um VIP L7 único para roteamento de host/caminho para back-ends que residem em clusters diferentes.

É possível selecionar clusters por região/nome no objeto MultiClusterService. Isso controla para quais clusters o Ingress for Anthos aponta e onde os Serviços derivados são programados. Os clusters no mesmo environ e região não devem ter o mesmo nome para que os clusters possam ter referências exclusivas.

  1. Abrir 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
    

    No momento, essa especificação cria Serviços derivados em todos os clusters, o comportamento padrão.

  2. Anexe as seguintes linhas na seção de clusters:

    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"
    

    Este exemplo cria recursos de Serviços derivados apenas nos clusters gke-us e gke-eu. Você precisa selecionar clusters para aplicar seletivamente as regras de entrada. Se a seção "clusters" do MultiClusterService não for especificada ou se nenhum cluster estiver listado, ele será interpretado como o padrão "todos".

Suporte a HTTPS

O secret do Kubernetes é compatível com HTTPS. Antes de ativar o suporte a HTTPS, crie um endereço IP estático. Esse IP estático permite que HTTP e HTTPS compartilhem o mesmo endereço IP. Para mais informações, consulte Como criar um IP estático.

Depois de criar um endereço IP estático, crie um secret.

  1. Crie um secret:

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

    em que secret-name é o nome do secret.

  2. Atualize o arquivo mci.yaml com o IP estático e o secret:

    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
    

Suporte a BackendConfig

O CRD BackendConfig permite personalizar configurações no recurso BackendService do Compute Engine. A especificação compatível é:

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 | TCP]
    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]

Para usar o BackendConfig, anexe-o ao recurso MultiClusterService usando uma anotação:

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

Para mais informações sobre a semântica do BackendConfig, consulte Como associar uma porta de serviço a um BackendConfig.

Suporte ao gRPC

A configuração de aplicativos gRPC no Ingress for Anthos requer uma configuração muito específica. Veja algumas dicas para garantir que seu balanceador de carga esteja configurado corretamente:

  1. Verifique se o tráfego do balanceador de carga para o aplicativo é HTTP/2. Use protocolos de aplicativo para configurar isso.
  2. Verifique se o aplicativo está configurado corretamente no SSL, já que esse é um requisito de HTTP/2. É permitido o uso de certificados autoassinados.
  3. Desative o mTLS no aplicativo, já que o mTLS não é compatível com os balanceadores de carga externos L7.

Ciclo de vida dos recursos

Alterações de configuração

Os recursos MultiClusterIngress e MultiClusterService se comportam como objetos padrão do Kubernetes. Por isso, as alterações feitas nos objetos são refletidas de maneira assíncrona no sistema. Qualquer alteração que resulte em uma configuração inválida faz com que os objetos associados do Google Cloud permaneçam inalterados e gerem um erro no stream de eventos do objeto. Os erros associados à configuração serão informados como eventos.

Como gerenciar recursos do Kubernetes

A exclusão do objeto do Ingress desativa o balanceador de carga HTTP(S) para que o tráfego não seja mais encaminhado para qualquer MultiClusterService definido.

A exclusão de MultiClusterService remove os serviços derivados associados em cada um dos clusters.

Como gerenciar clusters

O conjunto de clusters segmentados pelo balanceador de carga pode ser alterado adicionando ou removendo uma assinatura.

Por exemplo, para remover o cluster gke-eu como back-end de uma entrada, execute:

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

em que:

  • cluster-name é o nome do cluster;
  • uri é o URI do cluster do GKE.

Para adicionar um cluster na Europa, execute:

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

Registrar ou cancelar o registro de um cluster altera o status dele como um back-end para todas as entradas. No caso acima, cancelar o registro do cluster gke-eu o removerá como um back-end disponível para todas as entradas criadas. O inverso é verdadeiro para registrar um novo cluster.

Como desativar o Ingress for Anthos

Na versão Beta, desativar o Ingress for Anthos resulta em recursos de rede órfãos. Para evitar isso, exclua os recursos MultiClusterIngress e MultiClusterService e verifique se os recursos de rede associados foram excluídos.

Desative o Ingress for Anthos:

gcloud alpha container hub ingress disable

Anotações

Como criar um IP estático

  1. Aloque um IP estático:

    gcloud compute addresses create address-name --global
    

    em que address-name é o nome do endereço que será criado.

    A saída é semelhante a esta:

    Created [https://www.googleapis.com/compute/v1/projects/project-id/global/addresses/address-name].
    
  2. Veja o endereço IP que você acabou de criar:

    gcloud compute addresses list
    

    A saída é semelhante a esta:

    NAME          ADDRESS/RANGE  TYPE      STATUS
    address-name  34.102.201.47  EXTERNAL  RESERVED
    
  3. Aplique o IP estático atualizando mci.yaml:

    kubectl get mci zone-mci -o yaml
    

    A saída é semelhante a esta:

    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
    

Certificados pré-compartilhados

Os certificados pré-compartilhados são enviados ao Google Cloud e podem ser usados pelo balanceador de carga para o encerramento de TLS em vez de certificados armazenados em secrets do Kubernetes. Esses certificados são enviados do GKE para o Google Cloud por meio de um canal separado ("out of band") e referenciados por um objeto do Ingress for Anthos. Vários certificados, seja por meio de certificados pré-compartilhados ou secrets do Kubernetes, também são compatíveis.

O uso dos certificados no Ingress for Anthos requer a anotação networking.gke.io/pre-shared-certs e os nomes dos certificados. Quando vários certificados são especificados para um determinado objeto do Ingress for Anthos, um pedido predeterminado define qual certificado é apresentado ao cliente.

Liste os certificados SSL disponíveis executando:

gcloud compute ssl-certificates list

O exemplo abaixo descreve o tráfego de clientes para um dos hosts especificados que corresponde ao nome comum dos certificados pré-compartilhados. Assim, o certificado que corresponde ao nome de domínio será apresentado.

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

Protocolos de aplicativo

A conexão entre o proxy do balanceador de carga e seu aplicativo usa HTTP por padrão. Ao usar a anotação networking.gke.io/app-protocols, é possível configurar o balanceador de carga para usar HTTPS ou HTTP/2 ao encaminhar solicitações para o aplicativo.

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

Consulte a seção acima sobre como configurar a anotação.

Problemas conhecidos, limites de produtos e orientações

Veja a seguir limitações ou avisos importantes sobre o comportamento do Ingress for Anthos que determinam o uso seguro e aceitável. Entre em contato com a equipe de sua conta ou gke-mci-feedback@google.com se tiver dúvidas.

  • Os recursos do balanceador de carga do Compute Engine são criados com um nome que contém um prefixo mci-[6 char hash]. Todos os recursos gerenciados do Ingress for Anthos em um projeto usam o mesmo prefixo. Esse prefixo é usado para gerenciar e coletar lixo dos recursos do Compute Engine que o Ingress for Anthos implanta. Como esse prefixo contém um hash gerado, é improvável que um projeto contenha recursos do Compute Engine fora do domínio do Ingress for Anthos com esse mesmo prefixo. No entanto, os balanceadores de carga do Compute Engine no mesmo projeto não gerenciados pelo Ingress for Anthos não devem usar esse prefixo. Caso contrário, eles serão excluídos.

  • O Ingress for Anthos só aceita clusters no mesmo projeto. Somente uma instância do Ingress for Anthos pode ser implantada por projeto, embora o escopo dos clusters possa ser controlado com a seleção de cluster. Isso permite que os recursos do MultiClusterService sejam implantados apenas em subconjuntos específicos de clusters em um projeto.

  • O Ingress for Anthos e os ambientes têm uma cota pré-configurada de no máximo 15 clusters por projeto. Essa cota pode ser aumentada, se necessário. Entre em contato com a equipe da conta para solicitar um limite de cluster por projeto maior se você tiver a exigência de registrar mais clusters.

  • O Ingress for Anthos tem uma cota pré-configurada de 50 recursos de MultiClusterIngress e 100 de MultiClusterService por projeto. Isso permite que até 50 recursos de MCI e 100 de MCS sejam criados em um cluster de configuração para qualquer número de clusters de back-end até o máximo de clusters por projeto. Essa cota pode ser aumentada, se necessário. Entre em contato com a equipe da sua conta para solicitar cotas maiores de MCI e MCS por projeto se você tiver a exigência de uma escala maior.

  • A configuração de HTTPS requer um endereço IP estático pré-alocado. No momento, o HTTPS não é compatível com endereços IP temporários.

A seguir