Conceptos avanzados

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 (por defecto): Asigna la subred OpenShift HostSubnet al ADC externo a través de una ruta estática

Las rutas estáticas son comunes en las implementaciones heredadas de OpenShift que utilizan HAProxy. Las rutas estáticas se pueden utilizar en paralelo con Citrix node Controller (CNC), Citrix ingress controller (CIC) y CPX al migrar servicios de un Service Proxy 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, ambas compatibles con la fragmentación del router OpenShift.

Tipos de ruta

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

Obtenga más información sobre los diferentes tipos de ruta en Soluciones de implementación de Controller entrada de Citrix.

Implementar Citrix Ingress Controller con compatibilidad con la fragmentación del router OpenShift

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

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

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

  • Plug-in del router CIC (pod)
  • Enrutador CPX dentro de OpenShift (Sidecar)

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

Fragmentos del router OpenShift permite distribuir un conjunto de rutas entre múltiples enrutadores OpenShift. De forma predeterminada, un enrutador OpenShift selecciona todas las rutas de todos los espacios de nombres. En la fragmentación del enrutador, las etiquetas se agregan a las rutas o espacios de nombres y los selectores de etiquetas a los enrutadores para filtrar rutas. Cada fragmento de router selecciona solo rutas con etiquetas específicas que coinciden con sus parámetros de selección de etiquetas.

Para configurar la fragmentación del router para una implementación de Citrix ADC en OpenShift, se requiere una instancia de Controller de entrada de Citrix por fragmento. La instancia del Controller de entrada de Citrix se implementa con etiquetas de ruta o espacio de nombres o ambas como variables de entorno en función de los criterios necesarios para la fragmentación. Cuando el Controller de entrada de Citrix procesa una ruta, compara las etiquetas de la ruta o las etiquetas de espacio de nombres de la ruta con los criterios de selección configurados en ella. Si la ruta cumple los criterios, la configuración adecuada se aplica a Citrix ADC; de lo contrario, no se aplica la configuración.

En la fragmentación del router, la selección de un subconjunto de rutas de todo el grupo de rutas se basa en expresiones de selección. Las expresiones de selección son una combinación de múltiples valores y operaciones. Consulte más información sobre las expresiones, valores y operaciones de esta entrada de blog de Citrix.

Implementación de información del libro

La arquitectura de la aplicación Bookinfo se ve en la figura siguiente. Un CIC se implementa como un complemento de enrutador OpenShift en el primer nivel, configurando Citrix ADC VPX para enrutar el tráfico Norte-Sur a la página del producto. En el segundo nivel, un Citrix ADC CPX se implementa como un enrutador OpenShift, lo que enruta el tráfico Este-Oeste entre el microservicio Detalles y la página del producto, mientras que el tráfico Este-Oeste entre los microservicios Página del producto, Revisiones y Valoraciones se enruta a través del enrutador HAProxy predeterminado.

Diagrama de fragmentación de rutas de la aplicación Bookinfo implementada como una arquitectura de malla de servicio lite

Componentes de Citrix

  • VPX: ADC de entrada que presenta los servicios de clúster a DNS.
  • CIC: Proporciona ROUTE_LABELS y NAMESPACE_LABELS al Citrix ADC externo a través de la ruta CNC.
  • CPX: Proporciona enrutamiento 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 dirección IP virtual que cambia 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 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 esta entrada de 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 frente al servicio de detalles que hemos creado. Observe que la etiqueta es “name: Details”. 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. Implementar CPX para 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 en 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.

Continuous Delivery (CD) es la extensión natural de Continuous Integration: Un enfoque en el que los equipos aseguran que cada cambio en el sistema sea liberable, y que podemos liberar cualquier versión con solo pulsar un botón.

Las diferentes opciones de CD, junto con sus pros y sus contras, son:

  • Volver a crear: La versión 1 (V1) finaliza y luego se despliega la versión 2 (V2).
    • Pros
      • Fácil de instalar.
      • El estado de la aplicación se renueva completamente.
    • Contras
      • Alto impacto en el usuario. Espere tiempo de inactividad que depende tanto del apagado como de la duración del arranque.
  • Actualización Ramped/Rolling: V2 se despliega lentamente y reemplaza a V1.
    • Pros
      • Fácil de instalar.
      • La versión se libera lentamente en todas las instancias.
      • Conveniente para aplicaciones con estado que pueden manejar el reequilibrio de los datos.
    • Contras
      • El rollout/rollback puede llevar tiempo.
      • Es difícil admitir múltiples API.
      • Poco control del tráfico.
  • Verde azul: V2 se libera junto a V1, luego el tráfico se cambia a V2.
    • Pros
      • Implementación instantánea/reversión.
      • Evite el problema de la versión ya que toda la aplicación se cambia a la vez.
    • Contras
      • Caro ya que requiere el doble de recursos.
      • Se debe realizar una prueba adecuada de toda la plataforma antes de lanzarla a la producción.
      • El manejo de múltiples aplicaciones con estado puede ser difícil.
  • Canary: V2 se libera a un subconjunto de usuarios y luego procede a una implementación completa.
    • Pros
      • Versión publicada para un subconjunto de usuarios.
      • Conveniente para la supervisión de la tasa de error y el rendimiento.
      • Reversión rápida.
    • Contras
      • Implementación lento.
      • El manejo de múltiples aplicaciones con estado puede ser difícil.
  • Pruebas A/B: V2 se libera a un subconjunto de usuarios bajo condiciones específicas.
    • Pros
      • Varias versiones se ejecutan en paralelo.
      • Control total sobre la distribución del tráfico.
    • Contras
      • Requiere equilibrador de carga inteligente.
      • Es difícil solucionar errores para una sesión determinada, por lo que el seguimiento distribuido se vuelve obligatorio.
  • Sombra: V2 recibe tráfico del mundo real junto a 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 implementa hasta que la estabilidad y el rendimiento de la aplicación cumplan los requisitos.
    • Contras
      • Caro ya que requiere el doble de recursos.
      • No es una verdadera prueba de usuario y puede ser engañoso.
      • Complejo para montar.
      • Requiere servicio de burla para ciertos casos.

Materiales de referencia

Citrix GitHub: “Rutas y entrada de OpenShift”

Docs Citrix Developer: “Soluciones de implementación”

Blog de Citrix: “Habilitar la compatibilidad con la fragmentación del router OpenShift con 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