Revisiones del plano de control de Cloud Service Mesh

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

Información básica de instalación de malla de servicios

En un nivel alto, la instalación de Cloud Service Mesh consta de dos fases principales:

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

2. A continuación, debes implementar un proxy de sidecar especial en 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 torno a la malla sin hacer ningún cambio en tus cargas de trabajo.

   Para implementar los proxies, usa un proceso denominado inserción automática de sidecar (inserción automática) para ejecutar un proxy como un contenedor de sidecar adicional en cada Pod de carga de trabajo. No necesitas modificar los manifiestos de Kubernetes que usas para implementar tus cargas de trabajo, pero sí necesitas agregar una etiqueta a los espacios de nombres y reiniciar los Pods.

Usa las revisiones para actualizar la 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 cambiar el tráfico de manera gradual a una versión nueva de una aplicación cuando la implementas en producción por primera vez. Si detectas problemas durante la actualización, puedes revertir el tráfico a la versión original, lo que proporciona un medio simple y de bajo riesgo de reversión. Este procedimiento se conoce como lanzamiento Canary y reduce en gran medida el riesgo asociado con implementaciones nuevas.

Nota: Un tipo alternativo de actualización es una actualización in situ en la que se instala una versión nueva del plano de control. La versión del plano de control nueva reemplaza de inmediato a la versión anterior. Las actualizaciones en el lugar son riesgosas, ya que si hay fallas, la reversión puede ser difícil. Para volver a insertar los proxies y hacer que se comuniquen con la nueva versión del plano de control, era necesario reiniciar todas las cargas de trabajo en todos los espacios de nombres. Según la cantidad de cargas de trabajo y espacios de nombres en la malla, el proceso de actualización completo podría demorar una hora o más. Las actualizaciones locales pueden provocar un tiempo de inactividad y deben programarse en los períodos de mantenimiento.

Mediante las revisiones del plano de control en una actualización canary, puedes realizar una configuración y, también, instalar un plano de control nuevo y separado junto con el plano de control existente. El instalador asigna una string llamada revisión para identificar el nuevo plano de control. Al principio, los proxies de sidecar siguen recibiendo la configuración de la versión anterior del plano de control. Para asociar gradualmente las cargas de trabajo con el nuevo plano de control, debes etiquetar sus espacios de nombres o pods con la revisión nueva del plano de control. Una vez que hayas etiquetado un espacio de nombres o Pods con la revisión nueva, reinicia los Pods de la carga de trabajo para que se incorporen automáticamente los nuevos sidecars y reciban su configuración del plano de control nuevo. Si hay problemas, puedes asociar las cargas de trabajo con el plano de control original para revertirlos con facilidad.

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

La inserción automática usa una función de Kubernetes llamada control de admisión. Un webhook de admisión de mutación está registrado para observar Pods nuevos. 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 particular. Cuando un Pod coincide, el webhook consulta un servicio de inserción que proporciona el plano de control para obtener una configuración nueva y mutada del Pod, que contiene los contenedores y volúmenes necesarios a fin de ejecutar el sidecar.

1. La configuración de webhook se crea durante la instalación. El webhook se registra con el servidor de la API de Kubernetes.
2. El servidor de la API de Kubernetes observa las implementaciones del Pod en 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 que proporciona el plano de control modifica las especificaciones del pod para insertar automáticamente el sidecar.

¿Qué es una revisión?

La etiqueta que se usa para la inserción automática es como cualquier otra etiqueta de Kubernetes definida por el usuario. Una etiqueta es, en esencia, un par clave-valor que se puede usar para respaldar el concepto de etiquetado. Las etiquetas se usan mucho para el etiquetado y las revisiones. Por ejemplo, las etiquetas de Git, las etiquetas de Docker y las 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 todos los objetos del plano de control con la revisión. La clave en el par clave-valor es istio.io/rev, pero el valor de la etiqueta de revisión difiere para el plano de control administrado y el del clúster.

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

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

  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, tienes la opción de usar etiquetas de inyección predeterminadas (por ejemplo, istio-injection=enabled).

Para habilitar la inserción automática, agrega una etiqueta de revisión a tus espacios de nombres que coincida con la etiqueta de revisión en el plano de control. Por ejemplo, un plano de control con revisión istio.io/rev=asm-1233-2 selecciona Pods en espacios de nombres con la etiqueta istio.io/rev=asm-1233-2 y, luego, inserta sidecars.

El proceso de actualización de la versión canary

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

En los siguientes pasos, se describe el funcionamiento del proceso:

1. Comienza con una instalación existente 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 string de revisión cuando instales la versión nueva del plano de control. Debido a la string de revisión, el nuevo plano de control se instala junto con la versión existente. La instalación nueva incluye una configuración de webhook nueva con un namespaceSelector configurado para observar espacios de nombres con esa etiqueta de revisión específica.
3. Debes migrar los proxies de sidecar al nuevo plano de control si quitas la etiqueta antigua del espacio de nombres, agregas la etiqueta de revisión nueva y reinicias los Pods. Si usas revisiones con Cloud Service Mesh, deberás 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, incluso si hay una etiqueta de revisión. El webhook para el plano de control nuevo inserta sidecars en los Pods.
4. Prueba con cuidado las cargas de trabajo asociadas con el plano de control actualizado y continúa lanzando la actualización o reviértela al plano de control original.

Después de asociar los Pods con el plano de control nuevo, el plano de control y el webhook existentes aún estarán instalados. El webhook anterior no tiene efecto para los Pods en los espacios de nombres que se migraron al nuevo plano de control. Puedes revertir los Pods en un espacio de nombres al plano de control original si quitas la nueva etiqueta de revisión, agregas la etiqueta original y reinicias los Pods. Cuando estés seguro de que la actualización estará completa, puedes quitar el plano de control anterior.

Para obtener pasos detallados sobre cómo actualizar mediante revisiones, consulta la Guía de actualización.

Un análisis más detallado de la configuración del webhook

Para comprender mejor el webhook de mutación para la inserción automática de sidecar, inspecciona la configuración tú mismo. Usa el siguiente comando:

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

Deberías ver una configuración separada para cada plano de control que instalaste. Un selector de espacio de nombres para un plano de control basado en revisiones se ve de la siguiente manera:

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

El selector puede variar según la versión de Cloud Service Mesh o Istio que ejecutes. Este selector hace coincidir los espacios de nombres con una etiqueta de revisión específica, siempre y cuando no tengan una etiqueta istio-injection.

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

     service:
        name: istiod-asm-1233-2
        namespace: istio-system
        path: /inject
        port: 443

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

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

En la sección rules, se especifica que el webhook debe aplicarse a la creación de Pods:

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

¿Qué sigue?

• Actualiza Cloud Service Mesh
• Incorpora proxies de sidecar