Canales de versiones de Managed Cloud Service Mesh

Cloud Service Mesh lanza actualizaciones con frecuencia para entregar actualizaciones de seguridad, solucionar problemas conocidos e introducir funciones nuevas. Equilibrio de los canales de versiones entre y el conjunto de atributos de la versión de Cloud Service Mesh. Malla de servicios en la nube canales de versiones están vinculados Canales de versiones de Google Kubernetes Engine (GKE). Google administra automáticamente la versión y la cadencia de actualización de cada versión. canal.

Nota: La malla de servicios de Cloud administrada consta del plano de control administrado y en el plano de datos. Ambos componentes usan el mismo canal de versiones.

En este documento, se abordan comparaciones de canales de versiones y cómo actualizar con 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 administrado	Propiedades
Rápido	Después de cada lanzamiento de la malla de servicios de Cloud	Obtén la versión más reciente de Cloud Service Mesh lo antes posible y puedan usar las funciones nuevas desde el momento en que se incluyen en una versió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 versiones más recientes de Cloud Service Mesh y APIs en entornos de preproducción.
Normal	Rápido asciende a regular*	Acceder a las funciones de Istio y Cloud Service Mesh poco tiempo después de que debut, pero en una versión que ha sido calificada por un período más largo tiempo. 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 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 administrado tiene suficiente uso y demostró estabilidad en el canal Rápido, se asciende al canal Regular canal. 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. Nueva malla de servicios en la nube se lanzan por primera vez en el canal rápido y, con el tiempo, se promueven el canal regular y el estable. Esto te permite seleccionar un canal que cumpla con tus necesidades empresariales, de estabilidad y funcionalidad.

El canal de la malla de servicios de Cloud de tu clúster está determinado por su GKE en el canal del clúster.

Canal de GKE	Canal de la malla de servicios de Cloud
Rápido	Rápido
Normal	Normal
Estable	Estable
(sin canal)	Normal

Versiones de Cloud Service Mesh por canal

El clúster de GKE determina el canal de la malla de servicios de Cloud cuando se aprovisionan Cloud Service Mesh administrado. Si cambias el en el canal del clúster de GKE más adelante, en el canal de Cloud Service Mesh.

En la siguiente tabla, se muestra la asignación de la versión del canal actual a Cloud Service Mesh:

Canal	Versión de la malla de servicios de Cloud
Rápido	1.19
Normal	1.18
Estable	1.18

Canal predeterminado

En una malla de servicios de Cloud recién instalada en la que hay un solo canal administrado instalado en un clúster, ese canal será el predeterminado para ese clúster.

Si los clústeres con una instalación existente de Istio o Cloud Service Mesh tienen etiqueta predeterminada, debe 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 inyección en las otras etiquetas que usas para el canal, como el 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 el espacio de nombres debe estar etiquetado con la etiqueta correspondiente al canal instalado. La malla de servicios de Cloud administrada 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 canales stable, regular y rapid.
• etiqueta de inyección predeterminada (por ejemplo, istio-injection=enabled), que corresponde al canal predeterminado para ese clúster. El uso de la etiqueta de inserción predeterminada simplifica la migración entre revisiones. Por ejemplo, cuando migrar desde Istio OSS o desde de Cloud Service Mesh no administrado a Cloud Service Mesh administrado, ya que no es necesario vuelve a etiquetar cada espacio de nombres de forma individual. Donde se muestre la documentación de Cloud Service Mesh a fin de usar la etiqueta de espacio de nombres istio.io/rev para la inyección, puedes usar la etiqueta istio-injection=enabled.

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:

Nota: Aunque también puedes usar istio.io/rev=default en lugar de istio-injection=enabled como etiqueta de inyección predeterminada, te recomendamos estandariza en torno a istio-injection=enabled.

kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev- --overwrite

Nota: Puedes ignorar el mensaje "istio-injection not found" en el resultado. Eso significa que el espacio de nombres no tenía el elemento Etiqueta istio-injection, que debes esperar en los nuevos o implementaciones nuevas de la malla de servicios de Cloud.

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 tu servicios y puertas de enlace. Aunque la malla de servicios funciona bien cuando plano de control y los proxies están en versiones diferentes, te recomendamos actualizar los proxies para que estén configurados con la nueva malla de servicios de Cloud versión.

1. Verifica el plano de control y la versión del proxy.

2. 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