Solución de problemas y operaciones de entrada de varios clústeres

El controlador de Ingress de GKE Enterprise gestiona los recursos de Compute Engine. Los recursos MultiClusterIngress y MultiClusterService se asignan a diferentes recursos de Compute Engine, por lo que entender la relación entre estos recursos te ayudará a solucionar problemas. Por ejemplo, consulta 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 a recursos de Multi Cluster Ingress

En la tabla siguiente se muestra la asignación de recursos de la flota a los recursos creados en los clústeres de Kubernetes y Google Cloud:

Recurso de Kubernetes Google Cloud recurso Descripción
MultiClusterIngress Regla de reenvío VIP del balanceador de carga HTTP(S).
Proxy de destino Ajustes de terminación de HTTP/S tomados de las anotaciones y del bloque TLS.
Mapa de URLs Mapeo de rutas de host virtual de la sección de reglas.
Servicio de varios clústeres Servicio de Kubernetes Recurso derivado de una plantilla.
Servicio de backend Se crea un servicio de backend para cada par (Service, ServicePort).
Grupos de puntos finales de red Conjunto de pods de backend que participan en el servicio.

Inspeccionar recursos de balanceadores de carga de Compute Engine

Después de crear un balanceador de carga, el estado de Multi Cluster Ingress contendrá los nombres de todos los recursos de Compute Engine que se hayan creado para construir el balanceador de carga. 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"

VIP no creado

Si no ves ningún VIP, es posible que se haya producido un error durante su creación. Para comprobar si se ha producido un error, ejecuta el siguiente comando:

kubectl describe mci shopping-service

La salida puede ser similar a la siguiente:

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 se debe a que el usuario no ha creado un recurso MultiClusterService al que hace referencia un MultiClusterIngress.

Respuesta 502

Si tu balanceador de carga ha adquirido una dirección IP virtual, pero siempre devuelve una respuesta 502, es posible que las comprobaciones del estado del balanceador de carga estén fallando. Las comprobaciones del estado pueden fallar por dos motivos:

  1. Los pods de la aplicación no están en buen estado (consulta la sección de depuración de la consola de Cloud, por ejemplo).
  2. Un cortafuegos mal configurado impide que los comprobadores de estado de Google realicen comprobaciones del estado.

En el caso del punto 1, asegúrate de que tu aplicación esté sirviendo una respuesta 200 en la ruta "/".

En el caso del paso 2, asegúrate de que haya un cortafuegos llamado "mci-default-l7" en tu VPC. El controlador de entrada crea el cortafuegos en tu VPC para asegurarse de que los comprobadores de estado de Google puedan acceder a tus back-ends. Si el cortafuegos no existe, asegúrate de que no haya ninguna automatización externa que lo elimine al crearse.

Tráfico no añadido ni eliminado del clúster

Cuando se añade una nueva pertenencia, el tráfico debe llegar a los back-ends del clúster subyacente, si procede. Del mismo modo, si se elimina un Membership, no debería llegar tráfico a los back-ends del clúster subyacente. Si no observas este comportamiento, comprueba si hay errores en los recursos MultiClusterIngress y MultiClusterService.

Este error se produce en casos habituales, como cuando se añade un nuevo Membership a un clúster de GKE que no está en modo nativo de VPC o cuando se añade un nuevo Membership, pero no se implementa una aplicación en el clúster de GKE.

  1. Describe el MultiClusterService:

    kubectl describe mcs zone-svc

  2. Describe el MultiClusterIngress:

    kubectl describe mci zone-mci

Configurar la migración de clústeres

Para obtener más información sobre los casos prácticos de la migración, consulta el artículo Concepto de diseño de clúster de configuración.

La migración de clústeres de configuración puede ser una operación disruptiva si no se gestiona correctamente. Sigue estas directrices al realizar una migración de clúster de configuración:

  1. Asegúrate de usar la anotación static-ip en tus recursos MultiClusterIngress. Si no lo haces, el tráfico se interrumpirá durante la migración. Las IPs efímeras se volverán a crear al migrar clústeres de configuración.
  2. Los recursos MultiClusterIngress y MultiClusterService deben desplegarse de forma idéntica en el clúster de configuración antiguo y en el nuevo. Las diferencias entre ellos darán lugar a la conciliación de los recursos MultiClusterService y MultiClusterIngress que sean diferentes en el nuevo clúster de configuración.
  3. Solo puede haber un clúster de configuración activo a la vez. Hasta que se cambie el clúster de configuración, los recursos MultiClusterIngress y MultiClusterService del nuevo clúster de configuración no afectarán a los recursos del balanceador de carga.

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

Para comprobar que el comando ha funcionado, asegúrate de que no haya errores visibles en el estado de la función:

  gcloud container fleet ingress describe

Depuración de la consola

