Ingress Controller de Citrix ADC

Solución de equilibrio de carga y entrada de varios clústeres mediante el Citrix Ingress Controller

Información general

Para garantizar la alta disponibilidad, el equilibrio de carga basado en la proximidad y la escalabilidad, es posible que deba implementar una aplicación en varios clústeres de Kubernetes distribuidos. Cuando la misma aplicación se implementa en varios clústeres de Kubernetes, se debe tomar una decisión de equilibrio de carga entre las instancias de aplicaciones dispersas en los clústeres.

Para implementar una solución de equilibrio de carga para clústeres distribuidos de Kubernetes, el estado de las aplicaciones en los clústeres debe supervisarse de manera global. Debe supervisar la disponibilidad y el rendimiento de las aplicaciones, actualizar el estado de las aplicaciones en los clústeres, recopilar estadísticas de los puntos finales en los centros de datos y compartir las estadísticas en los centros de datos.

Citrix proporciona una solución de equilibrio de carga y entrada de varios clústeres que supervisa las aplicaciones de forma global, recopila y comparte métricas en diferentes clústeres y proporciona decisiones inteligentes de equilibrio de carga. Garantiza un mejor rendimiento y fiabilidad para sus servicios de Kubernetes que se exponen mediante Ingress o con el tipo LoadBalancer.

Topología de implementación

En el siguiente diagrama, se explica una topología de implementación para la solución de ingreso y equilibrio de carga de varios clústeres para clústeres de Kubernetes.

Nota:

También se admiten los servicios de tipo LoadBalancer (disponibles para clústeres bare metal que usan Citrix ADC).

Multi-cluster-deployment

Este diagrama muestra una topología de ejemplo con dos centros de datos y cada centro de datos contiene varios clústeres de Kubernetes. Para el centro de datos 1, Citrix ADC CPX se implementa como el equilibrador de carga de entrada en cada clúster de Kubernetes. Para el centro de datos 2, HAProxy se implementa como el equilibrador de carga en cada clúster de Kubernetes. Solución de equilibrio de carga y ingreso de varios clústeres de Citrix para balanceos de carga de Kubernetes en todos los ingresos.

Nota:

Se admite cualquier solución de entrada, incluidas las soluciones de terceros, como la puerta de enlace de entrada de Istio y el Citrix Ingress Controller de Citrix con Citrix ADC MPX, VPX o BLX. Esta topología es solo una implementación de muestra.

Se configura un dispositivo de equilibrio de carga de servidor global (GSLB) de Citrix para cada centro de datos. En cada Citrix ADC que actúa como equilibrador de carga global, un sitio se configura como un sitio local que representa el centro de datos local. Los demás sitios se configuran como sitios remotos para cada centro de datos remoto. El Citrix ADC (MPX o VPX) utilizado como GSLB también se puede usar como el dispositivo Ingress con el Citrix Ingress Controller.

La opción de sincronización de configuración de equilibrio de carga del servidor global (GSLB) de Citrix ADC se utiliza para sincronizar la configuración en los sitios. El dispositivo Citrix ADC desde el que utiliza la sincronización se denomina nodo maestro y el sitio donde se copia la configuración como el sitio subordinado.

Cada clúster de la implementación ejecuta una instancia del controlador de Kubernetes GSLB. El controlador GSLB es el módulo responsable de la configuración del dispositivo Citrix ADC GSLB. El controlador GSLB configura el dispositivo maestro GSLB para las aplicaciones implementadas en su clúster respectivo. El dispositivo maestro GSLB envía la configuración GSLB a los dispositivos subordinados GSLB restantes mediante la función de sincronización GSLB. Cuando sincroniza una configuración de GSLB, las configuraciones de todos los sitios de GSLB que participan en la configuración de GSLB se hacen similares a la configuración del sitio maestro.

La solución de equilibrio de carga y entrada de varios clústeres se puede aplicar a cualquier objeto de Kubernetes que se utilice para redirigir el tráfico al clúster.

Se admiten los siguientes métodos de equilibrio de carga global:

Se admiten los siguientes tipos de implementación:

  • Primero local: en una primera implementación local, cuando una aplicación quiere comunicarse con otra aplicación, prefiere una aplicación local en el mismo clúster. Cuando la aplicación no está disponible localmente, la solicitud se dirige a otros clústeres o regiones.

  • Canary: La versión de Canary es una técnica para reducir el riesgo de introducir una nueva versión de software en producción al implementar primero el cambio a un pequeño subconjunto de usuarios. En esta solución, la implementación de Canary se puede usar cuando quiere implementar nuevas versiones de la aplicación en clústeres seleccionados antes de moverla a producción.

  • Conmutación por error: una implementación de conmutación por error se usa cuando quiere implementar aplicaciones en una configuración activa/pasiva cuando no se pueden implementar en modo activo/activo.

  • Tiempo de ida y vuelta (RTT): en una implementación de RTT, se supervisa el estado en tiempo real de la red y dirige dinámicamente la solicitud del cliente al centro de datos con el valor de RTT más bajo.

  • Proximidad estática: en una implementación de proximidad estática, se utiliza una base de datos de proximidad estática basada en direcciones IP para determinar la proximidad entre el servidor DNS local del cliente y los sitios GSLB. Las solicitudes se envían al sitio que mejor se ajusta a los criterios de proximidad.

  • Round robin: En una implementación por turnos, el dispositivo GSLB rota continuamente una lista de los servicios que están vinculados a él. Cuando recibe una solicitud, asigna la conexión al primer servicio de la lista y, a continuación, mueve ese servicio al final de la lista.

Nota:

Actualmente, no se admite IPv6.

CRD para configurar la solución de equilibrio de carga y ingreso de varios clústeres para clústeres de Kubernetes

Los siguientes CRD se presentan para admitir la configuración de Citrix ADC para realizar aplicaciones GSLB de Kubernetes.

  • Directiva de tráfico global (GTP)
  • Entrada de servicios globales (GSE)

GTP CRD

GTP CRD acepta los parámetros para configurar GSLB en Citrix ADC, incluido el tipo de implementación (Canary, failover, local primero), dominio GSLB, monitor de estado para Ingress y tipo de servicio.

La especificación de CRD de GTP está disponible en el repositorio de GitHub del Citrix Ingress Controller en: grp-crd.yaml.

GSE CRD

La CRD de GSE dicta la información de punto final (cualquier objeto de Kubernetes que redirija el tráfico al clúster) en cada clúster.

La especificación de CRD de GSE está disponible en el repositorio de GitHub del controlador de entrada de citrix en: gse-crd.yaml

La CRD de GSE se genera automáticamente para un objeto Ingress si el servicio especificado en el recurso Ingress se hace referencia en la instancia de CRD de GTP y el campo status-loadbalancer-ip/hostname ya está rellenado. Para un servicio de tipo LoadBalancer, la CRD de GSE se genera automáticamente si se hace referencia al servicio en la instancia de CRD de GTP y el campo status-loadbalancer-ip/hostname ya está rellenado.

Nota: Para la generación automática de CRD de GSE en el caso de Ingress, el nombre de host debe coincidir exactamente con el nombre de host especificado en la instancia de GTP CRD. Tanto para el tipo de entrada como para el servicio LoadBalancer, la CRD de GSE se genera solo para el primer puerto especificado.

Implementar Citrix solución de equilibrio de carga e ingreso de varios clústeres de

Se aplican los siguientes requisitos previos antes de realizar los pasos para implementar la solución de equilibrio de carga global de Citrix:

  • Debe configurar los sitios GSLB en Citrix ADC, que actúa como dispositivo GSLB.
  • Las funciones como el cambio de contenido y SSL deben estar habilitadas en el dispositivo GSLB
  • Para la proximidad estática, la base de datos de ubicación debe aplicarse externamente

