Implementa una puerta de enlace externa de varios clústeres

En este documento, se te guía a través de un ejemplo práctico para implementar una puerta de enlace externa de varios clústeres que enruta el tráfico de Internet a una aplicación que se ejecuta en dos clústeres de GKE diferentes.

Las Gateways de varios clústeres proporcionan una forma eficaz de administrar el tráfico de los servicios implementados en varios clústeres de GKE. Si usas la infraestructura global de balanceo de cargas de Google, puedes crear un solo punto de entrada para tus aplicaciones, lo que simplifica la administración y mejora la confiabilidad.

En este instructivo, usarás una aplicación de ejemplo de store para simular una situación real en la que un servicio de compras en línea es propiedad de equipos independientes y está operado por ellos, y se implementa en una flota de clústeres de GKE compartidos.

En este ejemplo, se muestra cómo configurar el enrutamiento basado en rutas para dirigir el tráfico a diferentes clústeres.

Antes de comenzar

Las puertas de enlace de varios clústeres requieren cierta preparación del entorno antes de que puedan implementarse. Antes de continuar, sigue los pasos que se indican en Prepara tu entorno para las puertas de enlace de varios clústeres:

  1. Implemente clústeres de GKE

  2. Registra tus clústeres en una flota (si aún no lo hiciste).

  3. Habilita el Service de varios clústeres y los controladores de puertas de enlace de varios clústeres.

Por último, revisa las limitaciones y los problemas conocidos del controlador de puerta de enlace de GKE antes de usarlo en tu entorno.

Puerta de enlace externa, varios clústeres y varias regiones

En este instructivo, crearás una puerta de enlace externa de varios clústeres con la que se entrega tráfico externo en una aplicación que se ejecuta en dos clústeres de GKE.

store.example.com se implementa en dos clústeres de GKE y se expone a Internet a través de una puerta de enlace de varios clústeres.

En los siguientes pasos, haz lo siguiente:

  1. Implementa la aplicación store de muestra en los clústeres gke-west-1 y gke-east-1.
  2. Configura los servicios en cada clúster que se exportará a tu flota (servicios de varios clústeres).
  3. Implementa una puerta de enlace externa de varios clústeres y una HTTPRoute en tu clúster de configuración (gke-west-1).

Después de implementar la aplicación y los recursos de las puertas de enlace, puedes controlar el tráfico en los dos clústeres de GKE con el enrutamiento basado en rutas de acceso:

  • Las solicitudes a /west se enrutan a los Pods store en el clúster gke-west-1.
  • Las solicitudes a /east se enrutan a los Pods store en el clúster gke-east-1.
  • Las solicitudes a cualquier otra ruta de acceso se enrutan a cualquiera de los clústeres, según su estado, capacidad y proximidad al cliente solicitante.

Implementa la aplicación de demostración

  1. Crea la Deployment store y el espacio de nombres en los tres clústeres que se implementaron en Prepara tu entorno para las puertas de enlace de varios clústeres:

    kubectl apply --context gke-west-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-west-2 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml
kubectl apply --context gke-east-1 -f https://raw.githubusercontent.com/GoogleCloudPlatform/gke-networking-recipes/main/gateway/gke-gateway-controller/multi-cluster-gateway/store.yaml

    Implementa los siguientes recursos en cada clúster:

    namespace/store created
deployment.apps/store created

    En todos los ejemplos de esta página, se usa la app implementada en este paso. Asegúrate de que la app se implemente en los tres clústeres antes de probar cualquiera de los pasos restantes. En este ejemplo, solo se usan los clústeres gke-west-1 y gke-east-1, y gke-west-2 se usa en otro ejemplo.

Service de varios clústeres

Los servicios son la forma en que los Pods se exponen a los clientes. Debido a que el controlador de puertas de enlace de GKE usa el balanceo de cargas nativo del contenedor, no usa el balanceo de cargas de ClusterIP o Kubernetes para llegar a los Pods. El tráfico se envía directamente desde el balanceador de cargas a las direcciones IP del Pod. Sin embargo, los objetos de Service desempeñan una función crítica como un identificador lógico para la agrupación de Pods.

