Configura Service de varios clústeres

En esta página, se muestra cómo habilitar y usar los Service de varios clústeres (MCS). Para obtener más información sobre cómo funciona MCS y sus beneficios, consulta Service de varios clústeres.

La función MCS de Google Kubernetes Engine (GKE) extiende el alcance del Service de Kubernetes más allá del límite del clúster y te permite descubrir y, además, invocar Service en varios clústeres de GKE. Puedes exportar un subconjunto de Service existentes o nuevos.

Cuando exportas un Service con MCS, ese Service 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 la VPC compartida en varios proyectos, consulta Configura servicios de varios clústeres con una VPC compartida.

Recursos deGoogle Cloud administrados por MCS

MCS administra los siguientes componentes de Google Cloud:

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

  • Reglas de firewall: MCS configura reglas de firewall 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 borran según los clústeres que agregues a tu flota. Estas reglas son similares a las reglas que GKE crea para permitir la comunicación entre los Pods en un clúster de GKE.

  • Cloud Service Mesh: MCS usa Cloud Service Mesh como un plano de control para realizar un seguimiento de los extremos y su estado en los clústeres.

Requisitos

MCS tiene los siguientes requisitos:

  • MCS solo admite la exportación de servicios desde clústeres de GKE nativos de la VPC en Google Cloud. Para obtener más información, consulta Crea un clúster nativo de la VPC. No puedes usar clústeres de GKE Standard no nativos de la VPC.

  • La conectividad entre clústeres depende de los clústeres que se ejecutan dentro de la misma red de VPC, en redes de VPC con intercambio de tráfico o en redes de VPC compartida. Si los clústeres se encuentran en redes separadas y no conectadas, se bloquearán las llamadas a servicios externos. Te recomendamos que habilites MCS en proyectos en los que los clústeres se encuentren en la misma red de VPC.

    Para configurar MCS en una flota entre proyectos con una VPC compartida, consulta Configura servicios de varios clústeres con una VPC compartida.

  • Si bien una flota puede abarcar varios Google Cloud proyectos y redes de VPC, un solo servicio de varios clústeres debe exportarse desde un solo proyecto y una sola red de VPC.

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

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

Precios

Los servicios de varios clústeres se incluyen como parte de la tarifa de administración de clústeres de GKE y no tienen costo adicional por su uso. Debes habilitar la API de Traffic Director, pero MCS no genera cargos de extremo de Cloud Service Mesh.

Antes de comenzar

Antes de comenzar, 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 el intercambio de tráfico entre redes de VPC, Cloud Interconnect o Cloud VPN.

  4. Habilita las APIs de MCS, flota (concentrador), 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

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

Habilita MCS en tu proyecto

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

Habilita MCS en tu clúster de GKE

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

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

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

    La habilitación de los servicios de varios clústeres en el proyecto host de la flota crea o garantiza 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 que registres tu clúster con la federación de identidades para cargas de trabajo para GKE habilitada. Si no habilitas la federación de identidades para cargas 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 en Autentica cuentas de servicio.

    A fin de registrar tu clúster con la federación de identidades para cargas de trabajo 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

    Reemplaza lo siguiente:

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

  3. Otorga los permisos necesarios de Identity and Access Management (IAM) para el importador de MCS:

    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"

    Reemplaza lo siguiente:

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

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

    kubectl create ns NAMESPACE

    Reemplaza NAMESPACE por un nombre para el espacio de nombres.

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

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

    El resultado es similar a este:

    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.

Autentica cuentas de servicio

Si registraste tus clústeres de GKE en una flota mediante una cuenta de servicio, debes realizar pasos adicionales para autenticar la cuenta de servicio. MCS implementa un componente llamado gke-mcs-importer. Este componente recibe actualizaciones de extremo de Cloud Service Mesh, por lo que, como parte de la habilitación de MCS, debes otorgar permiso a tu cuenta de servicio para leer información desde Cloud Service Mesh.

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

Usa MCS

En las siguientes secciones, se muestra cómo usar MCS. MCS usa la API de Kubernetes de varios clústeres.

