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

El Citrix ADC Stack cumple con los requisitos básicos de las funciones de disponibilidad de las aplicaciones (ADC), la segregación de funciones de seguridad (WAF), el escalado de topologías de aplicaciones ágiles (SSL y GSLB) y la observabilidad proactiva (Service Graph) en un entorno altamente orquestado de la era nativa de la nube.

La transformación digital está impulsando la necesidad de trasladar las implementaciones de aplicaciones modernas a arquitecturas basadas en microservicios. Estas arquitecturas nativas de la nube aprovechan contenedores de aplicaciones, microservicios y Kubernetes.

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

La nueva era de la implementación de aplicaciones modernas también ha cambiado las disciplinas del modelo de negocio de los centros de datos tradicionales, incluidas las versiones y contratos de software mensuales y anuales, los recursos y el presupuesto de cómputos de silo y el modelo de consumo de proveedores.

Y si bien toda esta modernización se produce en el ecosistema, aún existen requisitos básicos para las funciones de disponibilidad de las aplicaciones (ADC), la segregación de funciones de seguridad (WAF), el escalado de topologías de aplicaciones ágiles (SSL y GSLB) y la observabilidad proactiva (Service Graph) en un sistema altamente orquestado medio ambiente.

Por qué Citrix para la entrega de aplicaciones modernas

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

La 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 se puede actualizar 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 y Fix.

La entrega continua (CD) integra la canalización de implementación directamente en el proceso de desarrollo de la CI, optimizando y mejorando así el modelo de entrega de software para las aplicaciones modernas.

Los ADC de Citrix se integran en el proceso de entrega continua mediante la implementación de implementaciones progresivas automatizadas de Canary Analytics

Una solución para todas las partes interesadas

Citrix ha creado una solución basada en software dedicada que aborda los requisitos multifuncionales 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 de entrega y disponibilidad común a todos los miembros involucrados en la CI/CD, estos recursos generalmente se definen como las “partes interesadas” de la unidad de negocio y, aunque cada parte interesada es invertido en el éxito general de la organización, cada parte interesada generalmente tiene requisitos y diferencias distintos.

Algunos ejemplos comunes de partes interesadas en la actividad de entrega moderna incluyen:

  • Equipo de plataformas: Implemente la infraestructura del centro de datos, como IaaS, PaaS, SDN, ADC y 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 confiabilidad de servicios (SRE): reduzca los silos organizacionales, la administración de errores, la automatización de la implementación y las medidas
  • Equipo de operaciones de seguridad: Directivas de seguridad proactivas, administración de incidentes, implementación de parches, fortalecimiento de portafolio

Explicación de la pila de software Citrix

Base de código única: Todo es el mismo código para usted : Implementaciones locales, implementaciones en la nube pública, implementaciones en la nube privada, implementaciones en la nube de GOV

  • Selección de plataformas: Para cumplir con cualquier requisito ágil, elija cualquier modelo de Citrix ADC

    • CPX: Citrix ADC CPX es un Citrix ADC que se entrega como un 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 ofrecen un rendimiento que varía de 10 MB/s a 100 Gb/s.
    • MPX: Citrix ADC MPX es un dispositivo de entrega de aplicaciones basado en hardware que ofrece un rendimiento que varía de 500 MB/s a 200 Gb/s.
    • SDX: El dispositivo Citrix ADC SDX es una plataforma multiusuario en la que puede aprovisionar y administrar varias máquinas Citrix ADC virtuales (instancias).
    • BLX: El dispositivo Citrix ADC BLX es un factor de forma de software de Citrix ADC. Está diseñado para ejecutarse de forma nativa en Linux desnudo en servidores comerciales listos para usar (COTS) Entornos en contenedores - Cree superposiciones y configure automáticamente su Citrix ADC
    • Citrix Ingress Controller - Creado en torno a Kubernetes Ingress y configura automáticamente uno o más Citrix ADC según la configuración de recursos de Ingress
    • Citrix Node Controller - Cree una red superpuesta basada en VXLAN entre los nodos de Kubernetes y el Citrix ADC de Ingress
    • Citrix IPAM Controller - 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) Capacidadagrupada Licencias - Una licencia global - El conjunto de licencias global ubicuo separa las plataformas y las licencias para lograr una flexibilidad total de diseño y rendimiento Application Delivery Manager: un panel único
    • administre la flota, organice directivas y aplicaciones, supervisión y solución de problemas en tiempo real
      Topologías flexibles: centro de datos tradicional o nubes modernas - Nivel único, dos niveles y malla de servicio lite

