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
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.
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:
- Como contenedor sidecar junto con 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 de OpenShift.
- Como pod independiente en el clúster de OpenShift: En este modo, puede controlar el dispositivo Citrix ADC MPX o VPX implementado fuera del clúster. Consulte Implementar Citrix ADC MPX/VPX como una redirección fuera del 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.).
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.
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.
-
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í.
-
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--> -
Implemente la aplicación.
oc apply -f application.yaml -
Asegúrese de que los pods estén funcionando.
oc get pods -
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--> -
Exponga la aplicación a través de NodePort con un servicio.
oc apply -f service.yaml -
Verifique que se haya creado el servicio.
oc get service -
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--> -
Implemente el archivo YAML de Ingress.
oc apply -f ingress.yaml -
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--> -
Implemente el archivo RBAC.
oc apply -f rbac.yaml -
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--> -
Implemente el CIC.
oc apply -f cic.yaml -
Verifica que todos los pods estén funcionando.
oc get pods -
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.
-
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)”.
-
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.
-
Cree un espacio de nombres llamado “tier-2-adc”.
oc create namespace tier-2-adc -
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--> -
Implemente la aplicación en el espacio de nombres.
oc apply -f application-2t.yaml -n tier-2-adc -
Asegúrese de que los pods estén funcionando.
oc get pods -
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--> -
Exponga la aplicación a través de NodePort con un servicio.
oc apply -f service-2t.yaml -n tier-2-adc -
Verifique que se haya creado el servicio.
oc get service -n tier-2-adc -
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--> -
Implemente el archivo YAML de Ingress.
oc apply -f ingress-2t.yaml -n tier-2-adc -
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--> -
Implemente el archivo RBAC.
oc apply -f rbac-2t.yaml -
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 -
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 archivoingress-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--> -
Implemente el CPX.
oc apply -f cpx-2t.yaml -n tier-2-adc -
Verifique que el pod esté en ejecución y que se haya creado el servicio.
oc get pods -n tier-2-adcoc get service -n tier-2-adc -
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--> -
Despliegue el Ingress.
oc apply -f ingress-cpx-2t.yaml -n tier-2-adc -
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--> -
Implemente el CIC.
oc apply -f cic-2t.yaml -n tier-2-adc -
Verifica que todos los pods estén funcionando.
oc get pods -n tier-2-adc -
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.
-
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.
-
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í.
-
Cree un espacio de nombres para esta implementación. En este ejemplo,
smlse usa.oc create namespace sml -
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-->
-
Implemente bookinfo.yaml en el espacio de nombres sml.
oc apply -f bookinfo.yaml -n sml -
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
-
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.yamltal 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
-
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 -
Modifique el archivo de hosts en el equipo local con bookinfo.com asignado a la IP de interfaz especificada en
ingress-productpage.yaml. -
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
-
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).
-
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 -
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
-
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
-
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
-
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
- 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
-
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 smloc delete -f detailsservice.yaml -n smloc delete -f detailsingress.yaml -n smloc delete -f CPXEastWest.yaml -n sml -
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
-
Vuelva a implementar detailsservice.yaml delante del microservicio details.
oc apply -f detailsservice.yaml -n sml -
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
- 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í
-
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" -
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 -
Exponga el servicio con service.yaml.
metadata: name: apache-service spec: type: NodePort #type=LoadBalancer ports: - port: 80 targetPort: 80 selector: app: apache -
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.
En este artículo
- Por qué Citrix para la entrega de aplicaciones modernas
- Una solución para todas las partes interesadas
- Explicación de la pila de software Citrix
- El valor de Citrix ADC
- Los beneficios de Citrix ADC
- La ventaja de Citrix ADC Suite
- Ecosistema de partners
-
Resumen de OpenShift
- Proyectos OpenShift
- Espacios de nombres OpenShift
- Redes definidas por software (SDN) OpenShift
- Routing y complementos de OpenShift
- Rutas OpenShift y métodos de entrada
- 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
- Implementar el Citrix Ingress Controller como un plug-in de enrutador OpenShift
- Arquitecturas recomendadas
- Cómo implementar
- Migración de servicios a Citrix ADC mediante rutas o clases de ingreso en Openshift
- Exportador de métricas de Citrix