Registra un Service para exportar

Si deseas registrar un servicio para exportar a otros clústeres dentro de tu flota, completa los siguientes 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

    Reemplaza lo siguiente:

    • NAMESPACE: es el espacio de nombres del objeto ServiceExport. Este espacio de nombres debe coincidir con el espacio de nombres del Service que exportarás.
    • SERVICE_EXPORT_NAME: Es el nombre de un Service en tu clúster que deseas exportar a otros clústeres dentro de tu flota.

  2. Crea el recurso ServiceExport mediante el siguiente comando:

    kubectl apply -f export.yaml

La exportación inicial de tu servicio tarda alrededor de cinco minutos en sincronizarse con los clústeres registrados en tu flota. Después de la exportación de un servicio, las sincronizaciones de extremos posteriores ocurren de inmediato.

Puedes exportar el mismo Service desde varios clústeres para crear un extremo de servicio de varios clústeres con alta disponibilidad con distribución de tráfico entre clústeres. Antes de exportar los Service que tienen el mismo nombre y espacio de nombres, asegúrate de que quieras que se agrupen de esta manera. Recomendamos no exportar servicios en los espacios de nombres default y kube-system debido a la alta probabilidad de que haya conflictos de nombres no deseados y se genere una agrupación no deseada. 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 puede limitarse a cinco servicios exportados.

Consume Service entre clústeres

MCS admite ClusterSetIP y servicios sin interfaz gráfica. Solo están disponibles los registros “A” del DNS.

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

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

El resultado incluye los siguientes valores:

  • SERVICE_EXPORT_NAME y NAMESPACE: Los valores que defines en el objeto ServiceExport.

Para los servicios de ClusterSetIP, el dominio se resuelve en ClusterSetIP. Puedes encontrar este valor si ubicas el objeto ServiceImport en un clúster en el espacio de nombres en el que se creó el objeto ServiceExport. El objeto ServiceImport se crea de forma automática.

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 a un clúster. Si investigas este objeto, puedes supervisar el progreso de una importación del servicio. Para encontrar el nombre del objeto Endpoints, busca el valor de la anotación net.gke.io/derived-service en un objeto ServiceImport correspondiente a tu 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 verificar si MCS ya propagó los extremos al clúster de importación. El objeto Endpoints se crea en el mismo espacio de nombres que el objeto ServiceImport, debajo del nombre almacenado en la anotación net.gke.io/derived-service. Por ejemplo:

kubectl get endpoints DERIVED_SERVICE_NAME -n NAMESPACE

Reemplaza lo siguiente:

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

Puedes obtener más información sobre el estado de los extremos con el panel de Cloud Service Mesh en la consola de Google Cloud .

En el caso de los Service sin interfaz gráfica, el dominio se resuelve en la lista de direcciones IP de los extremos de los clústeres de exportación. Cada Pod de backend con un nombre de host también es accesible de manera independiente con un nombre de dominio con el siguiente formato:

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

El resultado incluye los siguientes valores:

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

También puedes abordar un Pod de backend con un nombre de host exportado desde un clúster registrado con una membresía global, mediante el uso de un nombre de dominio con el siguiente formato:

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

Inhabilita MCS

Para inhabilitar MCS, completa los siguientes pasos:

  1. Para cada clúster en tu flota, borra cada objeto ServiceExport que creaste:

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    Reemplaza lo siguiente:

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

  2. Verifica que ServiceExport desaparezca de la lista en 30 minutos.

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

  4. Inhabilita la función multiclusterservicediscovery:

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

    Reemplaza PROJECT_ID con el ID del proyecto en el que registraste los clústeres.

  5. Inhabilita la API para MCS:

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

    Reemplaza PROJECT_ID con el ID del proyecto en el que registraste los clústeres.

Limitaciones

Cantidad de clústeres, Pods y puertos de Service