El valor de Citrix ADC

  • Integración de Kubernetes y CNCF Open Source Tools
  • The Perfect Proxy: Un controlador de entrega de aplicaciones de capa 7 que ha demostrado funcionar para aplicaciones modernas
    • Contenedor ADC de alto rendimiento en una implementación 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 de tráfico avanzada e implementación de Canary para CI/CD
  • Seguridad comprobada mediante TLS/SSL, WAF, DoS y protección de API
  • Capacidades enriquecidas de capa 7
  • Supervisión integrada para implementaciones de aplicaciones antiguas y modernas
  • Insights accionables y gráficos de servicio para la visibilidad

Los beneficios de Citrix ADC

  • Mueva las aplicaciones heredadas sin tener que volver a escribirlas
  • Los desarrolladores pueden proteger las aplicaciones con las directivas de Citrix ADC mediante las API de Kubernetes (mediante CRD, fáciles de usar para desarrolladores)
  • Implemente microservicios de alto rendimiento para Norte-Sur y Service Mesh
  • Utilice un gráfico de servicio de aplicaciones para todos los microservicios
  • Solucionar problemas de microservicios más rápido en TCP, UDP, HTTP/S, SSL
  • Proteja las API y configure con las API de Kubernetes
  • Mejorar el proceso CICD para implementaciones Canary

Componentes de arquitectura

Portafolio de soluciones de Citrix para aplicaciones nativas

La ventaja de Citrix ADC Suite

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

Citrix está validado. Las plantillas de diseño validadas y las aplicaciones de muestra permiten una referencia fácil de un estado y un requisito empresarial deseado para abordarlos de manera rápida y completa. Hemos documentado y publicado ejemplos de configuración en una ubicación central para facilitar la consulta entre los equipos de DevOps, SecOps y Platforms.

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

Citrix es transparente. Ayudar a los clientes a comprender nuestra integración con los ecosistemas de socios En este documento utilizamos tanto herramientas CNCF de código abierto como productos de nivel empresarial de Citrix.

Ecosistema de partners

En este tema se proporcionan detalles sobre varias plataformas de Kubernetes, topologías de implementación, funciones y CNI compatibles con implementaciones nativas de la nube, que incluyen Citrix ADC y Citrix Ingress Controller.

Citrix Ingress Controller es compatible con las siguientes plataformas:

  • Kubernetes v1.10 en bare metal o autohospedado en nubes públicas como AWS, GCP o Azure.
  • Motor de Google Kubernetes (GKE)
  • Servicio de Elastic Kubernetes (EKS)
  • Servicio Azure Kubernetes (AKS)
  • Red Hat OpenShift versión 3.11 y posteriores
  • Servicio de contenedores pivotales (PKS)
  • Plataforma Kubernetes empresarial Diamanti

Nuestro ecosistema de partners 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 multinube y el análisis Canary
  • Elasticsearch: Un servicio de búsqueda de aplicaciones o sitios
  • Kibana: Una herramienta de visualización de datos de búsqueda elástica y una herramienta de navegación de Elastic Stack
  • Fluentd: Una herramienta de recopilación de datos

El enfoque de la siguiente sección es el diseño y la arquitectura con OpenShift.

Resumen de OpenShift

Red Hat OpenShift es una plataforma de Kubernetes para implementaciones que se centran en el uso de microservicios y contenedores para crear y escalar aplicaciones con mayor rapidez. Al automatizar, instalar, actualizar y administrar la pila de contenedores, OpenShift optimiza Kubernetes y facilita las tareas diarias de DevOps.

  • Los desarrolladores proporcionan aplicaciones con acceso a soluciones validadas y socios que pasan 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.

Ilustración 1-6: Arquitectura de alto nivel de OpenShift.

Otras ventajas y componentes de OpenShift incluyen:

  • Elección de infraestructura
  • Nodos maestro y trabajador
  • Registro de imágenes
  • Capa de redirección y servicio
  • 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:

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

En este documento, analizamos cómo Citric ADC proporciona una integración sólida de la capa de redirección/servicio.

Proyectos OpenShift

El primer concepto nuevo que agrega OpenShift es project, que envuelve eficazmente un espacio de nombres, con el acceso al espacio de nombres que se controla a través del proyecto. El acceso se controla mediante un modelo de autenticación y autorización basado en usuarios y grupos. Por lo tanto, los proyectos de OpenShift proporcionan barreras entre los espacios de nombres, lo que garantiza que los usuarios o las aplicaciones solo puedan ver y acceder a lo que están autorizados.

