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). Hasta la versión 1.6.8, el proceso de instalación predeterminado de Anthos Service Mesh no usaba revisiones de plano de control. La introducción de revisiones puede requerir un poco de esfuerzo y modificaciones en los procedimientos de instalación, pero te recomendamos que la uses, ya que aporta importantes beneficios.
Información básica de la malla de servicios
La instalación de Anthos Service Mesh consta de dos partes principales: primero, debes usar la herramienta de línea de comandos istioctl o la secuencia de comandos install_asm para instalar un plano de control en el clúster o configurar el plano de control administrado por Google. El plano de control consta de un conjunto de servicios del sistema responsables de administrar la configuración de la malla. A continuación, implementarás 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.
Antes de Anthos Service Mesh 1.6, actualizaste mediante la instalación de una versión nueva del plano de control que reemplazó de inmediato la versión anterior. Este procedimiento se conoce como actualización in situ y es riesgoso, ya que si hay fallas, revertir el proceso 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.
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.
Del mismo modo, puedes minimizar el riesgo asociado con la actualización de la malla de servicios. Anthos Service Mesh 1.6 y versiones posteriores admite actualizaciones de la versión canary mediante revisiones del plano de control. Con 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 con la revisión nueva del plano de control. Una vez que hayas etiquetado un espacio de nombres con la revisión nueva, reinicia los Pods de la carga de trabajo para que se incorporen 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.
- La configuración de webhook se crea durante la instalación. Registra webhook con el servidor de la API de Kubernetes.
- El servidor de la API de Kubernetes observa las implementaciones del Pod en espacios de nombres que coinciden con el webhook
namespaceSelector. - Se etiqueta un espacio de nombres para que coincida con
namespaceSelector. - Los Pods implementados en el espacio de nombres activan el webhook.
- El servicio
injectque proporciona el plano de control modifica las especificaciones del pod para insertar 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.
Hasta la versión 1.6.8 de Anthos Service Mesh, los procedimientos de instalación predeterminados establecieron una convención para configurar el selector de espacios de nombres en el webhook a fin de usar la etiqueta: istio-injection=enabled.
El proceso de instalación actual de Anthos Service Mesh te permite etiquetar el plano de control instalado con una string 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 por Google y el del clúster.
En los planos de control en el clúster, el servicio y la implementación de
istiodsuelen tener una etiqueta de revisión similar aistio.io/rev=asm-1106-2, en la queasm-1106-2identifica la versión de Anthos Service Mesh. La revisión pasa a formar parte del nombre del servicio, por ejemplo:istiod-asm-1106-2.istio-system.En el plano de control administrado por Google, la etiqueta de revisión corresponde a un canal de versiones:
Etiqueta de revisión Canal istio.io/rev=asm-managedNormal istio.io/rev=asm-managed-rapidRápido istio.io/rev=asm-managed-stableEstable
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-1106-2 selecciona Pods en espacios de nombres con la etiqueta istio.io/rev=asm-1106-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 por Google 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:
- Comienza con una Anthos Service Mesh existente o una instalación de Istio de código abierto. No importa si los espacios de nombres usan una etiqueta de revisión o la etiqueta
istio-injection=enabled. - 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
namespaceSelectorconfigurado para observar espacios de nombres con esa etiqueta de revisión específica. - 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 Anthos 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 etiquetaistio-injection, incluso si hay una etiqueta de revisión. El webhook para el plano de control nuevo inserta sidecars en los Pods. - 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 las Guías de actualización.
Un análisis más detallado de la configuración del webhook
La mejor manera de entender el webhook de mutación para la inserción automática del sidecar es inspeccionar la configuración. 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-173-6
El selector puede variar según la versión de Anthos 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-173-6
namespace: istio-system
path: /inject
port: 443
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: '*'
Resumen
A pesar de que podría tardar un tiempo en aplicarse el cambio del uso de etiquetas de revisión en tus espacios de nombres para habilitar la inyección automática, los beneficios que ofrecen las etiquetas de revisión proporcionan actualizaciones canary y seguras bien valen el esfuerzo.