Los servicios de varios clústeres (MCS) son un estándar de API para los Services que abarcan clústeres y a través de su controlador de GKE se ofrece un descubrimiento de servicios en clústeres de GKE. El controlador de la puerta de enlace de varios clústeres usa recursos de la API de MCS para agrupar Pods en un Service que se pueda dirigir a varios profesionales o a través de ellos.

La API de Services de varios clústeres define los siguientes recursos personalizados:

  • ServiceExports asigna a un Service de Kubernetes mediante la exportación de los extremos de ese Service a todos los clústeres registrados en la flota. Cuando un Service tiene una ServiceExport correspondiente, significa que se puede abordar con una puerta de enlace de varios clústeres.
  • Con el controlador de Service de varios clústeres se genera ServiceImports de forma automática. ServiceExport y ServiceImport vienen en pares. Si existe una ServiceExport en la flota, se crea una ServiceImport correspondiente para permitir que se acceda al Service asignado a ServiceExport desde todos los clústeres.

La exportación de Services funciona de la siguiente manera. Existe un Service de almacenamiento en gke-west-1 que selecciona un grupo de Pods en ese clúster. Se crea un objeto ServiceExport en el clúster que permite que se pueda acceder a los Pods en gke-west-1 desde los otros clústeres de la flota. ServiceExport se asigna a los Services que tienen el mismo nombre y el mismo espacio de nombres que el recurso de ServiceExport y los expone.

apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store

En el siguiente diagrama, se muestra lo que sucede después de implementar una ServiceExport. Si existe un par Service y ServiceExport, el controlador de Service de varios clústeres implementa una ServiceImport correspondiente en cada clúster de GKE de la flota. ServiceImport es la representación local del Service store en cada clúster. Esto permite que el client Pod en gke-east-1 use ClusterIP o los Service sin interfaz gráfica para llegar a los store Pods en gke-west-1 Cuando se usan de esta manera, los Service de varios clústeres proporcionan un balanceo de cargas este-oeste entre clústeres sin necesidad de un Service LoadBalancer interno. Si deseas usar los Service de varios clústeres para el balanceo de cargas de clúster a clúster, consulta Configura Service de varios clústeres.

Los Services de varios clústeres exportan Services entre clústeres que permiten la comunicación de clúster a clúster

Las puertas de enlace de varios clústeres también usan ServiceImports, pero no para el balanceo de cargas de clúster a clúster. En cambio, las puerta de enlace usan ServiceImports como identificadores lógicos para un Service que existe en otro clúster o que se extiende a varios clústeres. La siguiente HTTPRoute hace referencia a una ServiceImport en lugar de un recurso de Service. Si se hace referencia a una ServiceImport, esto indica que reenvía el tráfico a un grupo de Pods de backend que se ejecutan en uno o más clústeres.

kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: store-route
  namespace: store
  labels:
    gateway: multi-cluster-gateway
spec:
  parentRefs:
  - kind: Gateway
    namespace: store
    name: external-http
  hostnames:
  - "store.example.com"
  rules:
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080

En el siguiente diagrama, se muestra cómo la HTTPRoute enruta el tráfico store.example.com a los Pods store en gke-west-1 y gke-east-1. El balanceador de cargas los trata como un grupo de backends. Si los Pods de uno de los clústeres se encuentran en mal estado, son inaccesibles o no tienen capacidad de tráfico, la carga de tráfico se balancea a los Pods restantes en el otro clúster. Los clústeres nuevos se pueden agregar o quitar con el Service store y ServiceExport. Esto agrega o quita con transparencia los Pods de backend sin ningún cambio explícito en la configuración del enrutamiento.

Recurso de MCS

Exporta Services

En este punto, la aplicación se ejecuta en ambos clústeres. A continuación, deberás exponer las aplicaciones y exportarlas mediante la implementación de objetos Service y ServiceExports en cada clúster.

  1. Aplica el siguiente manifiesto al clúster gke-west-1 para crear tus Services y servicios y exportaciones de store y store-west-1:

    cat << EOF | kubectl apply --context gke-west-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store
