Solución de problemas y operaciones para Ingress de varios clústeres

El controlador de Ingress de GKE Enterprise administra los recursos de Compute Engine. Los recursos MultiClusterIngress y MultiClusterService se asignan a diferentes recursos de Compute Engine, por lo que comprender la relación entre estos recursos te ayuda a solucionar problemas. Por ejemplo, examina el siguiente recurso MultiClusterIngress:

apiVersion: extensions/v1beta1
kind: MultiClusterIngress
metadata:
  name: foo-ingress
spec:
  template:
    spec:
      rules:
      - host: store.foo.com
        http:
          paths:
          - backend:
              serviceName: store-foo
              servicePort: 80
      - host: search.foo.com
        http:
          paths:
          - backend:
              serviceName: search-foo
              servicePort: 80

Asignaciones de recursos de Compute Engine para Ingress de varios clústeres

En la siguiente tabla, se muestra el mapeo de los recursos de flota a los recursos creados en los clústeres de Kubernetes y Google Cloud:

Recurso de Kubernetes Recurso de Google Cloud Descripción
MultiClusterIngress Regla de reenvío VIP de balanceador de cargas de HTTP(S)
Proxy de destino Configuración de las interrupciones de HTTP/S extraída de las anotaciones y del bloque de TLS
Mapa de URL Asignación de la ruta de host virtual desde la sección de reglas.
MultiClusterService Service de Kubernetes Recurso derivado de la plantilla.
Servicio de backend Se crea un servicio de backend para cada par (Service, ServicePort).
Grupos de extremos de red Conjunto de pods de backend que participan en el Service.

Inspecciona los recursos del balanceador de cargas de Compute Engine

Después de crear un balanceador de cargas, el estado de Ingress contendrá los nombres de cada recurso de Compute Engine que se creó para construir el balanceador de cargas. Por ejemplo:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
  CloudResources:
    Firewalls: "mci-l7"
    ForwardingRules: "mci-abcdef-myforwardingrule"
    TargetProxies: "mci-abcdef-mytargetproxy"
    UrlMap: "mci-abcdef-myurlmap"
    HealthChecks: "mci-abcdef-80-myhealthcheck"
    BackendServices: "mci-abcdef-80-mybackendservice"
    NetworkEndpointGroups: "k8s1-neg1", "k8s1-neg2", "k8s1-neg3"

No se creó la VIP

Si no ves una VIP, es posible que se haya producido un error durante su creación. Para descubrir si se produjo un error, ejecuta el siguiente comando:

kubectl describe mci shopping-service

Es posible que el resultado sea similar a este:

Name:         shopping-service
Namespace:    prod
Labels:       <none>
Annotations:  <none>
API Version:  networking.gke.io/v1beta1
Kind:         MultiClusterIngress
Metadata:
  Creation Timestamp:  2019-07-16T17:23:14Z
  Finalizers:
    mci.finalizer.networking.gke.io
Spec:
  Template:
    Spec:
      Backend:
        Service Name:  shopping-service
        Service Port:  80
Status:
  VIP:  34.102.212.68
Events:
  Type     Reason  Age   From                              Message
  ----     ------  ----  ----                              -------
  Warning  SYNC    29s   multi-cluster-ingress-controller  error translating MCI prod/shopping-service: exceeded 4 retries with final error: error translating MCI prod/shopping-service: multiclusterservice prod/shopping-service does not exist

En este ejemplo, el error fue que el usuario no creó un recurso MultiClusterService con un recurso MultiClusterIngress que hiciera referencia a él.

Respuesta 502

Si tu balanceador de cargas adquirió una VIP, pero entrega de forma continua una respuesta 502, es posible que haya un error en las verificaciones de estado del balanceador de cargas. Las verificaciones de estado pueden fallar por dos motivos:

  1. Los pods de la aplicación no están en buen estado (consulta la depuración de la consola de Cloud para obtener un ejemplo).
  2. Un firewall mal configurado impide que los verificadores de estado de Google realicen verificaciones de estado.

En el caso n.º 1, asegúrate de que tu aplicación entregue una respuesta 200 en la ruta “/”.

