entrada multi-clúster

Autopilot Standard

---

Multi Cluster Ingress es un controlador alojado en la nube para clústeres de Google Kubernetes Engine (GKE). Es un servicio alojado en Google que admite el despliegue de recursos de balanceo de carga compartidos en varios clústeres y regiones. Para desplegar Ingress de varios clústeres en varios clústeres, completa la sección Configurar Ingress de varios clústeres y, a continuación, consulta Desplegar Ingress en varios clústeres.

Para ver una comparación detallada entre Multi Cluster Ingress (MCI), Multi-cluster Gateway (MCG) y el balanceador de carga con grupos de endpoints de red independientes (LB y Standalone NEGs), consulta Elegir la API de balanceo de carga multiclúster para GKE.

Redes de varios clústeres

Hay muchos factores que influyen en las topologías multiclúster, como la proximidad de los usuarios a las aplicaciones, la alta disponibilidad de los clústeres y las regiones, la seguridad y la separación organizativa, la migración de clústeres y la localidad de los datos. Estos casos prácticos rara vez se dan de forma aislada. A medida que aumentan los motivos para usar varios clústeres, se hace más urgente la necesidad de una plataforma multiclúster formal y productizada.

Multi Cluster Ingress se ha diseñado para satisfacer las necesidades de balanceo de carga de entornos multiclúster y multirregión. Es un controlador del balanceador de carga HTTP(S) externo que proporciona un objeto Ingress para el tráfico procedente de Internet en uno o varios clústeres.

La compatibilidad con varios clústeres de Multi Cluster Ingress se ajusta a muchos casos prácticos, entre los que se incluyen los siguientes:

• Una única IP virtual (VIP) coherente para una aplicación, independientemente de dónde se implemente en todo el mundo.
• Disponibilidad multirregional y multiclúster mediante comprobaciones de estado y conmutación por error del tráfico.
• Enrutamiento basado en la proximidad a través de IPs virtuales Anycast públicas para reducir la latencia de los clientes.
• Migración de clústeres transparente para actualizaciones o recompilaciones de clústeres.

Cuotas predeterminadas

Ingress de varios clústeres tiene las siguientes cuotas predeterminadas:

• Para obtener información sobre los límites de miembros de las flotas, consulta las cuotas de gestión de flotas. para saber cuántos miembros se admiten en una flota.
• 100 recursos MultiClusterIngress y 100 recursos MultiClusterService por proyecto. Puede crear hasta 100 recursos MultiClusterIngress y 100 MultiClusterService en un clúster de configuración para cualquier número de clústeres backend, hasta el máximo por proyecto.

Precios y pruebas

Para obtener información sobre los precios de Ingress de varios clústeres, consulta Precios de Ingress de varios clústeres.

Cómo funciona Multi Cluster Ingress

La entrada multi-clúster se basa en la arquitectura del balanceador de carga de aplicación externo global. El balanceador de carga de aplicación externo global es un balanceador de carga distribuido a nivel mundial con proxies desplegados en más de 100 puntos de presencia (PoPs) de Google en todo el mundo. Estos proxies, llamados Google Front Ends (GFEs), se encuentran en el perímetro de la red de Google, cerca de los clientes. Ingress de varios clústeres crea balanceadores de carga de aplicación externos en el nivel Premium. Estos balanceadores de carga usan direcciones IP externas globales anunciadas mediante anycast. Las solicitudes se atienden mediante GFEs y el clúster más cercano al cliente. El tráfico de Internet se dirige al PoP de Google más cercano y usa la red troncal de Google para llegar a un clúster de GKE. Esta configuración de balanceo de carga da como resultado una latencia más baja del cliente a GFE. También puedes reducir la latencia entre los clústeres de GKE y los GFE si ejecutas los clústeres de GKE en las regiones más cercanas a tus clientes.

Al finalizar las conexiones HTTP y HTTPS en el perímetro, el balanceador de carga de Google puede decidir a dónde dirigir el tráfico determinando la disponibilidad del backend antes de que el tráfico entre en un centro de datos o una región. De esta forma, el tráfico sigue la ruta más eficiente desde el cliente hasta el backend, teniendo en cuenta el estado y la capacidad de los backends.

