Configurar servicios de varios clústeres

En esta página se explica cómo habilitar y usar los servicios multiclúster (MCS). Para obtener más información sobre cómo funciona MCS y sus ventajas, consulta Servicios multiclúster.

La función MCS de Google Kubernetes Engine (GKE) amplía el alcance del servicio de Kubernetes más allá del límite del clúster y te permite descubrir e invocar servicios en varios clústeres de GKE. Puede exportar un subconjunto de los servicios que ya tenga o de los nuevos.

Cuando exportas un servicio con MCS, ese servicio está disponible en todos los clústeres de tu flota.

En esta página se explica cómo configurar MCS con un solo proyecto. Para configurar una VPC compartida entre varios proyectos, sigue las instrucciones de Configurar servicios de varios clústeres con VPC compartida.

Google Cloud Recursos gestionados por MCS

MCS gestiona los siguientes componentes de Google Cloud:

  • Cloud DNS: MCS configura las zonas y los registros de Cloud DNS de cada servicio exportado en tus clústeres de flota. Esto te permite conectarte a servicios que se ejecutan en otros clústeres. Estas zonas y registros se crean, leen, actualizan y eliminan en función de los servicios que elijas exportar entre clústeres.

  • Reglas de cortafuegos: MCS configura reglas de cortafuegos que permiten que los pods se comuniquen entre sí en los clústeres de tu flota. Las reglas de firewall se crean, leen, actualizan y eliminan en función de los clústeres que añadas a tu flota. Estas reglas son similares a las que crea GKE para habilitar la comunicación entre pods de un clúster de GKE.

  • Cloud Service Mesh: MCS usa Cloud Service Mesh como plano de control para monitorizar los endpoints y su estado en los clústeres.

Requisitos

MCS tiene los siguientes requisitos:

  • MCS solo admite la exportación de servicios de clústeres de GKE nativos de VPC en Google Cloud. Para obtener más información, consulta el artículo Crear un clúster nativo de VPC. No puedes usar clústeres estándar de GKE que no sean nativos de VPC.

  • La conectividad entre clústeres depende de si los clústeres se ejecutan en la misma red de VPC o en redes de VPC emparejadas o compartidas. Si los clústeres están en redes independientes que no están conectadas, se bloquearán las llamadas a servicios externos. Te recomendamos que habilites MCS en proyectos en los que los clústeres estén en la misma red de VPC.

    Para configurar MCS en una flota entre proyectos con una VPC compartida, sigue las instrucciones de Configurar servicios de varios clústeres con VPC compartida.

  • Aunque una flota puede abarcar varios proyectos y redes de VPC, un servicio de varios clústeres debe exportarse desde un único proyecto y una única red de VPC. Google Cloud

  • MCS no es compatible con las políticas de red.

  • Los clústeres deben tener habilitado el complemento HttpLoadBalancing. Asegúrate de que el complemento HttpLoadBalancing esté habilitado. El complemento HttpLoadBalancing está habilitado de forma predeterminada y no debe inhabilitarse.

Precios

Los servicios multi-clúster se incluyen en la tarifa de gestión de clústeres de GKE y no tienen ningún coste adicional por uso. Debes habilitar la API Traffic Director, pero MCS no incurre en ningún cargo por los endpoints de Cloud Service Mesh.

Antes de empezar

Antes de empezar, asegúrate de haber realizado las siguientes tareas:

  1. Instala el SDK de Google Cloud.

  2. Habilita la API de Google Kubernetes Engine:

    Habilitar la API de Google Kubernetes Engine

  3. Conecta tus redes de VPC con VPC Network Peering, Cloud Interconnect o Cloud VPN.

  4. Habilita las APIs MCS, de flota (hub), Resource Manager, Cloud Service Mesh y Cloud DNS:

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    --project=PROJECT_ID

    Sustituye PROJECT_ID por el ID del proyecto en el que quieras registrar tus clústeres en una flota.

Habilitar MCS en tu proyecto

MCS requiere que los clústeres de GKE participantes estén registrados en la misma flota. Una vez que la función MCS está habilitada en una flota, cualquier clúster puede exportar servicios entre clústeres de la flota.