Espacios de nombres OpenShift

El concepto de agrupamiento 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 los espacios de nombres en Kubernetes. Si es “usuario” de 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 llamado "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 permita la comunicación entre los pods en todo el clúster de OpenShift Container Platform. Esta red de cápsulas la establece y mantiene la SDN de OpenShift, que configura una red superpuesta mediante Open vSwitch (OVS).

OpenShift SDN proporciona tres complementos de SDN para configurar la red del pod:

  • El plug-in ovs-subnet es el plug-in original, que proporciona una red de cápsulas “plana” en la que cada pod puede comunicarse con todos los demás pods y servicios.
  • El plug-in ovs-multitenant proporciona aislamiento a nivel de proyecto para los pods y los servicios. Cada proyecto recibe un ID de red virtual (VNID) único que identifica el tráfico de los pods asignados al proyecto. Los pods de diferentes proyectos no pueden enviar paquetes 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 plug-in ovs-networkpolicy permite a los administradores de proyectos configurar sus propias directivas de aislamiento mediante objetos NetworkPolicy.

Routing y complementos de OpenShift

Un administrador de OpenShift puedeimplementar enrutadoresen un clúster de OpenShift, lo que permite que las rutascreadas por los desarrolladores sean utilizadas por clientes externos. La capa de redirección en OpenShift se puede conectar y se proporcionan y admiten doscomplementos de enrutadordisponibles de forma predeterminada.

Los routers OpenShift proporcionan asignación de nombres de host externos y equilibrio de carga a losserviciosa través de protocolos que pasan información distintiva directamente al router; el nombre de host debe estar presente en el protocolo para que el router determine dónde enviarlo.

Los complementos del enrutador asumen que pueden vincularse a los puertos host 80 y 443. Esto permite que el tráfico externo se dirija al host y, posteriormente, a través del router. Los routers también asumen que las redes están configuradas de manera que puedan acceder a todos los pods del clúster.

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

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

Rutas OpenShift y métodos de entrada

En un clúster de OpenShift, los clientes externos necesitan una forma de acceder a los servicios proporcionados por los pods.OpenShift proporciona dos recursos para comunicarse con los servicios que se ejecutan en el clúster: rutas e Ingress.

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 redirigen las solicitudes externas a los servicios dentro del clúster OpenShift de acuerdo con las reglas especificadas en las rutas. Cuando utiliza el enrutador OpenShift, también debe configurar el DNS externo para asegurarse de que el tráfico llega al enrutador.

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

El Citrix Ingress Controller admite las siguientes rutas de OpenShift:

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

Según cómo quiera utilizar Citrix ADC, hay dos formas de implementar Citrix Ingress Controller como un plug-in de enrutador en el clúster de OpenShift: como un Citrix ADC CPX dentro del clúster o como un Citrix ADC MPX/VPX fuera del clúster.

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

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

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

El Citrix ingress controller 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 una redirección fuera del clúster de OpenShift.

Ingreso

Kubernetes Ingress le proporciona una forma de redirigir las solicitudes a los servicios en función del host o la ruta de la solicitud, centralizando una serie de servicios en un único punto de entrada.

Citrix Ingress Controller se basa en Kubernetes Ingress y configura automáticamente uno o más dispositivos Citrix ADC en función del recurso Ingress.

La redirección con Ingress se puede realizar mediante:

  • Redirección basada en nombres de host
  • Redirección por rutas
  • Redirección basada en comodines
  • Coincidencia de ruta exacta
  • Redirección sin nombre de host
  • Backend predeterminado

Consulte Configuraciones de Ingress para ver ejemplos y más información.

Implementar el Citrix Ingress Controller como un plug-in de enrutador OpenShift

Según cómo quiera usar Citrix ADC, hay dos formas de implementar Citrix Ingress Controller como un plug-in 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
  • Servicio Mesh Lite de Citrix

Ilustración 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 envían por proxy el tráfico norte-sur de los clientes a las aplicaciones de nivel empresarial implementadas como microservicios dentro del clúster. El Citrix ingress controller se implementa como un 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 en los microservicios o los recursos de Ingress.

Puede empezar a implementar el modelo de ingreso unificado mientras su aplicación sigue siendo un monolito. Simplemente coloque el Citrix ADC como un proxy inverso delante del servidor de aplicaciones e implemente las funciones que se describen más adelante. De este modo, se encuentra en una buena posición para convertir su aplicación en microservicios.

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

