Implementa Ingress en clústeres

En esta página, se muestra cómo implementar un Ingress que entrega una aplicación en varios clústeres de GKE.

Instructivo para la implementación

En las siguientes tareas, implementarás Ingress for Anthos y una aplicación ficticia llamada zoneprinter en dos clústeres. El Ingress proporciona una dirección IP virtual (VIP) compartida para las implementaciones de la aplicación.

En esta página, se desarrolla el trabajo realizado en el artículo sobre cómo configurar Ingress for Anthos, en el que creaste y registraste dos clústeres. En este punto, deberías tener dos clústeres que también estén registrados en el Hub:

$ 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    ***             n1-standard-1  1.16.8-gke.9     2          RUNNING
gke-us  us-central1-a   1.16.8-gke.9    ***             n1-standard-1  1.16.6-gke.13 *  2          RUNNING

Crea el espacio de nombres

Debido a que los entornos tienen la propiedad de similitud de espacio de nombres, recomendamos que coordines la creación y administración de los espacios de nombres entre los clústeres para que el mismo grupo sea propietario y administrador de los espacios de nombres idénticos. Puedes crear espacios de nombres por equipo, por entorno, por aplicación o por componente de la aplicación. Los espacios de nombres pueden ser tan detallados como sea necesario, siempre que un espacio de nombres ns1 en un clúster tenga el mismo significado y uso que ns1 en otro clúster.

En este ejemplo, crearás un espacio de nombres zoneprinter para cada aplicación en cada clúster.

  1. Crea namespace.yaml a partir del siguiente manifiesto:

    apiVersion: v1
    kind: Namespace
    metadata:
      name: zoneprinter
    
  2. Cambia al contexto de gke-us:

    kubectl config use-context gke-us
    
  3. Crea el espacio de nombres:

    kubectl apply -f namespace.yaml
    
  4. Cambia al contexto de gke-eu:

    kubectl config use-context gke-eu
    
  5. Crea el espacio de nombres:

    kubectl apply -f namespace.yaml
    

Implementa la aplicación

  1. Crea deploy.yaml a partir del siguiente manifiesto:

    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. Cambia al contexto de gke-us:

    kubectl config use-context gke-us
    
  3. Implementa la aplicación zoneprinter:

    kubectl apply -f deploy.yaml
    
  4. Cambia al contexto de gke-eu:

    kubectl config use-context gke-eu
    
  5. Implementa la aplicación zoneprinter:

    kubectl apply -f deploy.yaml
    
  6. Verifica que la aplicación zoneprinter se haya implementado correctamente en cada clúster:

    kubectl get deployment --namespace zoneprinter
    

    El resultado debería ser similar a este en ambos clústeres:

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

Implementa a través del clúster de configuración

Ahora que la aplicación está implementada en gke-us y gke-eu, implementarás un balanceador de cargas mediante la implementación de los recursos MultiClusterIngress (MCI) y MultiClusterService (MCS) en el clúster de configuración. MCI y MCS son recursos personalizados (CRD) que son los equivalentes de varios clústeres a los recursos Ingress y Service.

En los pasos de la guía de configuración, configuraste el clúster gke-us como el clúster de configuración. El clúster de configuración se usa para implementar y configurar Ingress en todos los clústeres.

  1. Configura el contexto en el clúster de configuración.

    kubectl config use-context gke-us
    

MultiClusterService

  1. Crea un archivo llamado mcs.yaml a partir del siguiente manifiesto:

    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. Implementa el recurso MultiClusterService que coincida con la aplicación zoneprinter:

    kubectl apply -f mcs.yaml
    
  3. Verifica que el recurso zone-mcs se haya implementado correctamente en el clúster de configuración:

    kubectl get mcs -n zoneprinter
    

    El resultado es similar al siguiente ejemplo:

    NAME       AGE
    zone-mcs   9m26s
    

Este MCS crea un Service sin interfaz gráfica derivado en cada clúster que coincida con pods con app: zoneprinter. Puedes ver que existe uno en el clúster sh kubectl get service -n zoneprinter de gke-us.

The output is similar to this:

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

También habrá un Service sin interfaz gráfica similar en gke-eu. Estos Services locales se usan para seleccionar de forma dinámica los extremos del pod a fin de programar el balanceador de cargas del Ingress global con backends.

MultiClusterIngress

  1. Crea un archivo llamado mci.yaml a partir del siguiente manifiesto:

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

    Ten en cuenta que esta configuración enruta todo el tráfico al MultiClusterService llamado zone-mcs que existe en el espacio de nombres zoneprinter.

  2. Implementa el recurso MultiClusterIngress que hace referencia a zone-mcs como un backend:

    kubectl apply -f mci.yaml
    

    El resultado es similar al siguiente ejemplo:

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

    Ten en cuenta que MultiClusterIngress tiene el mismo esquema que el Ingress de Kubernetes. La semántica del recurso Ingress también es la misma, salvo el campo backend.serviceName.