Habilitar MCS en un clúster de GKE

  1. Habilita la función MCS para la flota de tu proyecto:

    gcloud container fleet multi-cluster-services enable \
    --project PROJECT_ID

    Sustituye PROJECT_ID por el ID del proyecto en el que quieras registrar tus clústeres en una flota. Este es tu proyecto host de la flota.

    Al habilitar los servicios multiclúster en el proyecto host de la flota, se crea o se asegura que exista la cuenta de servicio service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com.

  2. Registra tus clústeres de GKE en la flota. Te recomendamos encarecidamente que registres tu clúster con Workload Identity Federation for GKE habilitado. Si no habilitas la federación de identidades de carga de trabajo para GKE, debes registrar el clúster con una Google Cloud cuenta de servicio para la autenticación y completar los pasos adicionales que se indican en Autenticar cuentas de servicio.

    Para registrar tu clúster con Workload Identity Federation para GKE, ejecuta el siguiente comando:

    gcloud container fleet memberships register MEMBERSHIP_NAME \
   --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
   --enable-workload-identity \
   --project PROJECT_ID

    Haz los cambios siguientes:

    • MEMBERSHIP_NAME: el nombre del grupo de miembros que elijas para representar de forma única el clúster en la flota. Por lo general, el nombre de pertenencia a la flota de un clúster es el nombre del clúster, pero es posible que tengas que especificar un nombre nuevo si ya existe otro clúster con el nombre original en la flota.
    • CLUSTER_LOCATION: la zona o la región en la que se encuentra el clúster.
    • CLUSTER_NAME: el nombre del clúster.

  3. Concede los permisos de gestión de identidades y accesos (IAM) necesarios para MCS Importer:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-mcs/sa/gke-mcs-importer" \
    --role "roles/compute.networkViewer"

    Haz los cambios siguientes:

    • PROJECT_ID: el ID del proyecto del host de la flota.
    • PROJECT_NUMBER: el número de proyecto del proyecto host de la flota.

  4. Asegúrate de que cada clúster de la flota tenga un espacio de nombres para compartir servicios. Si es necesario, crea un espacio de nombres con el siguiente comando:

    kubectl create ns NAMESPACE

    Sustituye NAMESPACE por el nombre del espacio de nombres.

  5. Para verificar que MCS esté habilitado, ejecuta el siguiente comando:

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

    El resultado debería ser similar al siguiente:

    createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
  projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
    state:
      code: OK
      description: Firewall successfully updated
      updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}

    Si el valor de state no es ACTIVE, consulta la sección Solución de problemas.

Autenticar cuentas de servicio

Si has registrado tus clústeres de GKE en una flota mediante una cuenta de servicio, debes seguir pasos adicionales para autenticar la cuenta de servicio. MCS implementa un componente llamado gke-mcs-importer. Este componente recibe actualizaciones de endpoints de Cloud Service Mesh, por lo que, para habilitar MCS, debes conceder permiso a tu cuenta de servicio para leer información de Cloud Service Mesh.

Si usas una cuenta de servicio, puedes usar la cuenta de servicio predeterminada de Compute Engine o tu propia cuenta de servicio de nodo:

Usar MCS

En las siguientes secciones se explica cómo usar MCS. MCS usa la API de servicios multiclúster de Kubernetes.

Registrar un servicio para exportarlo

Para registrar un servicio para exportarlo a otros clústeres de tu flota, sigue estos pasos:

  1. Crea un objeto ServiceExport llamado export.yaml:

    # export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: NAMESPACE
 name: SERVICE_EXPORT_NAME

    Haz los cambios siguientes:

    • NAMESPACE: el espacio de nombres del objeto ServiceExport. Este espacio de nombres debe coincidir con el espacio de nombres del servicio que vas a exportar.
    • SERVICE_EXPORT_NAME: el nombre de un servicio de tu clúster que quieras exportar a otros clústeres de tu flota.

  2. Para crear el recurso ServiceExport, ejecuta el siguiente comando:

    kubectl apply -f export.yaml

La exportación inicial de tu servicio tarda aproximadamente cinco minutos en sincronizarse con los clústeres registrados en tu flota. Una vez que se exporta un servicio, las sincronizaciones de endpoints posteriores se producen inmediatamente.

