Ingress for Anthos

Ingress for Anthos (Ingress) es un controlador de Ingress de varios clústeres alojado en la nube para clústeres de Anthos 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 for Anthos en varios clústeres, sigue los pasos en Configura Ingress for Anthos y consulta Implementa 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 for Anthos 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 con varios clústeres de Ingress for Anthos satisface muchos casos prácticos, incluidos los que se mencionan a continuación:

  • 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

Cómo funciona Ingress for Anthos

Ingress for Anthos se basa en la arquitectura del Balanceo de cargas de 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 se encuentran en el extremo de la red de Google para ubicarse cerca de los clientes. Las VIP del balanceador de cargas se anuncian como IP Anycast. Las solicitudes de los clientes usan el enrutamiento de papa fría a los PoP de Google, lo que significa que el tráfico de Internet se dirige al PoP más cercano y llega a la red troncal de Google lo más rápido posible.

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 for Anthos es un controlador de Ingress que programa el balanceador de cargas de HTTP(S) externo mediante grupos de extremos 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 for Anthos

A medida que implementas aplicaciones en los clústeres en GKE, Ingress for Anthos 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 for Anthos actualiza el balanceador de cargas para que sea coherente con el entorno y el estado deseado de los recursos de Kubernetes.

Arquitectura de Ingress for Anthos

Ingress for Anthos usa un servidor de la API de Kubernetes centralizado 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 Anthos implementa balanceadores de cargas en varios clústeres.

Los siguientes conceptos y componentes conforman Ingress for Anthos:

  • Controlador de Ingress de Anthos: 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.

  • Environ: Es un dominio que agrupa la infraestructura y los clústeres, administra recursos y mantiene una política coherente en ellos. Ingress usa el concepto de Environ para su aplicación en diferentes clústeres. Los clústeres que registras en un Environ se vuelven visibles para Ingress, por lo que se pueden usar como backends para Ingress.

  • Clústeres miembros: Son los clústeres registrados en un Environ. Los clústeres miembros en el Environ conforman el alcance completo de los backends que Ingress 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.

Arco de Ingress for Anthos

Flujo de trabajo de Deployment

En los siguientes pasos, se ilustra un flujo de trabajo de alto nivel para usar Ingress for Anthos 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 for Anthos usa un servidor de la API de Kubernetes centralizado para implementar Ingress en varios clústeres. En las siguientes secciones, se describe el modelo de recursos de Ingress for Anthos, 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 usa Ingress for Anthos 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/v1alpha1
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 Service, 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 el Environ. Este MCS implementa un Service 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-frontend
  ports:
  - name: web
    protocol: TCP
    port: 80
    targetPort: 80

Algunas notas sobre el Service derivado: Su función es una agrupación lógica de extremos como backends de Ingress for Anthos. 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 de Ingress de Anthos 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/v1alpha1
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 un entorno.

Los Environ 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 entorno.

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 for Anthos. 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 un Environ.
  • 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. Debes elegir el clúster de configuración cuando habilitas Ingress for Anthos. 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 for Anthos 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.
  • El clúster de configuración no tiene que ser un clúster dedicado para Ingress for Anthos. 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 habilitas Ingress for Anthos. Se puede seleccionar cualquier clúster miembro de un entorno 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 de Anthos 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 Configura Ingress for Anthos a fin de configurar la selección del clúster.

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 del mismo entorno 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/v1beta1
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

Precios y pruebas

Ingress for Anthos requiere licencias de Anthos en GCP para todos los clústeres que participan como backends de Ingress. Las licencias se pueden comprar por hora por CPU virtual o como una suscripción a largo plazo. Los cargos de Ingress for Anthos entrarán en vigor a partir del 1 de agosto de 2020. Hasta entonces, Ingress for Anthos se ofrece de forma gratuita. Los precios del balanceador de cargas de Compute Engine estándar se aplican al tráfico de entrada y a las reglas de reenvío creadas a través de Ingress.

Después del 1 de agosto de 2020, Ingress for Anthos aún puede probarse de forma gratuita durante un máximo de 30 días y hasta 100 CPU virtuales en cualquier cantidad de clústeres. Para iniciar o finalizar la prueba, habilita o inhabilita la API de Anthos en un proyecto de Google Cloud, que proporciona acceso a Anthos en los productos de Google Cloud. Si se requieren períodos de prueba más largos, comunícate con tu equipo de cuentas para conocer los plazos extendidos.

¿Qué sigue?