Conceptos avanzados

Diseño de referencia validado de las redes nativas de Citrix Cloud para Red Hat OpenShift 3.11

Citrix ADC Stack cumple los requisitos básicos de funciones de disponibilidad de aplicaciones (ADC), segregación de funciones de seguridad (WAF), escalado de topologías ágiles de aplicaciones (SSL y GSLB) y observabilidad proactiva (Service Graph) en un entorno altamente orquestado, Cloud Native Era.

La transformación digital está alimentando la necesidad de mover las implementaciones de aplicaciones modernas a arquitecturas basadas en microservicios. Estas arquitecturas Cloud Native aprovechan contenedores de aplicaciones, microservicios y Kubernetes.

El enfoque Cloud Native para las aplicaciones modernas también transformó el ciclo de vida del desarrollo, incluidos flujos de trabajo ágiles, conjuntos de herramientas de implementación de automatización y lenguajes y plataformas de desarrollo.

La nueva era de la implementación moderna de aplicaciones también ha cambiado las disciplinas tradicionales del modelo de negocio del centro de datos, incluidas las versiones y contratos de software mensuales y anuales, los recursos informáticos de silos y el presupuesto, y el modelo de consumo de proveedores.

Y aunque toda esta modernización se está produciendo en el ecosistema, todavía existen requisitos básicos para las funciones de disponibilidad de aplicaciones (ADC), la segregación de funciones de seguridad (WAF), el escalado de topologías ágiles de aplicaciones (SSL y GSLB) y la observabilidad proactiva (Service Graph) en un entorno altamente orquestado.

Por qué Citrix para la entrega de aplicaciones modernas

El enfoque de software Citrix para la implementación moderna de aplicaciones requiere la incorporación de un flujo de trabajo ágil en muchos equipos dentro de la organización. Una de las ventajas del desarrollo y la entrega de aplicaciones ágiles es el marco conocido como CI/CD.

CI/CD es una forma de proporcionar velocidad, seguridad y fiabilidad en el ciclo de vida de las aplicaciones modernas.

La integración continua (CI) permite una base de código común que puede actualizarse en tiempo real varias veces al día e integrarse en una plataforma de compilación automatizada. Las tres fases de la integración continua son Push, Test, Fix.

Continuous Delivery (CD) integra el proceso de implementación directamente en el proceso de desarrollo de CI, optimizando y mejorando así el modelo de entrega de software para aplicaciones modernas.

Los ADC de Citrix se vinculan al proceso de entrega continua mediante la implementación de implementaciones progresivas automatizadas de análisis Canary.

Una solución para todas las partes interesadas

Citrix ha creado una solución basada en software dedicada que aborda los requisitos de funcionalidad cruzada al implementar aplicaciones modernas e integra los diversos componentes de la pila de observabilidad, el marco de seguridad y la infraestructura de CI/CD.

Las organizaciones tradicionales que adoptan técnicas de CI/CD para implementar aplicaciones modernas han reconocido la necesidad de proporcionar un marco común de entrega y disponibilidad a todos los miembros que participan en las CI/CD, estos recursos se definen generalmente como “partes interesadas” de la unidad de negocio, y si bien cada parte interesada es invertidos en el éxito general de la organización, cada uno de los interesados generalmente tiene requisitos y diferencias distintos.

Algunos ejemplos comunes de partes interesadas en la actividad moderna de prestación de servicios incluyen:

  • Equipo de plataformas: Implemente infraestructura de centros de datos como IaaS, PaaS, SDN, ADC, WAF
  • Equipo de DevOps e Ingeniería: Desarrolle y mantenga el repositorio de código unificado, las herramientas de automatización y la arquitectura de software
  • Equipo de ingeniería de fiabilidad de servicios (SRE): Reduzca los silos organizativos, la administración de errores, la automatización de implementaciones y las mediciones
  • Equipo de operaciones de seguridad: Directivas de seguridad proactivas, administración de incidentes, implementación de parches, endurecimiento de carteras

Explicación de la pila de software de Citrix

Base de código único: Es el mismo código para usted

  • Implementaciones locales, implementaciones de nube pública, implementaciones de nube privada, implementaciones de nube GOV Cloud

  • Opciones de plataformas: Para satisfacer cualquier requisito ágil, elija cualquier modelo de Citrix ADC

    • CPX: Citrix ADC CPX es un Citrix ADC entregado como contenedor
    • VPX: El producto Citrix ADC VPX es un dispositivo virtual que se puede alojar en una amplia variedad de plataformas de virtualización y nube que ofrece un rendimiento que oscila entre 10 MB/s y 100 Gb/s.
    • MPX: Citrix ADC MPX es un dispositivo de entrega de aplicaciones basado en hardware que ofrece un rendimiento que oscila entre 500 MB/s y 200 GB/s.
    • SDX: El dispositivo Citrix ADC SDX es una plataforma multiarrendatario en la que puede aprovisionar y administrar varias máquinas virtuales Citrix ADC (instancias).
    • BLX: El dispositivo Citrix ADC BLX es un factor de forma de software de Citrix ADC. Está diseñado para funcionar de forma nativa en Bare-Metal-Linux en servidores comerciales listos para usar (COTS) Entornos en contenedores: Cree superposiciones y configure automáticamente su Citrix ADC
    • Controlador de entrada de Citrix: Construido alrededor de Kubernetes Ingress y configura automáticamente uno o más Citrix ADC basado en la configuración de recursos de entrada
    • Controlador de nodo Citrix: Cree una red de superposición basada en VXLAN entre los nodos Kubernetes y el Citrix ADC Ingress
    • Controladora IPAM de Citrix: Asigne automáticamente el servidor virtual de equilibrio de carga en un Citrix ADC con una dirección IP (dirección IP virtual o VIP) Pooled Capacity Licensing: Una licencia global
    • Ubiquous Global Licensing desacopla plataformas y licencias para obtener una flexibilidad completa para el diseño y el rendimiento Application Delivery Manager, el único panel de cristal
    • Administre la flota, organice directivas y aplicaciones, supervise y solucione problemas en tiempo real Topologías flexibles: Centro de datos tradicional o nubes modernas
    • Nivel único, dos niveles y servicio mesh lite

El valor Citrix ADC

  • Integración de Kubernetes y CNCF Open Source Tools
  • Perfect Proxy: Un Controller de entrega de aplicaciones Layer7 probado para aplicaciones modernas
    • Contenedor ADC de alto rendimiento en una implementación de Pod o Sidecar
    • Acceso de baja latencia al clúster de Kubernetes mediante múltiples opciones
  • API rica en funciones: Implemente y orqueste fácilmente las funciones de seguridad sin límites
  • Dirección avanzada de tráfico e implementación de Canarias para CI/CD
  • Seguridad comprobada a través de TLS/SSL, WAF, DoS y protección API
  • Capacidades de nivel 7 enriquecidas
  • Supervisión integrada para implementaciones de aplicaciones antiguas y modernas
  • Información práctica y gráficos de servicio para la visibilidad

Ventajas de Citrix ADC

  • Mover aplicaciones heredadas sin tener que volver a escribirlas
  • Los desarrolladores pueden proteger las aplicaciones con las directivas Citrix ADC mediante las API de Kubernetes (Uso de CRDs: Fácil para desarrolladores)
  • Implementar microservicios de alto rendimiento para Norte-Sur y Service Mesh
  • Utilizar un gráfico de servicio de aplicaciones para todos los microservicios
  • Solucionar problemas de microservicios más rápido a través de TCP, UDP, HTTP/S, SSL
  • Asegure las API y configure mediante las API de Kubernetes
  • Mejore el proceso de CICD para implementaciones de Canary

Componentes de arquitectura

Cartera de soluciones Citrix para aplicaciones nativas en la nube

La ventaja de Citrix ADC Suite

Citrix es Choice. Tanto si vive con centros de datos y componentes heredados como si ha lanzado una nueva aplicación moderna nativa en la nube, Citrix ADC se integra perfectamente en cualquier requisito de plataforma que pueda tener. Proporcionamos funcionalidad ADC nativa en la nube para plataformas y herramientas en la nube basadas en suscripciones, permitimos dirigir y orquestar el tráfico en su clúster Kubernetes de forma local con una fácil orquestación del Controller Ingress, y abordamos las arquitecturas de Service Mesh desde simples hasta complejas.

