Entrada de varios clústeres

Ingress de varios clústeres (MCI) es un controlador de entrada de varios clústeres alojado en la nube para clústeres de GKE. Es un servicio alojado por Google que admite la implementación de recursos de balanceo de cargas compartidos en clústeres y regiones. Para implementar Ingress de varios clústeres en varios clústeres, completa la configuración de Ingress para varios clústeres y, luego, consulta Cómo implementar Ingress en varios clústeres.

Herramientas de redes de varios clústeres

Existen muchos factores que impulsan las topologías de varios clústeres, incluida la proximidad del usuario a las apps, la alta disponibilidad regional y de clúster, la separación de organización y seguridad, y la localidad de datos. Estos casos prácticos rara vez son aislados. A medida que aumentan los motivos de tener varios clústeres, se vuelve más urgente la necesidad de una plataforma de varios clústeres formal y desarrollada.

Ingress de varios clústeres está diseñado para satisfacer las necesidades de balanceo de cargas de entornos de varios clústeres y regiones. Es un controlador para el balanceador de cargas de HTTP(S) externo que proporciona entrada de tráfico que proviene de Internet en uno o más clústeres.

La compatibilidad de Ingress de varios clústeres satisface muchos casos de uso, incluidos los siguientes:

  • Una sola IP virtual (VIP) coherente de una app, sin importar dónde se implemente de manera global
  • La disponibilidad de varios clústeres y regiones a través de la conmutación por error del tráfico y la verificación de estado
  • Enrutamiento basado en la proximidad mediante VIP Anycast públicas para una latencia del cliente baja
  • Migración transparente de clústeres para actualizaciones o para volver a compilar clústeres

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 Ingress de varios clústeres

Ingress de varios clústeres se basa en la arquitectura del balanceo de cargas HTTP(S) externo. El balanceo de cargas de HTTP(S) es un balanceador de cargas distribuido de forma global con proxies implementados en más de 100 puntos de presencia (PoP) de Google en todo el mundo. Estos proxies, llamados Google Front End (GFE), se encuentran en el perímetro de la red de Google, cerca de los clientes. Ingress de varios clústeres crea balanceadores de cargas de HTTP(S) externos en el nivel Premium. Estos balanceadores de cargas usan direcciones IP externas globales que se anuncian mediante anycast. Los GFE entregan y el clúster más cercano al cliente entregan las solicitudes. 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 cargas da como resultado una latencia más baja desde el cliente hasta el GFE. También puedes reducir la latencia entre la entrega de clústeres de GKE y los GFE; para ello, ejecuta los clústeres de GKE en las regiones más cercanas a los clientes.

Finalizar las conexiones HTTP y HTTPS en el extremo permite que el balanceador de cargas de Google decida dónde enrutar el tráfico mediante la determinación de la disponibilidad del backend antes de que el tráfico entre en un centro de datos o una región. Esto le da al tráfico la ruta más eficiente desde el cliente hasta el backend mientras considera el estado y la capacidad de los backends.

Ingress de varios clústeres es un controlador de Ingress que programa el balanceador de cargas HTTP(S) externo mediante grupos de extremo de red (NEG). Cuando creas un recurso MultiClusterIngress, GKE implementa los recursos del balanceador de cargas de Compute Engine y configura los Pods adecuados en los clústeres como backends. Los NEG se usan para hacer un seguimiento dinámico de los extremos del pod, de modo que el balanceador de cargas de Google tenga el conjunto correcto de backends en buen estado.

Flujo de tráfico de Ingress de varios clústeres

A medida que implementas aplicaciones en los clústeres en GKE, Ingress de varios clústeres garantiza que el balanceador de cargas esté sincronizado con los eventos que ocurren en el clúster:

  • Se crea un Deployment con las etiquetas coincidentes adecuadas.
  • El proceso de un Pod se detiene y falla su verificación de estado.
  • Se quita un clúster del grupo de backends.

Ingress de varios clústeres actualiza el balanceador de cargas para que sea coherente con el entorno y el estado deseado de los recursos de Kubernetes.

Arquitectura de Ingress de varios clústeres

Ingress de varios clústeres usa un servidor de API centralizado de Kubernetes para implementar Ingress en varios clústeres. Este servidor de la API centralizado se denomina 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. Mediante la implementación de estos recursos en el clúster de configuración, el controlador de Ingress de varios clústeres implementa balanceadores de cargas en varios clústeres.