---
apiVersion: v1
kind: Service
metadata:
  name: store-west-1
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-west-1
  namespace: store
EOF

  2. Aplica el siguiente manifiesto al clúster gke-east-1 para crear tus Services y servicios y exportaciones de store y store-east-1:

    cat << EOF | kubectl apply --context gke-east-1 -f -
apiVersion: v1
kind: Service
metadata:
  name: store
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store
  namespace: store
---
apiVersion: v1
kind: Service
metadata:
  name: store-east-1
  namespace: store
spec:
  selector:
    app: store
  ports:
  - port: 8080
    targetPort: 8080
---
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
  name: store-east-1
  namespace: store
EOF

  3. Verifica que se hayan creado las ServiceExports correctas en el clúster.

    kubectl get serviceexports --context CLUSTER_NAME --namespace store

    Reemplaza CLUSTER_NAME por gke-west-1 y gke-east-1. El resultado se ve de la manera siguiente:

    # gke-west-1
NAME           AGE
store          2m40s
store-west-1   2m40s

# gke-east-1
NAME           AGE
store          2m25s
store-east-1   2m25s

    El resultado demuestra que el Service store contiene Pods store en ambos clústeres, y los Services store-west-1 y store-east-1 solo contienen Pods store en sus clústeres respectivos. Estos Service superpuestos se usan para apuntar a los Pods en varios clústeres o en un subconjunto de Pods en un solo clúster.

  4. Después de unos minutos, verifica que el controlador de Services de varios clústeres haya creado de forma automática el ServiceImports adjunto en todos los clústeres de la flota.

    kubectl get serviceimports --context CLUSTER_NAME --namespace store

    Reemplaza CLUSTER_NAME por gke-west-1 y gke-east-1. El resultado debe parecerse al siguiente:

    # gke-west-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.112.31.15"]    6m54s
store-east-1   ClusterSetIP   ["10.112.26.235"]   5m49s
store-west-1   ClusterSetIP   ["10.112.16.112"]   6m54s

# gke-east-1
NAME           TYPE           IP                  AGE
store          ClusterSetIP   ["10.72.28.226"]    5d10h
store-east-1   ClusterSetIP   ["10.72.19.177"]    5d10h
store-west-1   ClusterSetIP   ["10.72.28.68"]     4h32m

    Esto demuestra que se puede acceder a los tres Services desde ambos clústeres en la flota. Sin embargo, debido a que solo hay un clúster de configuración activo por flota, solo puedes implementar puertas de enlace y HTTPRouters que hagan referencia a estas ServiceImports en gke-west-1. Cuando una HTTPRouter en el clúster de configuración hace referencia a estas ServiceImports como backends, la puerta de enlace puede reenviar tráfico a estos servicios sin importar desde qué clúster se exporten.

Implementa la puerta de enlace y HTTPRouter

Una vez que se implementaron las aplicaciones, puedes configurar una puerta de enlace con la GatewayClass gke-l7-global-external-managed-mc. Con esta puerta de enlace se crea un balanceador de cargas de aplicaciones externo configurado para distribuir el tráfico entre los clústeres de destino.

  1. Aplica el siguiente manifiesto Gateway al clúster de configuración, gke-west-1 en este ejemplo:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: external-http
  namespace: store
spec:
  gatewayClassName: gke-l7-global-external-managed-mc
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      kinds:
      - kind: HTTPRoute
EOF

    A través de esta configuración de puerta de enlace se implementan recursos externos del balanceador de cargas de aplicaciones con la siguiente convención de nombres: gkemcg1-NAMESPACE-GATEWAY_NAME-HASH.

    Los recursos predeterminados creados con esta configuración son los siguientes:

    • 1 Balanceador de cargas: gkemcg1-store-external-http-HASH
    • 1 Dirección IP pública: gkemcg1-store-external-http-HASH
    • 1 Regla de reenvío: gkemcg1-store-external-http-HASH
    • 2 Servicios de backend:
      • Configuración predeterminada 404 de servicio de backend gkemcg1-store-gw-serve404-HASH
      • Configuración predeterminada 500 de servicio de backend gkemcg1-store-gw-serve500-HASH
    • 1 Verificación de estado
      • Verificación de estado 404 predeterminada: gkemcg1-store-gw-serve404-HASH
    • 0 reglas de enrutamiento (el mapa de URL está vacío)

    En esta etapa, cualquier solicitud a GATEWAY_IP:80 genera una página predeterminada que muestra el siguiente mensaje: fault filter abort.

  2. Aplica el siguiente manifiesto HTTPRoute al clúster de configuración, gke-west-1 en este ejemplo:

    cat << EOF | kubectl apply --context gke-west-1 -f -