Citrix está validado. Las plantillas de diseño validadas y las aplicaciones de muestra permiten la fácil referencia del estado deseado y los requisitos empresariales que se deben abordar de forma rápida y completa. Hemos documentado y publicado ejemplos de configuración en una ubicación central para facilitar la referencia entre los equipos de DevOps, SecOps y Plataformas.

Citrix es ágil y moderno. Cree una arquitectura fundacional para que los clientes consuman nuevas funciones de Citrix Cloud Native Stack con su ADC existente y nuevos módulos (CNC, IPAM, etc.)

Citrix está abierto. Ayude a los clientes a comprender nuestra integración con los ecosistemas asociados. En este documento utilizamos las herramientas OpenSource CNCF y los productos Citrix Enterprise Grade.

Ecosistema de socios

En este tema se proporcionan detalles acerca de varias plataformas Kubernetes, topologías de implementación, funciones y CNIs compatibles con implementaciones Native en la nube que incluyen Citrix ADC y el Controller de entrada de Citrix.

Citrix Ingress Controller es compatible con las siguientes plataformas:

  • Kubernetes v1.10 en hardware desnudo o autoalojado en nubes públicas como, por ejemplo, AWS, GCP o Azure.
  • Motor de Google Kubernetes (GKE)
  • Elastic Kubernetes Service (EKS)
  • Servicio Kubernetes de Azure (AKS)
  • Red Hat OpenShift versión 3.11 y posterior
  • Servicio de contenedores dinámicos (PKS)
  • Diamanti Enterprise Plataforma Kubernetes

Nuestro ecosistema de socios también incluye lo siguiente:

  • Prometheus: Herramienta de supervisión de métricas, alertas e información
  • Grafana: Una plataforma de análisis y supervisión
  • Spinnaker: Una herramienta para la entrega continua de Canary y varias nubes: Análisis
  • Elasticsearch: Un servicio de búsqueda de aplicaciones o sitios
  • Kibana: Una herramienta de visualización para datos de búsqueda elásticos y una herramienta de navegación de pila elástica
  • Fluentd: Una herramienta de recopilación de datos

El enfoque de esta siguiente sección es diseño/arquitectura con OpenShift.

Visión general de OpenShift

Red Hat OpenShift es una plataforma Kubernetes para implementaciones centradas en el uso de microservicios y contenedores para crear y escalar aplicaciones más rápido. Al automatizar, instalar, actualizar y administrar la pila de contenedores, OpenShift optimiza Kubernetes y facilita las tareas diarias de DevOps.

  • Los desarrolladores aprovisionan aplicaciones con acceso a soluciones validadas y socios que se envían a la producción a través de flujos de trabajo optimizados.
  • Las operaciones pueden administrar y escalar el entorno mediante la Consola Web y el registro y la supervisión integrados.

Figura 1-6: Arquitectura de alto nivel OpenShift.

Más ventajas y componentes de OpenShift incluyen:

  • Selección de infraestructura
  • Nodos maestro y trabajador
  • Registro de imágenes
  • Capa de servicio y enrutamiento
  • Operación del desarrollador (introducida pero está fuera del alcance de este documento)

Los casos de uso para integrar Red Hat OpenShift con Citrix Native Stack incluyen:

  • Compatibilidad con aplicaciones heredadas
  • Directivas de reescritura/respuesta implementadas como API
  • Solución de problemas de microservicios
  • Operaciones diarias con parches de seguridad y mejoras de funciones

En este documento cubrimos cómo Citric ADC proporciona una integración sólida de la capa de enrutamiento y servicio.

Proyectos OpenShift

El primer nuevo concepto que OpenShift agrega es proyecto, que efectivamente envuelve un espacio de nombres, con el acceso al espacio de nombres que se controla a través del proyecto. El acceso se controla a través de un modelo de autenticación y autorización basado en usuarios y grupos. Por lo tanto, los proyectos en OpenShift proporcionan los muros entre espacios de nombres, asegurando que los usuarios, o las aplicaciones, solo pueden ver y acceder a lo que se les permite.

Espacios de nombres OpenShift

El concepto de agrupación principal en Kubernetes es el espacio de nombres. Los espacios de nombres también son una forma de dividir los recursos del clúster entre varios usos. Dicho esto, no hay seguridad entre espacios de nombres en Kubernetes. Si usted es un “usuario” en un clúster de Kubernetes, puede ver todos los diferentes espacios de nombres y los recursos definidos en ellos.

Ejemplo de archivo YAML que crea un espacio de nombres denominado "Tier-2-adc".

Redes definidas por software (SDN) OpenShift

OpenShift Container Platform utiliza un enfoque de redes definidas por software (SDN) para proporcionar una red de clústeres unificada que permite la comunicación entre pods a través del clúster OpenShift Container Platform. Esta red de pods es establecida y mantenida por OpenShift SDN, que configura una red de superposición mediante Open vSwitch (OVS).

OpenShift SDN proporciona tres plug-ins SDN para configurar la red de pods:

  • El plug-in ovs-subnet es el plug-in original, que proporciona una red de pods “plana” donde cada pod puede comunicarse con cualquier otro pod y servicio.
  • El complemento ovs-multitenant proporciona aislamiento a nivel de proyecto para pods y servicios. Cada proyecto recibe un ID de red virtual (VNID) único que identifica el tráfico de pods asignados al proyecto. Los pods de diferentes proyectos no pueden enviar ni recibir paquetes de pods y servicios de un proyecto diferente.
  • Sin embargo, los proyectos que reciben VNID 0 tienen más privilegios en el sentido de que se les permite comunicarse con todos los demás pods, y todos los demás pods pueden comunicarse con ellos. En los clústeres de OpenShift Container Platform, el proyecto predeterminado tiene VNID 0.Esto facilita que ciertos servicios, como el equilibrador de carga, se comuniquen con todos los demás pods del clúster y viceversa.
  • El complemento ovs-networkpolicy permite a los administradores de proyectos configurar sus propias directivas de aislamiento mediante objetos NetworkPolicy.

Enrutamiento y complementos OpenShift

Un administrador de OpenShift puede implementar enrutadores en un clúster de OpenShift, que habilita rutas creadas por los desarrolladores para que las utilicen clientes externos. La capa de enrutamiento en OpenShift es conectable, y plug-ins de enrutador se proporcionan y admiten dos disponibles de forma predeterminada.

Los enrutadores OpenShift proporcionan asignación externa de nombres de host y equilibrio de carga a servicios a través de protocolos que pasan la información distintiva directamente al enrutador; el nombre de host debe estar presente en el protocolo para que el enrutador para determinar dónde enviarlo.

Los complementos del enrutador asumen que pueden vincularse a los puertos host 80 y 443. Esto es para permitir que el tráfico externo se enrute al host y, posteriormente, a través del enrutador. Los enrutadores también asumen que la red está configurada de modo que pueda acceder a todos los pods del clúster.

El enrutador de OpenShift es el punto de entrada para todo el tráfico externo destinado a servicios en la instalación de OpenShift. OpenShift proporciona y admite los siguientes complementos de enrutador:

  • El enrutador de plantilla HAProxy es el plug-in predeterminado. Utiliza openshift3/ose-haproxy-routerimage para ejecutar una instancia HAProxy junto al complemento del enrutador plantilla dentro de un contenedor en OpenShift. Actualmente soporta tráfico HTTP (S) y tráfico habilitado para TLS a través de SNI. El contenedor del router escucha en la interfaz de red del host, a diferencia de la mayoría de los contenedores que solo escuchan en IP privadas. El enrutador envía solicitudes externas de nombres de ruta a las direcciones IP de pods reales identificados por el servicio asociado a la ruta.
  • El Controller de entrada de Citrix se puede implementar como un complemento de enrutador en el clúster de OpenShift para integrarse con los ADC de Citrix implementados en su entorno. El Controller de entrada de Citrix le permite utilizar las capacidades avanzadas de equilibrio de carga y administración de tráfico de Citrix ADC con su clúster OpenShift. Consulte Implementar el Controller de entrada de Citrix como un complemento de enrutador en un clúster de OpenShift.

Rutas OpenShift y métodos de entrada

