Configuración de carriles de tráfico y degradación de tráfico basada en reglas de tráfico - Alibaba Cloud Service Mesh

Los carriles de tráfico de Alibaba Cloud Service Mesh (ASM) aíslan versiones de aplicaciones u otras características en entornos de ejecución independientes. El tráfico coincidente se enruta hacia las versiones de destino mediante reglas de gestión de tráfico, como VirtualService y DestinationRule. Cuando la versión de destino no está disponible, la degradación de tráfico enruta automáticamente las solicitudes a una versión alternativa especificada.

Requisitos previos

Se creó una instancia de ASM Enterprise Edition o Ultimate Edition con la versión 1.17 o posterior. Para obtener más información, consulte Create an ASM instance o Upgrade an ASM instance.
Se agregó un clúster de Kubernetes a la instancia de ASM. Para obtener más información, consulte Add a cluster to an ASM instance.
Se creó una puerta de enlace de ASM llamada ingressgateway. Para obtener más información, consulte Create an ingress gateway.

Paso 1: Desplegar los servicios de ejemplo

Habilite la inyección automática de sidecar para el namespace default. Para obtener más información, consulte Enable automatic sidecar proxy injection.

Para obtener más información sobre la inyección automática de sidecar, consulte Configure sidecar injection policies.
Utilice el archivo kubeconfig del clúster del plano de datos y ejecute a continuación los comandos para desplegar los servicios de ejemplo.

Los servicios de ejemplo incluyen mocka, mockb y mockc. Cada servicio tiene tres versiones: v1, v2 y v3.

kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v1/application-v1.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v2/application-v2.yaml
kubectl apply -f https://alibabacloudservicemesh.oss-cn-beijing.aliyuncs.com/asm-labs/swimlane/v3/application-v3.yaml

Paso 2: Crear reglas de tráfico para implementar un carril de tráfico

Complete las siguientes subtareas para crear las reglas de enrutamiento de DestinationRule, VirtualService y la puerta de enlace que definen el carril de tráfico.

Crear reglas de tráfico de DestinationRule

Cree un DestinationRule para cada servicio con el fin de definir los subconjuntos de versiones.

Utilice el siguiente contenido para crear el archivo dr-mock.yaml.

El siguiente archivo divide cada uno de los servicios mocka, mockb y mockc en tres subconjuntos: v1, v2 y v3.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mocka
  namespace: istio-system
spec:
  host: mocka.default.svc.cluster.local
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    - labels:
        version: v3
      name: v3
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mockb
  namespace: istio-system
spec:
  host: mockb.default.svc.cluster.local
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    - labels:
        version: v3
      name: v3
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: mockc
  namespace: istio-system
spec:
  host: mockc.default.svc.cluster.local
  subsets:
    - labels:
        version: v1
      name: v1
    - labels:
        version: v2
      name: v2
    - labels:
        version: v3
      name: v3

Utilice el archivo kubeconfig de la instancia de ASM y ejecute el siguiente comando para aplicar las reglas de tráfico de DestinationRule.

kubectl apply -f dr-mock.yaml

Crear reglas de tráfico de VirtualService

Cree un VirtualService para cada servicio interno con el fin de definir el enrutamiento basado en versiones dentro del carril de tráfico.

Utilice el siguiente contenido para crear el archivo vs-mock.yaml.

El siguiente archivo crea un carril de tráfico para la cadena de invocación de servicios mocka→mockb→mockc. Una vez creado el carril de tráfico, una solicitud enviada por un servicio de una versión solo puede enviarse a un servicio de la misma versión.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockb
  namespace: istio-system
spec:
  hosts:
    - mockb.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v2
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v3
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockc
  namespace: istio-system
spec:
  hosts:
    - mockc.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v2
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v3

Utilice el archivo kubeconfig de la instancia de ASM y ejecute el siguiente comando para aplicar las reglas de tráfico de VirtualService.

kubectl apply -f vs-mock.yaml

Crear reglas de enrutamiento de tráfico de la puerta de enlace

Cree reglas de enrutamiento de la puerta de enlace para dirigir las solicitudes externas al carril de tráfico según el encabezado x-asm-prefer-tag.

Utilice el siguiente contenido para crear el archivo gw-mock.yaml.

El siguiente archivo crea reglas de enrutamiento de tráfico de la puerta de enlace para la cadena de invocación de servicios mocka→mockb→mockc. Las reglas coinciden con el encabezado x-asm-prefer-tag de las solicitudes enviadas a la puerta de enlace. Luego, enrutan dichas solicitudes a la versión v1, v2 o v3 del servicio mocka según el valor del encabezado.

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - '*'
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ingressgateway
  namespace: istio-system
spec:
  gateways:
    - istio-system/ingressgateway
  hosts:
    - '*'
  http:
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: v1
          uri:
            exact: /mock
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: v1
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: v2
          uri:
            exact: /mock
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: v2
    - match:
        - headers:
            x-asm-prefer-tag:
              exact: v3
          uri:
            exact: /mock
      route:
        - destination:
            host: mocka.default.svc.cluster.local
            subset: v3

