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

Integración de BGP y Route Health Injection de Acme Inc. para aplicaciones de Kubernetes

Acme Inc. es un cliente de Citrix desde hace mucho tiempo que tiene una gran presencia de Citrix ADC. Citrix ADC funciona como la principal solución de equilibrio de carga y continuidad empresarial para las 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 ofrecer una mayor tolerancia a fallas entre todos los racks de implementación en los tres centros de datos.

Al usar la inyección de estado de ruta en Citrix ADC, la solución proporciona redundancia para los servicios de Kubernetes a los que se accede a través del tejido de redirección BGP + ECMP existente.

Además de la inyección de estado de ruta, muchas aplicaciones de Kubernetes requieren que el servidor back-end reciba la IP real del cliente. El equilibrio de carga tradicional con Citrix ADC genera paquetes destinados a servidores back-end desde la dirección IP de la subred de ADC. Para las aplicaciones que requieren la verdadera dirección IP del cliente como dirección de origen, Citrix ADC ofrece varios métodos. Estos métodos incluyen USIP (usar modo IP de origen) y DSR (Direct Server Return).

Las provisiones de TI de Acme Inc. prueban las instancias de Citrix ADC VPX con VIP de prueba para las aplicaciones de Kubernetes. Este entorno de prueba se utiliza para crear la solución de inyección de estado de ruta con IP de cliente y probarla 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 redirección dinámica (3)
• Direcciones IP para hasta tres servidores virtuales que se configuran como rutas /32 en la redirección dinámica de Acme Inc.

Entorno:

VIP de prueba de Kubernetes

• La dirección SNIP de cada centro de datos que se utilizará como siguiente salto para la inyección de estado de ruta VIP en cada unidad Citrix ADC debe tener su propia dirección SNIP con la redirección dinámica habilitado. Esta es la puerta de enlace para el VIP de inyección de estado de ruta anunciado.

Identificar la información de Kubernetes, como:

• Pods de Kubernetes back-end y VIP de prueba
• Parámetros de equilibrio de carga y puertos necesarios
• 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 analizan en la sección de opciones de IP del cliente.

Inyección de salud de ruta (RHI)

Redirección dinámico de Citrix ADC con inyección de estado de ruta

El objetivo principal de la redirección dinámica y la inyección de estado de ruta en Citrix ADC es comunicar el estado o el estado de los VIP a los enrutadores ascendentes. El estado de una VIP depende de los servidores virtuales asociados a ella y de los servicios que están vinculados a esa VIP. El anuncio de un VIP a través de la 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 habilitada la publicidad. 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 ip o al modificar una dirección IP existente con el comando set ns ip.

Monitorización de la inyección 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 botón - 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 ruta del servidor virtual:

• ALL_VSERVERS: Una ruta de host se inyecta a 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 en el 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 describe la funcionalidad básica de inyección de estado de ruta para una dirección IP virtual asociada a un servidor virtual con equilibrio de carga en Citrix ADC:

Opciones de inyección de Route Health con varios centros de datos

A continuación se describe la configuración de inyección de estado de ruta que se selecciona por aplicación, según 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)

Inyección de estado de ruta activa: Activa: Anycast o ECMP

La inyección de salud de la ruta activa/activa es Anycast o ECMP. Esta es una verdadera alternativa activo-activo. 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 de Citrix ADC específica de cada centro de datos que actúa como puerta de enlace para acceder a cada VIP. El entorno de redirección dinámica 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 caso de que los servicios fallen en uno de los tres centros de datos, los monitores vinculados a los servicios de equilibrio de carga desactivan el servidor virtual. Esto, a su vez, elimina el anuncio de ruta para el centro de datos con la falla. Todas las conexiones de clientes siguen funcionando con los centros de datos restantes.

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

1. La inyección de estado 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 estado de ruta con ECMP tiene un límite en la cantidad de rutas que los enrutadores ascendentes pueden admitir (64).
2. la inyección de estado de ruta con Anycast admite servicios basados en UDP y no se recomienda para los servicios basados en TCP.

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

Opciones de IP de cliente y Citrix ADC