Puedes exportar el mismo servicio desde varios clústeres para crear un único endpoint de servicio multiclúster de alta disponibilidad con distribución del tráfico entre clústeres. Antes de exportar servicios que tengan el mismo nombre y espacio de nombres, asegúrate de que quieres que se agrupen de esta forma. No recomendamos exportar servicios en los espacios de nombres default y kube-system debido a la alta probabilidad de que se produzcan conflictos de nombres no deseados y la agrupación no deseada resultante. Si exportas más de cinco servicios con el mismo nombre y espacio de nombres, la distribución del tráfico en los servicios importados podría limitarse a cinco servicios exportados.

Consumir servicios entre clústeres

MCS solo admite ClusterSetIP y servicios sin interfaz. Solo están disponibles los registros "A" de DNS.

Después de crear un objeto ServiceExport, el siguiente nombre de dominio se resuelve en el servicio exportado desde cualquier pod de cualquier clúster de flota:

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

La salida incluye los siguientes valores:

  • SERVICE_EXPORT_NAME y NAMESPACE: los valores que definas en tu objeto ServiceExport.

En el caso de los servicios ClusterSetIP, el dominio se resuelve en ClusterSetIP. Para encontrar este valor, busca el objeto ServiceImport en un clúster del espacio de nombres en el que se creó el objeto ServiceExport. El objeto ServiceImport se crea automáticamente.

Por ejemplo:

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

MCS crea un objeto Endpoints como parte de la importación de un Service en un clúster. Al investigar este objeto, puedes monitorizar el progreso de una importación de servicios. Para encontrar el nombre del objeto Endpoints, busca el valor de la anotación net.gke.io/derived-service en un objeto ServiceImport correspondiente al servicio importado. Por ejemplo:

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET

A continuación, busca el objeto Endpoints para comprobar si MCS ya ha propagado los endpoints al clúster de importación. El objeto Endpoints se crea en el mismo espacio de nombres que el objeto ServiceImport, con el nombre almacenado en la anotación net.gke.io/derived-service. Por ejemplo:

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

Haz los cambios siguientes:

  • DERIVED_SERVICE_NAME: el valor de la anotación net.gke.io/derived-service en el objeto ServiceImport.
  • NAMESPACE: el espacio de nombres del objeto ServiceExport.

Puedes consultar el estado de los endpoints en el panel de control de Cloud Service Mesh en la Google Cloud consola.

En el caso de los servicios sin interfaz gráfica, el dominio se resuelve en la lista de direcciones IP de los endpoints de los clústeres de exportación. Cada pod de backend con un nombre de host también se puede direccionar de forma independiente con un nombre de dominio con el siguiente formato:

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

La salida incluye los siguientes valores:

  • SERVICE_EXPORT_NAME y NAMESPACE: los valores que definas en tu objeto ServiceExport.
  • MEMBERSHIP_NAME: el identificador único de la flota del clúster en el que se encuentra el pod.
  • LOCATION: la ubicación de la membresía. Las membresías son de global o su ubicación es una de las regiones o zonas en las que se encuentra el pod, como us-central1.
  • HOSTNAME: el nombre de host del pod.

También puedes dirigirte a un pod de backend con un nombre de host exportado desde un clúster registrado en una pertenencia global mediante un nombre de dominio con el siguiente formato:

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

Inhabilitar MCS

Para inhabilitar MCS, sigue estos pasos:

  1. En cada clúster de tu flota, elimina cada objeto ServiceExport que hayas creado:

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    Haz los cambios siguientes:

    • SERVICE_EXPORT_NAME: el nombre de tu objeto ServiceExport.
    • NAMESPACE: el espacio de nombres del objeto ServiceExport.

  2. Comprueba que el ServiceExport desaparece de la lista en 30 minutos.

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

  4. Para inhabilitar la función multiclusterservicediscovery, sigue estos pasos:

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    Sustituye PROJECT_ID por el ID del proyecto en el que has registrado los clústeres.

  5. Inhabilita la API de MCS:

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    Sustituye PROJECT_ID por el ID del proyecto en el que has registrado los clústeres.

Limitaciones

Número de clústeres, pods y puertos de servicio

Los siguientes límites no se aplican y, en algunos casos, puedes superarlos en función de la carga de tus clústeres o proyectos, y de la tasa de rotación de los endpoints. Es posible que tengas problemas de rendimiento cuando se superen estos límites.

