Acerca de las actualizaciones de clústeres con secuencia de lanzamiento

Puedes administrar el orden y el horario de las actualizaciones de clústeres en los clústeres de Google Kubernetes Engine (GKE) en varios entornos con la secuencia de lanzamiento. Por ejemplo, puedes calificar una versión nueva en clústeres de producción previa antes de actualizar los clústeres de producción. Para comenzar, consulta Administra las actualizaciones de los clústeres en todos los entornos de producción.

En este documento, se explica la vista previa privada para la secuencia de lanzamiento. Para obtener más información sobre cómo cambiará esta función después de esta etapa de lanzamiento, consulta Cómo cambiarán las secuencias de lanzamiento después de una vista previa privada.

Para administrar las actualizaciones de clústeres mediante la secuencia de lanzamientos, primero organiza tus clústeres en flotas y permisos de flota. Las flotas te permiten agrupar y normalizar clústeres de forma lógica, por ejemplo, por su asociación con una etapa de implementación específica, como pruebas, etapa de pruebas o producción. Los permisos te permiten crear subconjuntos de clústeres miembros de la flota para que los usen equipos de aplicaciones específicos. En este documento, se explica cómo usar los permisos para organizar clústeres y crear secuencias de lanzamiento.

Después de organizar tus clústeres en permisos, debes elegir la secuencia de permisos y definir un tiempo de prueba entre permisos. Si quieres obtener más información sobre cómo usar los permisos para organizar clústeres, consulta el ejemplo de negocios minoristas.

Cuando se selecciona una versión nueva para las actualizaciones automáticas en el canal de versiones, GKE actualiza los clústeres en la secuencia que definiste. Como esta estrategia de administración es calificar una versión nueva en varios entornos, todos los clústeres de una secuencia de lanzamiento deben estar en el mismo canal de versiones y una versión secundaria para actualizaciones continuas exitosas a versiones nuevas.

La secuencia de lanzamientos proporciona un control adicional sobre el uso de los canales de versiones, en los que GKE califica las versiones nuevas de cada canal antes de ascender las versiones al siguiente.

Ejemplo: El negocio de venta minorista lanza de forma gradual cambios de las pruebas a la producción

En este ejemplo, puedes ver cómo usar flotas y permisos para agrupar clústeres para administrar las actualizaciones de clústeres con secuenciación de lanzamiento. Debes registrar clústeres en una flota cuando quieras administrarlos juntos. Con los permisos, puedes agrupar más clústeres dentro de una flota.

Por ejemplo, una empresa de venta minorista ejecuta una variedad de aplicaciones en varios clústeres de GKE, incluido un sitio web de compras en línea y una base de datos. Para cada una de estas aplicaciones, las cargas de trabajo se ejecutan en un grupo de clústeres. Este grupo de clústeres se replica en varias etapas de implementación, incluidas las pruebas, la etapa de pruebas y la producción.

Este negocio de venta minorista usa los siguientes permisos para agrupar clústeres que ejecutan el sitio web y la base de datos de compras en línea:

  • Permisos para el sitio web de compras en línea:

    • El permiso online-shop en la flota testing tiene varios clústeres, todos inscritos en el canal regular.
    • El permiso online-shop en la flota staging tiene varios clústeres, todos inscritos en el canal regular.
    • El permiso online-shop en la flota production tiene varios clústeres, todos inscritos en el canal regular.

  • Permisos para la base de datos:

    • El permiso database en la flota testing tiene varios clústeres, todos inscritos en el canal estable.
    • El permiso database en la flota staging tiene varios clústeres, todos inscritos en el canal estable.
    • El permiso database en la flota production tiene varios clústeres, todos inscritos en el canal estable.

La empresa de venta minorista prueba versiones nuevas para sus clústeres de GKE mediante la siguiente estrategia de calificación. Los permisos online-shop y los permisos database en las flotas testing, staging y production se organizan cada una en secuencias de lanzamiento independientes, de modo que cuando haya versiones nuevas disponibles en el canal de versiones de la secuencia de lanzamiento (regular para online-shop y estable para database) y GKE comienza las actualizaciones automáticas, la versión nueva se califica en cada permiso, en ese orden.