Uno de los requisitos importantes que solicita Acme Inc. para una gran cantidad de sus aplicaciones de Kubernetes es que los servidores de fondo reciban la verdadera dirección IP del cliente para los servicios que Citrix ADC equilibra la carga. El equilibrio de carga típico en Citrix ADC origina todo el tráfico destinado a los servidores de fondo desde una dirección SNIP (IP de subred) propiedad de NetScaler. Para algunas aplicaciones, se requiere la IP real del cliente. La mayoría de las aplicaciones que utilizan 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 descarta. 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 sobretensiones en el artículo de Citrix aquí.

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

• Modo USIP con Citrix ADC SNIP como puerta de enlace predeterminada
• Nivel 3 de devolución de servidor directo
  • Tunelización IP
  • Inserción de IP de cliente en encabezado TOS
• Nivel 2 de devolución 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 el departamento de TI de Acme Inc., se determinó que este método es el preferido para la mayoría de los servicios de equilibrio de carga que requieren IP de cliente. Este método implica cambiar la puerta de enlace predeterminada para cada servidor back-end al que se le equilibra la carga y configurarla en la dirección SNIP de la unidad Citrix ADC que aloja la VIP con equilibrio de carga. Esta opción admite todas las funciones de Citrix ADC a diferencia de las opciones de devolución directa del servidor, donde Citrix ADC solo administra las solicitudes entrantes de los clientes. 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 a los que se les equilibra la carga.
• La dirección SNIP se configura como la puerta de enlace predeterminada para todos los servidores back-end. Se pueden usar varias direcciones SNIP para servidores back-end en diferentes subredes L2.
• El modo USIP debe estar habilitado en los servicios que apuntan a los servidores back-end.

Nota:

USIP también se puede habilitar 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 de clientes.

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

Retorno directo 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 de los clientes en los servidores back-end en una configuración de equilibrio de carga. El retorno directo del servidor se puede configurar en el modo de capa 3, lo que permite el uso de servidores back-end en otras VLAN L3, a diferencia 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 de las unidades Citrix ADC.

La devolución directa del servidor tiene configuraciones más complejas necesarias para los servidores back-end, ya que deben poder extraer la IP del cliente y volver a escribir el encabezado TCP para responder directamente al cliente. Citrix admite actualmente dos métodos diferentes para configurar DSR de capa 3:

• Modo DSR con tunelización IP (IP sobre IP)
• Modo DSR con TOS (campo de encabezado TCP de tipo de servicio) Capa 3

DSR tiene los siguientes requisitos básicos:

• El Citrix ADC debe estar configurado 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 dos 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 la Direct Server Return con capa 3 aquí:

Configure el modo DSR cuando utilice TOS - DSR con TOS

• DSR con tunelización IP

Exponer servicios de tipo “LoadBalancer”

Los servicios del tipo LoadBalancer se admiten de forma nativa en las implementaciones de Kubernetes en nubes públicas como AWS, GCP o Azure. En las implementaciones en la nube, cuando creas 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 las implementaciones locales, bare metal o en la nube pública de Kubernetes, puede usar 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 Citrix ingress controller le permite equilibrar la carga de varios servicios mediante un único ADC y también combina varias funciones de ingreso. Al usar Citrix ADC con el Citrix ingress controller, puede maximizar la utilización de los recursos del balanceador de carga para su nube pública y reducir significativamente sus gastos operativos.

El Citrix ingress controller admite los servicios de tipo LoadBalancer cuando el Citrix ADC está fuera del clúster de Kubernetes (nivel 1). Cuando se crea, actualiza o elimina un servicio de tipo LoadBalancer, el Citrix ingress controller 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. Al asignar automáticamente una dirección IP virtual al servicio mediante el controlador IPAM proporcionado por Citrix. La solución está diseñada de tal manera que puede integrar fácilmente la solución con proveedores de DNS externos como Infoblox. Para obtener más información, consulte Interoperabilidad con ExternalDNS. ​

2. Especificando una dirección IP mediante el campo spec.loadBalancerIP de 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.

Requisito previo de IPAM

Como requisito previo para Citrix ADC Dynamic Routing with Kubernetes, se debe configurar la administración de direcciones IP (IPAM). IPAM se utiliza para asignar y liberar automáticamente direcciones IP en las implementaciones gestionadas por ADM. Para obtener una referencia más detallada, consulte Configurar la administración de direcciones IP.