Los siguientes conceptos y componentes conforman Ingress de varios clústeres:

  • Controlador de Ingress de varios clústeres: Es un plano de control distribuido de forma global que se ejecuta como un servicio fuera de los clústeres. Esto permite que el ciclo de vida y las operaciones del controlador sean independientes de los clústeres de GKE.

  • Clúster de configuración: Es un clúster de GKE elegido que se ejecuta en Google Cloud en el que se implementan los recursos MultiClusterIngress y MultiClusterService. Este es un punto de control centralizado para estos recursos de varios clústeres. Estos recursos de varios clústeres existen en una sola API lógica y se pueden acceder desde ella a fin de mantener la coherencia en todos los clústeres. El controlador de Ingress detecta el clúster del archivo de configuración y concilia la infraestructura del balanceo de cargas.

  • Flota (antes environ): Una flota es un dominio que agrupa la infraestructura y los clústeres, administra recursos y mantiene una política coherente en ellos. Ingress de varios clústeres usa el concepto de flotas para saber cómo se aplica Ingress en diferentes clústeres. Los clústeres que registras en una flota se vuelven visibles para Ingress de varios clústeres, por lo que se pueden usar como backends para Ingress.

  • Clústeres miembros: los clústeres registrados en una flota se denominan clústeres miembros. Los clústeres miembros en la flota conforman el alcance completo de los backends que Ingress de varios clústeres conoce. La vista de administración de clústeres de Google Kubernetes Engine proporciona una consola segura para ver el estado de todos tus clústeres registrados.

Arquitectura de Ingress de varios clústeres

Flujo de trabajo de Deployment

En los siguientes pasos, se ilustra un flujo de trabajo de alto nivel para usar Ingress de varios clústeres en varios clústeres.

  1. Registra los clústeres de GKE como clústeres miembros.

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

  3. Implementa aplicaciones en los clústeres de GKE en los que deben ejecutarse.

  4. Implementa uno o más recursos MultiClusterService en el clúster de configuración con coincidencias de clústeres y etiquetas a fin de seleccionar clústeres, espacios de nombres y Pods que se consideren backends para un Service determinado. Esto crea NEG en Compute Engine, que comienza a registrar y administrar extremos de servicio.

  5. Implementa un recurso MultiClusterIngress en el clúster de configuración que haga referencia a uno o más recursos MultiClusterService como backends del balanceador de cargas. Esto implementa los recursos del balanceador de cargas externo de Compute Engine y expone los extremos en los clústeres a través de una sola VIP de balanceador de cargas.

Conceptos de Ingress

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

Recursos MultiClusterService

Un MultiClusterService (MCS) es un recurso personalizado que utiliza Ingress de varios clústeres y que es una representación lógica de un Service en varios clústeres. Un MCS es similar, pero bastante diferente, al tipo de Service principal. Un MCS solo existe en el clúster de configuración y genera objetos Service derivados en los clústeres de destino. Un MCS no enruta nada similar a lo que un Service ClusterIP, LoadBalancer o NodePort enruta. Solo permite que el MCI pueda hacer referencia a un recurso distribuido único. A continuación, se muestra un MCS simple para la aplicación 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

Al igual que un servicio, un MCS es un selector para Pods, pero también puede seleccionar etiquetas y clústeres. El grupo de clústeres que selecciona se denomina clústeres miembros, que son todos los clústeres registrados en la flota. Este MCS implementa un servicio derivado en todos los clústeres miembros con el selector app: foo. Si existen Pods app: foo en ese clúster, esas IP de Pod se agregarán como backends para el MCI.

El siguiente mci-zone1-svc-j726y6p1lilewtu7 es un Service derivado que el MCS generó en uno de los clústeres de destino. Este Service crea un NEG que realiza un seguimiento de los extremos del Pod para todos los pods que coinciden con el selector de etiquetas especificado en este clúster. Un Service derivado y un NEG existirán en cada clúster de destino para cada MCS (a menos que se usen selectores de clústeres). Si no hay Pods coincidentes en un clúster de destino, el Service y el NEG estarán vacíos. Los MCS administran en su totalidad los objetos Service derivados, los usuarios no los administran 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

Notas el Service derivado:

  • Su función es una agrupación lógica de extremos como backends de Ingress de varios clústeres.
  • Administra el ciclo de vida del NEG para un clúster y una aplicación determinados.
  • También se crea como un Service sin interfaz gráfica. Ten en cuenta que solo los campos Selector y Ports se transfieren de la especificación de MCS a la del Service derivado.
  • El controlador Ingress administra su ciclo de vida.

Recurso MultiClusterIngress

