Prepárate para el cierre del agente de inicio

El agente de inicio de contenedores que implementa contenedores en instancias de Compute Engine durante la creación de la VM está en desuso.

En este documento, se describe cómo planificar la migración de los contenedores que creaste durante la creación de la VM a otros servicios de Trusted Cloud by S3NS .

Información general

¿Qué es un agente de inicio de contenedores en Compute Engine?
El agente de inicio de contenedores te permite implementar y configurar contenedores en instancias de Compute Engine o en instancias de un grupo de instancias administrado (MIG) durante la creación de la VM y, luego, inicia un contenedor de Docker.
¿Por qué dejó de estar disponible el agente de inicio del contenedor?

Según los comentarios de los clientes, Trusted Cloud by S3NS mejora las opciones de implementación de contenedores. Hemos dejado de utilizar el agente de inicio de contenedores para poder ofrecerte opciones más flexibles para implementar tus contenedores.

Para obtener más información sobre las opciones que dejaron de estar disponibles, consulta Opciones obsoletas para configurar contenedores en VMs.

¿Cuáles son los hitos clave de esta baja y qué sucede si no tomo medidas antes de la fecha límite?

A partir del 31 de julio de 2026, dejarán de funcionar todos los flujos de trabajo que dependan del agente de inicio del contenedor o de los metadatos de la instancia gce-container-declaration.

A partir del 31 de julio de 2027, Google dejará de admitir el agente de inicio de contenedores y no se proporcionarán más actualizaciones para las VMs en ejecución que usen los metadatos de gce-container-declaration. Ejecutarás las cargas de trabajo bajo tu propio riesgo, y esto puede afectar tu flujo de trabajo.

Te recomendamos que migres los contenedores a soluciones alternativas mucho antes de estas fechas para garantizar una transición sin problemas.

¿Cuándo ya no podré crear VMs o MIGs nuevas con contenedores implementados directamente con los metadatos de gce-container-declaration?

12 meses después de la notificación inicial de baja, es decir, el 31 de julio de 2026.

¿Cuándo ya no podré ejecutar implementaciones de contenedores en VMs o MIGs que usen los metadatos gce-container-declaration?

Dejaremos de admitir las cargas de trabajo implementadas con el agente de inicio de contenedores 24 meses después de la notificación inicial de baja, es decir, el 31 de julio de 2027.

Uso cloud-init para ejecutar contenedores en VMs. ¿Me afecta este cambio?

No. Esta baja no afecta a las VMs configuradas con cloud-init. Puedes seguir usando cloud-init para configurar instancias. Para obtener más información, consulta Usa cloud-init con Cloud config.

¿Cómo puedo saber si me afectará este cambio?

Si implementas un contenedor en una VM durante la creación de la VM con el agente de inicio de contenedores o especificando gce-container-declaration, esta baja te afectará. Para validar si hay instancias afectadas en tu proyecto, ejecuta el siguiente comando de gcloud CLI:

gcloud compute instances list --filter="metadata.items.key:gce-container-declaration"

Este comando proporciona una lista de todas las instancias de VM de tu proyecto que contienen la clave de metadatos gce-container-declaration. La clave de metadatos identifica de forma única las VMs que se encuentran dentro del alcance de la baja. Si usas varios proyectos, ejecuta el comando en todos los proyectos activos.

Para obtener más información sobre cómo ver los metadatos del proyecto, consulta la documentación de metadatos.

Si tienes una instancia específica que deseas verificar, ejecuta el siguiente comando de gcloud CLI:

gcloud compute instances describe VM_NAME

Reemplaza VM_NAME con el nombre de la instancia de VM. Este comando proporciona toda la información de una instancia determinada, incluidos los metadatos. Si ves la clave de metadatos gce-container-declaration en el resultado del comando, significa que este cambio afecta a tu VM.

¿Existe algún riesgo para la seguridad o la privacidad del proyecto durante la migración?

No. La seguridad y la privacidad son fundamentales para todo lo que hacemos en Google. Cuando usas nuestros secuencias de comandos o soluciones administradas, tienes la flexibilidad de configurar parámetros de seguridad y privacidad específicos para satisfacer tus requisitos. Para obtener más información, consulta la guía de migración.

También es posible

¿Cuáles son las soluciones alternativas recomendadas para los contenedores en Compute Engine y cómo elijo la adecuada para mis requisitos?