Multi Cluster Ingress es un controlador Ingress que programa el balanceador de carga HTTP(S) externo mediante grupos de puntos finales de red (NEGs). Cuando creas un recurso MultiClusterIngress, GKE implementa recursos de balanceador de carga de Compute Engine y configura los pods adecuados en los clústeres como back-ends. Los NEGs se usan para monitorizar los endpoints de los pods de forma dinámica, de modo que el balanceador de carga de Google tenga el conjunto adecuado de backends en buen estado.

Cuando despliega aplicaciones en clústeres de GKE, Multi Cluster Ingress se asegura de que el balanceador de carga esté sincronizado con los eventos que se producen en el clúster:

• Se crea un Deployment con las etiquetas coincidentes adecuadas.
• El proceso de un pod falla y no supera la comprobación del estado.
• Se quita un clúster del grupo de back-ends.

Multi Cluster Ingress actualiza el balanceador de carga para que sea coherente con el entorno y el estado deseado de los recursos de Kubernetes.

Arquitectura de Ingress de varios clústeres

Multi Cluster Ingress usa un servidor de API de Kubernetes centralizado para desplegar Ingress en varios clústeres. Este servidor de APIs centralizado se llama clúster de configuración. Cualquier clúster de GKE puede actuar como clúster de configuración. El clúster de configuración usa dos tipos de recursos personalizados: MultiClusterIngress y MultiClusterService. Al desplegar estos recursos en el clúster de configuración, el controlador de entrada de varios clústeres despliega balanceadores de carga en varios clústeres.

Los siguientes conceptos y componentes forman Multi Cluster Ingress:

• Controlador de Ingress de varios clústeres: se trata de un plano de control distribuido a nivel mundial que se ejecuta como un servicio fuera de tus clústeres. De esta forma, el ciclo de vida y las operaciones del controlador son independientes de los clústeres de GKE.

• Clúster de configuración: es un clúster de GKE elegido que se ejecuta enGoogle Cloud , donde se despliegan los recursos MultiClusterIngress y MultiClusterService. Se trata de un punto de control centralizado para estos recursos multiclúster. Estos recursos multiclúster se encuentran en una sola API lógica y se puede acceder a ellos desde ella para mantener la coherencia en todos los clústeres. El controlador Ingress monitoriza el clúster de configuración y reconcilia la infraestructura de balanceo de carga.

• Una flota te permite agrupar y normalizar lógicamente los clústeres de GKE, lo que facilita la administración de la infraestructura y permite usar funciones multiclúster, como la entrada multiclúster. Puede consultar más información sobre las ventajas de las flotas y cómo crearlas en la documentación sobre gestión de flotas. Un clúster solo puede ser miembro de una flota.

• Clúster miembro: los clústeres registrados en una flota se denominan clústeres miembros. Los clústeres miembros de la flota abarcan todo el ámbito de los backends que conoce Ingress de varios clústeres. La vista de gestión de clústeres de Google Kubernetes Engine proporciona una consola segura para ver el estado de todos los clústeres registrados.

Flujo de trabajo de implementación

En los pasos siguientes se muestra un flujo de trabajo general para usar Multi Cluster Ingress en varios clústeres.

1. Registra los clústeres de GKE en una flota del proyecto que elijas.

2. Configura un clúster de GKE como clúster de configuración central. Este clúster puede ser un plano de control dedicado o puede ejecutar otras cargas de trabajo.

3. Despliega aplicaciones en los clústeres de GKE donde deban ejecutarse.

4. Implementa uno o varios recursos MultiClusterService en el clúster de configuración con etiquetas y coincidencias de clústeres para seleccionar los clústeres, el espacio de nombres y los pods que se consideren back-ends de un servicio determinado. De esta forma, se crean NEGs en Compute Engine, que empieza a registrar y gestionar los endpoints de servicio.

5. Despliega un recurso MultiClusterIngress en el clúster de configuración que haga referencia a uno o varios recursos MultiClusterService como back-ends del balanceador de carga. De esta forma, se implementan los recursos del balanceador de carga externo de Compute Engine y se exponen los endpoints de los clústeres a través de una única IP virtual del balanceador de carga.

Conceptos de Ingress

Multi Cluster Ingress usa un servidor de API de Kubernetes centralizado para desplegar Ingress en varios clústeres. En las siguientes secciones se describe el modelo de recursos de Multi Cluster Ingress, cómo implementar Ingress y los conceptos importantes para gestionar este plano de control de red de alta disponibilidad.