Realice los siguientes pasos para implementar la solución de equilibrio de carga global de Citrix para clústeres de Kubernetes distribuidos geográficamente.

  1. Cree los permisos RBAC necesarios para implementar el controlador GSLB mediante el archivo gslb-rbac.yaml.

    kubectl apply -f gslb-rbac.yaml
    
  2. Cree los secretos necesarios para que el controlador GSLB se conecte a los dispositivos GSLB e inserte la configuración desde el controlador GSLB.

    kubectl create secret generic secret-1 --from-literal=username=<username for gslb device1> --from-literal=password=<password for gslb device1>
    kubectl create secret generic secret-2 --from-literal=username=<username for gslb device2> --from-literal=password=<password for gslb device2>
    

    Nota:

    Estos secretos se utilizan en el archivo YAML del controlador GSLB para los sitios respectivos. La username y password en el comando especifica el nombre de usuario y la contraseña del Citrix GSLB ADC.

  3. Descargue el archivo YAML del controlador GSLB gslb-controller.yaml.

  4. Modifique el archivo YAML del controlador GSLB y actualice los siguientes valores según los requisitos de cada clúster.

    • LOCAL_REGION y LOCAL_CLUSTER: especifique la región y el nombre del clúster donde se implementa este controlador.
    • SITENAMES: proporcione los nombres de los sitios separados por comas y la configuración debe ser la misma que la del sitio configurado en los dispositivos GSLB.
    • La dirección IP, la región, el nombre de usuario y la contraseña de cada sitio deben comenzar con el nombre del sitio correspondiente. Por ejemplo: Para sitio1 en SITENAMES, los campos deben ser site1_ip, site1_region, site1_username y site1_password.
    • la sección de argumentos de la especificación debe incluir --config-interface y gslb-endpoint.

    A continuación se muestra un fragmento del archivo YAML para implementar el controlador GSLB.

    env:
     - name: "LOCAL_REGION"
       value: "east"
     - name: "LOCAL_CLUSTER"
       value: "cluster1"
     - name: "SITENAMES"
       value: "site1,site2"
     - name: "site1_ip"
       value: "x.x.x.x"
     - name: "site1_region"
       value: "east"
     - name: "site1_username"
       valueFrom:
         secretKeyRef:
           name: secret-1
           key: username
     - name: "site1_password"
       valueFrom:
         secretKeyRef:
           name: secret-1
           key: password
     - name: "site2_ip"
       value: "x.x.x.x"
     - name: "site2_region"
       value: "west"
     - name: "site2_username"
       valueFrom:
         secretKeyRef:
           name: secret-2
           key: username
     - name: "site2_password"
       valueFrom:
         secretKeyRef:
           name: secret-2
           key: password
    args:
    - --config-interface
        gslb-endpoints
    

    Nota:

    El orden de la información del sitio GSLB debe ser el mismo en todos los clústeres. El primer sitio del pedido se considera el sitio maestro para enviar la configuración. Cuando ese sitio maestro deja de funcionar, el siguiente sitio de la lista será el nuevo sitio maestro. Por lo tanto, el orden de los sitios debe ser el mismo en todos los clústeres de Kubernetes. Por ejemplo, si el orden de los sitios va site1 seguido site2 de cluster1, todos los demás clústeres deben seguir el mismo orden.

  5. Implemente el archivo YAML modificado del controlador GSLB específico para cada clúster en el clúster correspondiente.

    kubectl apply -f gslb-controller.yaml
    
  6. Implemente el archivo YAML de definición de GTP CRD mediante el siguiente comando.

    kubectl create -f  gtp-crd.yaml
    
  7. Implemente el archivo YAML de definición de CRD de GSE con el siguiente comando.

    kubectl create -f  gse-crd.yaml
    
  8. Defina los GTP de su dominio como archivos YAML y aplique instancias de GTP.

    kubectl create -f  gtp-example.yaml
    

    Nota:

    La CRD de GTP se debe aplicar en todos los clústeres con la misma configuración para el mismo dominio.

    A continuación se muestra un ejemplo de una configuración de directiva de tráfico global en la que la directiva de tráfico se especifica como local primero para el dominio app2.com. Cuando su aplicación prefiera servicios locales, puede usar esta opción. El CIDR del clúster local (cluster1) se especifica mediante el campo CIDR. El weight campo se utiliza para dirigir más solicitudes de clientes a un clúster en particular que a otros clústeres cuando Citrix ADC toma la decisión de GSLB. El método de equilibrio de carga se especifica mediante el campo secLbMethod como round robin.

    Nota:

    Puede especificar el método de equilibrio de carga para implementaciones locales first, Canary y failover.

    apiVersion: "citrix.com/v1beta1"
    kind: globaltrafficpolicy
    metadata:
      name: gtp1
      namespace: default
    spec:
      serviceType: 'HTTP'
      hosts:
      - host: 'app2.com'
        policy:
          trafficPolicy: 'LOCAL-FIRST'
          secLbMethod: 'ROUNDROBIN'
          targets:
          - destination: 'app2.default.east.cluster1'
            CIDR: '10.102.217.69/24'
            weight: 1
          - destination: 'app2.default.west.cluster2'
            weight: 1
          monitor:
          - monType: tcp
            uri: ''
            respCode: 200
    

    Para obtener más información sobre otras opciones de implementación de GTP, como Canary y conmutación por error, consulte Ejemplos: implementaciones de directivas de tráfico globales.

  9. Aplica instancias de GSE manualmente para GSLB de entrada.

    kubectl create -f  gse-example.yaml
    

    Nota:

    La CRD de GSE se aplica en un clúster específico en función de la información de punto final del clúster. El nombre de la entrada del servicio global debe ser el mismo que el nombre del destino de destino en la directiva de tráfico global.

    A continuación se presenta un ejemplo de una entrada de servicio global.

    apiVersion: "citrix.com/v1beta1"
    kind: globalserviceentry
    metadata:
      name: 'app2.default.east.cluster1'
      namespace: default
    spec:
      endpoint:
        ipv4address: 10.102.217.70
        monitorPort: 33036
    

    En este ejemplo, el nombre de entrada de servicio global app2.default.east.cluster1 es uno de los nombres de destino de la directiva de tráfico global creada en el paso 8.

  10. Aplique el servicio YAML para GSLB de servicios de tipo LoadBalancer.

     kubectl create -f  service-example.yaml
    

    A continuación se presenta un servicio de muestra.

     apiVersion: v1
     kind: Service
     metadata:
       name: cold
       namespace: default
     spec:
       type: LoadBalancer
       ports:
       - name: port-8080
         port: 8090
         targetPort: 8080
       selector:
         dep: citrixapp
     status:
       loadBalancer:
         ingress:
         - ip: 10.102.217.72
    