kind: HTTPRoute
apiVersion: gateway.networking.k8s.io/v1
metadata:
  name: public-store-route
  namespace: store
  labels:
    gateway: external-http
spec:
  hostnames:
  - "store.example.com"
  parentRefs:
  - name: external-http
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /west
    backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store-west-1
      port: 8080
  - matches:
    - path:
        type: PathPrefix
        value: /east
    backendRefs:
      - group: net.gke.io
        kind: ServiceImport
        name: store-east-1
        port: 8080
  - backendRefs:
    - group: net.gke.io
      kind: ServiceImport
      name: store
      port: 8080
EOF

    En esta etapa, cualquier solicitud a GATEWAY_IP:80 genera una página predeterminada que muestra el siguiente mensaje: fault filter abort.

    Después de la implementación, este HTTPRoute configura el siguiente comportamiento de enrutamiento:

    • Las solicitudes a /west se enrutan a los Pods store en el clúster gke-west-1, ya que los Pods que selecciona la ServiceExport store-west-1 solo existen en el clúster gke-west-1.
    • Las solicitudes a /east se enrutan a los Pods store en el clúster gke-east-1, porque los Pods que selecciona la ServiceExport store-east-1 solo existen en el clúster gke-east-1.
    • Las solicitudes a cualquier otra ruta de acceso se enrutan en store los Pods en cualquiera de los clústeres, según su estado, capacidad y proximidad al cliente solicitante.
    • Las solicitudes a GATEWAY_IP:80 generan una página predeterminada que muestra el siguiente mensaje: fault filter abort.

    El HTTPRoute permite el enrutamiento a diferentes subconjuntos de clústeres mediante servicios superpuestos

    Ten en cuenta que si todos los Pods en un clúster determinado están en mal estado (o no existen), el tráfico al Service store solo se enviará a los clústeres que en realidad tengan Pods store. La existencia de un ServiceExport y un Service en un clúster determinado no garantiza que el tráfico se envíe a ese clúster. Los Pods deben existir y responder de manera afirmativa a la verificación de estado del balanceador de cargas. De lo contrario, el balanceador de cargas solo enviará tráfico a Pods store en buen estado en otros clústeres.

    Se crean recursos nuevos con esta configuración:

    • 3 Servicios de backend
      • El storeservicio de backendgkemcg1-store-store-8080-HASH
      • El store-east-1servicio de backendgkemcg1-store-store-east-1-8080-HASH
      • El store-west-1servicio de backendgkemcg1-store-store-west-1-8080-HASH
    • 3 Verificaciones de estado (
        )
      • La storeverificación de estado gkemcg1-store-store-8080-HASH
      • La store-east-1verificación de estado gkemcg1-store-store-east-1-8080-HASH
      • La store-west-1verificación de estado gkemcg1-store-store-west-1-8080-HASH
    • 1 regla de enrutamiento en el URLmap:
      • La store.example.comregla de enrutamiento:
      • 1 Host: store.example.com
      • Varios matchRules para enrutar a los nuevos servicios de backend

En el siguiente diagrama, se muestran los recursos que implementaste en ambos clústeres. Debido a que gke-west-1 es el clúster de configuración de puerta de enlace, es el clúster en el que el controlador de puerta de enlace observa nuestras puerta de enlace, HTTPRoutes y ServiceImports. Cada clúster tiene una ServiceImport store y otra ServiceImport específica para ese clúster. Ambos apuntan a los mismos Pods. Esto permite que HTTPRoute especifique con exactitud dónde debe ir el tráfico: a los Pods store en un clúster específico o a los Pods store en todos los clústeres.