En Kubernetes, un servicio se identifica de forma única por su nombre y el espacio de nombres al que pertenece. Este nombre y el par de espacios de nombres se denominan nombre con espacio de nombres.

  • Exportación de clústeres: un solo servicio, identificado por un nombre con espacio de nombres, se puede exportar de forma segura desde un máximo de 5 clústeres simultáneamente. Si se supera ese límite, es posible que solo se pueda importar un subconjunto de endpoints a los clústeres consumidores. Puedes exportar diferentes servicios de distintos subconjuntos de clústeres.

  • Número de pods detrás de un solo servicio: es seguro si no supera los 250 pods detrás de un solo servicio. Si las cargas de trabajo son relativamente estáticas y el número de servicios de varios clústeres es pequeño, es posible que se supere este número considerablemente y se alcancen miles de endpoints por servicio. Al igual que con los servicios de un solo clúster, kube-proxy monitoriza todos los endpoints de cada nodo. Si supera este límite, sobre todo al exportar datos de varios clústeres simultáneamente, es posible que necesite nodos más grandes.

  • Número de servicios multiclúster exportados simultáneamente: le recomendamos que no exporte simultáneamente más de 250 puertos de servicio únicos.

    Un puerto de servicio único se identifica mediante un nombre con espacio de nombres y un número de puerto, es decir, una tupla (nombre, espacio de nombres, número de puerto). Esto significa que:

    • Los servicios con el mismo nombre y puerto de espacio de nombres, exportados desde varios clústeres, se consideran un único puerto de servicio.

    • Dos servicios con el mismo nombre y puerto, pero con espacios de nombres diferentes, por ejemplo, (nombre, ns1, puerto-80) y (nombre, ns2, puerto-80), son dos puertos de servicio diferentes, por lo que se contabilizan como dos de los 250 puertos de servicio únicos.

    • Un servicio exportado que exponga los puertos 80 y 443 cuenta como dos de los 250 puertos de servicio únicos, independientemente del número de clústeres de la flota que exporten este servicio simultáneamente.

    Cada servicio multiclúster se tiene en cuenta para la cuota de servicios de backend y cada zona de cada clúster de exportación crea un grupo de puntos finales de red (NEG). Aumentar estas cuotas no cambia el límite indicado para el recuento total de puertos de servicio únicos.

Tipos de servicio

MCS solo admite ClusterSetIP y servicios sin encabezado. No se admiten los servicios NodePort y LoadBalancer, y pueden provocar un comportamiento inesperado.

Usar el agente IPmasq con MCS

MCS funciona correctamente cuando se usa un intervalo de IPs de Pod predeterminado u otro que no esté enmascarado.

Si usas un intervalo de IPs de pods personalizado o un ConfigMap de agente IPmasq personalizado, se puede enmascarar el tráfico de MCS. Esto impide que MCS funcione porque las reglas de cortafuegos solo permiten el tráfico de IPs de pods.

Para evitar este problema, debes usar el intervalo de IPs de pods predeterminado o especificar todos los intervalos de IPs de pods en el campo nonMasqueradeCIDRs del ConfigMap del agente IPmasq. Si usas Autopilot o debes usar un intervalo de IPs de pods que no sea el predeterminado y no puedes especificar todos los intervalos de IPs de pods en el ConfigMap, debes usar la política de NAT de salida para configurar el enmascaramiento de IPs.

Reutilizar números de puerto en un servicio MCS

No puedes reutilizar el mismo número de puerto en un servicio MCS, aunque los protocolos sean diferentes.

Esto se aplica tanto a un servicio de Kubernetes como a todos los servicios de Kubernetes de un servicio de MCS.

MCS con clústeres en varios proyectos

No puedes exportar un servicio si ya lo están exportando otros clústeres de un proyecto diferente de la flota con el mismo nombre y espacio de nombres. Puedes acceder al servicio en otros clústeres de la flota en otros proyectos, pero esos clústeres no pueden exportar el mismo servicio en el mismo espacio de nombres.

Solución de problemas

En las siguientes secciones se ofrecen consejos para solucionar problemas con MCS.

Ver el estado de la función MCS