In an OpenShift cluster, external clients need a way to access the services provided by pods.OpenShift provides two resources for communicating with services running in the cluster: rutas and Ingreso.

Rutas

En un clúster de OpenShift, una ruta expone un servicio en un nombre de dominio determinado o asocia un nombre de dominio a un servicio. Los enrutadores OpenShift enrutar las solicitudes externas a los servicios dentro del clúster OpenShift de acuerdo con las reglas especificadas en las rutas. Cuando utilice el enrutador OpenShift, también debe configurar el DNS externo para asegurarse de que el tráfico está aterrizando en el enrutador.

El Controller de entrada de Citrix se puede implementar como un complemento de enrutador en el clúster de OpenShift para integrarse con los ADC de Citrix implementados en su entorno. El Controller de entrada de Citrix le permite utilizar las capacidades avanzadas de equilibrio de carga y administración de tráfico de Citrix ADC con su clúster OpenShift. Las rutas OpenShift pueden ser seguras o no seguras. Las rutas seguras especifican la terminación TLS de la ruta.

El Controller de entrada de Citrix admite las siguientes rutas OpenShift:

  • Rutas no seguras: Para rutas no seguras, el tráfico HTTP no está cifrado.
  • Terminaciónde borde: Para la terminación de borde, TLS termina en el enrutador. El tráfico desde el enrutador a los dispositivos de punto final a través de la red interna no está cifrado.
  • Terminaciónde paso: Con la terminación de paso, el enrutador no participa en la descarga de TLS y el tráfico cifrado se envía directamente al destino.
  • Terminación de recifrado: En la terminación de recifrado, el enrutador termina la conexión TLS pero luego establece otra conexión TLS con el punto final.

En función de cómo quiere utilizar Citrix ADC, existen dos formas de implementar Citrix Ingress Controller como un complemento de enrutador en el clúster de OpenShift: Como Citrix ADC CPX dentro del clúster o como Citrix ADC MPX/VPX fuera del clúster.

Implementar Citrix ADC CPX como enrutador dentro del clúster OpenShift

El Controller Citrix Ingress se implementa como sidecar junto con el contenedor Citrix ADC CPX en el mismo pod. En este modo, el Controller de entrada de Citrix configura Citrix ADC CPX. Consulte Implementar Citrix ADC CPX como enrutador dentro del clúster OpenShift.

Implementar Citrix ADC MPX/VPX como un enrutador fuera del clúster OpenShift

El Controller de entrada de Citrix se implementa como un pod independiente y le permite controlar el dispositivo Citrix ADC MPX o VPX desde fuera del clúster de OpenShift. Consulte Implementar Citrix ADC MPX/VPX como un enrutador fuera del clúster OpenShift.

Ingreso

Kubernetes le Ingreso proporciona una forma de enrutar solicitudes a servicios basados en el host de solicitud o ruta, centralizando una serie de servicios en un único punto de entrada.

Citrix Ingress Controller se basa en Kubernetes Ingress, configurando automáticamente uno o más dispositivos Citrix ADC basados en el recurso Ingress.

El enrutamiento con entrada se puede realizar mediante:

  • Enrutamiento basado en nombre de host
  • Redirección basada en rutas
  • Enrutamiento basado en comodines
  • Coincidencia exacta de la ruta
  • Enrutamiento sin nombre de host
  • Atrás predeterminado

Consulte Configuraciones de entrada para obtener ejemplos y más información.

Implementar el Controller de entrada de Citrix como un complemento de enrutador OpenShift

Según cómo quiere utilizar Citrix ADC, existen dos formas de implementar Citrix Ingress Controller como complemento de enrutador en el clúster de OpenShift:

Arquitecturas recomendadas

Recomendamos las siguientes arquitecturas para los clientes al diseñar sus arquitecturas de microservicios:

  • Entrada unificada de Citrix
  • Entrada de 2 niveles de Citrix
  • Citrix Service Mesh Lite

Figura 1-2: La arquitectura varía de relativamente simple a más compleja y rica en funciones.

Entrada unificada de Citrix

En una implementación de Unified Ingress, los dispositivos Citrix ADC MPX o VPX proxy tráfico Norte-Sur de los clientes a las aplicaciones de nivel empresarial implementadas como microservicios dentro del clúster. El Controller de entrada de Citrix se implementa como pod o sidecar en el clúster de Kubernetes para automatizar la configuración de los dispositivos Citrix ADC (MPX o VPX) en función de los cambios realizados en los microservicios o en los recursos de Ingress.

Puede comenzar a implementar el modelo de entrada unificado mientras su aplicación sigue siendo un monolito. Simplemente coloque Citrix ADC como un proxy inverso frente al servidor de aplicaciones e implemente las funciones descritas más adelante. Entonces está en una buena posición para convertir su aplicación en microservicios.

La comunicación entre los microservicios se maneja a través de un mecanismo de su elección (kube-proxy, IPVS, etc.).

Diagrama de Unified Ingress con Citrix ADC VPX/MPX

Funcionalidad proporcionada en diferentes categorías

Las capacidades de la arquitectura Unified Ingress se dividen en tres grupos.

Las funciones del primer grupo optimizan el rendimiento:

  • Equilibrio de carga
  • Conectividad de baja latencia
  • Alta disponibilidad

Las funciones del segundo grupo mejoran la seguridad y facilitan la administración de aplicaciones:

  • Limitación de velocidad
  • Terminación de SSL/TLS
  • Soporte HTTP/2
  • Comprobaciones de estado

Las funciones del grupo final son específicas de los microservicios:

  • Punto central de comunicaciones para servicios
  • Capacidad de Gateway de API

Resumen

Las funciones del modelo de entrada unificado incluyen equilibrio de carga sólido para servicios, un punto de comunicación central, detección dinámica de servicios, conectividad de baja latencia, alta disponibilidad, limitación de velocidad, terminación de SSL/TLS, HTTP/2 y más.

El modelo Unified Ingress facilita la administración del tráfico, las solicitudes de equilibrio de carga y la respuesta dinámica a los cambios en la aplicación de microservicios back-end.

Las ventajas incluyen:

  • Los flujos de tráfico Norte-Sur son bien escalables, visibles para observación y supervisión, y proporcionan una entrega continua con herramientas como Spinnaker y Citrix ADM
  • Un solo nivel unifica al equipo de infraestructura que administra los servicios de red y plataforma, y reduce los saltos a una latencia menor
  • Adecuado para aplicaciones internas que no necesitan Web App Firewall y descarga SSL, pero se pueden agregar más adelante

Las desventajas incluyen:

  • No hay seguridad Este-Oeste con kube-proxy, pero puede agregar Calico para la segmentación L4
  • Se desconoce la escalabilidad de Kube-proxy
  • No se limita a la visibilidad del tráfico Este-Oeste ya que kube-proxy no proporciona visibilidad, control o registros, lo que reduce la integración de herramientas abiertas y la entrega continua
  • El equipo de la plataforma también debe ser experto en redes

Entrada de 2 niveles de Citrix

El modelo arquitectónico de entrada de 2 niveles es una gran solución para principiantes nativos de la nube. En este modelo, el Citrix ADC de nivel 1 administra el tráfico entrante, pero envía solicitudes al ADC de 2 niveles administrado por los desarrolladores en lugar de directamente a las instancias de servicio. El modelo de entrada de nivel 2 aplica directivas, escritas por el equipo de Platform and Developers, solo al tráfico entrante, y habilita la escalabilidad y el multiarrendamiento en la nube.

Figura 1-4: Diagrama del modelo de entrada de dos niveles de Citrix con contenedores Citrix ADC VPX/MPX de nivel 1 y Citrix ADC CPX de nivel 2.

Funcionalidad proporcionada por el nivel 1

El ADC de primer nivel, administrado por el equipo de redes tradicional, proporciona equilibrio de carga de L4, Citrix Web App Firewall, descarga SSL y servicios de proxy inverso. Los dispositivos Citrix ADC MPX o VPX en el nivel 1 proxy el tráfico (Norte-Sur) desde el cliente a Citrix ADC CPxS en el nivel 2.

De forma predeterminada, Citrix Ingress Controller programará las siguientes configuraciones en el nivel 1:

  • Proxy inverso de aplicaciones a los usuarios:
  • Content Switching servidores virtuales
  • Servidor virtual (front-end, orientado al usuario)
  • Grupos de servicios
  • Descarga de SSL
  • Registro/Depuración de NetScaler
  • Vigilancia sanitaria de los servicios

