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, que, por lo general, se automatizan con la secuencia de comandos install_asm. Primero, usa la herramienta de línea de comandos istioctl y los archivos YAML de IstioOperator para instalar el plano de control y su configuración. El plano de control (también conocido como istiod) consta de un conjunto de servicios del sistema que son 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) alrededor de 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 Istio para obtener una configuración nueva y mutada del Pod, que contiene los contenedores y volúmenes necesarios a fin de ejecutar el archivo adicional.
- 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 istiod muda las especificaciones del Pod para incorporar 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 Anthos Service Mesh te permite etiquetar el plano de control instalado con una string de revisión, como un argumento revision para los comandos istioctl y como un campo en el objeto IstioOperator recurso personalizado. El instalador etiqueta cada objeto del plano de control con la revisión, incluido el servicio y la implementación de istiod. La revisión pasa a formar parte del nombre del servicio, por ejemplo, istiod-asm-173-6.istio-system.
La clave de etiqueta correspondiente para los espacios de nombres es istio.io/rev y el valor, por lo general, se configura a fin de indicar la versión de la malla. Por ejemplo, un plano de control con revisión asm-173-6 selecciona Pods en espacios de nombres con la etiqueta istio.io/rev=asm-173-6 y, luego, inserta sidecars.
El proceso de actualización de la versión canary
Las etiquetas de revisión permiten realizar actualizaciones de la versión Canary y reversiones sencillas del plano de control.
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
istiod expone el servicio en el puerto 443 en la ruta de URL inject.
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.