Implement session persistence in an ASM gateway - Alibaba Cloud Service Mesh

Las aplicaciones con estado, como los carritos de compras, las sesiones de inicio de sesión y los paneles personalizados, requieren que todas las solicitudes de un mismo cliente lleguen al mismo pod de backend. La afinidad de sesión (sticky sessions) en ASM dirige las solicitudes a un backend constante mediante la aplicación de hash consistente en una regla de destino de Istio.

El hash consistente asigna cada solicitud a un backend con base en una clave de hash: una cookie, un encabezado HTTP, una IP de origen o un parámetro de consulta. Esto proporciona una afinidad de sesión flexible. Las solicitudes de un mismo cliente suelen llegar al mismo pod, pero la afinidad puede romperse cuando se agregan o eliminan backends.

Cómo funciona

Algoritmos de hash

Envoy admite dos algoritmos de hash consistente:

Algoritmo	Predeterminado	Cuándo usarlo
HashRing	Sí	Afinidad de sesión de uso general con una rotación moderada de backends
Maglev	No	Escenarios de alto rendimiento donde importa la velocidad de búsqueda. Requiere ASM v1.16 o posterior

Requisitos previos

Antes de empezar, compruebe que cuenta con lo siguiente:

Un clúster de Container Service for Kubernetes (ACK) agregado a su instancia de Service Mesh (ASM). Para obtener más información, consulte Add a cluster to an ASM instance
Una puerta de enlace de entrada con el puerto 80 expuesto. Para obtener más información, consulte Create an ingress gateway
La aplicación HTTPBin desplegada. Para obtener más información, consulte Deploy the HTTPBin application

Configurar la afinidad de sesión basada en cookies

Este tutorial muestra cómo configurar la afinidad de sesión basada en cookies. La misma estructura de DestinationRule aplica para otros tipos de claves de hash; solo debe reemplazar el bloque httpCookie por el campo correspondiente.

Paso 1: Escalar el despliegue de HTTPBin a tres réplicas

Se necesitan tres réplicas para observar cómo se distribuyen las solicitudes entre los pods. Conéctese al plano de datos del clúster de ACK con kubectl y ejecute el siguiente comando:

kubectl scale deployment/httpbin --replicas 3

Paso 2: Comprobar la distribución de solicitudes sin afinidad de sesión

Abra http://<ingress-gateway-ip>/status/418 en un navegador y actualice la página varias veces.

Para consultar las instrucciones sobre cómo obtener la IP de la puerta de enlace de entrada, vea el subpaso 1 del paso 3 en Use Istio resources to route traffic to different versions of a service.
Revise los registros de la puerta de enlace para confirmar que las solicitudes se distribuyen entre los tres pods:
1. Inicie sesión en la consola de ASM. En el panel de navegación izquierdo, elija Service Mesh > Mesh Management.
2. En la página Mesh Management, haga clic en el nombre de la instancia de ASM. En el panel de navegación izquierdo, elija ASM Gateways > Ingress Gateway.
3. En la página Ingress Gateway, busque la puerta de enlace de entrada de destino y haga clic en Log Center. En la pestaña Gateway Logs, agregue and 418 al cuadro de búsqueda y haga clic en Search & Analyze. En la pestaña Raw Logs, ubicada en la esquina inferior izquierda, expanda el índice upstream_addr.
Los registros muestran que las solicitudes se distribuyen de manera aproximadamente uniforme entre los tres pods de HTTPBin.

Paso 3: Crear una regla de destino para la afinidad de sesión basada en cookies

Aplique a continuación el recurso DestinationRule. Para obtener detalles sobre cómo gestionar reglas de destino, consulte Manage destination rules.

apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: httpbin
  namespace: default
spec:
  host: httpbin.default.svc.cluster.local
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpCookie:
          name: sticky-session-key
          ttl: 0s

Campo	Valor	Descripción
`host`	`httpbin.default.svc.cluster.local`	Nombre de host completo del servicio al que aplica esta regla
`consistentHash.httpCookie.name`	`sticky-session-key`	Nombre de la cookie que se usa como clave de hash
`consistentHash.httpCookie.ttl`	`0s`	Tiempo de vida de la cookie

Después de aplicar esta regla, ocurre lo siguiente:

En la primera solicitud (sin cookie presente), la puerta de enlace genera un hash a partir de las direcciones IP y los puertos de origen y destino. Luego dirige la solicitud a un backend y establece la cookie sticky-session-key en la respuesta.
En las solicitudes posteriores, el cliente envía esta cookie de vuelta. La puerta de enlace calcula el hash del valor de la cookie para determinar el backend y dirige la solicitud al mismo pod.

Este ejemplo utiliza el algoritmo predeterminado HashRing. Para usar Maglev (requiere ASM v1.16 o posterior), agregue el campo hashAlgorithm a su política de tráfico según sus necesidades.

Paso 4: Comprobar que la afinidad de sesión funciona correctamente

Abra http://<ingress-gateway-ip>/status/333 en un navegador y actualice la página varias veces.

Para consultar las instrucciones sobre cómo obtener la IP de la puerta de enlace de entrada, vea el subpaso 1 del paso 3 en Use Istio resources to route traffic to different versions of a service.
Revise los registros de la puerta de enlace para confirmar que todas las solicitudes llegan al mismo pod:
1. Inicie sesión en la consola de ASM. En el panel de navegación izquierdo, elija Service Mesh > Mesh Management.
2. En la página Mesh Management, haga clic en el nombre de la instancia de ASM. En el panel de navegación izquierdo, elija ASM Gateways > Ingress Gateway.
3. En la página Ingress Gateway, busque la puerta de enlace de entrada de destino y haga clic en Log Center. En la pestaña Gateway Logs, agregue and 333 al cuadro de búsqueda y haga clic en Search & Analyze. En la pestaña Raw Logs, ubicada en la esquina inferior izquierda, expanda el índice upstream_addr.
Los registros muestran que todas las solicitudes se dirigen al mismo pod de backend.
Confirme la cookie en el navegador: abra las herramientas de desarrollo, haga clic en la pestaña Network, actualice la página e inspeccione una solicitud. La respuesta incluye una cookie sticky-session-key que coincide con el nombre definido en el recurso DestinationRule. La puerta de enlace utiliza esta cookie para mantener la afinidad de sesión.