Diagrama de ingreso unificado con un Citrix ADC VPX/MPX

Funcionalidad ofrecida 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 las 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 puerta de enlace de API

Resumen

Las funciones del modelo de ingreso unificado incluyen un sólido equilibrio de carga para los servicios, un punto de comunicación central, descubrimiento dinámico 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, el equilibrio de carga de las solicitudes y la respuesta dinámica a los cambios en la aplicación de microservicios de 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 para reducir la latencia
  • Adecuado para aplicaciones internas que no necesitan Web App Firewall ni descarga SSL, pero que se pueden agregar más adelante

Las desventajas incluyen:

  • No hay seguridad Este-Oeste con kube-proxy, pero se puede agregar Calico para la segmentación L4
  • La escalabilidad de Kube-proxy es desconocida
  • Hay una visibilidad limitada o nula del tráfico Este-Oeste, ya que kube-proxy no proporciona visibilidad, control ni registros, lo que mitiga 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 Ingress de 2 niveles es una excelente solución para los principiantes nativos de la nube. En este modelo, el Citrix ADC del nivel 1 administra el tráfico entrante, pero envía solicitudes al ADC de 2 niveles administrado por los desarrolladores en lugar de hacerlo directamente a las instancias de servicio. El modelo de Ingress de nivel 2 aplica directivas, redactadas por el equipo de plataformas y desarrolladores, solo al tráfico entrante y permite la escalabilidad en la nube y varios arrendatarios.

Ilustración 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 Tier-1

El ADC de primer nivel, administrado por el equipo de redes tradicional, proporciona equilibrio de carga L4, Citrix Web App Firewall, descarga de SSL y servicios de proxy inverso. Los dispositivos Citrix ADC MPX o VPX del nivel 1 envían por proxy el tráfico (norte-sur) del cliente a los CPX de Citrix ADC en el nivel 2.

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

  • Proxy inverso de aplicaciones para los usuarios:
  • Servidores virtuales de conmutación de contenido
  • Servidor virtual (front-end, orientado al usuario)
  • Grupos de servicios
  • Descarga de SSL
  • Depuración y registro de NetScaler
  • Monitorización 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 de servicios dinámico
  • Equilibrio de carga
  • Visibilidad y métricas completas

A continuación, Citrix ADC CPX de nivel 2 redirige el tráfico a los microservicios del clúster de Kubernetes. El Citrix Ingress Controller implementado como un pod independiente configura los dispositivos de nivel 1. Además, el controlador sidecar en 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 funciones diferentes. El ADC de nivel 1 actúa como un servidor proxy orientado al usuario y el ADC de nivel 2 como un proxy para los microservicios.

La división de 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, sólido y configurable.

Con este modelo, hay una clara separación entre el administrador de 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 de la nube con aprendizaje nuevo limitado para los equipos de redes y plataformas

Las desventajas incluyen:

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

Servicio Mesh Lite de Citrix

El Service Mesh Lite es el más rico en funciones de los tres modelos. Es internamente seguro, rápido, eficiente y resiliente, y se puede utilizar para hacer cumplir las directivas de tráfico entrante e intercontenedor.

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

  • Aplicaciones de salud y finanzas: Los requisitos reglamentarios y de los usuarios exigen una combinación de seguridad y rapidez para las 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 de los usuarios 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 un contenedor Citrix ADC CPX de nivel 2 para el proxy Este-Oeste.

Resumen

Las ventajas incluyen:

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

Las desventajas incluyen:

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

Resumen de las opciones de arquitectura

Entrada unificada de Citrix

  • Tráfico de aplicaciones norte-sur (NS): un Citrix ADC es responsable del tráfico NS de nivel 4 y L7, la seguridad y el equilibrio de carga externa fuera del clúster de K8s.

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

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

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

  • Observabilidad: E l 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): E l ADC de nivel 1 es responsable de la descarga SSL, el Web App Firewall y el tráfico L4 NS. Se utiliza tanto para aplicaciones monolíticas como CN. El CPX de nivel 2 administra el cambio rápido del tráfico NS k8 y L7.

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

  • Seguridad: E l 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 de EW no está protegido con Kube-Proxy.Agregue Calico para la segmentación L4.

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

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

