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. 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.
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 versión de Cloud Service Mesh | 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 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 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
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 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 Cloud Service Mesh |
---|---|
Rápido | 1.19 |
Normal | 1.19 |
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 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 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 canalesstable
,regular
yrapid
. - 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 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. Donde se muestre la documentación de Cloud Service Mesh a fin de usar la etiqueta de espacio de nombresistio.io/rev
para la inyección, puedes usar la etiquetaistio-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:
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 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.
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