Este es el modelo de recursos de los Services de las puertas de enlace y de varios clústeres en ambos clústeres

Ten en cuenta que este es un modelo de recursos lógico, no una descripción del flujo de tráfico. La ruta de tráfico va directamente del balanceador de cargas a los Pods de backend y no tiene relación directa con el clúster que es el clúster de configuración.

Valida la implementación

Ahora puedes emitir solicitudes a nuestra puerta de enlace de varios clústeres y distribuir el tráfico entre varios clústeres de GKE.

  1. Verifica que la puerta de enlace y la HTTPRoute se hayan implementado de forma correcta inspeccionando del estado y los eventos de la puerta de enlace.

    kubectl describe gateways.gateway.networking.k8s.io external-http --context gke-west-1 --namespace store

    El resultado debería ser similar al siguiente:

    Name:         external-http
Namespace:    store
Labels:       <none>
Annotations:  networking.gke.io/addresses: /projects/PROJECT_NUMBER/global/addresses/gkemcg1-store-external-http-laup24msshu4
              networking.gke.io/backend-services:
                /projects/PROJECT_NUMBER/global/backendServices/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/backendServices/gke...
              networking.gke.io/firewalls: /projects/PROJECT_NUMBER/global/firewalls/gkemcg1-l7-default-global
              networking.gke.io/forwarding-rules: /projects/PROJECT_NUMBER/global/forwardingRules/gkemcg1-store-external-http-a5et3e3itxsv
              networking.gke.io/health-checks:
                /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-store-gw-serve404-80-n65xmts4xvw2, /projects/PROJECT_NUMBER/global/healthChecks/gkemcg1-s...
              networking.gke.io/last-reconcile-time: 2023-10-12T17:54:24Z
              networking.gke.io/ssl-certificates:
              networking.gke.io/target-http-proxies: /projects/PROJECT_NUMBER/global/targetHttpProxies/gkemcg1-store-external-http-94oqhkftu5yz
              networking.gke.io/target-https-proxies:
              networking.gke.io/url-maps: /projects/PROJECT_NUMBER/global/urlMaps/gkemcg1-store-external-http-94oqhkftu5yz
API Version:  gateway.networking.k8s.io/v1
Kind:         Gateway
Metadata:
  Creation Timestamp:  2023-10-12T06:59:32Z
  Finalizers:
    gateway.finalizer.networking.gke.io
  Generation:        1
  Resource Version:  467057
  UID:               1dcb188e-2917-404f-9945-5f3c2e907b4c
Spec:
  Gateway Class Name:  gke-l7-global-external-managed-mc
  Listeners:
    Allowed Routes:
      Kinds:
        Group:  gateway.networking.k8s.io
        Kind:   HTTPRoute
      Namespaces:
        From:  Same
    Name:      http
    Port:      80
    Protocol:  HTTP
Status:
  Addresses:
    Type:   IPAddress
    Value:  34.36.127.249
  Conditions:
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has deprecated this condition, do not depend on it.
    Observed Generation:   1
    Reason:                Scheduled
    Status:                True
    Type:                  Scheduled
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:
    Observed Generation:   1
    Reason:                Accepted
    Status:                True
    Type:                  Accepted
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:
    Observed Generation:   1
    Reason:                Programmed
    Status:                True
    Type:                  Programmed
    Last Transition Time:  2023-10-12T07:00:41Z
    Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
    Observed Generation:   1
    Reason:                Ready
    Status:                True
    Type:                  Ready
  Listeners:
    Attached Routes:  1
    Conditions:
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:
      Observed Generation:   1
      Reason:                Programmed
      Status:                True
      Type:                  Programmed
      Last Transition Time:  2023-10-12T07:00:41Z
      Message:               The OSS Gateway API has altered the "Ready" condition semantics and reservedit for future use.  GKE Gateway will stop emitting it in a future update, use "Programmed" instead.
      Observed Generation:   1
      Reason:                Ready
      Status:                True
      Type:                  Ready
    Name:                    http
    Supported Kinds:
      Group:  gateway.networking.k8s.io
      Kind:   HTTPRoute
