Prepararse para el cierre del agente de inicio

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

En este documento se describe cómo planificar la migración de los contenedores que has creado durante la creación de la VM a otros servicios. Google Cloud

Información general

¿Qué es un agente de inicio de contenedor en Compute Engine?
El agente de inicio de contenedores te permite desplegar y configurar contenedores en instancias de Compute Engine o en instancias de un grupo de instancias gestionado (MIG) durante la creación de la VM e inicia un contenedor Docker.
¿Por qué se ha retirado el agente de inicio de contenedores?

En función de los comentarios de los clientes, Google Cloud mejora las opciones de implementación de contenedores. Hemos retirado el agente de inicio de contenedores para poder ofrecerte opciones más flexibles para desplegar tus contenedores.

Para obtener más información sobre las opciones obsoletas, consulta Opciones obsoletas para configurar contenedores en máquinas virtuales.

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

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

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

Te recomendamos que migres los contenedores a soluciones alternativas mucho antes de esas fechas para que la transición sea fluida.

¿Cuándo dejaré de poder crear máquinas virtuales o grupos de instancias gestionados con contenedores implementados directamente mediante los metadatos gce-container-declaration?

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

¿Cuándo dejaré de poder 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 la discontinuación, es decir, el 31 de julio del 2027.

Uso cloud-init para ejecutar contenedores en máquinas virtuales. ¿Me afecta este cambio?

No. Esta discontinuación no afecta a las VMs configuradas con cloud-init. Puedes seguir usando cloud-init para configurar instancias. Para obtener más información, consulta Usar cloud-init con la configuración de Cloud.

¿Cómo sé si este cambio me afecta?

Si vas a desplegar un contenedor en una VM durante la creación de la VM mediante el agente de inicio de contenedores o especificando gce-container-declaration, esta obsolescencia te afectará. Para comprobar si hay alguna instancia afectada 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 están en el ámbito de la obsolescencia. Si usas varios proyectos, ejecuta el comando en todos los proyectos activos.

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

Si quieres comprobar una instancia específica, ejecuta el siguiente comando de gcloud CLI:

gcloud compute instances describe VM_NAME

Sustituye VM_NAME por 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 la salida del comando, significa que tu VM se ve afectada por este cambio.

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

No. La seguridad y la privacidad son fundamentales en todo lo que hacemos en Google. Cuando usas nuestras secuencias de comandos o soluciones gestionadas, puedes configurar ajustes de seguridad y privacidad específicos para satisfacer tus necesidades. Para obtener más información, consulta la guía de migración.

Soluciones alternativas

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

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

  • Si quieres seguir desplegando contenedores en máquinas virtuales o grupos de instancias gestionados, ejecutar contenedores para pruebas y desarrollo, o ejecutar una carga de trabajo que conste de una sola máquina virtual, usa secuencias de comandos de inicio o cloud-init.
  • Si tienes aplicaciones de contenedores sin reconocimiento del estado y tareas pequeñas o medianas, te recomendamos que uses 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 informáticos adicionales, considera usar Batch. También puedes usar scripts de inicio.
  • Si necesitas un control y una escalabilidad avanzados, o bien no puedes cumplir los requisitos con las otras opciones, considera usar GKE.

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

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

Te recomendamos que te plantees migrar a soluciones de contenedores como Google Kubernetes Engine, Cloud Run y Batch. Estos servicios gestionados ofrecen ventajas significativas con respecto a las implementaciones convencionales basadas en máquinas virtuales, como una mayor escalabilidad, flexibilidad y funciones de gestión avanzadas.

Estas son algunas de las principales ventajas:

  • Reduce la sobrecarga de gestión: como servicios totalmente gestionados,Google Cloudse encarga de la infraestructura subyacente (máquinas virtuales, aplicación de parches y escalado). Este enfoque libera tiempo valioso del personal y reduce la carga operativa.
  • Escalar automáticamente y garantizar la elasticidad: estos servicios ajustan automáticamente los recursos en función de la demanda. Esto conlleva una mejor utilización de los recursos y un posible ahorro de costes en comparación con el aprovisionamiento excesivo de VMs.
  • Ahorra costes en cargas inactivas: a diferencia de las VMs, que generan costes incluso cuando están inactivas, los servicios gestionados 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 coste.

Para obtener instrucciones detalladas sobre la migración, consulta la guía de migración.

¿Qué costes conlleva cada solución alternativa y cómo se comparan con la configuración actual?

Secuencias de comandos de inicio de la implementación de contenedores o cloud-init: usar secuencias de comandos de inicio o cloud-init como sustituto directo no cambia los costes de Compute Engine. Seguirás pagando por los recursos de las máquinas virtuales subyacentes.