Por ejemplo, una nueva versión secundaria de GKE 1.28 avanzaría a la producción de una aplicación en el siguiente orden:

  1. 1.28 está disponible en el canal de versiones de la secuencia de lanzamiento.
  2. GKE actualiza los clústeres en el permiso de la prueba que se ejecuta en la versión 1.27 a 1.28.
  3. Una vez que los clústeres en el permiso de prueba calificaron la actualización 1.28, GKE actualiza los clústeres en el permiso de la etapa de pruebas que se ejecuta en la 1.27 a 1.28.
  4. Una vez que los clústeres en el permiso de la etapa de pruebas calificaron la actualización 1.28, GKE actualiza los clústeres en el permiso de producción que se ejecuta en 1.27 a 1.28.

Cómo se crea una secuencia de lanzamiento

Para administrar las actualizaciones del clúster con la secuencia de lanzamiento, primero debes organizar tus clústeres en permisos. Puedes incluir clústeres de Autopilot y Standard.

Para organizar tus clústeres en permisos, debes registrar tus clústeres con flotas y vincularlos a permisos. Una vez que hayas organizado tus clústeres en permisos, puedes crear una secuencia de lanzamiento.

Cuando creas una secuencia de lanzamiento, debes definir el orden en el que se actualizarán los permisos. Puedes tener hasta 3 permisos en una secuencia. Elige cuánto tiempo de prueba quieres entre el lanzamiento de cada versión de cada permiso (30 días como máximo).

Una secuencia de lanzamiento se define como una lista vinculada. Un permiso puede tener un permiso ascendente y descendente. Para que GKE comience a actualizar los clústeres en un permiso, el permiso ascendente debe calificar la versión; para ello, finaliza las actualizaciones y completa el período de prueba. Una vez que GKE completa las actualizaciones de los clústeres en un solo permiso, las actualizaciones pueden comenzar con el permiso descendente.

En el ejemplo de negocio de venta minorista, la secuencia de lanzamiento con los permiso de prueba, etapa de pruebas y producción tiene las siguientes referencias:

  • El permiso online-shop de la flota de testing:
    • Permiso ascendente: ninguno
    • Permiso descendente: permiso online-shop en la flota staging
  • El permiso online-shop en la flota de staging
    • Permiso ascendente: permiso online-shop en la flota testing
    • Permiso descendente: permiso online-shop en la flota production
  • El permiso online-shop en la flota de production
    • Permiso ascendente: permiso online-shop en la flota staging
    • Permiso descendente: ninguno (sin embargo, cuando lo describes, se enumera como el permiso descendente, ya que es el último permiso en la secuencia)P

Cuando creas o actualizas un permiso, solo estableces el permiso ascendente de ese permiso. Cuando describes un permiso, puedes ver el permiso ascendente y el permiso descendente de ese permiso.

El primer permiso en la secuencia de lanzamiento no tiene un permiso ascendente para calificar las versiones de sus clústeres. Recibe todos los objetivos de actualización disponibles de GKE para su canal de versiones.

Para crear una secuencia de lanzamiento, consulta Configura una secuencia de lanzamiento.

Consideraciones para elegir la secuencia de lanzamiento

Considera usar la secuencia de lanzamiento si deseas administrar las actualizaciones del clúster mediante la calificación de las versiones nuevas en un entorno antes de lanzarla en otro.

Sin embargo, es posible que esta no sea la opción correcta para tu entorno si se cumple alguna de las siguientes declaraciones:

  • Tienes clústeres que no están en el mismo canal de versiones o en una versión secundaria en el mismo entorno de producción.
  • Debes automatizar las actualizaciones de más de tres etapas de implementación, ya que solo puedes crear una secuencia de lanzamiento con hasta tres permisos.
  • No puedes usar la administración de flotas.
  • Realizas actualizaciones manuales con frecuencia.
  • No puedes actualizar tus clústeres a versiones nuevas cuando se convierten en destinos de actualización
    en tu canal de versiones debido al uso de las funciones o las APIs de Kubernetes obsoletas.

Cómo funciona la calificación de la versión en una secuencia de lanzamiento

Con las actualizaciones de clúster en una secuencia de lanzamiento, los clústeres en el permiso ascendente califican una nueva versión de GKE para los clústeres en el permiso descendente. En particular, las versiones nuevas se validan de forma independiente para el plano de control y los nodos del clúster. En una actualización del clúster, GKE actualiza el plano de control del clúster primero y, luego, comienza las actualizaciones del nodo. Una vez que finalizan las actualizaciones del plano de control, pueden comenzar las actualizaciones del plano de control en el siguiente permiso. Sin embargo, para que las actualizaciones del grupo de nodos comiencen en el permiso descendente, las actualizaciones del plano de control deben completarse en el permiso descendente y las actualizaciones de nodos deben completarse en el permiso ascendente.