El campo backend.serviceName en un MultiClusterIngress hace referencia a un MultiClusterService en la API de Hub en lugar de un Service en un clúster de Kubernetes. Esto significa que cualquiera de las opciones de configuración para Ingress, como la finalización de TLS, se puede establecer de la misma manera.

Valida un estado de implementación exitosa

La implementación del balanceador de cargas de Google Cloud puede tardar varios minutos en implementarse para los balanceadores de cargas nuevos. La actualización de los balanceadores de cargas existentes se completa más rápido porque no es necesario implementar los recursos nuevos. El recurso MCI detalla los recursos subyacentes de Compute Engine que se crearon en su nombre.

  1. Verifica que la implementación se haya realizado correctamente:

    kubectl describe mci zone-ingress -n zoneprinter
    

    El resultado es similar al siguiente ejemplo:

    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
    

Hay varios campos que indican el estado de la implementación de este Ingress:

  • Events es el primer lugar para buscar. Si se produjo un error, aparecerá aquí.
  • Cloud Resource enumera los recursos de Compute Engine, como las reglas de reenvío, los servicios de backend y las reglas de firewall que creó el controlador de Ingress de Anthos. Si no aparecen en la lista, significa que aún no se crearon. Puedes inspeccionar recursos individuales de Compute Engine mediante Console o el comando gcloud para obtener el estado.
  • VIP muestra una dirección IP una vez que se asignó una. Ten en cuenta que es posible que el balanceador de cargas aún no procese tráfico, aunque exista la VIP. Si no ves una VIP después de un par de minutos o si el balanceador de cargas no entrega una respuesta 200 en 10 minutos, consulta la página sobre solución de problemas y operaciones.

Si los eventos de salida son Normal, es probable que la implementación del MCI sea correcta, pero la única manera de determinar si toda la ruta del tráfico es funcional es probándola.

  1. Valida que la aplicación realiza las entregas en la VIP con el extremo /ping:

    curl ingress-vip/ping
    

    El resultado es similar al siguiente ejemplo:

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

    El resultado debe indicar la región y el backend de la aplicación.

  2. También puedes ir a la URL http://ingress-vip en tu navegador para ver una versión gráfica de la aplicación que muestra la región desde la que se entrega.

    El clúster al que se reenvía el tráfico depende de tu ubicación. El GCLB está diseñado para reenviar el tráfico del cliente al backend disponible con capacidad más cercano.

Especificaciones de los recursos

Especificaciones de MultiClusterService

La definición de MultiClusterService consta de dos partes:

  1. Una sección template, que define el servicio que se creará en los clústeres de Kubernetes. Ten en cuenta que, si bien la sección template contiene campos compatibles con un servicio típico, solo hay dos campos compatibles con MultiClusterService: selector y ports. Los otros campos se ignoran.

  2. Una sección clusters opcional, que define qué clústeres recibirán el tráfico y las propiedades del balanceo de cargas para cada clúster. Si no se especifica una sección clusters o si no se enumera ningún clúster, se usarán todos los clústeres de forma predeterminada.

En el siguiente manifiesto, se describe un MCS estándar:

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

Donde:

  • name es el nombre del MCS. El campo serviceName hace referencia a este nombre en los recursos MCI.
  • namespace es el espacio de nombres de Kubernetes en el que se implementa el MCS. Debe estar en el mismo espacio de nombres que el MCI y los pods en todos los clústeres del entorno.
  • pod-label es la etiqueta que determina qué pods se seleccionan como backends para este MCS en todos los clústeres del entorno.
  • port debe coincidir con el puerto al que hace referencia el MCI que hace referencia a este MCS.
  • target-port es el puerto que se usa para enviar tráfico al pod desde el GCLB. Se crea un NEG en cada clúster con este puerto como su puerto de entrega.

Especificaciones de MultiClusterIngress

En el siguiente mci.yaml, se describe el frontend del balanceador de cargas:

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

Donde:

  • name es el nombre del recurso de MCI.
  • namespace es el espacio de nombres de Kubernetes en el que se implementa el MCI. Debe estar en el mismo espacio de nombres que el MCS y los pods en todos los clústeres del entorno.
  • default-service actúa como el backend predeterminado para todo el tráfico que no coincide con ninguna regla de host ni de ruta de acceso. Este es un campo obligatorio y se debe especificar un backend predeterminado en el MCI, incluso si hay otras coincidencias de host o de ruta de acceso configuradas.
  • port es cualquier número de puerto válido. Este debe coincidir con el campo port de los recursos MCS.
  • host-header coincide con el tráfico según el campo del encabezado del host HTTP. El campo host es opcional.
  • path coincide con el tráfico según la ruta de acceso de la URL HTTP. El campo path es opcional.
  • service es el nombre de un MCS que se implementa en el mismo espacio de nombres y clúster de configuración que este MCI.