Servicio Mesh Lite de Citrix

  • Tráfico de aplicaciones Norte-Sur (NS): E l ADC de nivel 1 es responsable de la descarga SSL, el Web App Firewall y el tráfico L4 NS. Se utiliza tanto para aplicaciones monolíticas como CN. El CPX de nivel 2 administra el cambio rápido del tráfico NS k8 y L7.

  • Tráfico de aplicaciones de este a oeste (EW): E l CPX de nivel 2 o cualquier proxy de código abierto es responsable del tráfico L4 EW. Los clientes pueden seleccionar qué aplicaciones utilizan CPX y cuáles utilizan kube-proxy.

  • Seguridad: E l 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 de SSL y la protección del tráfico de EW. El cifrado se puede aplicar a nivel de aplicación.

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

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

Cómo implementar

Entrada unificada de Citrix

Para validar una implementación de Citrix Unified Ingress con OpenShift, utilice un ejemplo de aplicación “hello-world” con un 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 a mano y se configura 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 de 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 de 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. Verifique que se haya creado el servicio. oc get service

  8. Copie el siguiente ejemplo de archivo YAML en un directorio de OpenShift y asígnele el nombre Ingress.yaml. Debe cambiar la anotación “ingress.citrix.com/frontend-ip” por una dirección IP libre para convertirse 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 redirigir 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 otorgue al CIC los permisos correctos para ejecutarse.

    Nota:

    El archivo rbac yaml especifica el espacio de nombres y tendrá que cambiarse, a la espera del espacio de nombres que 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. Según las especificaciones, 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 la clase de Ingress especificada en el archivo YAML de Ingress.

    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. Implemente el CIC. oc apply -f cic.yaml

  14. Verifica que todos los pods estén funcionando. oc get pods

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

  16. Vaya a helloworld.com en un explorador web. “Hello Kubernetes!” debería aparecer.

Nota: Los siguientes son 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 2 niveles de Ingress con OpenShift, utilice un ejemplo de aplicación “hello-world” con un Citrix ADC VPX o MPX. Para esta implementación se usa el espacio de nombres predeterminado “tier-2-adc”.**Nota: Al implementar pods, servicios e Ingress, el espacio de nombres debe especificarse con el parámetro “-n (nombre del espacio de nombres)”.

  1. Una instancia de Citrix ADC se crea a mano y se configura con un NSIP/SNIP.Puede encontrar la instalación de Citrix ADC en XenServer [aquí]. Si la instancia ya estaba configurada, elimine la implementación de hello-world como Unified Ingress de cualquier servidor virtual en Equilibrio de carga o Conmutación de contenido que se haya enviado al ADC.

  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. Verifique que se haya creado 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 dé a CIC y CPX los permisos correctos para ejecutarse.

    Nota:

    El archivo rbac yaml especifica el espacio de nombres y tendrá que cambiarse, en función del espacio de nombres que 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 de Ingress Class coincide con la anotación del 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 esté en ejecución y que se haya creado el servicio. oc get pods -n tier-2-adc oc get service -n tier-2-adc

  17. Cree un Ingress para redirigir desde el VPX al CPX. La IP de 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. Despliegue el Ingress. oc apply -f ingress-cpx-2t.yaml -n tier-2-adc

  19. Antes de implementar el CIC, modifique el archivo YAML. Según las especificaciones, 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. Implemente el CIC. oc apply -f cic-2t.yaml -n tier-2-adc

  21. Verifica que todos los pods estén funcionando. 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 redirige desde VPX a CPX.

  23. Vaya a helloworld.com en un explorador web. “Hello Kubernetes!” debería aparecer.

Servicio Mesh Lite de Citrix

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 de N/S en Kubernetes y también proporcionar equilibrio de carga de tráfico E/W, redirección y observabilidad. Citrix ADC (MPX, VPX o CPX) puede proporcionar beneficios para el tráfico E-W, tales como:

  • Descarga mutua de TLS o SSL
  • Redirección basada en contenido para permitir o bloquear el tráfico en función de los parámetros de encabezado HTTP o HTTPS
  • Algoritmos de equilibrio de carga avanzados (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). Service Graph 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, eliminamos y reemplazamos los servicios de Kubernetes predeterminados y usamos CPX y VPX para hacer proxy de nuestro tráfico E/W.

Citrix Service Mesh Lite con CPX