Servicios gestionados: migrar a servicios como Cloud Run o Batch puede suponer un ahorro de costes, sobre todo en el caso de las aplicaciones con un uso variable. A diferencia de las máquinas virtuales, que generan cargos incluso cuando están inactivas, estos servicios gestionados pueden ser más eficientes. Además, los niveles gratuitos pueden reducir aún más los costes de las cargas de trabajo más pequeñas y temporales.

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

¿Esta discontinuación significa que las imágenes de Container-Optimized OS se discontinuarán y, por lo tanto, si queremos ejecutar Docker en máquinas virtuales de Compute Engine, tendremos que configurar nuestra propia plantilla de VM?

No, las imágenes de Container-Optimized OS no se van a dejar de usar. El cambio se refiere a cómo 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 los contenedores mediante la clave de metadatos gce-container-declaration. Esto significa que las imágenes de Container-Optimized OS seguirán estando disponibles y compatibles. Sin embargo, debe actualizar su máquina virtual para que use una secuencia de comandos de inicio o una configuración de cloud-init para desplegar contenedores en lugar de usar la clave de metadatos gce-container-declaration.

Proceso de migración

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

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

  • Conoce tus opciones: consulta la guía de migración para descubrir otras formas de ejecutar tus contenedores.
  • Planifica la migración con antelación: para que la transición se lleve a cabo sin contratiempos, empieza a planificar la migración de tus implementaciones de contenedores actuales mucho antes del 31 de julio del 2026.
  • Prepara 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 del 2026, ya que no se podrán desplegar contenedores directamente en VMs ni MIGs.
  • Fecha límite de migración final: asegúrate de que todas tus cargas de trabajo de contenedores se hayan migrado a soluciones alternativas antes del 31 de julio del 2027, fecha en la que se retirará por completo el método de implementación directa.
¿Tengo que migrar a una de las soluciones recomendadas o hay alternativas que pueda usar?

Te ofrecemos la flexibilidad de adoptar cualquier solución que se ajuste a las necesidades de tu empresa y que tenga asistencia activa. Tienes a tu disposición recursos como la guía de migración para ayudarte a elegir la opción más adecuada.

¿Es necesario crear una copia de seguridad de los datos o exportarlos como parte del proceso de migración?

Aunque siempre es una práctica recomendada fundamental hacer una copia de seguridad o exportar los datos para protegerlos y garantizar la continuidad de la actividad empresarial, no es un paso necesario en este proceso de migración.

¿Cuánto tiempo tardaré en migrar a una de las alternativas? ¿Hay factores que puedan afectar al tiempo que debo dedicar?

Secuencia de comandos de inicio del despliegue 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 llevar unos minutos cada una.

Servicios gestionados: optar por soluciones deGoogle Cloud PaaS totalmente gestionadas y sin servidor, como Cloud Run, Batch o GKE, puede implicar una mayor inversión inicial de tiempo y esfuerzo. Esto se debe al cambio fundamental de un enfoque centrado en las máquinas virtuales (IaaS), en el que gestionas la infraestructura, a un modelo de PaaS, en el que la plataforma se encarga de gran parte de esta tarea. Esta adaptación puede requerir cambios en tu aplicación, como asegurarte de que no tenga estado, pero las ventajas a largo plazo pueden incluir mejoras sustanciales en la eficiencia operativa, la escalabilidad y la rentabilidad.

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

Si decido migrar a una alternativa, ¿se producirán interrupciones o tiempos de inactividad en los Google Cloud proyectos, las VMs, los servicios y las aplicaciones?

Por lo general, la transición a la solución alternativa recomendada se ha diseñado para que sea un proceso sin tiempo de inactividad.

Para migrar contenedores de larga duración en VMs de Compute Engine, te recomendamos que configures nuevas VMs con la configuración alternativa y que cambies el tráfico una vez que se hayan probado para evitar interrupciones.

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

Si usas Terraform u otra automatización similar para crear o actualizar máquinas virtuales 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 del 2026. Para evitar interrupciones, debes actualizar tu configuración para incluir una secuencia de comandos de inicio para la implementación de contenedores y eliminar la dependencia de la clave de metadatos gce-container-declaration. Para obtener instrucciones detalladas sobre cómo implementar este cambio, consulta Migrar contenedores que se hayan desplegado en máquinas virtuales durante la creación de la máquina virtual.

Obtener asistencia

¿Con quién debo ponerme en contacto en Compute Engine si tengo alguna pregunta sobre el proceso de migración?
Si tienes alguna pregunta o necesitas ayuda, ponte en contacto con el equipo de Asistencia de Google Cloud.
¿Qué recursos tengo a mi disposición para recibir asistencia con la migración y obtener asesoramiento técnico?
Esta sección de preguntas frecuentes, una guía de migración y el equipo de Asistencia de Google Cloud están a tu disposición para ayudarte con el proceso de migración.