Recursos de MultiClusterService

Un MultiClusterService es un recurso personalizado que usa Multi Cluster Ingress para representar servicios compartidos entre clústeres. Un MultiClusterService recurso selecciona Pods, de forma similar al recurso Service, pero un MultiClusterService también puede seleccionar etiquetas y clústeres. El conjunto de clústeres entre los que selecciona un MultiClusterService se denomina clústeres miembros. Todos los clústeres registrados en la flota son clústeres miembros.

Un MultiClusterService solo existe en el clúster de configuración y no enruta nada como lo hacen los servicios ClusterIP, LoadBalancer o NodePort. En su lugar, permite que el controlador de entrada de varios clústeres haga referencia a un recurso distribuido único.

El siguiente manifiesto de ejemplo describe un MultiClusterService para una aplicación llamada foo:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80

Este manifiesto implementa un servicio en todos los clústeres miembros con el selector app: foo. Si hay pods app: foo en ese clúster, sus direcciones IP se añaden como backends del MultiClusterIngress.

El siguiente mci-zone1-svc-j726y6p1lilewtu7 es un servicio derivado generado en uno de los clústeres de destino. Este servicio crea un NEG que monitoriza los endpoints de Pod de todos los pods que coincidan con el selector de etiquetas especificado en este clúster. Se creará un servicio y un NEG derivados en cada clúster de destino por cada MultiClusterService (a menos que se usen selectores de clústeres). Si no hay ningún pod que coincida en un clúster de destino, el servicio y el NEG estarán vacíos. Los servicios derivados los gestiona por completo MultiClusterService y los usuarios no pueden gestionarlos directamente.

apiVersion: v1
kind: Service
metadata:
  annotations:
    cloud.google.com/neg: '{"exposed_ports":{"8080":{}}}'
    cloud.google.com/neg-status: '{"network_endpoint_groups":{"8080":"k8s1-a6b112b6-default-mci-zone1-svc-j726y6p1lilewt-808-e86163b5"},"zones":["us-central1-a"]}'
    networking.gke.io/multiclusterservice-parent: '{"Namespace":"default","Name":"zone1"}'
  name: mci-zone1-svc-j726y6p1lilewtu7
  namespace: blue
spec:
  selector:
    app: foo
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Algunas notas sobre el Servicio derivado:

• Su función es agrupar lógicamente los endpoints como back-ends de Ingress de varios clústeres.
• Gestiona el ciclo de vida del NEG de un clúster y una aplicación determinados.
• Se crea como un servicio sin interfaz gráfica. Ten en cuenta que solo los campos Selector y Ports se transfieren del MultiClusterService al servicio derivado.
• El controlador Ingress gestiona su ciclo de vida.

Recurso MultiClusterIngress

Un recurso MultiClusterIngress se comporta de forma idéntica en muchos aspectos al recurso Ingress principal. Ambos tienen la misma especificación para definir hosts, rutas, terminación de protocolos y back-ends.

El siguiente manifiesto describe un MultiClusterIngress que dirige el tráfico a los back-ends foo y bar en función de los encabezados de host HTTP:

apiVersion: networking.gke.io/v1
kind: MultiClusterIngress
metadata:
  name: foobar-ingress
  namespace: blue
spec:
  template:
    spec:
      backend:
        serviceName: default-backend
        servicePort: 80
      rules:
      - host: foo.example.com
        backend:
          serviceName: foo
          servicePort: 80
      - host: bar.example.com
        backend:
          serviceName: bar
          servicePort: 80

Este recurso MultiClusterIngress hace coincidir el tráfico con la dirección IP virtual de foo.example.com y bar.example.com enviando este tráfico a los recursos MultiClusterService llamados foo y bar. Este MultiClusterIngress tiene un backend predeterminado que coincide con todo el tráfico restante y lo envía al backend predeterminado MultiClusterService.

En el siguiente diagrama se muestra cómo fluye el tráfico de un Ingress a un clúster:

En el diagrama, hay dos clústeres: gke-us y gke-eu. El tráfico fluye de foo.example.com a los pods que tienen la etiqueta app:foo en ambos clústeres. Desde bar.example.com, el tráfico se dirige a los pods que tienen la etiqueta app:bar en ambos clústeres.

Recursos Ingress en clústeres