Funcionalidad proporcionada por Tier-2

Mientras que el ADC de primer nivel proporciona servicios de proxy inverso, el ADC de segundo nivel, administrado por el equipo de la plataforma, sirve como punto de comunicación para los microservicios, proporcionando:

  • Descubrimiento dinámico de servicios
  • Equilibrio de carga
  • Visibilidad y métricas enriquecidas

A continuación, Citrix ADC CPX de nivel 2 enruta el tráfico a los microservicios del clúster de Kubernetes. El Controller de entrada de Citrix implementado como un pod independiente configura los dispositivos de nivel 1. Además, el Controller sidecar de uno o más pods de Citrix ADC CPX configura el Citrix ADC CPX asociado en el mismo pod.

Resumen

La arquitectura de red para microservicios en el modelo de 2 niveles utiliza dos ADC configurados para diferentes roles. El ADC de nivel 1 actúa como servidor proxy orientado al usuario y el ADC de nivel 2 como proxy para los microservicios.

Dividir diferentes tipos de funciones entre dos niveles diferentes proporciona velocidad, control y oportunidades para optimizar la seguridad. En el segundo nivel, el equilibrio de carga es rápido, robusto y configurable.

Con este modelo, hay una clara separación entre el administrador ADC y el desarrollador. Es BYOL para Desarrolladores.

Las ventajas incluyen:

  • Los flujos de tráfico Norte-Sur son bien escalables, visibles para observación y supervisión, y proporcionan una entrega continua con herramientas como Spinnaker y Citrix ADM
  • Implementación más simple y rápida para un principiante nativo en la nube con aprendizaje limitado para equipos de redes y plataformas

Las desventajas incluyen:

  • No hay seguridad Este-Oeste con kube-proxy, pero puede agregar Calico para la segmentación L4
  • Se desconoce la escalabilidad de Kube-proxy
  • No se limita a la visibilidad del tráfico Este-Oeste ya que kube-proxy no proporciona visibilidad, control o registros, lo que mitiga la integración de herramientas abiertas y la entrega continua.

Citrix Service Mesh Lite

El Service Mesh Lite es el más rico de funciones de los tres modelos. Es internamente seguro, rápido, eficiente y resistente, y se puede utilizar para aplicar directivas para el tráfico entrante y entre contenedores.

El modelo Service Mesh Lite es adecuado para varios casos de uso, que incluyen:

  • Aplicaciones de salud y finanzas: Los requisitos reglamentarios y de usuario exigen una combinación de seguridad y velocidad para aplicaciones financieras y de salud, con miles de millones de dólares en valor financiero y de reputación en juego.
  • Aplicaciones de comercio electrónico: La confianza del usuario es un gran problema para el comercio electrónico y la velocidad es un diferenciador competitivo clave. Por lo tanto, combinar velocidad y seguridad es crucial.

Diagrama del modelo Citrix Service Mesh Lite con un contenedor Citrix ADC VPX/MPX de nivel 1 y Citrix ADC CPX de nivel 2 para proxy Este-Oeste.

Resumen

Las ventajas incluyen:

  • Un enfoque más sólido para la red, con un equilibrador de carga CPX aplica directivas al tráfico entrante e intercontenedor, implementando directivas L7 completas
  • Observabilidad más rica, análisis, entrega continua y seguridad para el tráfico Norte-Sur y Este-Oeste
  • Canary para cada contenedor con Citrix ADC integrado
  • Un solo nivel unifica al equipo de infraestructura que administra los servicios de red y plataforma, y reduce los saltos a una latencia menor

Las desventajas incluyen:

  • Modelo más complejo para implementar
  • El equipo de la plataforma debe ser experto en redes

Resumen de Architecture Choices

Entrada unificada de Citrix

  • Tráfico de aplicaciones Norte-Sur (NS): un Citrix ADC es responsable del tráfico L4 y L7 NS, la seguridad y el equilibrio de carga externo fuera del clúster K8s.

  • Tráfico de aplicaciones Este-Oeste (EW): kube-proxy es responsable del tráfico L4 EW.

  • Seguridad: el ADC es responsable de proteger el tráfico NS y autenticar a los usuarios. Kube-proxy es responsable del tráfico L4 EW.

  • Escalabilidad y rendimiento : el tráfico NS es bien escalable, y la agrupación en clústeres es una opción.Se desconoce el tráfico de EW y la escalabilidad de kube-proxy.

  • Observabilidad: el ADC proporciona una excelente observabilidad para el tráfico NS, pero no hay observabilidad para el tráfico EW.

Entrada de 2 niveles de Citrix

  • Tráfico de aplicaciones Norte-Sur (NS): el ADC de nivel 1 es responsable de la descarga SSL, el Web App Firewall y el tráfico L4 NS. Se utiliza para aplicaciones monolito y CN. El CPX de nivel 2 Gestiona el rápido cambio de tráfico k8s y L7 NS.

  • Tráfico de aplicaciones Este-Oeste (EW): kube-proxy es responsable del tráfico L4 EW.

  • Seguridad: el ADC de nivel 1 es responsable de asegurar el tráfico NS. La autenticación puede ocurrir en cualquiera de los ADC. El tráfico EW no está asegurado con Kube-proxy.Add Calico para la segmentación L4.

  • Escalabilidad y rendimiento : el tráfico NS es bien escalable, y la agrupación en clústeres es una opción.Se desconoce el tráfico de EW y la escalabilidad de kube-proxy.

  • Observabilidad: el ADC de nivel 1 proporciona una excelente observabilidad para el tráfico NS, pero no hay observabilidad para el tráfico EW.

Citrix Service Mesh Lite

  • Tráfico de aplicaciones Norte-Sur (NS): el ADC de nivel 1 es responsable de la descarga SSL, el Web App Firewall y el tráfico L4 NS. Se utiliza para aplicaciones monolito y CN. El CPX de nivel 2 Gestiona el rápido cambio de tráfico k8s y L7 NS.

  • Tráfico de aplicaciones Este-Oeste (EW): el CPX de nivel 2 o cualquier proxy de código abierto es responsable del tráfico L4 EW. Los clientes pueden seleccionar qué aplicaciones usan CPX y cuáles usan kube-proxy.

  • Seguridad: el ADC de nivel 1 es responsable de asegurar el tráfico NS. La autenticación puede ocurrir en cualquiera de los ADC. Citrix CPX es responsable de la autenticación, la descarga SSL y la protección del tráfico EW. El cifrado se puede aplicar a nivel de aplicación.

  • Escalabilidad y rendimiento: El tráfico NS y EW es bien escalable, pero agrega 1 salto en línea.

  • Observabilidad: El ADC de nivel 1 proporciona una excelente observabilidad del tráfico NS. El CPX en el nivel 2 proporciona observabilidad del tráfico EW, pero se puede inhabilitar para reducir la memoria CPX o el espacio de CPU.

Cómo implementar

Entrada unificada de Citrix