Un recurso MultiClusterIngress (MCI) se comporta de manera idéntica al recurso Ingress principal en varios aspectos. Ambos tienen la misma especificación para definir los hosts, las rutas, las finalizaciones de protocolos y los backends. Este es un ejemplo simple de un recurso MCI que enruta el tráfico a los backends de foo y bar, según 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

Ten en cuenta que este MCI hace coincidir el tráfico con la VIP en foo.example.com y bar.example.com mediante el envío de este tráfico a los recursos MultiClusterService (MCS) denominados foo y bar. Este MCI tiene un backend predeterminado que coincide con el resto del tráfico y lo envía al MCS del backend predeterminado.

Coincidencia del encabezado de host

Recursos de Ingress en los 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 MCS también tendrá un Service derivado correspondiente programado en ellos. Si un MCS no selecciona de manera explícita un clúster, no se crea un Service derivado correspondiente en ese clúster.

Un diagrama de un modelo de recursos de Ingress

Similitud de espacio de nombres

Los clústeres de GKE registrados se convierten en miembros de una flota.

Las flotas poseen una característica conocida como similitud de espacio de nombres, que supone que los recursos con los mismos nombres y el mismo espacio de nombres en los clústeres se consideren instancias del mismo recurso. En efecto, esto significa que los Pods en el espacio de nombres ns1 con las etiquetas app: foo en diferentes clústeres se consideran parte del mismo grupo de backends de aplicaciones desde la perspectiva de Ingress for Anthos.

Esto tiene consecuencias sobre cómo operan los diferentes equipos de desarrollo en un grupo de clústeres. Diferentes equipos aún pueden aprovechar la misma flota de clústeres mediante el uso de espacios de nombres para segmentar las cargas de trabajo incluso a través de los límites del clúster. Sin embargo, es importante que cada equipo reserve de forma explícita o implícita sus respectivos espacios de nombres en todos los clústeres de su flota.

En el siguiente ejemplo, un equipo azul tiene acceso para implementar en todos los espacios de nombres azules en los clústeres de la flota. El azul se considera el mismo espacio de nombres en cada clúster. El espacio de nombres azul también existe en el clúster de configuración de Ingress de varios clústeres. Los recursos de MultiClusterService que implementa el equipo azul solo pueden seleccionar en Pods que también existen en el espacio de nombres azul en diferentes clústeres. Los recursos MCI y MCS no tienen visibilidad ni acceso en los espacios de nombres en diferentes clústeres y, por lo tanto, la importancia y la “similitud” de los recursos se mantienen en los clústeres.

Un diagrama que demuestra la similitud de los espacios de nombres

Existe una ramificación en el diseño de la similitud de los espacios de nombres. Los siguientes principios ayudarán a los usuarios a tener éxito:

  • Los espacios de nombres para diferentes propósitos no deben tener el mismo nombre en todos los clústeres.
  • Los espacios de nombres deben reservarse de forma explícita, mediante la asignación de un espacio de nombres, o de manera implícita, mediante políticas fuera de banda, para equipos y clústeres dentro de una flota.
  • Los espacios de nombres para el mismo propósito en todos los clústeres deben compartir el mismo nombre.
  • El permiso del usuario para los espacios de nombres en los clústeres debe controlarse de forma estricta a fin de evitar el acceso no autorizado.
  • El espacio de nombres predeterminado o los espacios de nombres genéricos, como “prod” o “dev”, no deben usarse para la implementación normal de aplicaciones. Es frecuente que los usuarios implementen recursos en el espacio de nombres predeterminado de forma accidental y violen los principios de segmentación de los espacios de nombres.
  • Se debe crear el mismo espacio de nombres en los clústeres cada vez que un equipo o grupo de usuarios determinado tenga que implementar recursos.

Diseño del clúster de configuración

El clúster de configuración de Ingress for Anthos es un clúster de GKE único que aloja los recursos MCI y MCS y actúa como el único punto de control para Ingress en la flota de clústeres de GKE de destino. Elige el clúster de configuración cuando habilites Ingress de varios clústeres. Puedes elegir cualquier clúster de GKE como el clúster de configuración y cambiarlo en cualquier momento.

Disponibilidad del clúster de configuración

Debido a que el clúster de configuración es un único punto de control, los recursos de Ingress de varios clústeres no se pueden crear ni actualizar si la API del clúster de configuración no está disponible. Una interrupción del clúster de configuración no afectará a los balanceadores de cargas ni al tráfico que entregan, pero el controlador no conciliará los cambios en MCI y MCS hasta que vuelvan a estar disponibles.