Para validar una implementación de Citrix Unified Ingress con OpenShift, utilice un ejemplo de aplicación “hello-world” con un 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 a mano y se configura 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 usa. oc create namespace sml

  3. Copia el siguiente YAML para crear la implementación y los servicios de Bookinfo. Denomínemlo 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 bookinfo.yaml en el espacio de nombres sml. oc apply -f bookinfo.yaml -n sml

  2. Copie e implemente el archivo Ingress que se asigna al servicio de la página del producto. Este archivo puede tener un nombre ingress-productpage.yaml. La IP de front-end debe ser un VIP gratuito en el 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 impleméntelo. Asigne un nombre al archivo rbac-cic-pp.yaml tal y como se usa para el CIC delante de la página del producto (microservicio).

    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. Aumente 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 interfaz especificada en ingress-productpage.yaml.

  3. Copie e implemente la página del producto con un CIC. Asigne un nombre cic-productpage.yamlal archivo. 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. Vaya a bookinfo.com y haga clic en usuario normal. La página del producto debe extraer detalles, reseñas y calificaciones, que son otros microservicios. HAProxy es responsable de redirigir el tráfico entre microservicios (Este-Oeste).

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

  3. Copie e implemente un servicio headless para que el tráfico que viene de la página del producto a los detalles pase por 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. Copie e implemente un nuevo servicio de detalles, que debería llamarse detailsservice.yaml, para que se sitúe al frente del 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 impleméntelo. Llama 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. Actualice bookinfo.com y los detalles deben extraerse del microservicio de detalles. Se implementó correctamente CPX para redirigir el tráfico de EW.

Citrix Service Mesh Lite con VPX/MPX

  1. Ejecute los siguientes comandos para eliminar el CPX que se utiliza como proxy EW. Se implementa un nuevo archivo para configurar 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, llame al archivo DetailsToVPX.yaml, para enviar el tráfico de la página del producto de vuelta al VPX. El parámetro IP debe ser una VIP gratuita 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 detailsservice.yaml delante del microservicio details. 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 del 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. Actualice bookinfo.com y los detalles deben extraerse del microservicio de detalles. Se implementó correctamente un VPX para redirigir el tráfico de EW.

Migración de servicios a Citrix ADC mediante rutas o clases de ingreso en Openshift

Migración de servicios con fragmentación de rutas

Citrix Ingress Controller (CIC) actúa como una redirección 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 antiguas de Openshift hasta implementaciones automatizadas con componentes CNC, CIC y CPX de Citrix para los procedimientos de migración y actualización de clústeres.

Esta solución se puede lograr mediante dos métodos:

  • Enrutador CIC por plug-in (pod)
  • Enrutador CPX dentro de Openshift (Sidecar)

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

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

Las rutas estáticas son comunes en las implementaciones antiguas de Openshift que utilizan HAProxy. Las rutas estáticas se pueden usar en paralelo con Citrix CNC, CIC y CPX al migrar servicios de un proxy de servicio a otro sin interrumpir los espacios de nombres desplegados 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, las cuales admiten la fragmentación de enrutadores de OpenShift.

Tipos de rutas

  • 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 cierra 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 plug-in de router OpenShift

Para las rutas, utilizamos los conceptos de fragmentación de rutas. Aquí, el CIC actúa como una redirección y redirige el tráfico a varios pods para distribuir el tráfico entrante entre varios pods disponibles. El CIC se instala como un plug-in de enrutador para Citrix ADC MPX o VPX, implementado fuera del clúster.

Componentes de Citrix:

  • VPX: El ADC de ingreso que presenta los servicios de clúster al 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 de origen 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 de kubernetes. La expresión de fragmentación de rutas en CIC, NAMESPACE_LABELS, es un campo opcional. Si se usa, debe coincidir con las etiquetas de 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"
    
  2. 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 que se configurarán.

    metadata:
        name: apache-route
        namespace: hellogalaxy
        labels:
            name: apache-web
    
  3. Exponga el servicio con service.yaml.

    metadata:
        name: apache-service
    spec:
    type: NodePort
    #type=LoadBalancer
    ports:
        - port: 80
    targetPort: 80
    selector:
        app: apache
    
  4. Implemente una aplicación web sencilla con una etiqueta de selector que coincida con la de service.yaml.

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

Citrix ADC CPX se puede implementar como una redirección OpenShift, junto con el controlador Citrix Ingress Controller dentro del clúster. Para obtener más información sobre cómo implementar un CPX o CIC como enrutador en el clúster, consulte Habilitar la compatibilidad con fragmentación de redirección de OpenShift con Citrix ADC.

Componentes de Citrix:

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

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

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

Ejemplos de parámetros de archivo YAML para clases de ingreso:**

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

env:
    args:
      - --ingress-classes
        vpx

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

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

    kind: Ingress
        metadata:
            name: ingress-vpx
            annotations:
                kubernetes.io/ingress.class: "vpx"

Exportador de métricas de Citrix

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

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