Utilice el archivo kubeconfig de la instancia de ASM y ejecute el siguiente comando para aplicar las reglas de enrutamiento de tráfico de la puerta de enlace.

kubectl apply -f gw-mock.yaml

Paso 3: Comprobar que el carril de tráfico surte efecto

Obtenga la dirección IP pública de la puerta de enlace de ASM. Para obtener más información, consulte Obtain the address of an ASM gateway.
Ejecute el siguiente comando para establecer la variable de entorno.

xxx.xxx.xxx.xxx es la dirección IP obtenida en el paso anterior.

export ASM_GATEWAY_IP=xxx.xxx.xxx.xxx

Compruebe que el carril de tráfico surte efecto.
Ejecute el siguiente comando para revisar las respuestas del carril de tráfico v1.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v1' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Salida esperada:

-> mocka(version: v1, ip: 172.17.0.54)-> mockb(version: v1, ip: 172.17.0.129)-> mockc(version: v1, ip: 172.17.0.130)

La salida esperada indica que el tráfico con el encabezado HTTP x-asm-prefer-tag: v1 fluye hacia los servicios de la versión v1.

Ejecute el siguiente comando para revisar las respuestas del carril de tráfico v2.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Salida esperada:

-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v2, ip: 172.17.0.126)-> mockc(version: v2, ip: 172.17.0.128)

La salida esperada indica que el tráfico con el encabezado HTTP x-asm-prefer-tag: v2 fluye hacia los servicios de la versión v2.

Ejecute el siguiente comando para revisar las respuestas del carril de tráfico v3.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v3' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Salida esperada:

-> mocka(version: v3, ip: 172.17.0.132)-> mockb(version: v3, ip: 172.17.0.127)-> mockc(version: v3, ip: 172.17.0.69)

La salida esperada indica que el tráfico con el encabezado HTTP x-asm-prefer-tag: v3 fluye hacia los servicios de la versión v3.

(Opcional) Paso 4: Configurar la degradación de tráfico dentro del carril de tráfico

Modifique el archivo vs-mock.yaml con el siguiente contenido.

El siguiente archivo crea un carril de tráfico para la cadena de invocación de servicios mocka→mockb→mockc. Además, cuando la versión v2 o v3 de mockb o mockc no está disponible, las solicitudes se envían a la cadena de invocación de la versión v1 del servicio.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockb
  namespace: istio-system
spec:
  hosts:
    - mockb.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v2
      fallback:
        target:
          host: mockb.default.svc.cluster.local
          subset: v1
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockb.default.svc.cluster.local
        subset: v3
      fallback:
        target:
          host: mockb.default.svc.cluster.local
          subset: v1
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: mockc
  namespace: istio-system
spec:
  hosts:
    - mockc.default.svc.cluster.local
  http:
  - match:
    - sourceLabels:
        version: v1
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v1
  - match:
    - sourceLabels:
        version: v2
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v2
      fallback:
        target:
          host: mockc.default.svc.cluster.local
          subset: v1
  - match:
    - sourceLabels:
        version: v3
    route:
    - destination:
        host: mockc.default.svc.cluster.local
        subset: v3
      fallback:
        target:
          host: mockc.default.svc.cluster.local
          subset: v1

Utilice el archivo kubeconfig de la instancia de ASM y ejecute el siguiente comando para modificar las reglas de tráfico de VirtualService existentes y aplicar la configuración de degradación de tráfico.

kubectl apply -f vs-mock.yaml

(Opcional) Paso 5: Comprobar que la degradación de tráfico surte efecto

Inicie sesión en la consola de ACK. En el panel de navegación izquierdo, haga clic en Clusters.

En la página Clusters, haga clic en el nombre de su clúster. En el panel de navegación izquierdo, seleccione Workloads > Deployments.

En la página Deployments, busque la carga de trabajo mockb-v2 y haga clic en Scale en la columna Actions. En el cuadro de diálogo Scale, establezca Desired Pod Count en 1 y haga clic en OK. En el cuadro de diálogo Confirm, haga clic en OK para simular un error en el servicio mockb de la versión v2.

Ejecute el siguiente comando para revisar las respuestas del carril de tráfico v2.

for i in {1..100};  do curl   -H 'x-asm-prefer-tag: v2' http://${ASM_GATEWAY_IP}/mock ;  echo ''; sleep 1; done;

Salida esperada:

-> mocka(version: v2, ip: 172.17.0.9)-> mockb(version: v1, ip: 172.17.0.126)-> mockc(version: v1, ip: 172.17.0.128)

La salida esperada indica que el tráfico con el encabezado HTTP x-asm-prefer-tag: v2 fluye hacia los servicios de la versión v2. Cuando el tráfico pasa por el servicio mockb de la versión v2, la solicitud se envía a la cadena de invocación de la versión v1 del servicio porque el servicio mockb de la versión v2 falló. De esta manera se implementa la degradación de tráfico.