Una vez que creaste una secuencia de lanzamiento, las actualizaciones del clúster continúan en un nivel alto y siguen estos pasos:

  1. GKE establece un objetivo de actualización automática nuevo para clústeres en una versión secundaria, con la nota de la versión que menciona algo como el siguiente mensaje: “Planos de control y nodos con actualización automática habilitado en el canal regular se actualizará de la versión 1.21 a la versión 1.22.15-gke.1000 con esta versión".
  2. GKE inicia las actualizaciones automáticas para los clústeres en el primer permiso. Para cada clúster, el plano de control se actualiza primero y, luego, las actualizaciones de los nodos comienzan cuando se completa la actualización del plano de control del clúster.
  3. El período de prueba para un plano de control o una actualización de nodo comienza una vez que finalizan las actualizaciones del plano de control o los nodos en el permiso, o cuando transcurrieron los 30 días máximos desde que comenzaron las actualizaciones. Los administradores de la plataforma pueden usar el tiempo de prueba para confirmar que las actualizaciones del clúster se realizaron de forma correcta en el permiso. Si no se configura tiempo de prueba para el tipo de actualización, GKE comienza las actualizaciones en el permiso descendente.
  4. Una vez que se completa el período de prueba para la actualización del plano de control o la actualización del nodo en el permiso ascendente y la versión se considera calificada, el permiso descendente repite los pasos 2 y 3 hasta que cada uno de los clústeres en todos los clústeres los permisos de la secuencia de lanzamiento se actualizaron al nuevo objetivo de actualización.

Durante las actualizaciones del clúster, puedes inspeccionar el estado de la secuencia de lanzamiento o intervenir en el proceso si es necesario. Por ejemplo, puedes realizar algunas de las siguientes acciones:

  • Si determinas que la versión está calificada para el permiso descendente, anula el tiempo de prueba predeterminado a cero a fin de permitir que las actualizaciones del clúster pasen de inmediato al siguiente permiso.
  • Si observas un problema con los clústeres que se ejecutan en la versión nueva, puedes aumentar el tiempo de prueba para que tengas más tiempo a fin de inspeccionar el problema antes de que se actualicen los clústeres el permiso descendente. También puedes agregar una exclusión de mantenimiento a un clúster en el permiso en el que los clústeres se están actualizando para evitar que se complete el lanzamiento en el permiso. Para obtener más información, consulta Retrasa la finalización del lanzamiento de la versión del permiso.

Es posible que GKE no pueda continuar con las actualizaciones si hay discrepancias de versión entre los clústeres en los permisos de una secuencia de lanzamiento. Para obtener más información, consulta Elegibilidad para el lanzamiento.

Es posible que no se pueda actualizar los clústeres debido a exclusiones o períodos de mantenimiento, el uso obsoleto de la API o a otras razones. Para obtener más información, consulta Cómo funciona la secuencia de lanzamiento con otras funciones de actualización.

Elegibilidad del lanzamiento

GKE administra las actualizaciones de clústeres con secuencia de lanzamiento con permisos de clústeres en el mismo canal de versiones y en la misma versión secundaria. Esto se debe a que, para cada permiso, se califica una versión nueva, y todos los clústeres de esa versión deben calificarla para que las actualizaciones de clústeres procedan con un permiso descendente.

Para que GKE actualice correctamente los clústeres en cada uno de los permisos de una secuencia de lanzamiento, cada clúster debe ser apto para la misma versión nueva. Como el propósito de la secuencia de lanzamiento es para un permiso de clústeres a fin de calificar la versión nueva para otro permiso de clúster, si cada clúster no es apto para la misma versión nueva, es posible que GKE no pueda continuar. con actualizaciones del clúster. Por ejemplo, si los clústeres del primer permiso de una secuencia de lanzamiento califican un objetivo de actualización, pero los clústeres del segundo permiso no califican para ese objetivo de actualización como comenzaron en una versión secundaria diferente, GKE no puede actualizar los clústeres, ya que no hay una versión calificada. Obtén más información en la siguiente sección.

Si todos los clústeres de un permiso no tienen el mismo objetivo de actualización debido a las discrepancias de versión entre clústeres, el permiso se considera parcialmente apto. Puedes verificar el estado del lanzamiento de versión en una secuencia para obtener más información sobre el estado y cómo cada clúster afecta el estado. Según las discrepancias de la versión, es posible que debas tomar medidas, como actualizar un clúster de forma manual o quitarlo de un permiso para continuar con las actualizaciones del clúster. Para solucionar problemas de elegibilidad de lanzamiento parcial, consulta Soluciona problemas de elegibilidad de lanzamiento.