Para validar una implementación de Citrix Unified Ingress con OpenShift, utilice una aplicación “hello-world” de ejemplo con Citrix ADC VPX o MPX. El espacio de nombres predeterminado para OpenShift, “default”, se utiliza para esta implementación.

  1. Una instancia de Citrix ADC se crea y configura manualmente con un NSIP/SNIP. Puede encontrar la instalación de Citrix ADC en XenServer aquí.

  2. Copie el siguiente ejemplo de archivo YAML en un directorio OpenShift y asígnele el nombre application.yaml.

    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-world
    spec:
      selector:
        matchLabels:
          run: load-balancer-example
      replicas: 2
      template:
        metadata:
          labels:
            run: load-balancer-example
        spec:
          containers:
            -  name: hello-world
              image: gcr.io/google-samples/node-hello:1.0
              ports:
                -  containerPort: 8080
                  protocol: TCP
    <!--NeedCopy-->
    
  3. Implemente la aplicación. oc apply -f application.yaml

  4. Asegúrese de que los pods estén funcionando. oc get pods

  5. Copie el siguiente ejemplo de archivo YAML en un directorio OpenShift y asígnele el nombre service.yaml.

    apiVersion: v1
    kind: Service
    metadata:
      name: hello-world-service
    spec:
      type: NodePort
      ports:
      -  port: 80
        targetPort: 8080
      selector:
        run: load-balancer-example
    <!--NeedCopy-->
    
  6. Exponga la aplicación a través de NodePort con un servicio. oc apply -f service.yaml

  7. Compruebe que se creó el servicio. oc get service

  8. Copie el siguiente ejemplo de archivo YAML en un directorio OpenShift y asígnele el nombre ingress.yaml.Debe cambiar la anotación “ingress.citrix.com/frontend-ip” a una dirección IP gratuita para convertirla en VIP en el Citrix ADC.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: hello-world-ingress
      annotations:
       kubernetes.io/ingress.class: "vpx"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.183"
    spec:
      rules:
      -  host:  helloworld.com
        http:
          paths:
          -  path:
            backend:
              serviceName: hello-world-service
              servicePort: 80
    <!--NeedCopy-->
    
  9. Implemente el archivo YAML de Ingress. oc apply -f ingress.yaml

  10. Ahora hay pods de aplicación que hemos expuesto mediante un servicio, y pueden enrutar el tráfico a ellos mediante Ingress. Instale Citrix Ingress Controller (CIC) para enviar estas configuraciones a nuestro ADC VPX de nivel 1 Antes de implementar el CIC, implemente un archivo RBAC que le otorgue al CIC los permisos correctos para ejecutarse.

    Nota:

    El archivo YAML de RBAC especifica el espacio de nombres y tendrá que ser cambiado, pendiente de qué espacio de nombres se está utilizando.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -  apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"]
        verbs: ["\*"]
      -  apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -  apiGroups: ["citrix.com"]
        resources: ["rewritepolicies"]
        verbs: ["\*"]
      -  apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
    
    <!--NeedCopy-->
    
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cpx
    subjects:
    -  kind: ServiceAccount
      name: cpx
      namespace: default
    
    <!--NeedCopy-->
    
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: default
    <!--NeedCopy-->
    
  11. Implemente el archivo RBAC. oc apply -f rbac.yaml

  12. Antes de implementar el CIC, modifique el archivo YAML. En especificación, agregue el NSIP o el SNIP siempre que la administración esté habilitada en el SNIP, del ADC de nivel 1. Observe que el argumento “ingress-classes” es el mismo que la anotación de clase de entrada especificada en el archivo YAML de entrada.

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-world-cic
      labels:
        app: hello-world-cic
    spec:
      serviceAccountName: cpx
      containers:
      -  name: hello-world-cic
        image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
        env:
         # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
         -  name: "NS_IP"
           value: "10.217.101.193"
         # Set username for Nitro
         # Set log level
         -  name: "NS_ENABLE_MONITORING"
           value: "NO"
         -  name: "NS_USER"
           value: "nsroot"
         -  name: "NS_PASSWORD"
           value: "nsroot"
         -  name: "EULA"
           value: "yes"
         -  name: "LOGLEVEL"
           value: "DEBUG"
        args:
          -  --ingress-classes
            vpx
          -  --feature-node-watch
            false
        imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    
  13. Despliega el CIC. oc apply -f cic.yaml

  14. Verifique que todos los pods se estén ejecutando. oc get pods

  15. Modifique el archivo de hosts en su equipo local con una entrada para helloworld.com y el VIP en el Citrix ADC especificado en el archivo YAML de Ingress.

  16. Navegue a helloworld.com en un explorador. “¡Hola, Kubernetes! “debería aparecer.

Nota:

Los siguientes son los comandos de eliminación

  • oc delete pods (pod name) -n (namespace name)
  • oc delete deployment (deployment name) -n (namespace name)
  • oc delete service (service name) -n (namespace name)
  • oc delete ingress (ingress name) -n (namespace name)
  • oc delete serviceaccounts (serviceaccounts name) -n (namespace name)

Entrada de 2 niveles de Citrix

Para validar una implementación de Citrix de entrada de dos niveles con OpenShift, use una aplicación de ejemplo “hello-world” con Citrix ADC VPX o MPX. Para esta implementación se utiliza el espacio de nombres predeterminado “Tier-2-adc”.**Nota: Al implementar pods, servicios e Ingress, el espacio de nombres debe especificarse mediante el parámetro “-n (nombre del espacio de nombres)”.

  1. Una instancia de Citrix ADC se crea y configura manualmente con un NSIP/SNIP.La instalación de Citrix ADC en XenServer se puede encontrar [aquí. Si la instancia ya estaba configurada, borre cualquier servidor virtual en Equilibrio de carga o Content Switching que se haya enviado al ADC para que no implemente hello-world como entrada unificada.

  2. Cree un espacio de nombres llamado “tier-2-adc”. oc create namespace tier-2-adc

  3. Copie el siguiente ejemplo de archivo YAML en un directorio OpenShift y llámelo application-2t.yaml.

    
    apiVersion: apps/v1
    kind: Deployment
    metadata:
      name: hello-world
    spec:
      selector:
        matchLabels:
          run: load-balancer-example
      replicas: 2
      template:
        metadata:
          labels:
            run: load-balancer-example
        spec:
          containers:
            -  name: hello-world
              image: gcr.io/google-samples/node-hello:1.0
              ports:
                -  containerPort: 8080
                  protocol: TCP
    
    <!--NeedCopy-->
    
  4. Implemente la aplicación en el espacio de nombres. oc apply -f application-2t.yaml -n tier-2-adc

  5. Asegúrese de que los pods estén funcionando. oc get pods

  6. Copie el siguiente ejemplo de archivo YAML en un directorio OpenShift y llámelo service-2t.yaml.

    
    apiVersion: v1
    kind: Service
    metadata:
      name: hello-world-service-2
    spec:
      type: NodePort
      ports:
    
      -port: 80
        targetPort: 8080
      selector:
        run: load-balancer-example
    
    <!--NeedCopy-->
    
  7. Exponga la aplicación a través de NodePort con un servicio. oc apply -f service-2t.yaml -n tier-2-adc

  8. Compruebe que se creó el servicio. oc get service -n tier-2-adc

  9. Copie el siguiente ejemplo de archivo YAML en un directorio OpenShift y llámelo ingress-2t.yaml.

    
        apiVersion: extensions/v1beta1
        kind: Ingress
        metadata:
          name: hello-world-ingress-2
          annotations:
           kubernetes.io/ingress.class: "cpx"
        spec:
          backend:
            serviceName: hello-world-service-2
            servicePort: 80
    
    <!--NeedCopy-->
    
  10. Implemente el archivo YAML de Ingress. oc apply -f ingress-2t.yaml -n tier-2-adc

  11. Implemente un archivo RBAC que proporcione al CIC y CPX los permisos correctos para ejecutarse.

    Nota:

    El archivo rbac yaml especifica el espacio de nombres y tendrá que ser cambiado, pendiente de qué espacio de nombres se está utilizando.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "nodes", "routes", "routes/status", "tokenreviews", "subjectaccessreviews"]
        verbs: ["\*"]
      -apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -apiGroups: ["citrix.com"]
        resources: ["rewritepolicies"]
        verbs: ["\*"]
      -apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cpx
    subjects:
    -  kind: ServiceAccount
      name: cpx
      namespace: tier-2-adc
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: tier-2-adc
    <!--NeedCopy-->
    
  12. Implemente el archivo RBAC. oc apply -f rbac-2t.yaml

  13. La cuenta de servicio necesita permisos elevados para crear un CPX. oc adm policy add-scc-to-user privileged system:serviceaccount:tier-2-adc:cpx

  14. Modifique el archivo CPX YAML y llámelo cpx-2t.yaml. Esto implementa el CPX y el servicio que lo expone. Observe que el argumento para Ingress Class coincide con la anotación en el archivo ingress-2t.yaml.

        apiVersion: extensions/v1beta1
        kind: Deployment
        metadata:
          name: hello-world-cpx-2
        spec:
          replicas: 1
          template:
            metadata:
              name: hello-world-cpx-2
              labels:
                app: hello-world-cpx-2
                app1: exporter
              annotations:
                NETSCALER_AS_APP: "True"
            spec:
              serviceAccountName: cpx
              containers:
                -  name: hello-world-cpx-2
                  image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28"
                  securityContext:
                     privileged: true
                  env:
                  -  name: "EULA"
                  value: "yes"
                  -  name: "KUBERNETES_TASK_ID"
                    value: ""
                  imagePullPolicy: Always
            # Add cic as a sidecar
                -  name: cic
                  image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
                  env:
                  -  name: "EULA"
                    value: "yes"
                  -  name: "NS_IP"
                    value: "127.0.0.1"
                  -  name: "NS_PROTOCOL"
                    value: "HTTP"
                  -  name: "NS_PORT"
                    value: "80"
                  -  name: "NS_DEPLOYMENT_MODE"
                    value: "SIDECAR"
                  -  name: "NS_ENABLE_MONITORING"
                    value: "YES"
                  -  name: POD_NAME
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.name
                  -  name: POD_NAMESPACE
                    valueFrom:
                      fieldRef:
                        apiVersion: v1
                        fieldPath: metadata.namespace
                  args:
                    -  --ingress-classes
                      cpx
                  imagePullPolicy: Always
            apiVersion: v1
            kind: Service
            metadata:
              name: lb-service-cpx
              labels:
                app: lb-service-cpx
            spec:
              type: NodePort
              ports:
              -  port: 80
                protocol: TCP
                name: http
                targetPort: 80
              selector:
                app: hello-world-cpx-2
    
    <!--NeedCopy-->
    
  15. Implemente el CPX. oc apply -f cpx-2t.yaml -n tier-2-adc

  16. Verifique que el pod se esté ejecutando y que se haya creado el servicio. oc get pods -n tier-2-adc oc get service -n tier-2-adc

  17. Cree una entrada para enrutar desde la VPX a la CPX. La IP front-end debe ser una IP libre en el ADC. Asigne un nombre al archivo: ingress-cpx-2t.yaml.

    
    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: hello-world-ingress-vpx-2
      annotations:
       kubernetes.io/ingress.class: "helloworld"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.183"
    spec:
      rules:
        -  host:  helloworld.com
    
        http:
          paths:
          -  path:
            backend:
              serviceName: lb-service-cpx
              servicePort: 80
    <!--NeedCopy-->
    
  18. Implemente la entrada. oc apply -f ingress-cpx-2t.yaml -n tier-2-adc

  19. Antes de implementar el CIC, modifique el archivo YAML. En especificación, agregue el NSIP o el SNIP siempre que la administración esté habilitada en el SNIP, del ADC de nivel 1.

    apiVersion: v1
    kind: Pod
    metadata:
      name: hello-world-cic
      labels:
        app: hello-world-cic
    spec:
          serviceAccountName: cpx
          containers:
          -  name: hello-world-cic
            image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
            env:
             # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
             -  name: "NS_IP"
           value: "10.217.101.176"
         # Set username for Nitro
         # Set log level
         -  name: "NS_ENABLE_MONITORING"
           value: "NO"
         -  name: "NS_USER"
           value: "nsroot"
         -  name: "NS_PASSWORD"
           value: "nsroot"
         -  name: "EULA"
           value: "yes"
         -  name: "LOGLEVEL"
           value: "DEBUG"
        args:
          -  --ingress-classes
            helloworld
          -  --feature-node-watch
            false
        imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    
  20. Despliega el CIC. oc apply -f cic-2t.yaml -n tier-2-adc

  21. Verifique que todos los pods se estén ejecutando. oc get pods -n tier-2-adc

  22. Modifique el archivo de hosts en su equipo local con una entrada para helloworld.com y el VIP en el Citrix ADC especificado en el archivo YAML de entrada que enruta desde VPX a CPX.

  23. Navegue a helloworld.com en un explorador. “¡Hola, Kubernetes! “debería aparecer.