El clúster de configuración es el único que puede tener recursos MultiClusterIngress y MultiClusterService. Cada clúster de destino que tenga pods que coincidan con los selectores de etiquetas MultiClusterService también tendrá un servicio derivado correspondiente programado en ellos. Si un clúster no está seleccionado explícitamente por un MultiClusterService, no se creará un servicio derivado correspondiente en ese clúster.

Igualdad de espacios de nombres

La igualdad de espacios de nombres es una propiedad de los clústeres de Kubernetes en la que un espacio de nombres se extiende a varios clústeres y se considera el mismo espacio de nombres.

En el siguiente diagrama, el espacio de nombres blue existe en los clústeres de GKE gke-cfg, gke-eu y gke-us. La igualdad de espacios de nombres considera que el espacio de nombres blue es el mismo en todos los clústeres. Esto significa que un usuario tiene los mismos privilegios para los recursos del espacio de nombres blue en todos los clústeres. La igualdad de espacios de nombres también significa que los recursos de servicio con el mismo nombre en varios clústeres del espacio de nombres blue se consideran el mismo servicio.

La puerta de enlace trata el servicio como un único grupo de endpoints en los tres clústeres. Como los recursos de Routes y MultiClusterIngress solo pueden enrutar a servicios del mismo espacio de nombres, esto proporciona una multitenencia coherente para la configuración en todos los clústeres de la flota. Las flotas ofrecen un alto grado de portabilidad, ya que los recursos se pueden desplegar o mover entre clústeres sin que se modifique su configuración. La implementación en el mismo espacio de nombres de la flota proporciona coherencia entre los clústeres.

Ten en cuenta los siguientes principios de diseño para la igualdad de espacios de nombres:

• Los espacios de nombres con fines diferentes no deben tener el mismo nombre en los clústeres.
• Los espacios de nombres deben reservarse de forma explícita, asignando un espacio de nombres, o de forma implícita, mediante políticas fuera de banda, para los equipos y los clústeres de una flota.
• Los espacios de nombres que tengan el mismo propósito en diferentes clústeres deben tener el mismo nombre.
• Los permisos de usuario para los espacios de nombres de los clústeres deben controlarse estrictamente para evitar accesos no autorizados.
• No debe usar el espacio de nombres predeterminado ni espacios de nombres genéricos, como "prod" o "dev", para la implementación normal de aplicaciones. Es demasiado fácil que los usuarios implementen recursos en el espacio de nombres predeterminado por error e infrinjan los principios de segmentación de los espacios de nombres.
• El mismo espacio de nombres debe crearse en todos los clústeres en los que un equipo o un grupo de usuarios determinado deba implementar recursos.

Diseño de clúster de configuración

El clúster de configuración de MultiCluster Ingress es un único clúster de GKE que aloja los recursos MultiClusterIngress y MultiClusterService, y actúa como punto de control único de Ingress en toda la flota de clústeres de GKE de destino. El clúster de configuración se elige al habilitar Ingress con varios clústeres. Puedes elegir cualquier clúster de GKE como clúster de configuración y cambiarlo en cualquier momento.

Configurar la disponibilidad del clúster

Como el clúster de configuración es un único punto de control, los recursos de Multi Cluster Ingress no se pueden crear ni actualizar si la API del clúster de configuración no está disponible. Los balanceadores de carga y el tráfico que sirven no se verán afectados por una interrupción del clúster de configuración, pero el controlador no reconciliará los cambios en los recursos MultiClusterIngress y MultiClusterService hasta que vuelva a estar disponible.

Ten en cuenta los siguientes principios de diseño para los clústeres de configuración:

• El clúster de configuración debe elegirse de forma que tenga una alta disponibilidad. Se recomienda usar clústeres regionales en lugar de clústeres zonales.
• Para habilitar Ingress de varios clústeres, el clúster de configuración no tiene por qué ser un clúster dedicado. El clúster de configuración puede alojar cargas de trabajo administrativas o incluso de aplicaciones, aunque debes asegurarte de que las aplicaciones alojadas no afecten a la disponibilidad del servidor de la API del clúster de configuración. El clúster de configuración puede ser un clúster de destino que aloje backends para recursos de MultiClusterService , aunque, si se necesitan precauciones adicionales, el clúster de configuración también se puede excluir como backend mediante la selección de clústeres.
• Los clústeres de configuración deben tener todos los espacios de nombres que utilicen los back-ends del clúster de destino. Un recurso MultiClusterService solo puede hacer referencia a pods del mismo espacio de nombres en los clústeres, por lo que ese espacio de nombres debe estar presente en el clúster de configuración.
• Los usuarios que desplieguen objetos Ingress en varios clústeres deben tener acceso al clúster de configuración para desplegar recursos MultiClusterIngress y MultiClusterService. Sin embargo, los usuarios solo deben tener acceso a los espacios de nombres que tengan permiso para usar.