Funciones de Ingress for Anthos

En esta sección, se muestra cómo configurar funciones adicionales de Ingress for Anthos.

Selección de clústeres

De forma predeterminada, los Services derivados de Ingress for Anthos se programan en cada clúster miembro. Sin embargo, es posible que desees aplicar reglas de entrada a clústeres específicos. Estos son algunos casos prácticos:

  • Aplica Ingress for Anthos a todos los clústeres, excepto al clúster de configuración para aislarlo.
  • Migra cargas de trabajo entre clústeres de manera azul-verde.
  • Enruta a los backends de aplicaciones que solo existen en un subconjunto de clústeres.
  • Usa una solo VIP L7 para el enrutamiento del host o de la ruta de acceso a backends que se alojan en clústeres diferentes.

La selección de clústeres te permite seleccionarlos por región o nombre en el objeto MultiClusterService. Esto controla a qué clústeres apunta tu Ingress for Anthos y dónde están programados los Services derivados. Los clústeres dentro del mismo Hub y la misma región no deben tener el mismo nombre para que se pueda hacer referencia a los clústeres de manera única.

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

    Actualmente, esta especificación crea servicios derivados en todos los clústeres, que es el comportamiento predeterminado.

  2. Agrega las siguientes líneas en la sección de clústeres:

    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"
    

    En este ejemplo, se crean recursos Service derivados solo en clústeres de gke-us y gke-eu. Debes seleccionar clústeres para aplicar reglas de entrada de manera selectiva. Si no se especifica la sección “clústeres” del MultiClusterService, o si no se enumera ningún clúster, se interpretará como “todos” los clústeres de forma predeterminada.

Compatibilidad con HTTPS

El secreto de Kubernetes admite HTTPS. Antes de habilitar la compatibilidad con HTTPS, debes crear una dirección IP estática. Esta IP estática permite que HTTP y HTTPS compartan la misma dirección IP. Para obtener más información, consulta cómo crear una IP estática.

Una vez que creaste una dirección IP estática, puedes crear un secreto.

  1. Crea un secreto:

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

    En el ejemplo anterior, secret-name es el nombre de tu secreto.

  2. Actualiza el archivo mci.yaml con la IP estática y el secreto:

    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
    

Compatibilidad con BackendConfig

La CRD de BackendConfig te permite personalizar la configuración en el recurso de BackendService de Compute Engine. Actualmente, solo la configuración de verificación de estado es compatible con BackendConfig. La especificación compatible es la siguiente:

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]

Para usar BackendConfig, conéctalo a tu recurso MultiClusterService mediante una anotación:

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 obtener más información sobre la semántica de BackendConfig, consulta la sección Asocia un puerto de servicio a un BackendConfig.

Ciclo de vida de los recursos

Cambios de configuración

Los recursos MultiClusterIngress y MultiClusterService se comportan como objetos estándar de Kubernetes, por lo que los cambios en los objetos se reflejan de forma asíncrona en el sistema. Cualquier cambio que dé como resultado una configuración no válida hace que los objetos de Google Cloud asociados permanezcan sin cambios y se genere un error en la transmisión de eventos del objeto. Los errores asociados con la configuración se informarán como eventos.

Administra recursos de Kubernetes

Si borras el objeto Ingress se elimina el balanceador de cargas HTTP(S), por lo que el tráfico ya no se reenviará a ningún MultiClusterService definido.

Si borras MultiClusterService, se quitarán los servicios derivados asociados de cada clúster.

Administra clústeres

Puedes cambiar el conjunto de clústeres al que apunta el balanceador de cargas si agregas o quitas una membresía.

Por ejemplo, para quitar el clúster gke-eu como backend de un Ingress, ejecuta lo siguiente:

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

donde

  • cluster-name es el nombre de tu clúster.
  • uri es el URI del clúster de GKE.

Para agregar un clúster en Europa, ejecuta lo siguiente:

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

Ten en cuenta que registrar o cancelar el registro de un clúster cambia su estado como backend para todos los Ingress. En el caso anterior, cancelar el registro del clúster gke-eu lo quita como backend disponible para todos los Ingress que crees. Si se registra un clúster nuevo, sucede lo contrario.

Inhabilita Ingress for Anthos

En Beta, inhabilitar Ingress for Anthos da como resultado recursos de red huérfanos. Para evitar esto, borra los recursos MultiClusterIngress y MultiClusterService y verifica que se borren todos los recursos de red asociados.

