Revisiones del plano de control de Cloud Service Mesh

Nota: Esta guía solo admite Cloud Service Mesh con APIs de Istio y no admite APIs de Google Cloud . Para obtener más información, consulta la descripción general de Cloud Service Mesh.

Esta página se aplica a las implementaciones del plano de control ISTIOD en el clúster y gestionado. Esta página no se aplica a la implementación del plano de control de TRAFFIC_DIRECTOR, que es un plano de control global multiinquilino sin revisiones individuales.

En esta página se describe cómo funcionan las revisiones del plano de control y el valor de usarlas para realizar actualizaciones (y restauraciones) seguras de la malla de servicios.

Aspectos básicos de la instalación de mallas de servicios

A grandes rasgos, la instalación de Cloud Service Mesh consta de dos fases principales:

1. Primero, usa la herramienta asmcli para instalar un plano de control en el clúster o configurar el plano de control gestionado. El plano de control consta de un conjunto de servicios del sistema responsables de gestionar la configuración de la malla.

2. A continuación, implementas un proxy sidecar especial en todo tu entorno que intercepta la comunicación de red hacia y desde cada carga de trabajo. Los proxies se comunican con el plano de control para obtener su configuración, lo que te permite dirigir y controlar el tráfico (tráfico del plano de datos) en tu malla sin tener que hacer ningún cambio en tus cargas de trabajo.

   Para desplegar los proxies, se usa un proceso llamado inyección automática de sidecar (inyección automática) para ejecutar un proxy como contenedor sidecar adicional en cada uno de los pods de carga de trabajo. No es necesario que modifiques los manifiestos de Kubernetes que usas para desplegar tus cargas de trabajo, pero sí que añadas una etiqueta a tus espacios de nombres y reinicies los pods.

Usar revisiones para actualizar tu malla de forma segura

La capacidad de controlar el tráfico es una de las principales ventajas de usar una malla de servicios. Por ejemplo, puedes dirigir el tráfico gradualmente a una nueva versión de una aplicación cuando la implementes por primera vez en producción. Si detecta problemas durante la actualización, puede volver a dirigir el tráfico a la versión original, lo que le ofrece una forma sencilla y de bajo riesgo de revertir el proceso. Este procedimiento se conoce como lanzamiento canary y reduce considerablemente el riesgo asociado a las nuevas implementaciones.

Nota: Otra forma de actualizar es la actualización in situ, en la que se actualiza instalando una nueva versión del plano de control. La nueva versión del plano de control sustituye inmediatamente a la anterior. Las actualizaciones in situ son arriesgadas, ya que, si se producen errores, puede ser difícil revertir el proceso. Para volver a insertar los proxies y que se comuniquen con la nueva versión del plano de control, debes reiniciar todas las cargas de trabajo en todos tus espacios de nombres. En función del número de cargas de trabajo y espacios de nombres de tu malla, todo el proceso de actualización puede tardar una hora o más. Las actualizaciones in situ pueden provocar tiempos de inactividad y deben programarse en ventanas de mantenimiento.

Si usas revisiones del plano de control en una actualización canary, instalarás un plano de control y una configuración nuevos e independientes junto al plano de control actual. El instalador asigna una cadena llamada revisión para identificar el nuevo plano de control. Al principio, los proxies sidecar siguen recibiendo la configuración de la versión anterior del plano de control. Asocia gradualmente las cargas de trabajo con el nuevo plano de control etiquetando sus espacios de nombres o pods con la nueva revisión del plano de control. Una vez que hayas etiquetado un espacio de nombres o pods con la nueva revisión, reinicia los pods de la carga de trabajo para que se inserten automáticamente los nuevos sidecars y reciban su configuración del nuevo plano de control. Si hay problemas, puedes volver a la versión anterior fácilmente asociando las cargas de trabajo con el plano de control original.

¿Cómo funciona la inyección automática?

La inyección automática usa una función de Kubernetes llamada control de admisión. Se registra un webhook de admisión mutante para monitorizar los pods recién creados. El webhook se configura con un selector de espacio de nombres para que solo coincida con los pods que se implementan en espacios de nombres que tienen una etiqueta concreta. Cuando se encuentra una coincidencia con un pod, el webhook consulta un servicio de inyección proporcionado por el plano de control para obtener una configuración nueva y modificada del pod, que contiene los contenedores y los volúmenes necesarios para ejecutar el sidecar.

1. Una configuración de webhook se crea durante la instalación. El webhook se registra en el servidor de la API de Kubernetes.
2. El servidor de la API de Kubernetes monitoriza las implementaciones de pods en los espacios de nombres que coinciden con el webhook namespaceSelector.
3. Se etiqueta un espacio de nombres para que coincida con namespaceSelector.
4. Los pods implementados en el espacio de nombres activan el webhook.
5. El servicio inject proporcionado por el plano de control muta las especificaciones de los pods para insertar automáticamente el sidecar.

¿Qué es una revisión?

La etiqueta que se usa para la inyección automática es como cualquier otra etiqueta de Kubernetes definida por el usuario. Una etiqueta es básicamente un par clave-valor que se puede usar para admitir el concepto de etiquetado. Las etiquetas se usan mucho para etiquetar y para las revisiones. Por ejemplo, etiquetas de Git, etiquetas de Docker y revisiones de Knative.

