Canales de versiones de Cloud Service Mesh administrado
Cloud Service Mesh lanza actualizaciones con frecuencia para entregar actualizaciones de seguridad, solucionar problemas conocidos e ingresar características nuevas. Los canales de versiones equilibran la estabilidad y el conjunto de atributos de la versión de Cloud Service Mesh. Los canales de versiones de Cloud Service Mesh están vinculados a los canales de versiones de Google Kubernetes Engine (GKE). Google administra automáticamente la versión y la cadencia de actualización de cada canal de versiones.
En este documento, se explican las comparaciones de canales de versiones y cómo actualizar proxies no administrados.
Canales de versiones disponibles
Están disponibles los siguientes canales de versiones. Cada uno tiene una cadencia de actualización diferente y ofrece una compensación entre la disponibilidad de la característica y la renovación de la actualización. Las funciones de cada canal tienen un nivel de madurez diferente. Los parches de seguridad críticos se entregan a todos los canales de versiones para proteger tus clústeres y la infraestructura de Google.
Canal | Nueva disponibilidad de Cloud Service Mesh administrada | Propiedades |
---|---|---|
Rápido | Después de cada versión de Cloud Service Mesh | Obtén la versión más reciente de Cloud Service Mesh lo antes posible y usa las funciones nuevas apenas se incluyan en una actualización. Tu plano de control se actualiza con frecuencia para que se mantenga en la última versión de parche disponible y entregue capacidades más nuevas. El canal rápido se usa mejor para probar las versiones más recientes de Cloud Service Mesh y las APIs en entornos de preproducción. |
Normal | Rápido asciende a regular* | Accede a las funciones de Istio y Cloud Service Mesh poco después de su lanzamiento, pero en una versión calificada durante un período más largo. Ofrece un equilibrio entre la disponibilidad de las características y la estabilidad de las actualizaciones, y es lo que recomendamos para la mayoría de los usuarios. |
Estable | El formato regular asciende a Estable* | Prioriza la estabilidad por encima de las nuevas funcionalidades. Los cambios y las versiones nuevas de este canal se lanzan en último lugar, después del vencimiento en los canales rápidos y regulares, lo que permite más tiempo para la validación. |
*El programa de promoción al siguiente canal depende de varios factores, incluidos el lanzamiento de Istio de código abierto, el lanzamiento de Anthos y el programa de parches, y, por lo tanto, está sujeto a cambios. Para mantenerte informado con la información más reciente, agrega la URL de las notas de la versión de Cloud Service Mesh a tu lector de feeds o agrega directamente la URL del feed: https://cloud.google.com/feeds/servicemesh-release-notes.xml
|
Cuando una versión secundaria de Cloud Service Mesh administrada tiene suficiente uso y demostró estabilidad en el canal rápido, asciende al canal regular. Por último, la versión secundaria asciende al canal estable, que solo recibe actualizaciones y parches de seguridad de prioridad alta. Cada promoción señala un nivel gradual de estabilidad y preparación para la producción, según el rendimiento observado del plano de control que ejecuta esa versión.
Todos los canales se basan en una versión con disponibilidad general (DG), aunque es posible que las características individuales no siempre sean de disponibilidad general, como se indica. Las versiones nuevas de Cloud Service Mesh se lanzan por primera vez en el canal rápido y, con el tiempo, ascienden al canal regular y estable. Esto te permite seleccionar un canal que cumpla con tus necesidades empresariales, de estabilidad y funcionalidad.
El canal de Cloud Service Mesh de tu clúster se determina según el canal de clúster de GKE.
Canal de GKE | Canal de Cloud Service Mesh |
---|---|
Rápido | Rápido |
Normal | Normal |
Estable | Estable |
(sin canal) | Normal |
Versiones de Cloud Service Mesh por canal
Tu canal de Cloud Service Mesh se determina según el canal de tu clúster de GKE en el momento de aprovisionar Cloud Service Mesh administrado. Si cambias el canal del clúster de GKE más adelante, conservarás el canal original de Cloud Service Mesh.
En la siguiente tabla, se muestra el canal actual para la asignación de versiones de Cloud Service Mesh:
Canal | Versión de Cloud Service Mesh |
---|---|
Rápido | 1.19 |
Normal | 1.19 |
Estable | 1.19 |
Canal predeterminado
En una Cloud Service Mesh recién instalada en la que hay un solo canal administrado instalado en un clúster, ese canal será el canal predeterminado para ese clúster.
Si los clústeres con una instalación existente de Istio o Cloud Service Mesh tienen la etiqueta predeterminada configurada, deben apuntar a la revisión administrada. De lo contrario, no es necesario realizar ninguna acción.
Puedes usar la etiqueta istio-injection=enabled
como un alias que apunta a la inserción de las otras etiquetas que usas para el canal, como la revisión predeterminada. Siempre que se muestre la documentación a fin de usar la etiqueta de espacio de nombres istio.io/rev
para la inserción, es posible usar la etiqueta istio-injection=enabled
en su lugar.
Etiquetas de inserción
Para permitir que Cloud Service Mesh administre las cargas de trabajo en un espacio de nombres determinado, el espacio de nombres debe estar etiquetado con una etiqueta correspondiente al canal instalado. Cloud Service Mesh administrado admite dos tipos de etiquetas:
- Etiquetas de revisión estándar, es decir,
asm-managed-stable
,asm-managed
,asm-managed-rapid
, que corresponden a los canalesstable
,regular
yrapid
. - Etiqueta de inserción predeterminada (por ejemplo,
istio-injection=enabled
), que corresponde al canal predeterminado de ese clúster. El uso de la etiqueta de inserción predeterminada simplifica la migración entre revisiones. Por ejemplo, cuando migras de Istio OSS o de Cloud Service Mesh no administrado a Cloud Service Mesh administrado, ya que no es necesario volver a etiquetar cada espacio de nombres de forma individual. Siempre que la documentación de Cloud Service Mesh muestre que se usa la etiqueta de espacio de nombresistio.io/rev
para la inserción, es posible usar la etiquetaistio-injection=enabled
en su lugar.
Otros ejemplos de etiquetas de inserción incluyen el etiquetado de cargas de trabajo con sidecar.istio.io/inject
(comúnmente se usa para puertas de enlace) y istio.io/rev
, que funciona tanto en el espacio de nombres como en las cargas de trabajo.
Etiquetas de inserción predeterminadas
Para aplicar la etiqueta de inserción predeterminada a un espacio de nombres, haz lo siguiente:
kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite
Etiquetas de revisión
Al igual que otras etiquetas de Kubernetes, una etiqueta de revisión es un par clave-valor.
La clave en una etiqueta de revisión siempre es istio.io/rev
, pero el valor varía.
Para seleccionar un canal de versiones, aplica uno de los siguientes nombres de revisión a tus espacios de nombres:
Nombre de la revisión | Canal |
---|---|
asm-managed |
Normal |
asm-managed-rapid |
Rápido |
asm-managed-stable |
Estable |
Por ejemplo, para aplicar el canal de versiones regular a un espacio de nombres, haz lo siguiente:
kubectl label namespace NAMESPACE istio.io/rev=asm-managed --overwrite
Te recomendamos usar el mismo canal de versiones que usa el clúster.
Para ver qué canal de versiones usa un espacio de nombres, haz lo siguiente:
kubectl get namespace NAMESPACE -o jsonpath='{.metadata.labels.istio\.io/rev}{"\n"}'
Actualiza los proxies no administrados
Después de cada lanzamiento de Cloud Service Mesh, reinicia los proxies no administrados de tus servicios y puertas de enlace. Aunque la malla de servicios funciona bien cuando el plano de control y los proxies están en versiones diferentes, te recomendamos actualizar los proxies para que se configuren con la versión nueva de Cloud Service Mesh.
Verifica el plano de control y la versión del proxy.
Si la versión del plano de control es más reciente que la versión del proxy, reinicia los proxies no administrados para tus servicios y puertas de enlace.
kubectl rollout restart deployment -n NAMESPACE