En el caso n.º 2, asegúrate de que exista un firewall llamado “mci-default-l7” en tu VPC. El controlador de Ingress crea el firewall en tu VPC para garantizar que los verificadores de estado de Google puedan acceder a tus backends. Si el firewall no existe, asegúrate de que no haya automatización externa que lo borre cuando se cree.

No se agregó ni se quitó tráfico del clúster

Cuando se agrega una membresía nueva, el tráfico debe acceder a los backends en el clúster subyacente cuando corresponda. Del mismo modo, si se quita una membresía, el tráfico no debe acceder a los backends del clúster subyacente. Si no notas que este comportamiento no se produce, verifica si hay errores en los recursos MultiClusterIngress y MultiClusterService.

Dentro de los casos usuales en los que se produce este error, se incluyen los siguientes: cuando se agrega una membresía nueva en un clúster de GKE que no está en modo nativo de VPC o cuando se agrega una membresía nueva, pero no se implementa una aplicación en el clúster de GKE.

  1. Describe el recurso MultiClusterService:

    kubectl describe mcs zone-svc

  2. Describe el recurso MultiClusterIngress:

    kubectl describe mci zone-mci

Migración del clúster de configuración

Para obtener más información sobre los casos prácticos de migración, consulta el concepto de diseño del clúster de configuración.

La migración de un clúster de configuración puede generar interrupciones si no se maneja de forma correcta. Sigue estos lineamientos cuando realices una migración de clúster de configuración:

  1. Asegúrate de usar la anotación static-ip en los recursos MultiClusterIngress. De lo contrario, el tráfico se interrumpirá durante la migración. Se volverán a crear IP efímeras cuando se migren los clústeres de configuración.
  2. Los recursos MultiClusterIngress y MultiClusterService deben implementarse de forma idéntica en el clúster de configuración existente y en el nuevo. Si hay diferencias entre ambos, se conciliarán recursos MultiClusterService y MultiClusterIngress distintos en el clúster de configuración nuevo.
  3. Solo hay un clúster de configuración activo a la vez. Los recursos MultiClusterIngress y MultiClusterService en el nuevo clúster de configuración no afectarán los recursos del balanceador de cargas hasta que se cambie el clúster de configuración.

Para migrar el clúster de configuración, ejecuta el siguiente comando:

  gcloud container fleet ingress update \
    --config-membership=projects/project_id/locations/global/memberships/new_config_cluster

Verifica que el comando funcionó. Para ello, asegúrate de que no haya errores visibles en el estado de la función:

  gcloud container fleet ingress describe

Depuración de Console

En la mayoría de los casos, es útil verificar el estado exacto del balanceador de cargas cuando se depura un problema. Para encontrar el balanceador de cargas, dirígete a Balanceo de cargas en la consola de Google Cloud.

Códigos de error y advertencia

Ingress de varios clústeres emite códigos de advertencia y error en los recursos MultiClusterIngress y MultiClusterService, así como el campo de descripción de gcloud multiclusteringress para los problemas conocidos. Estos mensajes tienen códigos de error y advertencia documentados para que sea más fácil comprender lo que sucede cuando algo no funciona como se espera. Cada código consta de un ID de error en el formato AVMBR123, en el que 123 es un número único que corresponde a un error o una advertencia, junto con sugerencias sobre cómo se puede resolver.

AVMBR101: Annotation [NAME] not recognized

Este error aparece cuando se especifica una anotación en un manifiesto MultiClusterIngress o MultiClusterService que no se reconoce. Existe un par de razones por las que es posible que no se reconozca la anotación:

  1. La anotación no es compatible con Ingress de varios clústeres. Esto puede suceder si se anotan recursos que no se prevee que use el controlador de Ingress de GKE Enterprise.

  2. La anotación es compatible, pero está mal escrita y, por lo tanto, no se reconoce.

En ambos casos, consulta la documentación para descubrir las anotaciones compatibles y cómo se especifican.

AVMBR102: [RESOURCE_NAME] not found