El proceso de instalación actual de Cloud Service Mesh te permite etiquetar el plano de control instalado con una cadena de revisión. El instalador etiqueta cada objeto del plano de control con la revisión. La clave del par clave-valor es istio.io/rev, pero el valor de la etiqueta de revisión es diferente para el plano de control gestionado y los planos de control en el clúster.

• En el caso de los planos de control en el clúster, el istiod servicio y el despliegue suelen tener una etiqueta de revisión similar a istio.io/rev=asm-1246-9, donde asm-1246-9 identifica la versión de Cloud Service Mesh. La revisión pasa a formar parte del nombre del servicio. Por ejemplo: istiod-asm-1246-9.istio-system

• En el plano de control gestionado, la etiqueta de revisión corresponde a un canal de lanzamiento:

  Etiqueta de revisión	Canal
  istio.io/rev=asm-managed	Normal
  istio.io/rev=asm-managed-rapid	Rápido
  istio.io/rev=asm-managed-stable	Estable

Además, tiene la opción de usar etiquetas de inyección predeterminadas (por ejemplo, istio-injection=enabled).

Para habilitar la inyección automática, añade una etiqueta de revisión a tus espacios de nombres que coincida con la etiqueta de revisión del plano de control. Por ejemplo, un plano de control con la revisión istio.io/rev=asm-1246-9 selecciona los pods de los espacios de nombres con la etiqueta istio.io/rev=asm-1246-9 e inserta sidecars.

Proceso de actualización canary

Las etiquetas de revisión permiten realizar actualizaciones canary y restauraciones sencillas del plano de control en el clúster. El control gestionado usa un proceso similar, pero tu clúster se actualiza automáticamente a la versión más reciente de ese canal.

A continuación, se describe cómo funciona el proceso:

1. Empieza con una instalación de Cloud Service Mesh o Istio de código abierto. No importa si los espacios de nombres usan una etiqueta de revisión o la etiqueta istio-injection=enabled.
2. Usa una cadena de revisión al instalar la nueva versión del plano de control. Debido a la cadena de revisión, el nuevo plano de control se instala junto con la versión actual. La nueva instalación incluye una nueva configuración de webhook con un namespaceSelector configurado para monitorizar los espacios de nombres con esa etiqueta de revisión específica.
3. Para migrar los proxies sidecar al nuevo plano de control, elimina la etiqueta antigua del espacio de nombres, añade la nueva etiqueta de revisión y reinicia los pods. Si utilizas revisiones con Cloud Service Mesh, debes dejar de usar la etiqueta istio-injection=enabled. Un plano de control con una revisión no selecciona pods en espacios de nombres con una etiqueta istio-injection, aunque haya una etiqueta de revisión. El webhook del nuevo plano de control inserta sidecars en los pods.
4. Prueba detenidamente las cargas de trabajo asociadas al plano de control actualizado y sigue implementando la actualización o vuelve al plano de control original.

Después de asociar los pods al nuevo plano de control, el plano de control y el webhook anteriores seguirán instalados. El webhook antiguo no tiene ningún efecto en los pods de los espacios de nombres que se han migrado al nuevo plano de control. Puedes revertir los pods de un espacio de nombres al plano de control original quitando la nueva etiqueta de revisión, volviendo a añadir la etiqueta original y reiniciando los pods. Cuando tengas la certeza de que la actualización se ha completado, puedes quitar el plano de control antiguo.

Para ver los pasos detallados sobre cómo actualizar mediante revisiones, consulta la guía de actualización.

Análisis detallado de una configuración de webhook mutante

Para entender mejor el webhook de mutación de la inyección automática de sidecar, inspecciona la configuración. Usa el siguiente comando:

kubectl -n istio-system get mutatingwebhookconfiguration -l app=sidecar-injector -o yaml

Debería ver una configuración independiente para cada plano de control que haya instalado. Un selector de espacio de nombres para un plano de control basado en revisiones tiene este aspecto:

 namespaceSelector:
    matchExpressions:
    - key: istio-injection
      operator: DoesNotExist
    - key: istio.io/rev
      operator: In
      values:
      - asm-1246-9

El selector puede variar en función de la versión de Cloud Service Mesh o Istio que estés usando. Este selector coincide con los espacios de nombres que tienen una etiqueta de revisión específica siempre que no tengan también una etiqueta istio-injection.

Cuando se implementa un pod en un espacio de nombres que coincide con el selector, su especificación de pod se envía al servicio de inyector para que se modifique. El servicio de inyector al que se debe llamar se especifica de la siguiente manera:

     service:
        name: istiod-asm-1246-9
        namespace: istio-system
        path: /inject
        port: 443

Nota: En el caso de Cloud Service Mesh gestionado, el servicio gestionado por Google se especifica mediante url: en lugar de service:.

El plano de control expone el servicio en el puerto 443 en la ruta de la URL inject.

En la sección rules se especifica que el webhook se debe aplicar a la creación de pods:

   rules:
    - apiGroups:
      - ""
      apiVersions:
      - v1
      operations:
      - CREATE
      resources:
      - pods
      scope: '*'

Siguientes pasos

• Actualizar Cloud Service Mesh
• Inyectar proxies de sidecar