Ejemplo de discrepancias de versión y objetivos de actualización

En el siguiente ejemplo, se muestra por qué los clústeres dentro de los permisos de una secuencia de lanzamiento deben ejecutar la misma versión.

En la versión 2022-R25, cada versión secundaria disponible en un canal de versiones tenía un objetivo de actualización. Un objetivo de actualización podría ser una versión secundaria nueva o solo una versión de parche nueva. Por ejemplo, en la versión a la que se hace referencia, las siguientes versiones nuevas estaban disponibles para clústeres en versiones secundarias específicas:

  • Los clústeres en 1.20 y 1.21 se actualizaron a 1.21.14-gke.4300.
  • Los clústeres en 1.22 se actualizaron a la versión 1.23.8-gke.1900.
  • Los clústeres en 1.24 se actualizaron a la versión 1.24.5-gke.600.

El primer permiso en una secuencia de lanzamiento recibe este lote de objetivos de actualización y puede comenzar las actualizaciones del clúster. Para el primer permiso de una secuencia de lanzamiento, todos los objetivos de actualización se consideran calificados, por lo que las actualizaciones automáticas continúan sin importar las discrepancias de la versión en el primer permiso. Sin embargo, a fin de que este permiso califique los objetivos de actualización para el permiso descendente, cada clúster de este permiso debe tener el mismo objetivo de actualización, lo que significa que los clústeres se encuentran en la misma versión secundaria. Sin embargo, en este ejemplo, los clústeres de 1.20 y 1.21 tenían el mismo objetivo de actualización.

Una vez que GKE actualiza los clústeres en el primer permiso, esos clústeres validaron un objetivo de actualización. Si todos los clústeres del primer permiso estaban en 1.20 o 1.21, validan 1.21.14-gke.4300. Si todos los clústeres estaban en la versión 1.22, validaron 1.23.8-gke.1900. Esta versión validada ahora se pasa al permiso descendente. Sin embargo, si hay una discrepancia de versiones entre los clústeres del primer permiso o el segundo permiso, lo que significa que el destino de actualización es diferente, es posible que la versión validada no coincida con una versión de los clústeres en el permiso descendente.

Cómo funciona la secuencia de lanzamiento con otras funciones de actualización

La secuencia de lanzamiento es una función de una colección de funciones que te permiten controlar el aspecto de actualización del ciclo de vida del clúster. En esta sección, se explica cómo funciona con algunas de las otras funciones disponibles relacionadas con las actualizaciones de clústeres.

Cómo funciona la secuencia de lanzamiento con períodos de mantenimiento y exclusiones

GKE respeta los períodos de mantenimiento y las exclusiones de mantenimiento cuando se actualizan clústeres con secuencia de lanzamiento. GKE solo inicia una actualización del clúster dentro del período de mantenimiento de un clúster. Puedes usar una exclusión de mantenimiento para evitar que un clúster se actualice de forma temporal. Si GKE no puede actualizar un clúster debido a un período de mantenimiento o exclusión, esto puede evitar que las actualizaciones del clúster finalicen en un permiso. Si una actualización del clúster no se puede completar en un plazo de 30 días debido a períodos de mantenimiento o exclusiones, el permiso ingresará a su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse.

Puedes usar las exclusiones de mantenimiento como una medida temporal para evitar que una secuencia complete un lanzamiento en un permiso y pase al siguiente permiso. Para obtener más información, consulta Retrasa la finalización del lanzamiento de la versión del permiso.

Cómo funciona la secuencia de lanzamiento con la detección del uso de la baja

GKE pausa las actualizaciones del clúster cuando detecta el uso de ciertas APIs y funciones obsoletas. Las actualizaciones automáticas también se detienen en los clústeres que están dentro del permiso en una secuencia de lanzamiento. Para obtener más información, consulta Cómo funcionan las bajas de Kubernetes con GKE.

Cómo funciona la secuencia de lanzamiento con estrategias de actualización de grupos de nodos

Las actualizaciones del grupo de nodos usarán su estrategia de actualización de grupo de nodos configurada cuando se actualicen en una secuencia de lanzamiento. Al igual que con las actualizaciones de clústeres sin secuencia de lanzamiento, GKE usa actualizaciones de aumento para los nodos de Autopilot. Para obtener más información, consulta Actualizaciones automáticas de los nodos.