Para obtener un ejemplo de configuración de la solución de equilibrio de carga y entrada de varias nubes para clústeres de Amazon EKS y Microsoft AKS con Citrix ADC, consulte la solución de equilibrio de carga y entrada de múltiples nubes y clústeres con clústeres de Amazon EKS y Microsoft AKS.

Cómo dirigir la resolución DNS de los pods a Citrix GSLB ADC

Nota:

Este procedimiento es opcional y solo se necesita si los pods del clúster necesitan resolver el DNS a través del ADC GSLB de Citrix.

Cuando los pods están dentro del clúster de Kubernetes

Cuando quiera que los pods de un clúster de Kubernetes usen la solución GSLB, se debe actualizar el ConfigMap del proveedor de DNS para reenviar la solicitud de un dominio (para el que se requiere GSLB) a Citrix GSLB ADC.

El siguiente ejemplo muestra cómo actualizar ConfigMap si el proveedor de DNS es CoreDNS.

  # kubectl edit configmap coredns -n kube-system

    apiVersion: v1
    data:
      Corefile: |
        cluster.local:53 {
              errors
              health
              kubernetes cluster.local in-addr.arpa ip6.arpa {
                  pods insecure
                  upstream
                  fallthrough in-addr.arpa ip6.arpa
                  ttl 60
              }
              prometheus :9153
              forward . /etc/resolv.conf
              cache 90
              loop
              reload
              loadbalance
        }
        app2.com.:53 {
            errors
            cache 30
            forward . 10.102.217.149
        }
    kind: ConfigMap
    metadata:
      creationTimestamp: "2019-08-30T10:59:36Z"
      name: coredns
      namespace: kube-system
      resourceVersion: "43569751"
      selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
      uid: ac1d92e4-260f-45bd-8708-5f8194482885

Como se muestra en el ejemplo, debe agregar la configuración requerida para su dominio si quiere que un pod tome una decisión de GSLB para las aplicaciones alojadas detrás de un dominio. En este caso, el nombre de dominio es app2.com.

  app2.com.:53 {
      errors
      cache 30
      forward . 10.102.217.149
  }

La dirección IP especificada (forward . 10.102.217.149) es un servicio DNS configurado en Citrix GSLB ADC. Puede especificar las múltiples direcciones IP de diferentes sitios GSLB separándolas con espacios como se muestra a continuación.

  forward . ip1 ip2 ip3

Cuando los pods están dentro del clúster de OpenShift

Cuando quiera que los pods de un clúster de OpenShift usen la solución GSLB, el operador de DNS debe actualizarse para reenviar la solicitud de un dominio (para el que se requiere GSLB) a Citrix GSLB ADC.

  # oc edit dns.operator/default

  apiVersion: operator.openshift.io/v1
  kind: DNS
  metadata:
    name: default
  spec:
    servers:
      - name: gslb-app2
        zones:
          - app2.com
        forwardPlugin:
          upstreams:
            - 10.102.217.149
            - 10.102.218.129:5353