Ver el estado del recurso Feature puede ayudarte a confirmar si MCS se ha configurado correctamente. Puedes ver el estado con el siguiente comando:

gcloud container fleet multi-cluster-services describe

El resultado debería ser similar al siguiente:

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

Incluye, entre otra información, el estado general de la función en resourceState y el estado de las suscripciones individuales en membershipStates.

Si has habilitado la función MCS siguiendo las instrucciones de Habilitar MCS en tu clúster de GKE, pero el valor de resourceState.state no es ACTIVE, ponte en contacto con el equipo de Asistencia.

El estado de cada suscripción consta de su ruta y del campo state. Este último contiene code y description, que son útiles para solucionar problemas.

Códigos de los estados de la suscripción

Un código, representado por el campo state.code, indica el estado general del miembro en relación con MCS. Hay cuatro valores posibles:

  • OK: la membresía se ha añadido correctamente a MCS y ya se puede usar.

  • WARNING: MCS está conciliando la configuración de la suscripción. El campo de descripción puede proporcionar más información sobre la causa de este código.

  • FAILED: esta suscripción no se ha añadido a MCS. Esta suscripción a FAILED no afecta a otras suscripciones de la flota con un código OK. El campo de descripción puede proporcionar más información sobre la causa de este código.

  • ERROR: a esta membresía le faltan recursos. Esta suscripción a ERROR no afecta a otras suscripciones de la flota con un código OK. El campo de descripción puede proporcionar más información sobre la causa de este código.

Descripciones de los estados de la suscripción

Para ver información sobre el estado de la membresía en MCS, consulta el campo state.description. Este campo proporciona información sobre la configuración del proyecto y del centro, así como sobre el estado de la flota y de las suscripciones. Para ver información sobre los servicios individuales y su configuración, consulta el campo Status.Conditions del objeto ServiceExport. Para obtener más información, consulta la sección Analizar ServiceExport.

El campo state.description contiene la siguiente información:

  • Firewall successfully created: Este mensaje indica que la regla de cortafuegos del miembro se ha creado o actualizado correctamente. El código de la suscripción es OK.

  • Firewall creation pending: este mensaje indica que la regla de cortafuegos del miembro está pendiente de creación o actualización. El código de la suscripción es WARNING. Esta pertenencia puede tener problemas para actualizarse y conectarse a los nuevos servicios y pertenencias multiclúster que se hayan añadido mientras la regla de cortafuegos esté pendiente.

  • GKE Cluster missing: este mensaje indica que el clúster de GKE registrado no está disponible o se ha eliminado. El código de la suscripción es ERROR. Esta pertenencia debe anularse manualmente de la flota después de eliminar un clúster de GKE.

  • Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required: este mensaje indica que hay errores internos StatusForbidden (403) y que el código de la suscripción es FAILED. Este error se produce en los siguientes casos:

    • No has habilitado las APIs necesarias en el proyecto del miembro.

      Si el clúster miembro se encuentra en un proyecto distinto al de la flota, consulta la configuración entre proyectos para asegurarte de que has completado todos los pasos necesarios. Si has completado todos los pasos, asegúrate de que las siguientes APIs estén habilitadas en el proyecto de registro con los siguientes comandos:

      gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
gcloud services enable dns.googleapis.com --project PROJECT_ID
gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID

      Sustituye PROJECT_ID por el ID del proyecto en el que has registrado los clústeres.

    • La cuenta de servicio mcsd o gkehub requiere más permisos en el proyecto del miembro.

      Las cuentas de servicio mcsd y gkehub se deberían haber creado automáticamente en el proyecto host de la flota con todos los permisos necesarios. Para verificar que las cuentas de servicio existen, ejecuta los siguientes comandos:

      gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub

      Sustituye PROJECT_ID por el ID del proyecto host de la flota.

    Estos comandos deberían mostrar el nombre completo de las cuentas de servicio mcsd y gkehub.

  • Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity: este mensaje se produce cuando los clústeres alojados en diferentes VPCs se registran en la misma flota. El estado de la suscripción es OK. La red de VPC de un clúster se define mediante su red de NetworkConfig. Los servicios de varios clústeres requieren una red plana, y estas VPCs deben estar emparejadas activamente para que los servicios de varios clústeres se conecten correctamente entre sí. Para obtener más información, consulta el artículo sobre emparejar dos redes.

  • Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: este mensaje te recuerda que los clústeres entre proyectos requieren pasos de configuración adicionales. El estado de la suscripción es OK. Las pertenencias entre proyectos se definen como un clúster miembro que no está en el mismo proyecto que la flota. Para obtener más información, consulta la configuración entre proyectos.

  • Non-GKE clusters are currently not supported: Este mensaje te recuerda que MCS solo admite clústeres de GKE. Los clústeres que no sean de GKE no se pueden añadir a MCS. El estado de la suscripción es FAILED.