Citrix Service Mesh Lite

Service Mesh Lite permite la introducción de CPX (u otros dispositivos Citrix ADC) como reemplazo de las funcionalidades integradas de HAProxy. Esto nos permite ampliar nuestras capacidades N/S en Kubernetes y proporcionar equilibrio de carga de tráfico E/W, enrutamiento y observabilidad también. Citrix ADC (MPX, VPX o CPX) puede proporcionar tales beneficios para el tráfico E-W, tales como:

  • Descarga de TLS o SSL mutua
  • Enrutamiento basado en contenido para permitir o bloquear el tráfico basado en parámetros de encabezado HTTP o HTTPS
  • Algoritmos avanzados de equilibrio de carga (por ejemplo, menos conexiones, menos tiempo de respuesta, etc.)
  • Observabilidad del tráfico este-oeste mediante la medición de señales doradas (errores, latencias, saturación o volumen de tráfico) .El gráfico de servicio de Citrix ADM es una solución de observabilidad para supervisar y depurar microservicios.
  • En este caso de implementación implementamos la aplicación Bookinfo y observamos cómo funciona de forma predeterminada. Luego pasamos a ripear y reemplazar los servicios Kubernetes predeterminados y usamos CPX y VPX para proxy nuestro tráfico E/W.

Citrix Service Mesh Lite con CPX

Para validar una implementación de Citrix Unified Ingress con OpenShift, utilice una aplicación “hello-world” de ejemplo con Citrix ADC VPX o MPX. El espacio de nombres predeterminado para OpenShift, “default”, se utiliza para esta implementación.

  1. Una instancia de Citrix ADC se crea y configura manualmente con un NSIP/SNIP. Puede encontrar la instalación de Citrix ADC en XenServer aquí.

  2. Cree un espacio de nombres para esta implementación. En este ejemplo, sml se utiliza. oc create namespace sml

  3. Copie el siguiente YAML para crear la implementación y los servicios para Bookinfo. Llámelo bookinfo.yaml.

 ##################################################################################################
 # Details service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: details
   labels:
     app: details
     service: details
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: details
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: details-v1
   labels:
     app: details
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: details
         version: v1
     spec:
       containers:
       -  name: details
         image: docker.io/maistra/examples-bookinfo-details-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
 ##################################################################################################
 # Ratings service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: ratings
   labels:
     app: ratings
     service: ratings
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: ratings
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: ratings-v1
   labels:
     app: ratings
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: ratings
         version: v1
     spec:
       containers:
       -  name: ratings
         image: docker.io/maistra/examples-bookinfo-ratings-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
 ##################################################################################################
 # Reviews service
 ##################################################################################################
 apiVersion: v1
 kind: Service
 metadata:
   name: reviews
   labels:
     app: reviews
     service: reviews
 spec:
   ports:
   -  port: 9080
     name: http
   selector:
     app: reviews
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
   name: reviews-v1
   labels:
     app: reviews
     version: v1
 spec:
   replicas: 1
   template:
     metadata:
       annotations:
         sidecar.istio.io/inject: "false"
       labels:
         app: reviews
         version: v1
     spec:
       containers:
       -  name: reviews
         image: docker.io/maistra/examples-bookinfo-reviews-v1:0.12.0
         imagePullPolicy: IfNotPresent
         ports:
         -  containerPort: 9080
 ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: reviews-v2
      labels:
        app: reviews
        version: v2
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: reviews
            version: v2
        spec:
          containers:
          -  name: reviews
            image: docker.io/maistra/examples-bookinfo-reviews-v2:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
 ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: reviews-v3
      labels:
        app: reviews
        version: v3
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: reviews
            version: v3
        spec:
          containers:
          -  name: reviews
            image: docker.io/maistra/examples-bookinfo-reviews-v3:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
    ---
    ##################################################################################################
    # Productpage services
    ##################################################################################################
    apiVersion: v1
    kind: Service
    metadata:
      name: productpage-service
    spec:
      type: NodePort
      ports:
      -  port: 80
        targetPort: 9080
      selector:
        app: productpage
    ---
    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: productpage-v1
      labels:
        app: productpage
        version: v1
    spec:
      replicas: 1
      template:
        metadata:
          annotations:
            sidecar.istio.io/inject: "false"
          labels:
            app: productpage
            version: v1
        spec:
          containers:
          -  name: productpage
            image: docker.io/maistra/examples-bookinfo-productpage-v1:0.12.0
            imagePullPolicy: IfNotPresent
            ports:
            -  containerPort: 9080
    ---