En la mayoría de los casos, comprobar el estado exacto del balanceador de carga es útil para depurar un problema. Para encontrar el balanceador de carga, ve a Balanceo de carga en la Google Cloud consola.

Códigos de error o advertencia

Multi Cluster Ingress emite códigos de error y de advertencia en los recursos MultiClusterIngress y MultiClusterService, así como en el campo multiclusteringress Description de gcloud para los problemas conocidos. Estos mensajes tienen códigos de error y de advertencia documentados para que sea más fácil entender qué significa cuando algo no funciona como debería. Cada código consta de un ID de error con el formato AVMBR123, donde 123 es un número único que corresponde a un error o una advertencia, y sugerencias sobre cómo solucionarlo.

AVMBR101: Annotation [NAME] not recognized

Este error se muestra cuando se especifica una anotación en un manifiesto MultiClusterIngress o MultiClusterService que no se reconoce. Hay un par de motivos por los que es posible que no se reconozca la anotación:

  1. La anotación no se admite en Multi Cluster Ingress. Esto puede ocurrir si se anotan recursos que no se espera que utilice el controlador de Ingress de GKE Enterprise.

  2. La anotación se admite, pero tiene un error ortográfico y, por lo tanto, no se reconoce.

En ambos casos, consulta la documentación para saber qué anotaciones se admiten y cómo se especifican.

AVMBR102: [RESOURCE_NAME] not found

Este error se muestra cuando se especifica un recurso complementario en un elemento MultiClusterIngress, pero no se encuentra en la pertenencia a la configuración. Por ejemplo, este error se produce cuando un MultiClusterIngress hace referencia a un MultiClusterService que no se encuentra o cuando un MultiClusterService hace referencia a un BackendConfig que no se encuentra. Hay varios motivos por los que no se ha podido encontrar un recurso:

  1. No está en el espacio de nombres adecuado. Asegúrate de que todos los recursos que se referencian 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éala.

AVMBR103: [CLUSTER_SELECTOR] is invalid

Este error se muestra cuando un selector de clúster especificado en un MultiClusterService no es válido. Este selector puede no ser válido por varios motivos:

  1. La cadena proporcionada contiene un error tipográfico.
  2. La cadena proporcionada hace referencia a una pertenencia a un clúster que ya no existe en la flota.

AVMBR104: Cannot find NEGs for Service Port [SERVICE_PORT]

Este error se produce cuando no se encuentran los grupos de puntos finales de red (NEGs) de un par de MultiClusterService y puerto de servicio determinado. Los NEGs son los recursos que contienen los endpoints de los pods de cada uno de tus clústeres de backend. El motivo principal por el que es posible que no existan los NEGs es que se haya producido un error al crear o actualizar los servicios derivados en los clústeres de backend. Consulta los eventos de tu recurso MultiClusterService para obtener más información.

AVMBR105: Missing GKE Enterprise license.

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

AVMBR106: Derived service is invalid: [REASON].

Este error se muestra en los eventos del recurso MultiClusterService. Una de las razones más habituales de este error es que el recurso Service derivado de MultiClusterService tiene una especificación no válida.

Por ejemplo, este MultiClusterService no tiene ningún ServicePort definido 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 la función y se produce porque no hay ningún clúster de GKE subyacente al recurso Membership. Para comprobarlo, ejecuta el siguiente comando:

gcloud container fleet memberships describe membership-name

y asegúrate de que no haya ningún enlace de recurso de clúster de GKE en el campo del endpoint.

AVMBR108: GKE cluster [NAME] not found.

Este error se muestra en Estado de la función y se produce si no existe el clúster de GKE subyacente de la pertenencia.

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

Este error se muestra en Estado de la función. Este error se produce si el clúster de GKE especificado es un clúster basado en rutas. El controlador de entrada multi-clúster crea un balanceador de carga nativo de contenedores mediante NEGs. Los clústeres deben ser nativos de VPC para usar un balanceador de carga nativo de contenedores.

Para obtener más información, consulta el artículo Crear un clúster nativo de VPC.

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

Este error se muestra en Estado de la función. Este error puede deberse a varios motivos:

  1. El clúster de GKE subyacente de la suscripción se encuentra en un proyecto diferente al de la propia suscripción.
  2. Se ha quitado el permiso de gestión de identidades y accesos especificado del agente de servicio MultiClusterIngress.

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

Este error se muestra en Estado de la función. El motivo principal por el que se produce este error es que se ha eliminado la pertenencia a la configuración mientras la función estaba habilitada.

Nunca deberías tener que eliminar la pertenencia a la configuración. Si quieres cambiarlo, sigue los pasos para migrar el clúster de configuración.

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

Este error se muestra en Estado de la función y se produce cuando el complemento HTTPLoadBalancing está inhabilitado en un clúster de GKE. Puedes actualizar tu 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 no se hace referencia a él en otro recurso. Por ejemplo, verás este error si creas un recurso BackendConfig al que no hace referencia un MultiClusterService.