Seleccionar y migrar el clúster de configuración

Debe elegir el clúster de configuración al habilitar Multi Cluster Ingress. Se puede seleccionar cualquier clúster miembro de una flota como clúster de configuración. Puedes actualizar el clúster de configuración en cualquier momento, pero debes asegurarte de que no cause interrupciones. El controlador Ingress reconciliará los recursos que haya en el clúster de configuración. Al migrar el clúster de configuración del actual al siguiente, los recursos MultiClusterIngress y MultiClusterService deben ser idénticos. Si los recursos no son idénticos, es posible que los balanceadores de carga de Compute Engine se actualicen o se destruyan después de actualizar el clúster de configuración.

En el siguiente diagrama se muestra cómo un sistema de CI/CD centralizado aplica recursos de MultiClusterIngress y MultiClusterService al servidor de la API de GKE para el clúster de configuración (gke-us) y un clúster de copia de seguridad (gke-eu) en todo momento, de modo que los recursos sean idénticos en los dos clústeres. Puedes cambiar el clúster de configuración en cualquier momento en caso de emergencia o de inactividad programada sin que esto afecte a nada, ya que los recursos MultiClusterIngress y MultiClusterService son idénticos.

Selección de clústeres

Los recursos de MultiClusterService pueden seleccionar entre clústeres. De forma predeterminada, el controlador programa un servicio derivado en cada clúster de destino. Si no quieres que se derive un servicio en todos los clústeres de destino, puedes definir una lista de clústeres mediante el campo spec.clusters del manifiesto MultiClusterService.

Puede definir una lista de clústeres si necesita:

• Aísla el clúster de configuración para evitar que los recursos de MultiClusterService seleccionen en el clúster de configuración.
• Controlar el tráfico entre clústeres para la migración de aplicaciones.
• Dirige el tráfico a los backends de aplicaciones que solo existen en un subconjunto de clústeres.
• Usa una sola dirección IP virtual HTTP(S) para enrutar a back-ends que se encuentren en diferentes clústeres.

Debes asegurarte de que los clústeres miembros de la misma flota y región tengan nombres únicos para evitar conflictos de nombres.

Para obtener información sobre cómo configurar la selección de clústeres, consulta Configurar Ingress con varios clústeres.

El siguiente manifiesto describe un MultiClusterService que tiene un campo clusters que hace referencia a europe-west1-c/gke-eu y asia-northeast1-a/gke-asia:

apiVersion: networking.gke.io/v1
kind: MultiClusterService
metadata:
  name: foo
  namespace: blue
spec:
  template:
    spec:
      selector:
        app: foo
      ports:
      - name: web
        protocol: TCP
        port: 80
        targetPort: 80
  clusters:
  - link: "europe-west1-c/gke-eu"
  - link: "asia-northeast1-a/gke-asia-1"

Este manifiesto especifica que los pods con las etiquetas coincidentes de los clústeres gke-asia y gke-eu se pueden incluir como backends de MultiClusterIngress. Se excluyen todos los demás clústeres, aunque tengan pods con la etiqueta app: foo.

En el siguiente diagrama se muestra un ejemplo de configuración de MultiClusterService con el manifiesto anterior:

En el diagrama, hay tres clústeres: gke-eu, gke-asia-1 y gke-asia-2. El clúster gke-asia-2 no se incluye como backend, aunque haya pods con etiquetas coincidentes, porque no está incluido en la lista del manifiesto spec.clusters. El clúster no recibe tráfico para mantenimiento u otras operaciones.

Siguientes pasos

• Consulta cómo configurar Ingress con varios clústeres.
• Consulta información sobre cómo desplegar pasarelas de varios clústeres.
• Consulta información sobre cómo desplegar Ingress de varios clústeres.
• Implementa entrada de varios clústeres para el balanceo de carga externo.