<!--NeedCopy-->
  1. Implemente el bookinfo.yaml en el espacio de nombres sml. oc apply -f bookinfo.yaml -n sml

  2. Copie e implemente el archivo de entrada que se asigna al servicio de páginas del producto. Este archivo puede denominarse ingress-productpage.yaml. La IP de front-end debe ser una IP virtual gratuita en Citrix ADC VPX/MPX.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: productpage-ingress
      annotations:
       kubernetes.io/ingress.class: "bookinfo"
       ingress.citrix.com/insecure-termination: "redirect"
       ingress.citrix.com/frontend-ip: "10.217.101.182"
    spec:
      rules:
      -  host: bookinfo.com
        http:
          paths:
          -  path:
            backend:
              serviceName: productpage-service
              servicePort: 80
    <!--NeedCopy-->
    

oc apply -f ingress-productpage.yaml -n sml

  1. Copie el siguiente YAML para el archivo RBAC en el espacio de nombres sml e implemente. Asigne un nombre al archivo rbac-cic-pp.yaml tal como se utiliza para el CIC delante del microservicio de página del producto.

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    rules:
      -  apiGroups: [""]
        resources: ["services", "endpoints", "ingresses", "pods", "secrets", "routes", "routes/status", "nodes", "namespaces"]
        verbs: ["\*"]
      -  apiGroups: ["extensions"]
        resources: ["ingresses", "ingresses/status"]
        verbs: ["\*"]
      -  apiGroups: ["citrix.com"]
        resources: ["rewritepolicies", "vips"]
        verbs: ["\*"]
      -  apiGroups: ["apps"]
        resources: ["deployments"]
        verbs: ["\*"]
      -  apiGroups: ["apiextensions.k8s.io"]
        resources: ["customresourcedefinitions"]
        verbs: ["get", "list", "watch"]
    ---
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1beta1
    metadata:
      name: cpx
    roleRef:
      apiGroup: rbac.authorization.k8s.io
      kind: ClusterRole
      name: cpx
    subjects:
    -  kind: ServiceAccount
      name: cpx
      namespace: sml
    apiVersion: rbac.authorization.k8s.io/v1
    ---
    apiVersion: v1
    kind: ServiceAccount
    metadata:
      name: cpx
      namespace: sml
    <!--NeedCopy-->
    

oc apply -f rbac-cic-pp.yaml -n sml

  1. Elevar los privilegios de la cuenta de servicio para implementar CIC y CPX. oc adm policy add-scc-to-user privileged system:serviceaccount:sml:cpx

  2. Modifique el archivo de hosts en el equipo local con bookinfo.com asignado a la IP de front-end especificada en ingress-productpage.yaml.

  3. Copie e implemente la página del producto con un CIC. Asigne un nombre al archivo cic-productpage.yaml. El NS_IP debe ser el NS_IP del ADC de nivel 1.

    apiVersion: v1
    kind: Pod
    metadata:
      name: productpage-cic
      labels:
        app: productpage-cic
    spec:
          serviceAccountName: cpx
          containers:
          -  name: productpage-cic
            image: "quay.io/citrix/citrix-k8s-ingress-controller:1.1.3"
            env:
             # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled)
             -  name: "NS_IP"
               value: "10.217.101.176"
             # Set username for Nitro
             # Set log level
             -  name: "NS_ENABLE_MONITORING"
               value: "NO"
             -  name: "NS_USER"
               value: "nsroot"
             -  name: "NS_PASSWORD"
               value: "nsroot"
             -  name: "EULA"
               value: "yes"
             -  name: "LOGLEVEL"
               value: "DEBUG"
             -  name: "NS_APPS_NAME_PREFIX"
               value: "BI-"
            args:
              -  --ingress-classes
                bookinfo
              -  --feature-node-watch
                false
            imagePullPolicy: IfNotPresent
    <!--NeedCopy-->
    

oc apply -f cic-productpage.yaml -n sml

  1. Navegue a bookinfo.com y haga clic en el usuario normal. La página del producto debe obtener detalles, reseñas y calificaciones, que son otros microservicios. HAProxy es responsable de enrutar el tráfico entre microservicios (Este-Oeste).

  2. Elimine el servicio delante de los detalles. Actualice la página web Bookinfo y observe que la página del producto no pudo extraer el microservicio para obtener más detalles. oc delete service details -n sml

  3. Copie e implemente un servicio sin cabeza para que el tráfico procedente de la página del producto a los detalles pase a través de un CPX. Llame a este archivo detailsheadless.yaml.

    apiVersion: v1
    kind: Service
    metadata:
      name: details
    spec:
      ports:
      -  port: 9080
        name: http
      selector:
        app: cpx
    <!--NeedCopy-->
    

oc apply -f detailsheadless.yaml -n sml

  1. Copiar e implementar un nuevo servicio de detalles, que debe ser nombres detailsservice.yaml, para sentarse frente al microservicio de detalles.

    apiVersion: v1
    kind: Service
    metadata:
      name: details-service
      labels:
        app: details-service
        service: details-service
    spec:
      clusterIP: None
      ports:
      -  port: 9080
        name: http
      selector:
        app: details
    <!--NeedCopy-->
    

oc apply -f detailsservice.yaml -n sml

  1. Exponga el servicio de detalles con una entrada e implemente. Llame a este archivo detailsingress.yaml.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: details-ingress
      annotations:
       kubernetes.io/ingress.class: "cpx"
       ingress.citrix.com/insecure-port: "9080"
    spec:
      rules:
      -  host: details
        http:
          paths:
          -  path:
            backend:
              serviceName: details-service
              servicePort: 9080
    <!--NeedCopy-->
    

oc apply -f detailsingress.yaml -n sml

  1. Copie e implemente el archivo CPXEastWest.yaml.

    apiVersion: extensions/v1beta1
    kind: Deployment
    metadata:
      name: cpx
      labels:
        app: cpx
        service: cpx
    spec:
      replicas: 1
      template:
        metadata:
          name: cpx
          labels:
            app: cpx
            service: cpx
          annotations:
            NETSCALER_AS_APP: "True"
        spec:
          serviceAccountName: cpx
          containers:
            -  name: reviews-cpx
              image: "quay.io/citrix/citrix-k8s-cpx-ingress:13.0-36.28"
              securityContext:
                 privileged: true
              env:
              -  name: "EULA"
                value: "yes"
              -  name: "KUBERNETES_TASK_ID"
                value: ""
              -  name: "MGMT_HTTP_PORT"
                value: "9081"
              ports:
              -  name: http
                containerPort: 9080
              -  name: https
                containerPort: 443
              -  name: nitro-http
                containerPort: 9081
              -  name: nitro-https
                containerPort: 9443
              imagePullPolicy: Always
            # Add cic as a sidecar
            -  name: cic
              image: "quay.io/citrix/citrix-k8s-ingress-controller:1.2.0"
              env:
              -  name: "EULA"
                value: "yes"
              -  name: "NS_IP"
                value: "127.0.0.1"
              -  name: "NS_PROTOCOL"
                value: "HTTP"
              -  name: "NS_PORT"
                value: "80"
              -  name: "NS_DEPLOYMENT_MODE"
                value: "SIDECAR"
              -  name: "NS_ENABLE_MONITORING"
                value: "YES"
              -  name: POD_NAME
                valueFrom:
                  fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.name
              -  name: POD_NAMESPACE
                valueFrom:
                  fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.namespace
              args:
                -  --ingress-classes
                  cpx
              imagePullPolicy: Always
    <!--NeedCopy-->
    

oc apply -f CPXEastWest.yaml -n sml

  1. Actualizar bookinfo.com y los detalles deben extraerse de los detalles Microservice.A CPX se implementó correctamente para proxy tráfico EW.

Citrix Service Mesh Lite con un VPX/MPX

  1. Ejecute los siguientes comandos para eliminar el CPX que se está utilizando como proxy EW. Se implementa un nuevo archivo para configurar el VPX como el proxy EW entre la página del producto y los microservicios de detalles. oc delete -f detailsheadless.yaml -n sml oc delete -f detailsservice.yaml -n sml oc delete -f detailsingress.yaml -n sml oc delete -f CPXEastWest.yaml -n sml

  2. Copie e implemente un servicio, nombre al archivo DetailsToVPX.yaml, para enviar tráfico desde la página del producto de vuelta al VPX. El parámetro IP debe ser un VIP gratuito en Citrix ADC VPX/MPX.

    ---
    kind: "Service"
    apiVersion: "v1"
    metadata:
      name: "details"
    spec:
      ports:
        -
          name: "details"
          protocol: "TCP"
          port: 9080
    ---
    kind: "Endpoints"
    apiVersion: "v1"
    metadata:
      name: "details"
    subsets:
      -
        addresses:
          -
            ip: "10.217.101.182" # Ingress IP in MPX
        ports:
          -
            port: 9080
            name: "details"
    <!--NeedCopy-->
    

