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.

Recursos de Google Cloud administrados por MCS

El 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.

  • Traffic Director: MCS usa Traffic Director 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. De lo contrario, las llamadas a servicios externos no podrán cruzar el límite de red.

  • Si bien una flota puede abarcar varios proyectos de Google Cloud 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 se debe inhabilitar.

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 Traffic Director. No se requiere que las licencias de GKE Enterprise usen MCS.

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. Habilita las API de MCS, flota (concentrador), Resource Manager, Traffic Director 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.

Si bien MCS requiere el registro en una flota, no es necesario que habilites la plataforma de GKE Enterprise.

GKE Enterprise

Si la API de GKE Enterprise está habilitada en tu proyecto host de la flota como requisito para usar otros componentes de GKE Enterprise, cualquier clúster registrado en la flota del proyecto se cobrará según los precios de GKE Enterprise. Este modelo de precios te permite usar todas las funciones de GKE Enterprise en clústeres registrados por un solo cargo por CPU virtual. Puedes usar el siguiente comando para confirmar si la API de GKE Enterprise está habilitada:

gcloud services list --project=PROJECT_ID | grep anthos.googleapis.com

Si el resultado es similar al siguiente, la plataforma completa de GKE Enterprise está habilitada y cualquier clúster registrado en la flota generará cargos de GKE Enterprise:

anthos.googleapis.com                        Anthos API

Si esto no es lo esperado, comunícate con el administrador de tu proyecto.

Un resultado vacío indica que GKE Enterprise no está habilitado.

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.

  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 cuenta de servicio de Google Cloud 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 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 "serviceAccount:PROJECT_ID.svc.id.goog[gke-mcs/gke-mcs-importer]" \
    --role "roles/compute.networkViewer"

    Reemplaza PROJECT_ID por el ID 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 Traffic Director, por lo que, como parte de la habilitación de MCS, debes otorgar permiso a tu cuenta de servicio para leer información desde Traffic Director.

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: external-svc-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: external-svc-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 mediante el panel de Traffic Director 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. Anula el registro de tus clústeres en la flota si no es necesario que estén registrados para otro propósito.

  3. Inhabilita la función multiclusterservicediscovery:

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

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

  4. 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

Los siguientes límites no se aplican y, en algunos casos, puedes exceder estos límites según la carga de tus clústeres o proyecto y la tasa de deserción del extremo. Sin embargo, podrías experimentar problemas de rendimiento cuando se exceden estos límites.

  • 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. Esta es la misma limitación que tienen los Services de clúster único. 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 Services 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 50 puertos de Service únicos, identificados por el nombre de espacio de nombres de un Service y puertos declarados. Por ejemplo, exportar un Service que expone los puertos 80 y 443 contaría como 2 en el límite de 50 puertos de Service únicos. Los Services con el mismo nombre de espacio de nombres exportado desde varios clústeres cuentan como un solo Service único. El Service de 2 puertos antes mencionado se contaría solo como 2 puertos si se exportaron desde 5 clústeres a la vez. Cada Service de varios clústeres cuenta con tu cuota de Service de backend, y cada clúster o zona de exportación crea un grupo de extremos de red (NEG).

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

  • Uso de agentes 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.

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 featureState

Ver el estado de la función puede ayudarte a confirmar si MCS se configuró correctamente. Puedes ver el estado de la función de MCS mediante 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: {}

Los campos más útiles para solucionar problemas son code y description.

Códigos en featureState

Un código indica el estado general del miembro en relación con MCS. Puedes encontrar estos campos en el campo state.code. Existen tres códigos 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 featureState

Una descripción te brinda más información sobre el estado de la membresía en MCS. Puedes encontrar estas descripciones en el campo state.description y puedes ver las siguientes descripciones:

  • 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 Ejemplo de configuración de intercambio de tráfico entre redes de VPC.

  • 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.

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.

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.

Este comportamiento se corregirá en una próxima versión de MCS.

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.

Este comportamiento se corregirá en una próxima versión de MCS.

¿Qué sigue?