Puedes elegir una de las siguientes opciones para migrar tu contenedor:

  • Si deseas seguir implementando contenedores en VMs o MIG, ejecutar contenedores para pruebas y desarrollo, o ejecutar una carga de trabajo que consta de una sola VM, usa secuencias de comandos de inicio o cloud-init.
  • Si tienes aplicaciones en contenedores sin estado y trabajos pequeños o medianos, considera usar Cloud Run. También puedes usar secuencias de comandos de inicio.
  • Si tu contenedor es un trabajo por lotes que tiene un estado final definido y requiere recursos de procesamiento adicionales, considera usar Batch. También puedes usar secuencias de comandos de inicio.
  • Si necesitas control y escalabilidad avanzados, o bien no puedes cumplir con tus requisitos con las otras opciones, considera usar GKE.

Para obtener orientación y recomendaciones detalladas sobre las opciones de migración, lee la guía de migración.

¿Por qué debería considerar migrar a un servicio administrado, como Cloud Run, GKE o Batch, en lugar de usar una secuencia de comandos de inicio?

Te recomendamos que consideres migrar a soluciones de contenedores, como Google Kubernetes Engine, Cloud Run y Batch. Estos servicios administrados ofrecen ventajas significativas en comparación con las implementaciones convencionales basadas en VM, incluidas la escalabilidad mejorada, la flexibilidad y las capacidades de administración avanzadas.

Estos son algunos de los beneficios clave:

  • Reduce la sobrecarga de administración: Como servicios completamente administrados,Trusted Cloudse encarga de la infraestructura subyacente (VMs, parches, escalamiento). Este enfoque libera tiempo valioso del personal y reduce la carga operativa.
  • Escala automáticamente y garantiza la elasticidad: Estos servicios ajustan automáticamente los recursos en función de la demanda. Esto genera una mejor utilización de los recursos y posibles ahorros de costos en comparación con el aprovisionamiento excesivo de VMs.
  • Logra eficiencia en los costos para las cargas inactivas: A diferencia de las VMs, que generan costos incluso cuando están inactivas, los servicios administrados pueden ser más rentables para las aplicaciones con tráfico fluctuante o bajo.
  • Aprovecha la disponibilidad del nivel gratuito: GKE, Cloud Run y Batch ofrecen un nivel gratuito que te permite ejecutar cargas de trabajo más pequeñas o realizar pruebas sin costo.

Para obtener orientación detallada sobre la migración, consulta la guía de migración.

¿Cuáles son las consideraciones de costos para cada solución alternativa y cómo se comparan con la configuración actual?

Secuencias de comandos de inicio de implementación de contenedores o cloud-init: El uso de secuencias de comandos de inicio o cloud-init como reemplazo directo no cambia inherentemente los costos de Compute Engine. Aún pagas por los recursos de la VM subyacente.

Servicios administrados: Migrar a servicios como Cloud Run o Batch puede generar ahorros en los costos, en especial para las aplicaciones con uso variable. A diferencia de las VMs, que generan cargos incluso cuando están inactivas, estos servicios administrados pueden ser más eficientes. Además, los niveles gratuitos pueden reducir aún más los costos de las cargas de trabajo más pequeñas y temporales.

Para obtener más información, consulta Compara las opciones de implementación de contenedores. Los precios varían según el servicio elegido y tu configuración específica. Usa la calculadora de precios para obtener una estimación precisa.

¿Esta baja en la disponibilidad significa que las imágenes de Container-Optimized OS dejarán de estar disponibles y, por lo tanto, si queremos ejecutar Dockers en las VMs de Compute Engine, tendremos que configurar nuestra propia plantilla de VM?

No,las imágenes de Container-Optimized OS no se dejarán de usar. El cambio se relaciona con la forma en que se inician los contenedores en las VMs que usan Container-Optimized OS. Las versiones más recientes de Container-Optimized OS ya no admitirán konlet, que es el agente de inicio que inicia contenedores con la clave de metadatos gce-container-declaration. Esto significa que las imágenes de Container-Optimized OS seguirán disponibles y con asistencia. Sin embargo, debes actualizar tu VM para que use una secuencia de comandos de inicio o una configuración de cloud-init para implementar contenedores en lugar de usar la clave de metadatos gce-container-declaration.