oc apply -f detailstoVPX.yaml -n sml

  1. Vuelva a implementar el detailsservice.yaml delante del microservicio de detalles. oc apply -f detailsservice.yaml -n sml

  2. Copie e implemente el Ingress para exponer el microservicio de detalles al VPX. Esto se llama detailsVPXingress.yaml. La IP de front-end debe coincidir con la VIP en el ADC de nivel 1.

    apiVersion: extensions/v1beta1
    kind: Ingress
    metadata:
      name: details-ingress
      annotations:
       kubernetes.io/ingress.class: "vpx"
       ingress.citrix.com/insecure-port: "9080"
       ingress.citrix.com/frontend-ip: "10.217.101.182"
    spec:
      rules:
      -  host: details
        http:
          paths:
          -  path:
            backend:
              serviceName: details-service
              servicePort: 9080
    <!--NeedCopy-->
    

oc apply -f detailsVPXingress.yaml

  1. Actualizar bookinfo.com y los detalles deben extraerse del microservicio de detalles. Se implementó correctamente un VPX para proxy tráfico EW.

Migración de servicios a Citrix ADC mediante rutas o clases de entrada en OpenShift

Migración de servicios con fragmentación de rutas

Citrix Ingress Controller (CIC) actúa como enrutador y redirige el tráfico a varios pods para distribuir el tráfico entrante entre varios pods disponibles.

Este proceso de migración también puede formar parte de un proceso de actualización de clústeres desde topologías OpenShift heredadas hasta implementaciones automatizadas con componentes Citrix CNC, CIC y CPX para los procedimientos de migración y actualización de clústeres.

Esta solución se puede obtener por dos métodos:

  • Enrutador CIC por plug-in (pod)
  • Router CPX dentro OpenShift (Sidecar)

Ambos métodos se describen a continuación junto con ejemplos de migración.

Rutas estáticas (por defecto): Asigna la subred OpenShift HostSubnet al ADC externo a través de una ruta estática.

Las rutas estáticas son comunes en implementaciones heredadas de OpenShift mediante HAProxy. Las rutas estáticas se pueden utilizar en paralelo con Citrix CNC, CIC y CPX al migrar servicios de un proxy de servicio a otro sin interrumpir los espacios de nombres implementados en un clúster en funcionamiento.

Ejemplo de configuración de ruta estática para Citrix ADC:

oc get hostsubnet (OpenShift Cluster) snippet
    oc311-master.example.com 10.x.x.x 10.128.0.0/23
    oc311-node1.example.com 10.x.x.x 10.130.0.0/23
    oc311-node2.example.com 10.x.x.x 10.129.0.0/23

show route (external Citrix VPX) snippet
    10.128.0.0 255.255.254.0 10.x.x.x STATIC
    10.129.0.0 255.255.254.0 10.x.x.x STATIC
    10.130.0.0 255.255.254.0 10.x.x.x STATIC

Rutas automáticas: Utiliza el CNC (Citrix Node Controller) para automatizar las rutas externas a los fragmentos de ruta definidos

Puede integrar Citrix ADC con OpenShift de dos maneras, ambas compatibles con la fragmentación del router OpenShift.

Tipos de ruta

  • unsecured: Equilibrador de carga externo al enrutador CIC, el tráfico HTTP no está cifrado.
  • secured-edge: Equilibrador de carga externo al enrutador CIC que termina TLS.
  • secured-passthrough: Equilibrador de carga externo al destino que termina TLS
  • secured reencrypt: Equilibrador de carga externo al router CIC que termina TLS. Enrutador CIC cifrado a destino mediante TLS.

Ejemplo de implementación #1: CIC implementado como un complemento de enrutador OpenShift

Para Routes, usamos conceptos de Route Sharding. Aquí, el CIC actúa como un router y redirige el tráfico a varios pods para distribuir el tráfico entrante entre varios pods disponibles. El CIC se instala como un complemento de enrutador para Citrix ADC MPX o VPX, implementado fuera del clúster.

Componentes de Citrix:

  • VPX: ADC de entrada que presenta los servicios de clúster a DNS.
  • CIC: Proporciona ROUTE_LABELS y NAMESPACE_LABELS al Citrix ADC externo a través de la ruta CNC.

Parámetros de archivo YAML de ejemplo para fragmentos de ruta:

Los archivos fuente de Citrix OpenShift se encuentran en Github aquí

  1. Agregue las siguientes variables de entorno, ROUTE_LABELS y NAMESPACE_LABELS, con el valor en formato de etiqueta kubernetes. Las expresiones de fragmentación de ruta en CIC, NAMESPACE_LABELS, son un campo opcional. Si se utiliza, debe coincidir con las etiquetas del espacio de nombres que se mencionan en el archivo route.yaml.
        env:
         - name: "ROUTE_LABELS"
           value: "name=apache-web"
         - name: "NAMESPACE_LABELS"
           value: "app=hellogalaxy"

<!--NeedCopy-->
  1. Las rutas que se crean a través de route.yaml tendrán etiquetas que coincidan con las expresiones de fragmentación de ruta en el CIC se configurarán.
        metadata:
            name: apache-route
            namespace: hellogalaxy
            labels:
                name: apache-web
<!--NeedCopy-->
  1. Exponga el servicio con service.yaml.
        metadata:
            name: apache-service
        spec:
        type: NodePort
        #type=LoadBalancer
        ports:
            - port: 80
        targetPort: 80
        selector:
            app: apache
<!--NeedCopy-->
  1. Implemente una aplicación web simple con una etiqueta de selector que coincida con la del service.yaml.

Ejemplo de implementación #2: Citrix ADC CPX implementado como enrutador OpenShift

Citrix ADC CPX se puede implementar como un enrutador OpenShift, junto con Citrix Ingress Controller dentro del clúster. Para obtener más pasos sobre la implementación de un CPX o CIC como enrutador en el clúster, consulte Habilitar la compatibilidad con la partición de enrutamiento OpenShift con Citrix ADC.

Componentes de Citrix:

  • VPX: ADC de entrada que presenta los servicios de clúster a DNS.
  • CIC: Proporciona ROUTE_LABELS y NAMESPACE_LABELS al Citrix ADC externo para definir los fragmentos de ruta.
  • CNC: Proporciona la configuración de enrutamiento automático para fragmentos al equilibrador de carga externo.
  • CPX: Proporciona enrutamiento OpenShift dentro del clúster OpenShift.

Migración de servicios con anotación de clases de entrada

Anotaciones de clases de entrada utiliza el concepto de anotación de clases de entrada, agregamos anotaciones a Ingress con información de clase de entrada, esto ayudará a redirigir el tráfico a un pod/nodo particular desde el ADC externo.

Parámetros de archivo YAML de ejemplo para clases de entrada:**

Los archivos fuente de Citrix Ingress se encuentran en Github aquí

    env:
        args:
          - --ingress-classes
            vpx
<!--NeedCopy-->

El archivo de configuración de Ingress también debe tener un campo de anotaciones kubernetes.io/ingress.class dentro de los metadatos que se asociarán con el campo CIC ingress-classes args, en el momento de la creación.

Ejemplo de implementación VPX de Ingress con el ejemplo**“ingress.classes”

        kind: Ingress
            metadata:
                name: ingress-vpx
                annotations:
                    kubernetes.io/ingress.class: "vpx"
<!--NeedCopy-->

Exportador de métricas de Citrix

Puede utilizar el exportador de métricas de Citrix ADC y Prometheus-Operator para supervisar los dispositivos de entrada de Citrix ADC VPX o CPX y los dispositivos Citrix ADC CPX (este-oeste). Consulte Ver métricas de ADC de Citrix mediante Prometheus y Grafana.