Como se muestra en el ejemplo, debe agregar la configuración requerida para su dominio si quiere que un pod tome una decisión de GSLB para las aplicaciones alojadas detrás de un dominio. En este caso, el nombre de dominio es app2.com.

  servers:
      - name: gslb-app2
        zones:
          - app2.com
        forwardPlugin:
          upstreams:
            - 10.102.217.149
            - 10.102.218.129:5353

Las direcciones IP especificadas (10.102.217.149 y 10.102.218.129:5353) son servicios DNS configurados en Citrix GSLB ADC.

Esta configuración se puede verificar mediante el siguiente comando:

  # oc get configmap/dns-default -n openshift-dns -o yaml

  apiVersion: v1
  kind: ConfigMap
  metadata:
    labels:
      dns.operator.openshift.io/owning-dns: default
      manager: dns-operator
    name: dns-default
    namespace: openshift-dns
  data:
    Corefile: |
      # gslb-app2
      app2.com:5353 {
          forward . 10.102.217.149 10.102.218.129:5353
          errors
          bufsize 512
      }
      .:5353 {
          bufsize 512
          errors
          health {
              lameduck 20s
          }
          ready
          kubernetes cluster.local in-addr.arpa ip6.arpa {
              pods insecure
              fallthrough in-addr.arpa ip6.arpa
          }
          prometheus 127.0.0.1:9153
          forward . /etc/resolv.conf {
              policy sequential
          }
          cache 900 {
              denial 9984 30
          }
          reload
      }

Definición de GTP CRD

La definición de GTP CRD está disponible en gtp-crd.yaml)

En la siguiente tabla se explican los atributos de la CRD de GTP.

Campo Descripción
ipType Especifica el tipo de registro DNS como A o AAAA. Actualmente, solo se admite el tipo de A registro
serviceType: Especifica el protocolo al que se aplica la compatibilidad con varios clústeres.
host Especifica el dominio para el que se aplica la compatibilidad con varios clústeres.
trafficPolicy Especifica la directiva de distribución de tráfico admitida en una implementación de varios clústeres.
sourceIpPersistenceId Especifica el identificador de persistencia de IP de origen único. Este atributo permite la persistencia en función de la dirección IP de origen de los paquetes entrantes. El atributo sourceIpPersistenceId debe ser un múltiplo de 100 y debe ser único. Para obtener una configuración de ejemplo, consulte Ejemplo: persistencia de IP de origen.
secLbMethod Especifica la directiva de distribución de tráfico admitida entre los clústeres de un grupo en modo local primero, Canary o conmutación por error.
destination Especifica el extremo del servicio Ingress o LoadBalancer en cada clúster. El nombre del destino debe coincidir con el nombre de GSE.
weight Especifica la proporción de tráfico que se distribuirá entre los clústeres. Para la implementación Canary, la proporción se especifica como porcentaje.
CIDR Especifica el CIDR que se utilizará primero en local para determinar el alcance de la localidad.
primary Especifica si el destino es un clúster principal o un clúster de respaldo en la implementación de conmutación por error.
monType Especifica el tipo de sonda para determinar el estado del punto final de varios clústeres. Cuando el tipo de monitor es HTTPS, el SNI se habilita de forma predeterminada durante el protocolo de enlace TLS.
uri Especifica la ruta que se va a sondear para el estado del extremo de varios clústeres para HTTP y HTTPS.
respCode Especifica el código de respuesta que se espera que marque el extremo de varios clústeres como correcto para HTTP y HTTPS.

Definición de CRD de GSE

La definición de CRD de GSE está disponible en gse-crd.yaml

Ejemplos: implementaciones de directivas de tráfico globales

Implementación Canary

Puede usar la implementación Canary cuando quiera implementar nuevas versiones de la aplicación en clústeres seleccionados antes de moverla a producción.

En esta sección se explica un ejemplo de directiva de tráfico global con implementación de Canary, en la que debe implementar una versión más reciente de una aplicación en etapas antes de implementarla en producción.

