Documentación de productos
Citrix Tech Zone
Ver PDF

Migración de servicios a Citrix ADC mediante rutas en el diseño de referencia validado de OpenShift

October 4, 2022
Author:  Luis Ugarte, Beth Pollack

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.

Diagrama de fragmentación de rutas de la aplicación Bookinfo implementada como arquitectura service mesh lite

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

  1. Cree un espacio de nombres para la implementación. oc create ns sml

  2. 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-->

  3. 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-->

  4. 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-->

  5. 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-->

  6. 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-->

  7. 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-->

  8. 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-->

  9. 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

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”

Documentación de OpenShift Route:

Migración de servicios a Citrix ADC mediante rutas en el diseño de referencia validado de OpenShift
October 4, 2022
Author:  Luis Ugarte, Beth Pollack
October 4, 2022
Author:  Luis Ugarte, Beth Pollack

En este artículo

Comentarios sobre el sitio | Your privacy choices footer linkSus opciones de privacidad | Condiciones legales y de privacidad | Preferencias de cookies | Parámetros de consentimiento | docs.cloud.com
© 1999- Cloud Software Group, Inc. All rights reserved.