Estos son algunos principios de diseño sobre cómo usar y administrar el clúster de configuración:

  • El clúster de configuración debe elegirse de modo que tenga alta disponibilidad. Se prefieren los clústeres regionales en lugar de los clústeres zonales.
  • No es necesario que el clúster de configuración sea un clúster dedicado para Ingress de varios clústeres. El clúster de configuración puede alojar cargas de trabajo administrativas o incluso de aplicaciones, pero debes tener cuidado a fin de garantizar que las aplicaciones alojadas no afecten 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 aloja backends para MCI, pero si se necesitan precauciones adicionales, el clúster de configuración también se puede excluir como un backend de MCI a través de la selección de clústeres.
  • Los clústeres de configuración deben tener todos los espacios de nombres que usan los backends del clúster de destino. Un MCS solo puede hacer referencia a Pods en el mismo espacio de nombres en los clústeres, por lo que el espacio de nombres debe estar presente en el clúster de configuración.
  • Los usuarios que implementan Ingress en varios clústeres deben tener acceso al clúster de configuración para implementar recursos MCI y MCS. Sin embargo, los usuarios solo deben tener acceso a los espacios de nombres que tengan permiso para usar.

Selecciona y migra el clúster de configuración

Debes elegir el clúster de configuración cuando habilites Ingress de varios clústeres. Cualquier clúster miembro de una flota se puede seleccionar como el clúster de configuración. Puedes actualizar el clúster de configuración en cualquier momento, pero debes asegurarte de que no provoque interrupciones. El controlador de Ingress conciliará los recursos MCI y MCS que existan en el clúster de configuración. Cuando se migra el clúster de configuración del actual al siguiente, los recursos MCI y MCS deben ser idénticos. Si los recursos no son idénticos, los balanceadores de cargas de Compute Engine pueden actualizarse o destruirse después de la actualización del clúster de configuración.

En el siguiente diagrama, un sistema de CI/CD centralizado aplica los recursos MCI y MCS 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 a fin de que los recursos sean idénticos en los dos clústeres. Si necesitas cambiar el clúster de configuración, para emergencias o tiempo de inactividad planificado, este se puede actualizar sin ningún impacto porque los recursos MCI y MCS son idénticos.

Un sistema de CI/CD centralizado que aplica recursos MCI y MCS

Selección de clústeres

Los recursos MCS tienen la capacidad de seleccionar de manera explícita en todos los clústeres. De forma predeterminada, un MCS programará los objetos Service derivados en cada clúster de destino. La selección de clústeres define una lista explícita de clústeres para un MCS determinado en el que se deben programar los objetos Service derivados y se ignorarán todos los demás clústeres de destino. Consulta Cómo configurar Ingress de varios clústeres a fin de configurar la selección de clústeres.

Existen muchos casos prácticos en los que recomendamos aplicar reglas de entrada a clústeres específicos:

  • Aislamiento de los clústeres de configuración para evitar que los MCS seleccionen en ellos
  • Control del tráfico entre clústeres de manera azul-verde para la migración de apps
  • Enrutamiento a los backends de aplicaciones que solo existen en un subconjunto de clústeres
  • Uso de una sola VIP L7 para el enrutamiento del host o de la ruta a backends que se alojan en clústeres diferentes

La selección del clúster se realiza a través del campo clusters en el MCS. <region | zone>/<name> hace referencia de forma explícita a los clústeres. Los clústeres miembros dentro de la misma flota y región deben tener nombres únicos para que no haya colisión de nombres.

En el siguiente ejemplo, el MCS foo tiene un campo clusters que hace referencia a europe-west1-c/gke-eu y asia-northeast1-a/gke-asia. Como resultado, los Pods con las etiquetas coincidentes en los clústeres gke-asia y gke-eu se pueden incluir como backends para un MCI determinado. Esto excluirá el clúster de gke-us de Ingress incluso si tiene Pods con la etiqueta app: foo. Esto puede ser útil para integrar o migrar a clústeres nuevos y controlar el tráfico sin importar la implementación del Pod.

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"

En el siguiente diagrama, se muestran tres clústeres: gke-eu, gke-asia-1 y gke-asia-2. gke-asia-2 se excluye como un backend, aunque los Pods con etiquetas coincidentes ya se encuentran allí. Esto permite que el clúster se excluya del tráfico para mantenimiento o para otras operaciones. Ten en cuenta que si el campo “clústeres” se omite de un MCS, se seleccionan todos los clústeres miembros de forma implícita.

Un diagrama que muestra un backend excluido

¿Qué sigue?