En este ejemplo, se implementa una versión estable de una aplicación en un clúster cluster2 de la west región. Se está implementando una nueva versión cluster1 de la aplicación en la east región. Mediante el campo weight, puede especificar cuánto tráfico se redirige a cada clúster. En este caso, weight se especifica como 40 por ciento. Por lo tanto, solo el 40 por ciento del tráfico se dirige a la nueva versión. Si el campo weight no se menciona para un destino, se considera como parte de la producción que lleva la mayoría del tráfico. Cuando la versión más reciente de la aplicación se encuentra estable, la nueva versión también se puede implementar en otros clústeres.

  apiVersion: "citrix.com/v1beta1"
  kind: globaltrafficpolicy
  metadata:
    name: gtp1
    namespace: default
  spec:
    serviceType: 'HTTP'
    hosts:
    - host: 'app1.com'
      policy:
        trafficPolicy: 'CANARY'
        secLbMethod: 'ROUNDROBIN'
        targets:
        - destination: 'app1.default.east.cluster1'
          weight: 40
        - destination: 'app1.default.west.cluster2'
        monitor:
        - monType: http
          uri: ''
          respCode: 200

Implementación de failover

Puede usar la implementación de conmutación por error cuando quiera implementar aplicaciones en una configuración activa/pasiva.

En una implementación de conmutación por error, la aplicación se implementa en varios clústeres y estos clústeres se agrupan en un grupo de clústeres activo (grupo1) y un grupo de clústeres pasivo (grupo2). En cualquier momento, solo un conjunto de clústeres está activo, mientras que el otro conjunto permanece pasivo. Cuando todos los clústeres del grupo1 no están disponibles, los clústeres del grupo2 pasan al estado activo. Cuando cualquiera de los clústeres del grupo1 está disponible en un punto posterior, el grupo1 pasa al estado activo y el grupo2 pasa al estado pasivo.

En el siguiente ejemplo se muestra un ejemplo de configuración de GTP para la conmutación por error. Mediante el campo primary, puede especificar qué clúster pertenece al grupo activo y qué clúster pertenece al grupo pasivo. El valor predeterminado del campo True indica que el clúster pertenece al grupo activo. Puede usar el campo weight para dirigir más solicitudes de clientes a un clúster específico dentro de un grupo que a los demás clústeres si el método configurado es round robin. El monitor parámetro de la directiva de tráfico global se usa para configurar el monitor en Citrix ADC. El monitor se puede vincular a los puntos finales de cada clúster para probar su estado.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'FAILOVER'
      secLbMethod: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 1
      - destination: 'app1.default.west.cluster2'
        primary: false
        weight: 1
      monitor:
      - monType: http
        uri: ''
        respCode: 200

Implementación de RTT

A continuación se presenta un ejemplo de directiva de tráfico global para la implementación de ida y vuelta.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'RTT'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: tcp

Implementación round robin

A continuación se presenta un ejemplo de directiva de tráfico para la implementación por turnos. Puede usar esta implementación cuando necesite distribuir el tráfico de manera uniforme en los clústeres.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      targets:
      - destination: 'app1.default.east.cluster1'
        weight: 2
      - destination: 'app1.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200

Proximidad estática

A continuación se presenta un ejemplo de directiva de tráfico para la implementación de proximidad estática.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata:
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app1.com'
    policy:
      trafficPolicy: 'STATICPROXIMITY'
      targets:
      - destination: 'app1.default.east.cluster1'
      - destination: 'app1.default.west.cluster2'
      monitor:
      - monType: http
        uri: ''
        respCode: 200

Ejemplo: persistencia de IP de origen

La siguiente directiva de tráfico proporciona un ejemplo para habilitar la compatibilidad con la persistencia de IP de origen. La persistencia de IP de origen se puede habilitar proporcionando el parámetro sourceIpPersistenceId. El atributo de persistencia de IP de origen se puede habilitar con las directivas de tráfico compatibles.

apiVersion: "citrix.com/v1beta1"
kind: globaltrafficpolicy
metadata
  name: gtp1
  namespace: default
spec:
  serviceType: 'HTTP'
  hosts:
  - host: 'app2.com'
    policy:
      trafficPolicy: 'ROUNDROBIN'
      sourceIpPersistenceId: 300
      targets:
      - destination: 'app2.default.east.cluster1'
        weight: 2
      - destination: 'app2.default.west.cluster2'
        weight: 5
      monitor:
      - monType: tcp
        uri: ''
        respCode: 200