Revisiones del plano de control de la malla de servicios de Cloud
Esta página se aplica a las implementaciones del plano de control ISTIOD administradas y en el clúster.
Esta página no se aplica a la implementación del plano de control de TRAFFIC_DIRECTOR.
que es un plano de control global multiusuario, sin revisiones individuales.
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:
Primero, usa la herramienta de
asmclipara 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.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.
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 el debes reiniciar los Pods de la carga de trabajo para que se inserten automáticamente y reciben su configuración del nuevo plano de control. 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. El webhook se registra 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 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. En esencia, una etiqueta de recurso es un par clave-valor que se puede usar para respaldar la de etiquetado. Las etiquetas se usan mucho para el etiquetado y las revisiones. Por ejemplo, las etiquetas Git, las 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 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.
Para los planos de control en el clúster, el Service de
istiody la Deployment, por lo general, tendrás una etiqueta de revisión similar aistio.io/rev=asm-1233-2, en la queasm-1233-2identifica 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-managedNormal istio.io/rev=asm-managed-rapidRápido istio.io/rev=asm-managed-stableEstable
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:
- 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. - 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 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 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 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
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: '*'