Inhabilita Ingress for Anthos:

gcloud alpha container hub ingress disable

Anotaciones

Crea una IP estática

  1. Asigna una IP estática:

    gcloud compute addresses create address-name --global
    

    En el ejemplo anterior, address-name es el nombre de la dirección que se creará.

    El resultado es similar al siguiente ejemplo:

    Created [https://www.googleapis.com/compute/v1/projects/project-id/global/addresses/address-name].
    
  2. Visualiza la dirección IP que acabas de crear:

    gcloud compute addresses list
    

    El resultado es similar al siguiente ejemplo:

    NAME          ADDRESS/RANGE  TYPE      STATUS
    address-name  34.102.201.47  EXTERNAL  RESERVED
    
  3. Actualiza mci.yaml para aplicar la IP estática:

    kubectl get mci zone-mci -o yaml
    

    El resultado es similar al siguiente ejemplo:

    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 ya compartidos

Los certificados compartidos previamente son certificados subidos a Google Cloud que el balanceador de cargas puede usar para la finalización de TLS en lugar de los certificados almacenados en secretos de Kubernetes. Estos certificados se suben fuera de banda desde GKE a Google Cloud y se hace referencia a ellos mediante un objeto Ingress for Anthos. También se admiten varios certificados, ya sea mediante certificados compartidos previamente o secretos de Kubernetes.

Usar los certificados en Ingress for Anthos requiere la anotación networking.gke.io/pre-shared-certs y los nombres de los certificados. Cuando se especifican varios certificados para un objeto Ingress for Anthos determinado, rige un orden predeterminado sobre qué certificado se presenta al cliente.

Puedes generar una lista de los certificados SSL disponibles si ejecutas lo siguiente:

gcloud compute ssl-certificates list

En el siguiente ejemplo, se describe el tráfico del cliente a uno de los hosts especificados que coincide con el nombre común de los certificados compartidos previamente, por lo que se presentará el certificado respectivo que coincida con el nombre de dominio.

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 las aplicaciones

Para la conexión del proxy del balanceador de cargas con tu aplicación, se usa HTTP de forma predeterminada. Con la anotación networking.gke.io/app-protocols, puedes configurar el balanceador de cargas para que use HTTPS o HTTP/2 cuando reenvíe solicitudes a tu aplicación.

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

Consulta la sección anterior sobre cómo configurar la anotación.

Problemas conocidos, límites de productos y orientación

Las siguientes son limitaciones o avisos importantes sobre el comportamiento de Ingress for Anthos que determinan un uso seguro y aceptable. Comunícate con el equipo de cuentas o escribe a gke-mci-feedback@google.com si tienes alguna pregunta.

  • Los recursos del balanceador de cargas de Compute Engine se crean con un nombre que contiene un prefijo mci-[6 char hash]. Todos los recursos administrados de Ingress for Anthos en un proyecto usan el mismo prefijo. Este prefijo se usa para administrar y recolectar elementos no utilizados de los recursos de Compute Engine que Ingress for Anthos implementa. Debido a que este prefijo contiene un hash generado, es poco probable que un proyecto contenga recursos de Compute Engine fuera del dominio de Ingress for Anthos con este mismo prefijo. Sin embargo, los balanceadores de cargas de Compute Engine en el mismo proyecto que no los administra Ingress for Anthos no deben usar este prefijo o se borrarán.

  • Ingress for Anthos solo admite clústeres dentro del mismo proyecto. Solo se puede implementar una instancia de Ingress for Anthos por proyecto, aunque los permisos de los clústeres se pueden controlar con la selección de clústeres. Esto permite que los recursos MultiClusterService se implementen solo en subconjuntos de clústeres específicos dentro de un proyecto.

  • Ingress for Anthos y Hub tienen una cuota preconfigurada de un máximo de 15 clústeres por proyecto. Esta cuota se puede aumentar si es necesario. Comunícate con tu equipo de cuentas con el fin de solicitar un límite de clúster por proyecto más alto si tienes requisitos para registrar más clústeres.

  • Ingress for Anthos tiene una cuota preconfigurada de 50 recursos MultiClusterIngress y 100 recursos MultiClusterIngress por proyecto. Esto permite que se creen hasta 50 recursos MCI y 100 MCS en un clúster de configuración para cualquier cantidad de clústeres de backend hasta el máximo de clúster por proyecto. Esta cuota se puede aumentar si es necesario. Comunícate con tu equipo de cuentas para solicitar cuotas de MCI y MCS más altas si tienes requisitos de mayor escalamiento.

  • La configuración de HTTPS requiere una dirección IP estática asignada previamente. En este momento, HTTPS no es compatible con direcciones IP efímeras.

Próximos pasos