Los siguientes límites no se aplican y, en algunos casos, puedes excederlos según la carga de tus clústeres o proyecto, y la tasa de deserción del extremo. Es posible que experimentes problemas de rendimiento cuando se excedan estos límites.

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

  • Exportación de clústeres: Un Service único, identificado por un nombre de espacio de nombres, se puede exportar de forma segura desde hasta 5 clústeres de forma simultánea. Más allá de ese límite, es posible que solo se pueda importar un subconjunto de extremos a clústeres de consumo. Puedes exportar diferentes servicios desde diferentes subconjuntos de clústeres.

  • Cantidad de pods detrás de un solo Service: es seguro si mantienes menos de 250 pods detrás de un solo servicio. Con cargas de trabajo relativamente estáticas y una pequeña cantidad de servicios de varios clústeres, podría ser posible exceder de manera significativa esta cantidad a miles de extremos por servicio. Al igual que con los servicios de clúster único, kube-proxy vigila todos los extremos en cada nodo. Si sobrepasas este límite, en especial cuando se exportan desde varios clústeres a la vez, es posible que se necesiten nodos más grandes.

  • La cantidad de Service de varios clústeres exportados simultáneamente: Te recomendamos exportar de forma simultánea no más de 250 puertos de Service únicos.

    Un puerto de Service único se identifica por 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 lo siguiente:

    • Los Services con el mismo nombre de espacio de nombres y puerto, exportados desde varios clústeres, cuentan como un solo puerto de Service único.

    • Dos Services con el mismo nombre y puerto, pero diferentes espacios de nombres, por ejemplo, (nombre, ns1, puerto-80) y (nombre, ns2, puerto-80) son dos puertos de Service diferentes, que cuentan como dos del límite de 250 puertos de Service únicos.

    • Un Service exportado que expone dos puertos, el 80 y el 443, cuenta como dos en el límite de 250 puertos de Service únicos, independientemente de la cantidad de clústeres de la flota que exporten este Service de forma simultánea.

    Cada Service de varios clústeres cuenta para tu cuota de servicios de backend, y cada zona de cada clúster de exportación crea un grupo de extremos de red (NEG). Aumentar estas cuotas no cambia el límite establecido para el recuento total de puertos de servicio únicos.

Tipos de Service

MCS admite ClusterSetIP y servicios sin interfaz gráfica. Los objetos Service NodePort y LoadBalancer no son compatibles y pueden provocar un comportamiento inesperado.

Usa el agente de IPmasq con MCS

MCS funciona como se espera cuando usas un rango de IP de Pod predeterminado o de otro tipo sin enmascarar.

Si usas un rango de IP de Pod personalizado o un ConfigMap de agente de IPmasq personalizado, el tráfico de MCS se puede enmascarar. Esto evita que MCS funcione porque las reglas de firewall solo permiten tráfico de las IP de Pod.

Para evitar este problema, debes usar el rango de IP predeterminado del Pod o especificar todos los rangos de IP del Pod en el campo nonMasqueradeCIDRs del ConfigMap del agente de IPmasq. Si usas Autopilot o debes usar un rango de IP de Pod no predeterminado y no puedes especificar todos los rangos de IP de Pod en el ConfigMap, debes usar la política de NAT de salida para configurar el enmascaramiento de IP.

Vuelve a usar números de puerto dentro de un servicio de MCS

No puedes volver a usar el mismo número de puerto dentro de un servicio de MCS, incluso si los protocolos son diferentes.

Esto se aplica tanto dentro de un servicio de Kubernetes como en todos los servicios de Kubernetes para un servicio de MCS.

MCS con clústeres en varios proyectos

No puedes exportar un servicio si otros clústeres ya lo exportan en un proyecto diferente en 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.

Soluciona problemas

En las siguientes secciones, encontrarás sugerencias para la solución de problemas de MCS.

Cómo ver el estado de la función de MCS

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

gcloud container fleet multi-cluster-services describe

El resultado es similar a este:

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 membresías individuales en membershipStates.

Si habilitaste la función de MCS según la instrucción de Habilita MCS en tu clúster de GKE, pero el valor de resourceState.state no es ACTIVE, comunícate con el equipo de asistencia.