Examinando ServiceExport

Para ver el estado de un servicio concreto y los posibles errores, consulta el campo Status.Conditions del recurso ServiceExport de ese servicio:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

El resultado debería ser similar al siguiente:

Name:         SERVICE_NAME
Namespace:    NAMESPACE
Labels:       <none>
Annotations:  <none>
API Version:  net.gke.io/v1
Kind:         ServiceExport
Metadata:
  Creation Timestamp:  2024-09-06T15:57:40Z
  Finalizers:
    serviceexport.net.gke.io
  Generation:        2
  Resource Version:  856599
  UID:               8ac44d88-4c08-4b3d-8524-976efc455e4e
Status:
  Conditions:
    Last Transition Time:  2024-09-06T16:01:53Z
    Status:                True
    Type:                  Initialized
    Last Transition Time:  2024-09-06T16:02:48Z
    Status:                True
    Type:                  Exported
Events:                    <none>

Cuando el controlador de MCS detecta un recurso ServiceExport, añade las siguientes condiciones al campo Status.Conditions:

  • Initialized: true si el controlador de MCS ha recogido e intentado reconciliar el servicio representado por ServiceExport.

  • Exported: true si el servicio representado por ServiceExport se ha validado correctamente.

Cada condición contiene los campos obligatorios Type, Status y LastTransitionTime. A medida que el controlador de MCS reconcilia y valida el servicio, el campo Status de la condición correspondiente cambia de False a True.

Errores

Si se produce un error en la validación, el controlador asigna el valor False al campo Status de la condición Exported y añade los campos Reason y Message con más información sobre el error. El campo Reason puede tener uno de los siguientes valores:

  • NoMatchingService: no se ha encontrado ningún servicio que coincida con el nombre y el espacio de nombres de ServiceExport en el clúster indicado.
    Comprueba si el servicio de Kubernetes que quieres exportar está en el mismo clúster. Comprueba si el nombre y el espacio de nombres de ambos recursos (Service y ServiceExport) coinciden exactamente.

  • Conflict: Ya existe un servicio exportado con el mismo nombre y espacio de nombres que no coincide con el que exporta este ServiceExport o se ha exportado desde otra red u otro proyecto, lo que no está permitido. Consulta las limitaciones.
    Consulta los detalles en el campo Message y, si es necesario, consulta la sección Limitaciones. Asegúrate de que el nombre y el espacio de nombres de Service y ServiceExport coincidan y de que todos los recursos se creen en la misma red o proyecto.

  • ReadinessProbeError: Hay un readinessProbe configurado en un contenedor de un pod que respalda el servicio. Kubernetes ReadinessProbes se traducen a Google cloud HealthChecks y deben cumplir las mismas restricciones.

    A continuación, se explica cómo se alinean los campos de comprobación de la disponibilidad con los parámetros de comprobación del estado:

    • PeriodSeconds corresponde a CheckInterval
    • TimeoutSeconds corresponde a Timeout
    • SuccessThreshold corresponde a HealthyThreshold
    • FailureThreshold corresponde a UnhealthyThreshold

    Para alinear ReadinessProbes con las restricciones de HealthCheck, MCS implementa lo siguiente:

    • PeriodSeconds y TimeoutSeconds tienen un límite de 300 segundos. Si se supera este límite, se produce un error.
    • SuccessThreshold y FailureThreshold tienen un límite de 10 segundos. Si se supera este límite, se produce un error.
    • Se informa de un error y se produce un fallo en la creación de recursos (posiblemente de todos los recursos) si TimeoutSeconds es mayor que PeriodSeconds.

    El motivo de estas restricciones es evitar problemas de escalabilidad, superposición de sondeos posteriores, lentitud de las comprobaciones de estado o de disponibilidad, etc. Ajusta los parámetros de readinessProbe según las validaciones anteriores. Es importante corregir estos errores en todos los servicios de la flota. Consulta la sección Problemas conocidos para obtener más información.

  • ServiceError: se ha producido un error al obtener el servicio correspondiente.
    Este error suele estar relacionado con un problema de la infraestructura de Google Cloud. Si el problema persiste, ponte en contacto con el equipo de Asistencia de Google Cloud.

  • PodsError: se ha producido un error al obtener el pod o los pods de backend
    Este error suele estar relacionado con un problema de la infraestructura de Google Cloud. Si el problema persiste, ponte en contacto con el equipo de Asistencia de Google Cloud.

  • EndpointsError: se ha producido un error al agregar Endpoints para un servicio sin encabezado
    Este error suele estar relacionado con un problema de la infraestructura de Google Cloud. Si el problema persiste, ponte en contacto con el equipo de Asistencia de Google Cloud.

