Conceptos avanzados

Caso de uso de VRD: Uso de Citrix ADC Dynamic Routing con Kubernetes

Acme Inc. Route Health Injection e integración BGP para aplicaciones Kubernetes

Acme Inc. es un cliente Citrix desde hace mucho tiempo que tiene una gran presencia de Citrix ADC. Citrix ADC es la solución principal de equilibrio de carga y continuidad del negocio para aplicaciones críticas de Kubernetes. Acme Inc. cuenta actualmente con tres centros de datos principales.

Acme Inc. quiere proporcionar redundancia y alta disponibilidad para las aplicaciones críticas de Kubernetes para que puedan proporcionar una mayor tolerancia a fallos entre todos los racks de implementación en los tres centros de datos.

Mediante la inyección de mantenimiento de rutas en Citrix ADC, la solución proporciona redundancia para los servicios Kubernetes a los que se accede a través de la estructura de enrutamiento BGP + ECMP existente.

Además de la inyección de estado de ruta, muchas aplicaciones Kubernetes requieren el servidor back-end para recibir la IP real del cliente. Equilibrio de carga tradicional con Citrix ADC orígenes paquetes destinados a servidores back-end desde la dirección IP de subred ADC. Para aplicaciones que requieren la dirección IP del cliente verdadera como dirección de origen, Citrix ADC ofrece varios métodos. Estos métodos incluyen USIP (utilizar el modo IP de origen) y DSR (retorno directo del servidor).

Acme Inc. Las provisiones de TI prueban instancias Citrix ADC VPX con VIPs de prueba para las aplicaciones Kubernetes. Este entorno de prueba se utiliza para crear la solución de inyección de mantenimiento de ruta con IP del cliente y probarlo completamente antes de implementarla en el entorno de producción.

Requisitos de implementación

Acme Inc. y Citrix identificaron varios requisitos diferentes:

  • Unidades Citrix ADC VPX en cada centro de datos, con conectividad a la red de enrutamiento dinámico (3)
  • Direcciones IP para hasta tres servidores virtuales que se configurarán como rutas /32 en el enrutamiento dinámico de Acme Inc.

Entorno:

VIP de prueba de Kubernetes

  • La dirección SNIP en cada centro de datos que se utilizará como siguiente salto para VIP de inyección de estado de ruta en cada unidad Citrix ADC debe tener su propia dirección SNIP con enrutamiento dinámico habilitado. Esta es la Gateway para el VIP de inyección de salud de ruta anunciada.

Identificar la información de Kubernetes, incluyendo:

  • Backend Kubernetes Pods y VIPs de prueba
  • Puertos necesarios y parámetros de equilibrio de carga
  • Certificados SSL (cuando corresponda)

Configuración de IP de cliente

  • Los servidores back-end deben recibir la verdadera dirección IP del cliente
  • Las múltiples opciones disponibles se describen en la sección Opciones de IP del cliente

Vía de inyección de salud (RHI)

Enrutamiento dinámico Citrix ADC con inyección de mantenimiento de ruta

El objetivo principal del enrutamiento dinámico y la inyección de mantenimiento de rutas en Citrix ADC es comunicar el estado o el estado de los VIP a los enrutadores ascendentes. El estado de un VIP depende de los servidores virtuales asociados a él, y de los servicios que están vinculados a ese VIP. El anuncio de un VIP a través de inyección de estado de ruta está vinculado a los estados de los servidores virtuales asociados a la dirección IP virtual.

La dirección IP virtual debe tener el anuncio habilitado. Esto se logra al establecer la opción -hostroute en enabled en la dirección IP virtual. De forma predeterminada, la opción -hostroute se establece en disabled. La opción -hostroute se puede habilitar al agregar una dirección IP con el comando add ns ipo al modificar una dirección IP existente con el comando set ns ip.

Monitorización de inyección de estado de ruta

Una vez habilitada la opción hostRoute, el núcleo NetScaler inyecta la ruta del host en ZebOS NSM (Network Services Module), en función del estado de los servidores virtuales asociados a la dirección IP virtual. El conmutador - vserverroute health injectionLevel controla la relación entre el estado de los servidores virtuales y la ruta de host IP virtual que se envía al módulo de servicios de red (NSM).

Las tres opciones disponibles para el nivel de inyección de estado de la ruta del servidor virtual:

  • ALL_VSERVERS: Una ruta de host se inyecta en NSM solo si todos los servidores virtuales asociados a la IP virtual están activos.
  • ONE_VSERVER: Una ruta de host se inyecta en NSM solo si alguno de los servidores virtuales asociados a la IP virtual está activo.
  • NONE: Se inyecta una ruta de host a NSM independientemente del estado de los servidores virtuales asociados a la IP virtual.

Nota:

De forma predeterminada, -vserverRHILevel se establece en ONE_VSERVER.

El siguiente diagrama muestra la funcionalidad básica de inyección de mantenimiento de ruta para una dirección IP virtual asociada a un servidor virtual con equilibrio de carga en Citrix ADC:

Funcionalidad RHI para direcciones IP virtuales asociadas a un servidor virtual con equilibrio de carga en Citrix ADC

Opciones de inyección de mantenimiento de ruta con varios centros de datos

A continuación se describe la configuración de inyección de mantenimiento de ruta que se selecciona por aplicación, en función de los requisitos específicos de cada aplicación. Las opciones disponibles son:

Activo: Activo con BGP que determina la ruta más eficiente para cada cliente (Anycast o ECMP)

Vía Salud Inyección Activo: Activo: Anycast o ECMP

Vía de inyección de salud activa/activa es Anycast o ECMP. Esta es una verdadera alternativa activo-activa. En este caso, la ruta /32 para el VIP de inyección de mantenimiento de ruta se anuncia en todos los centros de datos sin que el coste o la preferencia local se presenten a BGP. Se presentan tres rutas a la red con la dirección SNIP del Citrix ADC específica para cada centro de datos que actúa como una Gateway para acceder a cada VIP. El entorno de enrutamiento dinámico de Acme Inc. dirige las solicitudes de los clientes al centro de datos sobre una base de igual coste para la distribución del tráfico. En el caso de que los servicios fallen en uno de los tres centros de datos, los monitores vinculados a los servicios de carga equilibrada bajan el servidor virtual. Esto, a su vez, elimina el anuncio de ruta para el centro de datos con el error. Todas las conexiones de cliente continúan trabajando con los centros de datos restantes.

Consideraciones importantes para la configuración activo-activa de inyección de mantenimiento de ruta:

  1. La inyección de mantenimiento de ruta con ECMP se recomienda para los servicios basados en TCP y UDP y requiere la configuración de BGP por parte del equipo de red de Acme Inc.. La inyección de mantenimiento de ruta con ECMP tiene un límite en el número de rutas que los enrutadores ascendentes pueden soportar (64).
  2. inyección de mantenimiento de ruta con Anycast funciona con servicios basados en UDP, no recomendado para servicios basados en TCP.

El siguiente diagrama describe el caso activo: Activo Anycast/ECMP:

Caso ECMP de Anycast activo-activo

Opciones de Citrix ADC y de IP de cliente

Uno de los requisitos importantes solicitados por Acme Inc. para una gran cantidad de sus aplicaciones Kubernetes es que los servidores back-end reciban la verdadera dirección IP del cliente para los servicios que el Citrix ADC equilibra la carga. El equilibrio de carga típico en Citrix ADC origina todo el tráfico destinado a servidores back-end desde una dirección SNIP (subred IP) propiedad de NetScaler. Para algunas aplicaciones se requiere la IP real del cliente. La mayoría de las aplicaciones que aprovechan la inyección de estado de ruta también requieren que la verdadera IP del cliente se envíe al servidor back-end.

Citrix ADC tiene una función denominada “Usar IP de origen” (USIP) que puede vincularse globalmente o individualmente a cada servicio que requiera la IP del cliente en el servidor back-end. El problema con esto es que una vez que el cliente recibe el paquete con una IP de origen diferente, se produce un enrutamiento asimétrico y el paquete se elimina. Es por esto que se deben evaluar otras consideraciones, y se requiere una configuración adicional en los servidores back-end para que USIP funcione correctamente.

Una consideración importante al implementar el modo IP de origen en Citrix ADC es que el modo Protección contra picos de actividad debe desactivarse en los modos Citrix ADC. Encontrará más información sobre el modo USIP con protección contra picos de actividad en el artículo de Citrix aquí.

Citrix ADC ofrece varios métodos para lograrlo, y se describen en la siguiente sección. Las opciones disponibles son:

  • Modo USIP con Citrix ADC SNIP como Gateway predeterminada
  • Capa 3 de retorno de servidor directo
    • Tunelización IP
    • Inserción de IP de cliente en el encabezado TOS
  • Capa 2 de retorno de servidor directo
  • Inserción de IP de cliente para encabezado TCP

Modo USIP con Citrix ADC SNIP como puerta de enlace predeterminada

Durante varias reuniones con Acme Inc. IT, se determinó que este método es preferido para la mayoría de los servicios de equilibrio de carga que requieren IP del cliente. Este método implica cambiar la Gateway predeterminada para cada servidor back-end que se equilibra la carga y configurarla en la dirección SNIP de la unidad Citrix ADC que aloja el VIP balanceado de carga. Esta opción admite todas las funciones de Citrix ADC en lugar de las opciones de devolución del servidor directo, donde Citrix ADC solo administra las solicitudes de clientes entrantes. Esta opción también requiere la mayor cantidad de ancho de banda en las unidades ADC. Este método tiene los siguientes requisitos básicos:

  • El Citrix ADC debe tener una dirección SNIP en la misma subred L2 que todos los servidores back-end balanceados de carga.
  • La dirección SNIP se configura como la Gateway predeterminada para todos los servidores back-end. Se pueden utilizar varias direcciones SNIP para servidores back-end en diferentes subredes L2.
  • El modo USIP debe estar habilitado en los servicios que apuntan a servidores back-end.

Nota:

USIP también puede estar habilitado globalmente en las unidades Citrix ADC; sin embargo, USIP solo se aplicará a los servicios creados después de habilitar el modo USIP.

Citrix recomienda agregar más interfaces de red a los servidores back-end y configurar rutas estáticas para el tráfico que no sea cliente.

  • Las rutinas de backup y otros procesos que requieren ancho de banda no tienen que atravesar la unidad Citrix ADC.

Devolución directa del servidor: Opciones de capa 3

La devolución directa del servidor con Citrix ADC es otra opción de configuración para obtener las direcciones IP del cliente en los servidores back-end en una configuración de equilibrio de carga. El retorno directo del servidor se puede configurar en modo de capa 3, lo que permite el uso de servidores back-end en otras VLAN L3, en lugar de USIP, que requiere conectividad L2 desde el ADC a los servidores back-end. La configuración de devolución directa del servidor no admite ciertas funciones de Citrix ADC debido a que el tráfico de respuesta no atraviesa la unidad Citrix ADC. Esta opción requiere el menor rendimiento en las unidades Citrix ADC.

El retorno directo del servidor tiene configuraciones más complejas necesarias para los servidores back-end, ya que deben poder extraer la IP del cliente y reescribir el encabezado TCP para responder directamente al cliente. Citrix admite actualmente dos métodos diferentes para configurar DSR de capa 3:

  • Modo DSR con túnel IP (IP sobre IP)
  • Modo DSR con TOS (tipo de campo de encabezado TCP de servicio) Capa 3

DSR tiene los siguientes requisitos básicos:

  • El Citrix ADC debe configurarse con USIP en el servicio.
  • Los servidores back-end tienen una dirección de bucle invertido configurada con la dirección VIP de Citrix ADC.
  • El servidor back-end debe configurarse específicamente para cada método:
    • Tunelización IP: El servidor back-end debe desencapsular los paquetes del ADC y extraer la IP del cliente para una respuesta directa al cliente.
    • TOS (Tipo de servicio): El servidor back-end debe poder leer el encabezado TOS del paquete TCP y usar esta información para responder directamente al cliente.
    • Cualquiera de los métodos puede requerir configuraciones personalizadas en servidores back-end y el uso de una aplicación de terceros.

El DSR de capa 3 puede requerir la configuración de excepciones en firewalls y dispositivos de seguridad.

Puede encontrar más información sobre el retorno directo del servidor con Capa 3 aquí:

  • DSR con TOS
  • DSR con túnel IP

Exponer servicios de tipo “LoadBalancer”

Los servicios de tipo LoadBalancer se admiten de forma nativa en implementaciones de Kubernetes en nubes públicas como AWS, GCP o Azure. En las implementaciones en la nube, al crear un servicio de tipo LoadBalancer, se asigna un equilibrador de carga administrado en la nube al servicio. A continuación, el servicio se expone mediante el equilibrador de carga.

Para implementaciones locales, de hardware o de nube pública de Kubernetes, puede utilizar un Citrix ADC fuera del clúster para equilibrar la carga del tráfico entrante. El Controller de entrada de Citrix proporciona una administración flexible de direcciones IP que permite el multiarrendamiento para los dispositivos Citrix ADC. El Controller de entrada de Citrix le permite equilibrar la carga de varios servicios mediante un único ADC y también combina varias funciones de entrada. Mediante el Citrix ADC con el Controller de entrada de Citrix, puede maximizar la utilización de los recursos del equilibrador de carga para su nube pública y reducir significativamente sus gastos operativos.

El Controller de entrada de Citrix admite los servicios de tipo LoadBalancer cuando Citrix ADC está fuera del clúster de Kubernetes (nivel 1). Cuando se crea, actualiza o elimina un servicio de tipo LoadBalancer, el Controller de entrada de Citrix configura Citrix ADC con un servidor virtual de equilibrio de carga.

El servidor virtual de equilibrio de carga se configura con una dirección IP (dirección IP virtual o VIP) que se obtiene de una de las siguientes maneras: ​

  1. Asignando automáticamente una dirección IP virtual al servicio mediante el Controller IPAM proporcionado por Citrix. La solución está diseñada de tal manera que puede integrar fácilmente la solución con proveedores externos de DNS como Infoblox. Para obtener más información, vea Interoperabilidad con DNS externos. ​
  2. Al especificar una dirección IP mediante el campo Spec.loadBalancerIP en la definición de servicio. El Controller de entrada de Citrix utiliza la dirección IP proporcionada en el campo Spec.LoadBalanceRip como la dirección IP del servidor virtual de equilibrio de carga que corresponde al servicio.

    apiVersion: v1
    kind: Service
    metadata:
        name: hello-world-service
    spec:
        type: LoadBalancer
        loadBalancerIP: ""
    ports:
    - port: 80
        targetPort: 8080
    selector:
        run: load-balancer-example
    <!--NeedCopy-->
    

Para obtener una referencia más detallada, consulte Exponer servicios de tipo LoadBalancer.

Caso de uso de VRD: Uso de Citrix ADC Dynamic Routing con Kubernetes