Si las actualizaciones de un nodo no se pueden completar en 30 días, el permiso entrará en su fase de prueba, sin importar si todos los clústeres terminaron de actualizarse. Esto puede suceder si la estrategia de actualización de grupos de nodos hace que la actualización de grupos de nodos de un clúster estándar tarde más en completarse, en especial si es un grupo de nodos grande. También puede verse agravado por los períodos de mantenimiento no lo suficientemente grandes como para que una actualización del grupo de nodos se complete. Para obtener más información, consulta Consideraciones para configurar un período de mantenimiento.

Cómo funciona la secuencia de lanzamiento con canales de versiones

Se requieren canales de versiones para usar la secuencia de lanzamiento. Todos los clústeres de todos los permisos de una secuencia de lanzamiento deben estar en el mismo canal de versiones.

Omite versiones de parche

Por lo general, los clústeres en un canal de versiones reciben una versión de parche nueva cada una o dos semanas, mientras que las versiones secundarias se reciben aproximadamente cada cuatro meses. Esto significa que, con una secuencia de los tres permisos máximos, puedes calificar una versión secundaria nueva durante un máximo de 4 meses antes de que alcance el permiso de producción: lanzamiento del primer permiso (máximo de 30 días) + tiempo de prueba del primer permiso (máximo de 30 días) + lanzamiento del segundo permiso (máximo de 30 días) + tiempo de prueba del segundo permiso (máximo de 30 días) = 120 días (~4 meses). Esto representa el lanzamiento más gradual posible y el último permiso necesitaría lanzar la versión secundaria en un plazo de 4 meses para evitar que se atrase el programa de lanzamientos de GKE.

Recibe varias actualizaciones en una secuencia

Si una versión nueva se convierte en un objetivo de actualización en el canal de versiones mientras las actualizaciones del clúster a un destino de actualización anterior aún continúan en la secuencia de lanzamiento, un permiso ascendente puede comenzar el lanzamiento de una versión nueva mientras un el permiso descendente aún recibe la actualización anterior. Por ejemplo, si el tercer permiso de una secuencia lanza 1.24.2-gke.100, el primer permiso en la secuencia puede lanzar 1.24.3-gke.500 de forma simultánea.

Controla el lanzamiento de una versión en curso

Una vez que hayas configurado una secuencia, cuando esté disponible una versión nueva para los clústeres en la secuencia de lanzamiento, las actualizaciones comenzarán de forma automática.

También puedes verificar el estado de un lanzamiento de versión en una secuencia de lanzamiento completa con un solo comando. Además, tienes los mismos controles sobre el proceso de actualización que cuando los clústeres no están en una secuencia de lanzamiento. Algunas de las acciones relevantes que puedes realizar para afectar el proceso de lanzamiento de la versión incluyen, entre otras, las siguientes acciones:

  • Retrasar la finalización del lanzamiento de una versión de un permiso.
  • Anula el tiempo de prueba para el lanzamiento de una versión específica.
  • Cambia el orden de una secuencia.
  • Borra una secuencia.

Para obtener más información, consulta Controla el proceso de lanzamiento de versiones.

Verifica el estado del lanzamiento de la versión en una secuencia

Puedes verificar el estado de un lanzamiento de una versión en una secuencia mediante gcloud alpha container fleet scopes describe [SCOPE] --show-cluster-upgrade. Para obtener más información, consulta Verifica el estado de una secuencia de lanzamiento.

El estado de un lanzamiento de versión incluye el estado de cada permiso y clúster dentro de ese permiso. Cuando ejecutas el comando, puedes usar la marca --show-linked-cluster-upgrade para ver el estado de todos los permisos dentro de la secuencia.

Consulta la siguiente tabla para conocer los estados posibles de un clúster o permiso:

Estado Para el clúster Para el permiso
INELIGIBLE Este clúster no es apto para esta actualización Uno o más clústeres de este permiso no son aptos para esta actualización.
PENDIENTE La actualización no se inició o está en curso para el clúster. La actualización no comenzó en ninguno de los clústeres del permiso.
IN_PROGRESS N/A La actualización comenzó en al menos un clúster, pero no finalizó en todos ellos.
SOAKING La actualización finalizó en el clúster y no terminó de prueba. La actualización terminó en todos los clústeres y no se terminó de activar.
FORCED_SOAKING La actualización tardó más que el tiempo máximo de actualización (30 días) y, por lo tanto, la obtuvimos a ingresar a la fase de prueba. La actualización puede continuar en el clúster. La actualización tardó más que el tiempo máximo de actualización (30 días) y, por lo tanto, la obtuvimos a ingresar a la fase de prueba. La actualización aún puede continuar en los clústeres.
COMPLETO La actualización se trata como “finalizada”, lo que significa que la actualización terminó de prueba en este clúster. La actualización se trata como “finalizada” y está lista para que la consuma el permiso descendente, lo que significa que la actualización terminó de prueba.

Por ejemplo:

$gcloud alpha container fleet scopes describe scope-A --show-linked-cluster-upgrade

clusterUpgrades:
- scope: projects/${some_project_number}/locations/global/workspaces/scope-C
  spec: {}
  state:
    downstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-A
- scope: projects/${current_project_id}/locations/global/workspaces/scope-A
  spec:
    upstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-C
  state:
    downstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-B
- scope: projects/${current_project_id}/locations/global/workspaces/scope-B
  spec:
    upstreamScopes:
    - projects/${some_project_number}/locations/global/workspaces/scope-A
  state: {}
createTime: '2022-09-07T19:53:49.442321517Z'
name: projects/${some_project_number}/locations/global/workspaces/scope-A
state:
  code: READY
uid: ${some-uuid}
updateTime: '2022-09-07T19:53:50.357882703Z'

Limitaciones

Para actualizar correctamente tus clústeres con secuencia de lanzamiento, debes cumplir con las siguientes limitaciones:

  • Inscribe un clúster en un solo permiso. Si un clúster está inscrito en varios permisos, GKE no puede actualizar el clúster de forma automática.
  • Crea una secuencia de lanzamiento lineal sin ciclos (un permiso tiene un permiso descendente como permiso ascendente) o ramas (un permiso tiene más de un permiso descendente).

Problemas conocidos

  • Si un permiso contiene clústeres de diferentes ubicaciones, es posible que una actualización del clúster solo esté disponible de forma temporal para algunos de los clústeres debido al lanzamiento gradual de la versión nueva. Es más probable que esto suceda con el primer clúster dentro de un permiso y debería resolverse en una semana.
  • Si hay un permiso vacío en una secuencia de lanzamiento, la forma en que esto afecta la calificación de la versión depende de las siguientes condiciones:
    • Si el permiso vacío no tiene permiso ascendente, las actualizaciones del clúster no continúan con el permiso descendente, ya que el permiso vacío no puede calificar versiones.
    • Si el permiso vacío tiene un permiso ascendente, todas las actualizaciones de clúster pendientes ingresan al estado COMPLETE y se propagan al permiso descendente.
  • Debido a la forma en que GKE realiza un seguimiento de las actualizaciones menores y de parches, es posible que veas dos actualizaciones del mismo tipo y la misma versión, pero con estados diferentes cuando verifiques el estado del permiso.
  • El comando gcloud alpha container fleet scopes describe <SCOPE_NAME> --show-linked-cluster-upgrade no muestra los estados de la membresía en el permiso. Para ver la membresía, ejecuta gcloud container fleet features describe clusterupgrade.

Cómo cambiará la secuencia de lanzamiento después de la vista previa privada

Con la administración de flotas, puedes organizar tus clústeres en grupos solo con flotas o con flotas y permisos. Los permisos proporcionan un nivel de detalle adicional para las organizaciones que operan grandes cantidades de clústeres para diferentes equipos y pueden beneficiarse de otro nivel de agrupación dentro de las flotas (por ejemplo, una flota de producción incluye grupos de cargas de trabajo de producción administradas por diferentes unidades de negocios en la organización).

Para la vista previa privada de la función Secuenciación de lanzamiento, solo puedes crear una secuencia de lanzamiento entre permisos. Para la disponibilidad general de la secuencia de lanzamiento, podrás elegir entre crear secuencias de lanzamiento entre flotas o entre permisos.

Durante la disponibilidad general, los permisos solo se ofrecerán como una función premium. Sin embargo, el acceso a las flotas y la creación de secuencias de lanzamiento de flotas estarán disponibles como una función estándar disponible para todos los clientes. Al igual que con otros lanzamientos de la vista previa privada, no habrá costos adicionales por acceder a la capacidad premium de usar Secuenciación de lanzamiento con permisos.

¿Qué sigue?