Modernización del plano de control administrado
Debes modernizar tus flotas de Cloud Service Mesh desde la
implementación obsoleta del plano de control de ISTIOD
hasta la implementación de TRAFFIC_DIRECTOR antes de la
fecha límite de finalización de la asistencia. Puedes iniciar la modernización según tu propio
programa o permitir que Google la programe automáticamente una vez que tu organización sea
compatible.
Existen dos rutas de modernización, y también puedes combinarlas:
- Modernización activada por el cliente (autoservicio): Tú inicias y controlas el momento exacto de la modernización de la flota con Google Cloud CLI, independientemente de los programas impulsados por Google.
- Modernización impulsada por Google (predeterminada): Google evalúa la compatibilidad de la flota y programa automáticamente la modernización en toda tu organización según los períodos de mantenimiento y las notificaciones anticipadas. Google espera a que todas las flotas de tu organización sean compatibles, por lo que una sola flota incompatible bloqueará tu modernización.
Independientemente de la ruta que elijas, debes completar los siguientes pasos principales para modernizar tu plano de control:
- Verifica la compatibilidad: Habilita las verificaciones de compatibilidad y comprende la compatibilidad de tus flotas con la modernización.
- Planifica y configura tu modernización: Elige tu ruta, configura el orden de lanzamiento de clústeres y flotas, o aplaza flotas específicas.
- Corrige las brechas de compatibilidad: Asegúrate de que tus flotas cumplan con todos los requisitos de compatibilidad antes de iniciar la modernización.
- Inicia la modernización: Activa la modernización iniciada por el cliente según tu programa o espera la programación impulsada por Google.
- Modernización activa del clúster: Durante los períodos de mantenimiento configurados, los planos de control duales se ejecutan en paralelo, y los Deployments (cargas de trabajo y puertas de enlace) realizan la transición de forma automática al plano de control nuevo. Deberás reiniciar de forma manual las cargas de trabajo de StatefulSet y DaemonSet.
- Supervisa el estado, el período de prueba y la finalización: Supervisa el progreso de las condiciones, resuelve los bloqueos, observa las cargas de trabajo durante el período de prueba (al menos 6 días hábiles), con compatibilidad total con la reversión antes de la finalización a nivel de la flota.
Verifica la compatibilidad de la flota y corrige las brechas
Antes de que cualquier flota pueda modernizarse, ya sea con la modernización activada por el cliente o impulsada por Google, se debe verificar que sea compatible. Debes habilitar los informes de compatibilidad para inspeccionar las posibles condiciones de bloqueo y corregir las brechas de configuración. Para obtener más detalles, consulta Información sobre la compatibilidad de Cloud Service Mesh.
- Para la modernización impulsada por Google, Google solo programará organizaciones en las que todas las flotas no aplazadas sean compatibles.
- Para la modernización activada por el cliente: Debes verificar que tu flota de destino
informe
MODERNIZATION_COMPATIBLEantes de iniciar la modernización.
Las verificaciones de compatibilidad evalúan los parámetros de configuración de CRD de Istio de tu flota, las anotaciones de Pod, las dependencias de infraestructura (como Workload Identity) y los parámetros de escalamiento.
Cómo controlar las funciones no compatibles
Como parte de la baja del plano de control de ISTIOD, Google Cloud finalizará
la compatibilidad con las funciones que no son compatibles con la implementación del plano de control de
TRAFFIC_DIRECTOR. Consulta los detalles de la
compatibilidad con la API.
Si usas funciones no compatibles, debes realizar una de las siguientes acciones antes de que finalice la asistencia (consulta Bajas):
- Refactoriza tu configuración (recomendado): Quita los campos no admitidos
o reemplázalos por alternativas compatibles de Cloud Service Mesh para que tu
flota informe
MODERNIZATION_COMPATIBLEy, luego, moderniza la implementación del plano de control deTRAFFIC_DIRECTOR. - Migra a Istio de código abierto (OSS): Si tus cargas de trabajo requieren estrictamente
funciones que Cloud Service Mesh administrado con
TRAFFIC_DIRECTORno admite, no puedes modernizar esos clústeres aTRAFFIC_DIRECTOR. Debes migrar esas cargas de trabajo a Istio de código abierto autoadministrado. - Desinstala Cloud Service Mesh: Puedes desinstalar Cloud Service Mesh administrado.
Planifica y configura tu modernización
Crea un plan para modernizar tus flotas. Si no lo haces, la modernización impulsada por Google se aplicará de forma predeterminada. Debes tomar medidas para asegurarte de que tus flotas que no son de producción se modernicen primero y tus flotas críticas se modernicen al final. Además, la modernización impulsada por Google no programará la modernización de tu organización hasta que el 100% de las flotas no aplazadas de toda tu organización sean compatibles, por lo que tu modernización podría verse bloqueada por incompatibilidades locales.
Antes de iniciar la modernización, revisa tus opciones y establece la configuración de lanzamiento en las flotas y los clústeres de tu organización.
Rutas disponibles
| Enfoque | Descripción | Clientes ideales | Alcance | Requisitos previos | Aviso anticipado | Capacidad de reversión |
|---|---|---|---|---|---|---|
| Modernización activada por el cliente | Inicias la modernización flota por flota según tu propio programa. | Control detallado sobre el momento de la modernización de la flota (tú decides cuándo iniciar y cuándo revertir a nivel de la flota). Aprovechar la supervisión de aplicaciones existente para recibir alertas si se necesita una reversión | Flota por flota (FLEET_PROJECT_ID) |
La flota de destino debe ser compatible con la modernización. | N/A. | Reversión inmediata de autoservicio con Google Cloud CLI |
| Modernización impulsada por Google (predeterminada) | Google programa automáticamente la modernización en toda tu organización. | Modernización automatizada una vez que todas las flotas de tu organización sean compatibles. | Toda la organización de Google Cloud (todas las flotas no aplazadas). | Todas las flotas no diferidas de la organización deben ser compatibles con la modernización y admitir la modernización impulsada por Google. | Notificación de flota de más de 14 días y notificación de clúster de más de 24 horas antes de comenzar. | Google revertirá los cambios si la supervisión estandarizada muestra un error. Debes comunicarte con Atención al cliente de Cloud si la supervisión de tu aplicación muestra un error. |
Administra varias flotas en una organización
Si tu organización de Google Cloud administra varias flotas, no es necesario que elijas un solo enfoque para todas ellas. Puedes combinar estrategias, por ejemplo:
- Difiere las flotas complejas o críticas: Fija flotas específicas en la implementación
heredada con
--modernization-strategy deferredpara que se excluyan de la programación controlada por Google mientras corriges las dependencias o planificas la ejecución activada por el cliente. - Comienza con la modernización activada por el cliente en las flotas seleccionadas: Moderniza primero las flotas de prueba, desarrollo o evaluación para validar el comportamiento en tu propio cronograma.
- Permite que Google modernice las flotas restantes: Cualquier flota compatible que no se haya aplazado seguirá habilitada para la programación controlada por Google.
Cómo aplazar la modernización de la flota (inhabilitación)
Para inhabilitar una flota individual de la modernización impulsada por Google, establece su estrategia
en DEFERRED:
gcloud alpha container fleet mesh update \
--modernization-strategy deferred \
--project FLEET_PROJECT_ID
Reemplaza FLEET_PROJECT_ID por el ID del proyecto host de flota.
Establecer --modernization-strategy deferred es la forma recomendada para hacer lo siguiente:
- Excluir flotas específicas de la programación controlada por Google porque tienes la intención de modernizarlas según tu propio cronograma con la modernización activada por el cliente
- Suspende temporalmente la modernización de las flotas complejas o críticas mientras corriges las dependencias, lo que permite que otras flotas compatibles de tu organización continúen con la programación controlada por Google.
Ten en cuenta que se respeta la etiqueta de proyecto heredada mesh-modernization-mode=manual, pero se recomienda --modernization-strategy deferred. Otras
flotas no aplazadas de tu organización siguen siendo aptas para la programación
controlada por Google una vez que todas sean compatibles.
Configura el orden de lanzamiento
Puedes controlar el orden de lanzamiento secuencial en tus clústeres y flotas
con la etiqueta mesh-modernization-order (temprano, predeterminado o tardío).
Orden de lanzamiento del clúster (se aplica a ambas rutas de acceso)
Si una flota contiene varios clústeres, puedes controlar el orden en el que
se modernizan aplicando la etiqueta mesh-modernization-order a cada
clúster. Cuando tú o Google activan la modernización de una flota, cada grupo de clústeres
se moderniza de forma secuencial, esperando que se completen los pasos de modernización automatizados
en el grupo actual antes de comenzar el siguiente:
gcloud container clusters update CLUSTER_NAME \
--location LOCATION \
--update-labels="mesh-modernization-order=VALUE"
Reemplaza CLUSTER_NAME por el nombre del clúster, LOCATION por la ubicación del clúster y VALUE por una de las siguientes opciones:
early: El clúster se moderniza en la primera ola de modernización.default: El clúster se moderniza en la segunda ola de modernización.late: El clúster se moderniza en la tercera y última ola de modernización.
Orden de lanzamiento de la flota (solo controlado por Google)
En las organizaciones con varias flotas que se someten a la modernización impulsada por Google, puedes controlar el orden en el que Google moderniza tus flotas configurando la etiqueta a nivel del proyecto en el proyecto host de la flota:
gcloud alpha projects update FLEET_PROJECT_ID \
--update-labels="mesh-modernization-order=VALUE"
Reemplaza FLEET_PROJECT_ID por el ID del proyecto host de la flota y VALUE por uno de los siguientes valores:
early: La flota se moderniza en la primera ola de modernización.default: La flota se moderniza en la segunda ola de modernización.late: La flota se moderniza en la tercera y última ola de modernización.
Google completa la modernización de cada nivel de la flota antes de comenzar con el siguiente: primero, el temprano; luego, el predeterminado (y sin etiquetar); y, por último, el tardío. Las flotas marcadas como aplazadas no se incluyen en este orden.
Por ejemplo, puedes configurar tus flotas que no son de producción en early, una flota especialmente
crítica en late y dejar las demás en el valor predeterminado.
Si no usas organizaciones de Google Cloud , tus flotas se programarán y modernizarán de forma independiente, y no podrás controlar el orden.
Modernización activada por el cliente (autoservicio)
La modernización activada por el cliente te brinda control directo sobre cuándo comienza la modernización de una flota individual.
Activación de la modernización de la flota
Una vez que tu flota de destino
informe
MODERNIZATION_COMPATIBLE, activa la modernización con el siguiente comando:
gcloud alpha container fleet mesh update \
--modernization-strategy automatic \
--project FLEET_PROJECT_ID
Reemplaza FLEET_PROJECT_ID por el ID del proyecto host de flota.
- Períodos de mantenimiento: Google respeta los períodos de mantenimiento y las exclusiones configurados para el clúster. La modernización del clúster comienza durante el próximo período de mantenimiento abierto del clúster.
- Orden de los clústeres: Si configuraste etiquetas
mesh-modernization-orderen tus clústeres, Google respeta ese orden.
Supervisa el progreso
Sigue las instrucciones que se indican en
Verifica el estado de la modernización para supervisar el
progreso de la modernización de la flota y del clúster. Observa la supervisión de tu aplicación
para determinar si necesitas una reversión, en especial durante los
estados MODERNIZATION_PREPARING y MODERNIZATION_MIGRATING_WORKLOADS.
Cómo revertir una modernización activada por el cliente
Si detectas problemas durante la modernización activa del clúster o durante el período de prueba de la flota (antes de la finalización a nivel de la flota), puedes activar una reversión inmediata:
gcloud alpha container fleet mesh update \
--modernization-strategy deferred \
--project FLEET_PROJECT_ID
Reemplaza FLEET_PROJECT_ID por el ID del proyecto host de flota.
Esto dejará tu flota en el estado diferido, es decir, no se considerará para la modernización impulsada por Google. Cuando tengas todo listo para volver a intentar la modernización, vuelve a ejecutar el comando para activar la modernización de la flota.
Modernización impulsada por Google (predeterminada automatizada)
Si no inicias la modernización activada por el cliente, Google administra la modernización en toda tu organización de forma automática.
Programación en toda la organización
Google supervisa tus flotas de forma continua. Después de que todas las flotas habilitadas para la malla en tu
organización (excepto las flotas diferidas) sean compatibles con la modernización
(MODERNIZATION_COMPATIBLE) y admitan la modernización impulsada por Google, Google
programará tu organización para la modernización.
Asistencia para la modernización impulsada por Google
Algunas condiciones bloquean la modernización impulsada por Google y requieren que el cliente
active la modernización de una flota. Verás una condición de nivel de flota de
MODERNIZATION_REQUIRES_CUSTOMER_TRIGGER y más detalles en otras condiciones
de nivel de flota o de clúster.
Esta condición bloquea la programación para toda la organización de la modernización impulsada por Google hasta que modernices esa flota con la modernización activada por el cliente o pospongas la flota.
Notificaciones y programación avanzadas
Google proporciona dos niveles de notificación anticipada antes de comenzar la modernización:
Notificación a nivel de la flota
Primero, recibirás una notificación cuando se identifique que tus flotas son compatibles con la modernización y se seleccionen para que se realice la modernización impulsada por Google en el futuro.
La modernización del clúster puede comenzar 14 días después del primer día hábil de EE.UU. del mes siguiente a la notificación. Por ejemplo, si Google determina que tu organización está lista el 10 de enero de 2027, te notificaremos antes del 31 de enero de 2027 que la fecha de inicio de la modernización más temprana posible es el 15 de febrero de 2027.
Recibirás una notificación simultánea para cada una de las flotas de tu organización (excepto las que hayas aplazado). Esta notificación está disponible en las condiciones de estado de la función a nivel de la flota (
MODERNIZATION_WILL_BE_SCHEDULED).
Notificación a nivel del clúster
Se te notificará, a nivel del clúster, la fecha de inicio estimada para la modernización de ese clúster impulsada por Google, al menos 1 día (24 horas) antes de que comience la modernización del clúster.
Después de la notificación a nivel de la flota, esto te brinda un momento mucho más preciso
para la modernización de los clústeres individuales. Esta notificación está disponible
en las condiciones de estado de la función a nivel del clúster (MODERNIZATION_SCHEDULED).
Solicita la reversión para la modernización impulsada por Google
Si surgen problemas durante la modernización activa o la asimilación en una flota de modernización administrada por Google, comunícate con Atención al cliente de Cloud para solicitar una reversión.
Qué sucede durante la modernización activa
En esta sección, se describe lo que sucede durante la modernización activa de las flotas y los clústeres.
Modernización de flotas
Para cada flota que se somete a una modernización (ya sea impulsada por Google o activada por el cliente), habilitamos la nueva implementación del plano de control para todos los clústeres según el orden (temprano → predeterminado → tardío).
Una vez que se habilita el plano de control para todos los clústeres, cambiamos el tráfico a la nueva implementación del plano de control para todos los clústeres según el orden (temprano → predeterminado → tardío).
Consulta Verifica el estado de modernización de la flota para comprobar el estado actual.
Período de prueba de la flota
Una vez que se cambia el tráfico para todos los clústeres, la flota entra en un período de prueba.
La flota permanece en el período de prueba (MODERNIZATION_MODERNIZED) durante al
menos 6 días hábiles después de que todos los clústeres completen la modernización antes
de la transición a MODERNIZATION_FINALIZED. La capacidad de reversión completa se
conserva durante todo el período de prueba. Una vez que se finaliza la modernización, ya no es posible
revertir los cambios, y es posible que se desaprovisionen los componentes de ISTIOD.
Moderniza un clúster
Durante la modernización activa de un clúster, ambas implementaciones del plano de control se ejecutan de forma temporal en paralelo y, de manera segura y controlada, se procesan las siguientes tareas:
- Habilita la nueva implementación del plano de control. Si configuraste períodos de mantenimiento
para tu clúster, este paso comenzará durante un período de mantenimiento
y continuará hasta que se complete.
Ten en cuenta los detalles siguientes:
- Para habilitar la verificación de estado, se crea el DaemonSet
snken el espacio de nombreskube-systemdel clúster y se crea una regla de firewall por clúster. - Para habilitar la transferencia del grupo de extremos de red (NEG),
se agrega la anotación
cloud.google.com/nega todos los servicios de Kubernetes. - Se crean recursos nuevos de Google Cloud , como malla, rutas, servicios de backend y verificaciones de estado, en el clúster.
- Algunos de los recursos nuevos tienen cuotas limitadas. Puedes ver las cuotas y solicitar más si es necesario.
- El clúster se supervisa durante el tiempo de prueba antes de pasar al siguiente paso.
- Para habilitar la verificación de estado, se crea el DaemonSet
- Cambia el tráfico a la nueva implementación del plano de control. Si configuraste
períodos de mantenimiento para tu clúster, este paso comenzará durante un
período de mantenimiento y continuará hasta que se complete. Ten en cuenta los detalles siguientes:
- Se reinician los Pods administrados por la implementación de Kubernetes que tienen proxies de Cloud Service Mesh, por lo que se vuelven a conectar al plano de control nuevo.
- Los Pods se reinician en oleadas cada vez más grandes con un tiempo de prueba después de cada oleada para la supervisión.
Reinicio manual de las cargas de trabajo que no son de implementación (se requiere la acción del cliente).
- Google reinicia automáticamente las cargas de trabajo administradas por los Deployments de Kubernetes.
Las cargas de trabajo administradas por otros tipos de recursos de Kubernetes, como
StatefulSets o DaemonSets, se deben reiniciar de forma manual. Si un clúster
contiene estas cargas de trabajo, informa la
condición
MODERNIZATION_REQUIRES_MANUAL_WORKLOAD_RESTARTy la flota informa la condiciónMODERNIZATION_REQUIRES_CUSTOMER_TRIGGER. - Durante la modernización activa del clúster, después de que se hayan reiniciado las cargas de trabajo de
Deployment, informamos una condición a nivel del clúster deMODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART(junto conMODERNIZATION_MIGRATING_WORKLOADS). - En este punto, debes reiniciar las cargas de trabajo restantes de forma manual para que
sus proxies se conecten a la implementación del plano de control de
TRAFFIC_DIRECTOR. - Google espera al menos 60 días para que reinicies todas las cargas de trabajo antes
de continuar con los clústeres posteriores (en una flota de varios clústeres) o iniciar
el período de prueba de la flota. Las cargas de trabajo que permanezcan
conectadas a
ISTIODperderán la asistencia. - Para verificar qué proxies aún están conectados a
ISTIOD, ejecuta el comandogcloud beta container fleet mesh debug proxy-status, como se describe en Visualiza el estado del plano de control. Los proxies con un ID de instancia de Istiod en la columnaISTIODdel resultado del comando aún se conectan aISTIODy requieren un reinicio manual. - Después de que todas las cargas de trabajo de la malla del clúster se conecten a
TRAFFIC_DIRECTOR, las condicionesMODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTARTyMODERNIZATION_REQUIRES_MANUAL_WORKLOAD_RESTARTse borran automáticamente y el estado del clúster cambia aMODERNIZATION_COMPLETED.
- Google reinicia automáticamente las cargas de trabajo administradas por los Deployments de Kubernetes.
Las cargas de trabajo administradas por otros tipos de recursos de Kubernetes, como
StatefulSets o DaemonSets, se deben reiniciar de forma manual. Si un clúster
contiene estas cargas de trabajo, informa la
condición
Una vez que se hayan migrado todas las cargas de trabajo de un clúster, este esperará el período de prueba de la flota.
Para supervisar el estado de modernización activo de tus clústeres, consulta Verifica el estado de modernización.
Verifica el estado de la modernización y toma medidas
Puedes supervisar el progreso de la modernización de tus flotas y clústeres con la Google Cloud CLI:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
Reemplaza FLEET_PROJECT_ID por el ID del proyecto host de flota.
El resultado es similar al siguiente:
membershipStates:
projects/123456789/locations/global/memberships/cluster-1:
servicemesh:
conditions:
- code: MODERNIZATION_MIGRATING_WORKLOADS
documentationLink: https://cloud.google.com/service-mesh/docs/...
severity: INFO
state:
servicemesh:
conditions:
- code: MODERNIZATION_MODERNIZING
documentationLink: https://cloud.google.com/service-mesh/docs/...
severity: INFO
El estado de modernización se informa en los campos state.servicemesh.conditions
(nivel de flota) y membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions
(nivel de clúster):
Estado de una modernización exitosa de la flota
En una modernización de flota exitosa, el estado de la flota comenzará como
MODERNIZATION_MODERNIZING.
Luego, cada clúster pasaría por los siguientes estados:
MODERNIZATION_SCHEDULEDMODERNIZATION_PREPARINGMODERNIZATION_PREPAREDMODERNIZATION_MIGRATING_WORKLOADS- (opcionalmente)
MODERNIZATION_MIGRATING_WORKLOADSporMODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART MODERNIZATION_COMPLETED
Una vez que todos los clústeres de la flota hayan completado su modernización, la flota pasará por los siguientes estados:
MODERNIZATION_MODERNIZEDMODERNIZATION_FINALIZED
Reversiones
La modernización impulsada por Google supervisa la preparación y el estado de la implementación durante todo el proceso de modernización, y activaremos automáticamente una reversión si detectamos problemas. Si detectas un problema, comunícate con Atención al cliente de Cloud para solicitar una reversión.
En el caso de la modernización activada por el cliente, puedes activar una reversión en cualquier momento.
Durante una reversión, la flota muestra el estado MODERNIZATION_ROLLING_BACK_FLEET
y el clúster muestra el estado MODERNIZATION_ROLLING_BACK_CLUSTER.
Una vez que se completa la reversión de un clúster, se muestra temporalmente el estado
MODERNIZATION_ABORTED.
Cómo controlar errores y bloqueos (solo activados por el cliente)
Durante la modernización activada por el cliente, si un clúster tiene un problema que
impide el progreso, su condición cambia a MODERNIZATION_STALLED.
Google no activará reversiones para la modernización activada por el cliente. Debes
clasificar el problema y decidir si quieres corregirlo o
activar una reversión.
Cuando un clúster informa MODERNIZATION_STALLED, inspecciona los detalles de la condición
para obtener un vínculo directo a la sección de error correspondiente:
Errores que el usuario puede corregir
Si detectamos una configuración de malla o clúster incompatible, detendremos la modernización. Asegúrate de que los informes de compatibilidad estén habilitados y revisa las condiciones a nivel de la flota y del clúster para detectar brechas, como se describe en Información sobre la compatibilidad de Cloud Service Mesh.
- Reintento inmediato: En cuanto se resuelve el bloqueo, detectamos el cambio y reanudamos la modernización de inmediato, sin esperar al siguiente período de mantenimiento.
Errores internos
Los ingenieros de Google revisan los problemas internos del servicio de Google y, si es posible, reanudarán la modernización. Ten en cuenta que la modernización podría reanudarse fuera de un período de mantenimiento, al igual que en el caso de los errores que requieren la intervención del usuario. Para evitar esto, puedes activar una reversión.
Si la modernización se detiene durante más de 24 horas y no hay brechas de compatibilidad, comunícate con Atención al cliente de Cloud para obtener más detalles o activa una reversión si las cargas de trabajo de producción se ven afectadas.
Referencia de las condiciones a nivel de la flota
| Condición | Descripción |
|---|---|
MODERNIZATION_COMPATIBLE |
La flota es compatible con la nueva implementación del plano de control. |
MODERNIZATION_REQUIRES_CUSTOMER_TRIGGER |
La modernización de la flota debe ser activada por el cliente y Google no puede programarla automáticamente. |
MODERNIZATION_WILL_BE_SCHEDULED |
Modernización impulsada por Google: Todas las flotas no aplazadas de la organización son compatibles y se pusieron en cola para su programación. |
MODERNIZATION_MODERNIZING |
La modernización está en curso de forma activa para uno o más clústeres de la flota. |
MODERNIZATION_MODERNIZED |
Todos los clústeres completaron la modernización activa. La flota se encuentra en el período de prueba. |
MODERNIZATION_FINALIZED |
La modernización se completó y finalizó. Se quitarán los componentes heredados de Istiod. Ya no es posible realizar la reversión. |
MODERNIZATION_ROLLING_BACK_FLEET |
Se está realizando una reversión a nivel de la flota. |
Referencia de las condiciones a nivel del clúster
| Condición | Descripción |
|---|---|
MODERNIZATION_REQUIRES_MANUAL_WORKLOAD_RESTART |
El clúster contiene cargas de trabajo de malla que no son de Deployment, como StatefulSets o DaemonSets, que Cloud Service Mesh no puede reiniciar automáticamente y que requieren un reinicio manual durante la modernización. |
MODERNIZATION_SCHEDULED |
El clúster está programado para modernizarse en la fecha especificada en la condición o después de ella. Si se configuran períodos de mantenimiento o exclusiones para tu clúster, la fecha indicará el período de mantenimiento objetivo. |
MODERNIZATION_PREPARING |
Habilita la nueva implementación del plano de control. |
MODERNIZATION_PREPARED |
La nueva implementación del plano de control está habilitada. La migración de la carga de trabajo aún no comenzó. |
MODERNIZATION_MIGRATING_WORKLOADS |
El clúster está migrando de forma activa las cargas de trabajo a la nueva implementación del plano de control. |
MODERNIZATION_AWAITING_MANUAL_WORKLOAD_RESTART |
Se completó la migración automatizada de la carga de trabajo. Reinicia las cargas de trabajo de la malla que no sean Deployment, como StatefulSets, DaemonSets o Jobs, para que sus proxies se conecten a la implementación del plano de control de TRAFFIC_DIRECTOR. |
MODERNIZATION_COMPLETED |
El clúster completó la modernización y se encuentra en el período de prueba. |
MODERNIZATION_STALLED |
La modernización se detuvo debido a un error (solo se activa por el cliente). Consulta los detalles de la condición para obtener la resolución. |
MODERNIZATION_ROLLING_BACK_CLUSTER |
Se está revirtiendo el clúster de forma activa. |
MODERNIZATION_ABORTED |
El clúster se revirtió al plano de control heredado. Se informó por un período breve. |