El campo Message proporciona contexto adicional sobre el error.

Problemas habituales con los permisos

  • Las APIs necesarias no están habilitadas en el proyecto.

    Asegúrate de haber habilitado las APIs necesarias tal como se indica en la sección Antes de empezar.

    Para una flota entre proyectos, sigue la sección Habilitar las APIs necesarias correspondiente en Configurar servicios de varios clústeres con VPC compartida.

  • La cuenta de servicio mcsd o gkehub no tiene permisos suficientes

    En una configuración de un solo proyecto, todos los permisos necesarios se conceden automáticamente a las cuentas de servicio que crean automáticamente GKE Hub y MCS.

    En el caso de una flota entre proyectos, debes crear enlaces de gestión de identidades y accesos adicionales. Sigue la sección Crear enlaces de gestión de identidades y accesos que corresponda en el artículo Configurar servicios de varios clústeres con VPC compartida.

Problemas conocidos

Servicios MCS con varios puertos

Hay un problema conocido con los servicios de varios clústeres con varios puertos (TCP/UDP) en GKE Dataplane V2, en el que algunos endpoints no se programan en el plano de datos. Este problema afecta a las versiones de GKE anteriores a la 1.26.3-gke.400.

Como solución alternativa, cuando uses GKE Dataplane V2, utiliza varios MCS con un solo puerto en lugar de un MCS con varios puertos.

Número de puerto reutilizado en un servicio MCS

No puedes reutilizar el mismo número de puerto en un MCS Service aunque los protocolos sean diferentes.

Esto se aplica tanto a un servicio de Kubernetes como a todos los servicios de Kubernetes de un servicio de MCS.

MCS con VPC compartida

Con la implementación actual de MCS, si despliega más de una flota en la misma VPC compartida, los metadatos se comparten entre las flotas. Cuando se crea un servicio en una flota, los metadatos del servicio se exportan o importan en todas las demás flotas que forman parte de la misma VPC compartida y que son visibles para el usuario.

La comprobación del estado usa el puerto predeterminado en lugar de containerPort

Cuando despliegas un servicio con un campo targetPort que hace referencia a un puerto con nombre en un despliegue, MCS configura el puerto predeterminado para la comprobación del estado en lugar del containerPort especificado.

Para evitar este problema, usa valores numéricos en los campos Servicio ports.targetPort y Despliegue readinessProbe.httpGet.port en lugar de valores con nombre.

Una sonda de preparación no válida para un solo servicio interrumpe otros servicios

Hay un posible readinessProbeerror de configuración conocido que se describe en el artículo Examinar ServiceExports. Con la implementación actual de MCS, si se produce este error en un solo servicio exportado, puede impedir que se sincronicen algunos o todos los demás servicios de la flota.

Es importante que las configuraciones de todos los servicios estén en buen estado. Si un servicio de MCS no se actualiza, asegúrate de que ninguno de los ServiceExports de ninguno de los clústeres de ninguno de los espacios de nombres indique ReadinessProbeError como motivo de que la condición de estado Exported sea False. Consulta Analizar ServiceExports para saber cómo comprobar las condiciones.

Siguientes pasos