El proceso de migración

¿Cuál es el enfoque recomendado para migrar contenedores a las soluciones alternativas?

Te recomendamos que sigas estos pasos para realizar la migración:

  • Conoce tus opciones: Revisa la guía de migración para explorar formas alternativas de ejecutar tus contenedores.
  • Planifica la migración con anticipación: Para garantizar una transición sin problemas, comienza a planificar la migración de tus implementaciones de contenedores actuales mucho antes del 31 de julio de 2026.
  • Prepárate para las nuevas cargas de trabajo: Asegúrate de que tus nuevas cargas de trabajo de contenedores estén listas para ejecutarse en soluciones alternativas antes del 31 de julio de 2026, ya que la implementación directa de contenedores en VMs o MIG ya no será posible.
  • Fecha límite final de la migración: Asegúrate de que todas tus cargas de trabajo de contenedores existentes se migren a soluciones alternativas antes del 31 de julio de 2027, fecha en la que se retirará por completo el método de implementación directa.
¿Debo migrar a una de las soluciones recomendadas o hay alternativas que puedo usar?

Apoyamos tu flexibilidad para adoptar cualquier solución que se alinee con tus necesidades comerciales y que reciba asistencia de forma activa. Hay recursos disponibles, como la guía de migración, para ayudarte a elegir la opción más adecuada.

¿Se requiere una copia de seguridad o exportación de datos como parte del proceso de migración?

Si bien realizar una copia de seguridad o exportar los datos es siempre una práctica recomendada fundamental para la seguridad de los datos y la continuidad del negocio, no es un paso necesario para este proceso de migración.

¿Cuánto tiempo me llevará migrar a una de las alternativas? ¿Hay factores que podrían afectar mi compromiso de tiempo?

Secuencia de comandos de inicio de la implementación del contenedor: La configuración inicial y las pruebas con secuencias de comandos de inicio deberían llevar entre 1 y 2 horas. Las implementaciones posteriores solo deberían tardar unos minutos cada una.

Servicios administrados: Optar por soluciones deTrusted Cloud by S3NS como Cloud Run, Batch o GKE, que son ofertas de PaaS sin servidores y completamente administradas, podría implicar una mayor inversión inicial de tiempo y esfuerzo. Esto se debe al cambio fundamental de un enfoque centrado en la VM (IaaS), en el que administras la infraestructura, a un modelo de PaaS en el que la plataforma se encarga de gran parte de esto. Esta adaptación puede requerir cambios en tu aplicación, como garantizar que no tenga estado, pero los beneficios a largo plazo pueden incluir ganancias sustanciales en eficiencia operativa, escalabilidad y rentabilidad.

Para obtener orientación sobre esta transición, consulta la guía de migración.

Si elijo migrar a una alternativa, ¿se producirán interrupciones o tiempo de inactividad en los proyectos, las VMs, los servicios y las apps de Trusted Cloud by S3NS ?

En general, la transición a la solución alternativa recomendada está diseñada para ser un proceso sin tiempo de inactividad.

Para la migración de contenedores de larga duración en VMs de Compute Engine, recomendamos configurar VMs nuevas con la configuración alternativa y cambiar el tráfico una vez que se prueben para evitar interrupciones.

¿Cómo afecta esta migración a mi configuración de Terraform?

Si usas Terraform o una automatización similar para crear o actualizar VMs o MIGs con contenedores configurando explícitamente la clave de metadatos gce-container-declaration, tu flujo de trabajo dejará de funcionar el 31 de julio de 2026. Para evitar interrupciones, debes actualizar tu configuración para incluir una secuencia de comandos de inicio para la implementación de contenedores y quitar la dependencia de la clave de metadatos gce-container-declaration. Para obtener instrucciones detalladas sobre cómo implementar este cambio, consulta Migra contenedores que se implementaron en VMs durante la creación de la VM.

Obtén asistencia

¿Con quién me debo comunicar en Compute Engine si tengo preguntas sobre el proceso de migración?
Si tienes alguna pregunta o necesitas ayuda, comunícate con la Asistencia de Google Cloud.
¿Qué recursos están disponibles para ayudarme con la migración y brindarme orientación técnica?
Esta preguntas frecuentes, una guía de migración y la Asistencia de Google Cloud están disponibles para ayudarte con el proceso de migración.