El estado de cada membresía consta de su ruta y el campo state. Este último contiene code y description, que son útiles para solucionar problemas.

Códigos en los estados de membresía

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

  • OK: la membresía se agregó correctamente a MCS y está lista para usarse.

  • WARNING: MCS está en el proceso de conciliación de la configuración de la membresía. El campo de descripción puede proporcionar más información sobre qué causó que se muestre este código.

  • FAILED: esta membresía no se agregó a MCS. Las demás membresías de la flota con un código OK no se ven afectadas por esta membresía de FAILED. El campo de descripción puede proporcionar más información sobre qué causó que se muestre este código.

  • ERROR: Faltan recursos en esta membresía. Las demás membresías de la flota con un código OK no se ven afectadas por esta membresía de ERROR. El campo de descripción puede proporcionar más información sobre qué causó que se muestre este código.

Descripciones en los estados de membresía

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, y el estado de la flota y de las membresías. Para ver información sobre los servicios individuales y su configuración, consulta el campo Status.Conditions en el objeto ServiceExport. Consulta la sección Cómo examinar ServiceExport.

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

  • Firewall successfully created: este mensaje indica que la regla de firewall del miembro se creó y actualizó correctamente. El código de la membresía es OK.

  • Firewall creation pending: Este mensaje indica que la regla de firewall del miembro está pendiente de creación o actualización. El código de la membresía es WARNING. Esta membresía puede experimentar problemas cuando se actualiza y se conecta a los servicios y clústeres nuevos que se agregaron mientras la regla de firewall está pendiente.

  • GKE Cluster missing: Este mensaje indica que el clúster de GKE registrado no está disponible o se borró. El código de la membresía es ERROR. A esta membresía se le debe cancelar el registro de la flota de forma manual después de que se borra 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 de Estado Prohibido (403) y el código de la membresía es FAILED. Este error ocurre en los siguientes casos:

    • No habilitaste las API necesarias en el proyecto del miembro.

      Si el clúster miembro se encuentra en un proyecto aparte de la flota, consulta la configuración para varios proyectos a fin de asegurarte de que completaste todos los pasos necesarios. Si completaste todos los pasos, asegúrate de que las siguientes API 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

      Reemplaza PROJECT_ID con el ID del proyecto en el que registraste 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 deberían haberse creado de forma automática en el proyecto host de la flota con todos los permisos necesarios. Para verificar que las cuentas de servicio existan, 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

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

    Estos comandos deberían mostrarte 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 ocurre cuando los clústeres alojados en diferentes VPC se registran en la misma flota. El estado de membresía 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 VPC deben intercambiar de forma activa para que los servicios de varios clústeres se conecten de manera correcta entre sí. Para obtener más información, consulta Establece la vinculación entre 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 de varios proyectos requieren pasos de configuración adicionales. El estado de membresía es OK. Las membresías 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 ajenos a GKE no se pueden agregar a MCS. El estado de la membresía es FAILED.

Examen de ServiceExport

Para ver el estado de un servicio individual y los posibles errores, verifica el campo Status.Conditions en el recurso ServiceExport de ese servicio:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

El resultado es similar a este:

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, agrega las siguientes condiciones al campo Status.Conditions:

  • Initialized: Es verdadero si el controlador de MCS recogió y trató de conciliar el servicio representado por ServiceExport.

  • Exported: Es verdadero si el servicio representado por ServiceExport se validó correctamente.