Este error aparece cuando se especifica un recurso complementario en MultiClusterIngress, pero no se lo encuentra en el archivo de configuración de la membresía. Por ejemplo, este error se produce cuando una MultiClusterIngress hace referencia a un MultiClusterService que no se puede encontrar o un MultiClusterService hace referencia a una BackendConfig que no se puede encontrar. Existen dos razones por las que no se pudo encontrar un recurso:

  1. No se encuentra en el espacio de nombres adecuado. Asegúrate de que los recursos que hacen referencia entre sí estén en el mismo espacio de nombres.
  2. El nombre del recurso está mal escrito.
  3. El recurso no existe con el espacio de nombres y el nombre adecuados. En este caso, créalo.

AVMBR103: [CLUSTER_SELECTOR] is invalid

Este error aparece cuando un selector de clúster especificado en un MultiClusterService no es válido. Existen dos razones por las que este selector puede no ser válido:

  1. La string que se proporcionó contiene un error tipográfico.
  2. La string que se proporcionó hace referencia a una membresía que ya no existe en la flota.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

Este error se produce cuando no se puede encontrar el NetworkEndpointGroup (NEG) para un servicio y par de puerto de MultiClusterService en particular. Los NEG son los recursos que contienen los extremos del pod en cada uno de tus clústeres de backend. El motivo principal por el que es posible que los NEG no existan es que se produjo un error durante la creación o actualización de los servicios derivados en tus clústeres de backend. Revisa los eventos en el recurso MultiClusterService para obtener más información.

AVMBR105: Missing GKE Enterprise license.

Este error se muestra en Estado de la función y, además, indica que no está habilitada la API de GKE Enterprise (anthos.googleapis.com).

AVMBR106: Derived service is invalid: [REASON].

Este error se muestra en los eventos del recurso MultiClusterService. Una razón común para este error es que el recurso Service derivado de MultiClusterService tiene una especificación no válida.

Por ejemplo, esta MultiClusterService no tiene ninguna ServicePort definida en su especificación.

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: zone-mcs
  namespace: whereami
spec:
  clusters:
  - link: "us-central1-a/gke-us"
  - link: "europe-west1-c/gke-eu"

Este error se muestra en Estado de función y se produce porque no hay un clúster de GKE subyacente en el recurso de la membresía. Para verificarlo, ejecuta el siguiente comando:

gcloud container fleet memberships describe membership-name

Debes asegurarte de que no haya un vínculo de un recurso del clúster de GKE en el campo de extremo.

AVMBR108: GKE cluster [NAME] not found.

Este error se muestra en Estado de función y se genera si la membresía no tiene un clúster de GKE subyacente.

AVMBR109: [NAME] is not a VPC-native GKE cluster.

Este error se muestra en Estado de función. Se produce si el clúster de GKE especificado es un clúster basado en rutas. El controlador de Ingress de varios clústeres crea un balanceador de cargas nativo del contenedor con NEG. Los clústeres deben ser nativos de VPC para usar un balanceador de cargas nativo del contenedor.

Para obtener más información, consulta Crea un clúster nativo de la VPC.

AVMBR110: [IAM_PERMISSION] permission missing for GKE cluster [NAME].

Este error se muestra en Estado de función. Existen dos motivos para este error:

  1. El clúster de GKE subyacente para la membresía se encuentra ubicado en un proyecto diferente al de la membresía.
  2. Se quitó el permiso de IAM especificado del agente de servicio de MultiClusterIngress.

AVMBR111: Failed to get Config Membership: [REASON].

Este error se muestra en Estado de función. El motivo principal por el que se produce este error es que el archivo de configuración de la membresía se borró mientras la función estaba habilitada.

Nunca deberías necesitar borrar el archivo de configuración de la membresía. Si deseas cambiarlo, sigue los pasos para configurar la migración del clúster.

AVMBR112: HTTPLoadBalancing Addon is disabled in GKE Cluster [NAME].

Este error se muestra en Estado de función y se produce cuando el complemento HTTPLoadBalancing está inhabilitado en un clúster de GKE. Puedes actualizar el clúster de GKE para habilitar el complemento HTTPLoadBalancing.

gcloud container clusters update name --update-addons=HttpLoadBalancing=ENABLED

AVMBR113: This resource is orphaned.

En algunos casos, la utilidad de un recurso depende de que otro recurso haga referencia a él. Este error se produce cuando se crea un recurso de Kubernetes, pero otro recurso no hace referencia a él. Por ejemplo, aparecerá si creas un recurso BackendConfig al que no se hace referencia en MultiClusterService.