Migración de servicios a Citrix ADC mediante rutas en el diseño de referencia validado de OpenShift
Rutas estáticas y automáticas en un clúster de OpenShift
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 heredadas de OpenShift que utilizan HAProxy. Las rutas estáticas se pueden usar en paralelo con el controlador de nodos Citrix (CNC), el Citrix ingress controller (CIC) y CPX al migrar servicios de un proxy de servicio a otro sin interrumpir los espacios de nombres implementados en un clúster en funcionamiento.
Ejemplo de configuración de ruta estática para Citrix ADC:
oc get hostsubnet (Openshift Cluster) snippet
oc311-master.example.com 10.x.x.x 10.128.0.0/23
oc311-node1.example.com 10.x.x.x 10.130.0.0/23
oc311-node2.example.com 10.x.x.x 10.129.0.0/23
show route (external Citrix VPX) snippet
10.128.0.0 255.255.254.0 10.x.x.x STATIC
10.129.0.0 255.255.254.0 10.x.x.x STATIC
10.130.0.0 255.255.254.0 10.x.x.x STATIC
<!--NeedCopy-->
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 que cifra al destino mediante TLS.
Obtenga más información sobre los diferentes tipos de rutas en las soluciones de implementación de Citrix ingress controller.
Implementación de Citrix Ingress Controller con soporte de fragmentación de router OpenShift
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 de OpenShift heredadas 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:
- Complemento de enrutador CIC (pod)
- Enrutador CPX dentro de OpenShift (Sidecar)
Ambos métodos se describen a continuación junto con ejemplos de migración.
La fragmentación de enrutadores OpenShift permite distribuir un conjunto de rutas entre varios enrutadores OpenShift. De forma predeterminada, una redirección OpenShift selecciona todas las rutas de todos los espacios de nombres. En la fragmentación de enrutadores, las etiquetas se agregan a las rutas o los espacios de nombres y los selectores de etiquetas a los enrutadores para filtrar las rutas. Cada fragmento de enrutador selecciona solo rutas con etiquetas específicas que coinciden con sus parámetros de selección de etiquetas.
Para configurar la fragmentación del enrutador para una implementación de Citrix ADC en OpenShift, se requiere una instancia de Citrix Ingress Controller por partición. La instancia del Citrix Ingress Controller se implementa con etiquetas de ruta o espacio de nombres o ambas como variables de entorno en función de los criterios requeridos para la fragmentación. Cuando el Citrix Ingress Controller procesa una ruta, compara las etiquetas de la ruta o las etiquetas del espacio de nombres de la ruta con los criterios de selección configurados en él. Si la ruta cumple los criterios, se aplica la configuración adecuada a Citrix ADC; de lo contrario, no se aplica la configuración.
En la fragmentación de enrutadores, la selección de un subconjunto de rutas de todo el conjunto de rutas se basa en expresiones de selección. Las expresiones de selección son una combinación de varios valores y operaciones. Obtenga más información sobre las expresiones, los valores y las operaciones en este blog de Citrix.
Implementación de Bookinfo
La arquitectura de la aplicación Bookinfo se muestra en la siguiente ilustración. Se implementa un CIC como un plug-in de enrutador de OpenShift en el primer nivel, configurando Citrix ADC VPX para redirigir el tráfico Norte-Sur a la página del producto. En el segundo nivel, se implementa un Citrix ADC CPX como enrutador OpenShift, que redirige el tráfico de este a oeste entre el microservicio de detalles y la página de producto, mientras que el tráfico de este a oeste entre los microservicios de página de producto, reseñas y calificaciones se redirige a través del enrutador HAProxy predeterminado.
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.
- CPX: Proporciona redirección OpenShift dentro del clúster OpenShift.
Pasos de implementación
- Cree un espacio de nombres para la implementación.
oc create ns sml
-
Implemente la aplicación Bookinfo en el espacio de nombres.
oc apply -f 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: "bookinfo.yaml" 224L, 5120C <!--NeedCopy-->
-
Implemente el archivo de ruta que se asigna a nuestro servicio de páginas de productos. Especifique
frontend-ip
(esta es la IP virtual de conmutación de contenido en el ADC de nivel 1)oc apply -f routes-productpage.yaml
apiVersion: v1 kind: Route metadata: name: productpage-route namespace: sml annotations: ingress.citrix.com/frontend-ip: "X.X.X.X" labels: name: productpage spec: host: bookinfo.com path: / port: targetPort: 80 to: kind: Service name: productpage-service <!--NeedCopy-->
-
Implemente el archivo RBAC para el espacio de nombres sml que otorga al CIC los permisos necesarios para ejecutarse. El archivo RBAC ya tiene un espacio de nombres.
oc apply -f rbac.yaml
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1beta1 metadata: name: cpx rules: - apiGroups: [""] resources: ["endpoints", "ingresses", "services", "pods", "secrets", "nodes", "routes", "namespaces","tokenreviews","subjectaccessreview"] verbs: ["get", "list", "watch"] # services/status is needed to update the loadbalancer IP in service status for integrating # service of type LoadBalancer with external-dns - apiGroups: [""] resources: ["services/status"] verbs: ["patch"] - apiGroups: ["extensions"] resources: ["ingresses", "ingresses/status"] verbs: ["get", "list", "watch"] - apiGroups: ["apiextensions.k8s.io"] resources: ["customresourcedefinitions"] verbs: ["get", "list", "watch"] - apiGroups: ["apps"] resources: ["deployments"] verbs: ["get", "list", "watch"] - apiGroups: ["citrix.com"] resources: ["rewritepolicies", "canarycrds", "authpolicies", "ratelimits"] verbs: ["get", "list", "watch"] - apiGroups: ["citrix.com"] resources: ["vips"] verbs: ["get", "list", "watch", "create", "delete"] - apiGroups: ["route.openshift.io"] resources: ["routes"] 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: v1 kind: ServiceAccount metadata: "rbac.yaml" 51L, 1513C <!--NeedCopy-->
-
Implemente su CIC para enviar las configuraciones de ruta a su VPX. Haga coincidir el parámetro ROUTE_LABELS con la etiqueta especificada en el
route-productpage.yaml
. Para obtener más información sobre la sintaxis de ROUTE_LABELS, consulte este blog.oc apply -f cic-productpage-v2.yaml
apiVersion: v1 kind: Pod metadata: name: cic labels: app: cic spec: serviceAccount: cpx containers: - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6" securityContext: privileged: true env: - name: "EULA" value: "yes" # Set NetScaler NSIP/SNIP, SNIP in case of HA (mgmt has to be enabled) - name: "NS_IP" value: "X.X.X.X" # Set NetScaler VIP that receives the traffic # - name: "NS_VIP" # value: "X.X.X.X" - name: "NS_USER" value: "nsroot" - name: "NS_PASSWORD" value: "nsroot" - name: "NS_APPS_NAME_PREFIX" value: "BOOK" - name: "ROUTE_LABELS" value: "name in (productpage)" # - name: "NAMESPACE_LABELS" # value: "app=hellogalaxy" # Set username for Nitro # - name: "NS_USER" # valueFrom: # secretKeyRef: # name: nslogin # key: nsroot # # Set user password for Nitro # - name: "NS_PASSWORD" # valueFrom: # secretKeyRef: # name: nslogin # key: nsroot args: # - --default-ssl-certificate # default/default-cert imagePullPolicy: Always ~ "cic-productpage-v2.yaml" 48L, 1165C <!--NeedCopy-->
-
Ahora debemos crear un servicio sin cabeza que señale a los usuarios que buscan detalles a nuestro CPX mediante los pods DNS de nuestro clúster.
oc apply -f detailsheadless.yaml
################################################################################################## # Details service ################################################################################################## apiVersion: v1 kind: Service metadata: name: details spec: ports: - port: 9080 name: http selector: app: cpx <!--NeedCopy-->
-
Implemente un nuevo servicio para exponer el contenedor de detalles.
oc apply -f detailsservice.yaml
################################################################################################## # Details service ################################################################################################## 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-->
-
Implemente una nueva definición de ruta que se encuentre delante del servicio de detalles que creamos. Observe que la etiqueta es “nombre: detalles”.
oc apply -f detailsroutes.yaml
apiVersion: v1 kind: Route metadata: name: details-route namespace: sml annotations: ingress.citrix.com/insecure-port: "9080" labels: name: details spec: host: details path: / port: targetPort: 9080 to: kind: Service name: details-service <!--NeedCopy-->
-
Implemente CPX para el tráfico E/W. Un CIC se implementa como sidecar y se configura con un parámetro ROUTE_LABEL para que coincida con la etiqueta de detailsroutes.yaml.
oc apply -f cpx.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: 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 # readiness probe? imagePullPolicy: Always # Add cic as a sidecar - name: cic image: "quay.io/citrix/citrix-k8s-ingress-controller:1.7.6" env: - name: "EULA" value: "yes" - name: "NS_IP" "cpx.yaml" 75L, 1939C <!--NeedCopy-->
Opciones de entrega continua en un entorno de microservicios
La integración continua (CI) es una práctica de desarrollo que requiere que los desarrolladores integren código en un repositorio compartido varias veces al día.
La entrega continua (CD) es la extensión natural de la integración continua: un enfoque en el que los equipos se aseguran de que todos los cambios en el sistema se puedan publicar y de que podemos lanzar cualquier versión con solo pulsar un botón.
Las diferentes opciones de CD, junto con sus ventajas y desventajas, son:
-
Recrear: La versión 1 (V1) finaliza y, a continuación, se implanta la versión 2 (V2).
-
Pros
- Fácil de configurar.
- El estado de la solicitud se renueva completamente
-
Contras
- Alto impacto en el usuario. Espere un tiempo de inactividad que depende de la duración del apagado y del arranque.
-
Pros
-
Actualización acelerada/continua: La V2 se implanta lentamente y reemplaza a la V1.
-
Pros
- Fácil de configurar.
- La versión se publica lentamente en todas las instancias.
- Conveniente para aplicaciones con estado que pueden gestionar el reequilibrio de los datos.
-
Contras
- La implementación y la reversión pueden llevar tiempo.
- Es difícil dar soporte a varias API.
- Pocos controles del tráfico.
-
Pros
-
Azul verde: La V2 se lanza junto con la V1, luego el tráfico se cambia a la V2.
-
Pros
- Implantación/reversión instantánea.
- Evite el problema de la versión, ya que toda la aplicación se cambia de una vez.
-
Contras
- Es caro, ya que requiere el doble de recursos.
- Se debe realizar una prueba adecuada de toda la plataforma antes de lanzarla a producción.
- Manejar varias aplicaciones con estado puede resultar difícil.
-
Pros
-
Canary: La V2 se lanza a un subconjunto de usuarios y, a continuación, pasa a su lanzamiento completo.
-
Pros
- Versión publicada para un subconjunto de usuarios.
- Conveniente para la supervisión de la tasa de errores y
- Reversión rápida.
-
Contras
- Implantación lenta.
- Manejar varias aplicaciones con estado puede resultar difícil.
-
Pros
-
Pruebas A/B: La versión V2 se lanza a un subconjunto de usuarios en condiciones específicas.
-
Pros
- Varias versiones funcionan en paralelo.
- Control total sobre la distribución del tráfico.
-
Contras
- Requiere un equilibrador de carga inteligente.
- Es difícil solucionar los errores de una sesión determinada, por lo que el seguimiento distribuido se vuelve obligatorio.
-
Pros
-
Remedo: La V2 recibe tráfico del mundo real junto con la V11 y no afecta a la respuesta.
-
Pros
- Pruebas de rendimiento de la aplicación con tráfico de producción.
- Sin impacto en el usuario.
- No se implementará hasta que la estabilidad y el rendimiento de la aplicación cumplan con los requisitos.
-
Contras
- Es caro, ya que requiere el doble de recursos.
- No es una verdadera prueba de usuario y puede resultar engañosa.
- Es complejo de configurar.
- Requiere servicio de burla para ciertos casos.
-
Pros
Materiales de referencia
Citrix GitHub: “Rutas y entrada de OpenShift”
Documentación de Citrix Developer: “Soluciones de implementación”
Blog de Citrix: “Enable OpenShift router sharding support with Citrix ADC”