Cada condición contiene los campos obligatorios Type, Status y LastTransitionTime. A medida que el controlador de MCS reconcilia y valida el Service, 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 establece el campo Status de la condición Exported en False y agrega un campo Reason y un campo Message con más información sobre el error. El campo Reason puede tener uno de los siguientes valores:

  • NoMatchingService: No se encontró ningún servicio que coincida con el nombre y el espacio de nombres del ServiceExport en el clúster determinado.
    Verifica si el servicio de Kubernetes que deseas exportar existe en el mismo clúster. Verifica 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 que se exporta desde otra red o proyecto que no está permitido. Consulta Limitaciones.
    Inspecciona el campo Message para obtener los detalles y consulta la sección Limitaciones si es necesario. Asegúrate de que el nombre y el espacio de nombres de Service y ServiceExport coincidan entre sí y de que todos los recursos se creen en la misma red o proyecto.

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

    A continuación, se explica cómo se alinean los campos de la verificación de preparación con los parámetros de la verificación de 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; los valores que superen este límite activarán un error.
    • SuccessThreshold y FailureThreshold tienen un límite de 10 segundos; los valores que superen este límite activarán un error.
    • Se informa un error y falla la creación de recursos (posiblemente, 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 en la verificación de estado o preparación, etcétera. Ajusta los parámetros de readinessProbe según las validaciones anteriores. Es importante corregir estos errores en cada Service de la flota. Consulta Problemas conocidos para obtener más información.

  • ServiceError: Se produjo un error al recuperar el servicio correspondiente.
    Por lo general, este error se relaciona con un problema de infraestructura de Google Cloud. Si el problema persiste, comunícate con el equipo de asistencia de Google Cloud.

  • PodsError: Se produjo un error al recuperar el Pod o los Pods de backend
    . Este error suele estar relacionado con un problema de infraestructura de Google Cloud. Si el problema persiste, comunícate con el equipo de asistencia de Google Cloud.

  • EndpointsError: Se produjo un error al agregar Endpoints para un servicio sin encabezado
    . Por lo general, este error se relaciona con un problema de infraestructura de Google Cloud. Si el problema persiste, comunícate con el equipo de asistencia de Google Cloud.

El campo Message proporciona contexto adicional para el error.

Problemas comunes de permisos

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

    Asegúrate de haber habilitado las APIs necesarias según las instrucciones de la sección Antes de comenzar.

    Para una flota entre proyectos, sigue la sección Habilita las APIs requeridas correspondiente en Configura servicios de varios clústeres con una 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 otorgan automáticamente a las cuentas de servicio que GKE Hub y MCS crean automáticamente.

    En el caso de una flota entre proyectos, debes crear vinculaciones de IAM adicionales. Sigue la sección Crea vinculaciones de IAM correspondiente en Configura servicios de varios clústeres con una VPC compartida.

Problemas conocidos

Servicios MCS con varios puertos

Existe un problema conocido con Services de varios clústeres con múltiples puertos (TCP/UDP) en GKE Dataplane V2 en el que algunos extremos 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, usa varios MCS con un solo puerto en lugar de un MCS con varios puertos.

Se reutilizó el número de puerto dentro de un servicio de MCS

No puedes volver a usar el mismo número de puerto dentro de un servicio de MCS, incluso si los protocolos son diferentes.

Esto se aplica tanto dentro de un servicio de Kubernetes como en todos los servicios de Kubernetes para un servicio de MCS.

MCS con VPC compartida

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

La verificación de estado usa un puerto predeterminado en lugar de containerPort

Cuando implementas un Service con un campo targetPort que hace referencia a un puerto con nombre en un Deployment, MCS configura el puerto predeterminado para la verificación de estado en lugar del containerPort especificado.

Para evitar este problema, usa valores numéricos en el campo ports.targetPort del Service y el campo readinessProbe.httpGet.port del Deployment en lugar de valores con nombre.

Una prueba de disponibilidad no válida para un solo servicio interrumpe otros servicios

Hay un posible error de configuración de readinessProbe conocido que se describe en Cómo examinar ServiceExports. Con la implementación actual de MCS, este error, si se introduce para un solo Service exportado, puede impedir que se sincronicen algunos o todos los demás Services de la flota.

Es importante mantener en buen estado la configuración de cada servicio. Si no se actualiza un servicio de MCS, asegúrate de que ninguno de los ServiceExports en cualquiera de los clústeres de cualquiera de los espacios de nombres informe ReadinessProbeError como el motivo por el que la condición de estado Exported es falsa. Consulta Cómo examinar ServiceExports para obtener información sobre cómo verificar las condiciones.

¿Qué sigue?