Events:
  Type    Reason  Age                    From                   Message
  ----    ------  ----                   ----                   -------
  Normal  UPDATE  35m (x4 over 10h)      mc-gateway-controller  store/external-http
  Normal  SYNC    4m22s (x216 over 10h)  mc-gateway-controller  SYNC on store/external-http was a success

  2. Una vez que la puerta de enlace se implementó correctamente, recupera la dirección IP externa de la puerta de enlace external-http.

    kubectl get gateways.gateway.networking.k8s.io external-http -o=jsonpath="{.status.addresses[0].value}" --context gke-west-1 --namespace store

    Reemplaza VIP en los siguientes pasos por la dirección IP que recibas como resultado.

  3. Envía tráfico a la ruta raíz del dominio. Esto balancea las cargas del tráfico a la ServiceImport store, que se encuentra en los clústeres gke-west-1 y gke-east-1. El balanceador de cargas envía tu tráfico a la región más cercana a ti y es posible que no veas respuestas de la otra región.

    curl -H "host: store.example.com" http://VIP

    El resultado confirma que el Pod entregó la solicitud desde el clúster gke-east-1:

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-t2lp.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-dg22z",
  "pod_name_emoji": "⏭",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:32:51"
}

  4. A continuación, envía el tráfico a la ruta /west. Esto enruta el tráfico a la ServiceImport store-west-1, que solo tiene Pods en ejecución en el clúster gke-west-1. Un objeto ServiceImport específico del clúster, como store-west-1, permite que el propietario de una aplicación envíe tráfico de forma explícita a un clúster específico, en lugar de permitir que el balanceador de cargas tome la decisión.

    curl -H "host: store.example.com" http://VIP/west

    El resultado confirma que el Pod entregó la solicitud desde el clúster gke-west-1:

    {
  "cluster_name": "gke-west-1", 
  "zone": "us-west1-a", 
  "host_header": "store.example.com",
  "node_name": "gke-gke-west-1-default-pool-65059399-2f41.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-d25m5",
  "pod_name_emoji": "🍾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:39:15",
}

  5. Por último, envía tráfico a la ruta /east.

    curl -H "host: store.example.com" http://VIP/east

    El resultado confirma que el Pod entregó la solicitud desde el clúster gke-east-1:

    {
  "cluster_name": "gke-east-1",
  "zone": "us-east1-b",
  "host_header": "store.example.com",
  "node_name": "gke-gke-east-1-default-pool-7aa30992-7j7z.c.agmsb-k8s.internal",
  "pod_name": "store-5f5b954888-hz6mw",
  "pod_name_emoji": "🧜🏾",
  "project_id": "agmsb-k8s",
  "timestamp": "2021-06-01T17:40:48"
}

Realiza una limpieza

Después de completar los ejercicios de este documento, sigue estos pasos para quitar los recursos a fin de prevenir cobros no deseados en tu cuenta:

  1. Borra los clústeres.

  2. Anula el registro de tus clústeres en la flota si no es necesario que estén registrados para otro propósito.

  3. Inhabilita la función multiclusterservicediscovery:

    gcloud container fleet multi-cluster-services disable

  4. Inhabilitar entrada de varios clústeres

    gcloud container fleet ingress disable

  5. Inhabilita las API:

    gcloud services disable \
    multiclusterservicediscovery.googleapis.com \
    multiclusteringress.googleapis.com \
    trafficdirector.googleapis.com \
    --project=PROJECT_ID

Soluciona problemas

Sin upstream en buen estado

Síntoma:

El siguiente problema puede ocurrir cuando creas una puerta de enlace, pero no puedes acceder a los servicios de backend (código de respuesta 503):

no healthy upstream

Motivo:

Este mensaje de error indica que el sistema de sondeo de verificación de estado no puede encontrar servicios de backend en buen estado. Es posible que tus servicios de backend estén en buen estado, pero es posible que debas personalizar las verificaciones de estado.

Solución alternativa:

Para resolver este problema, personaliza la verificación de estado según los requisitos de tu aplicación (por ejemplo, /health) mediante un HealthCheckPolicy.

¿Qué sigue?