El agente de inicio de contenedores (konlet) que implementa contenedores en instancias de Compute Engine durante la creación de VM dejó de estar disponible.
En este documento, se describe cómo planificar la migración de los contenedores que creaste durante la creación de VM a otros Google Cloud servicios.
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 VM y, luego, inicia un contenedor de Docker.
- ¿Por qué dejó de estar disponible el agente de inicio de contenedores?
Según los comentarios de los clientes, Google Cloud mejora las opciones de implementación de contenedores. Dimos de baja el agente de inicio de contenedores para poder brindarte 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, ya no funcionarán los flujos de trabajo que dependan del agente de inicio de contenedores o de los metadatos de instancia
gce-container-declaration.A partir del 31 de julio de 2027, Google dejará de brindar asistencia para el agente de inicio de contenedores y no se proporcionarán más actualizaciones para las VMs en ejecución que usen los
gce-container-declarationmetadatos. Ejecutarás las cargas de trabajo bajo tu propio riesgo, lo que 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 nuevos con contenedores implementados directamente con los metadatos
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.
- ¿Cómo afecta esta baja a mi configuración de Terraform?
Si usas Terraform o una automatización similar para crear o actualizar VMs o MIGs configurando de forma explícita la clave de metadatos
gce-container-declaration, tu flujo de trabajo dejará de funcionar el 31 de julio de 2026. Para evitar interrupciones, actualiza tu configuración de Terraform para usar una secuencia de comandos de inicio para la implementación de contenedores y quita la dependencia de la clave de metadatosgce-container-declaration. Para obtener instrucciones detalladas, consulta la guía de migración.- ¿Esta baja significa que las imágenes de Container-Optimized OS dejarán de estar disponibles?
No, las imágenes de Container-Optimized OS no dejarán de estar disponibles. El cambio se relaciona con la forma en que se implementan los contenedores en las VMs que usan Container-Optimized OS. Las versiones más recientes de Container-Optimized OS ya no admitirán konlet, el agente de inicio de contenedores que usa la clave de metadatos
gce-container-declarationpara implementar contenedores. Las imágenes de Container-Optimized OS seguirán estando disponibles y admitidas. Sin embargo, debes actualizar la configuración de tu VM para usar una secuencia de comandos de inicio ocloud-initpara implementar contenedores en lugar de depender de la clave de metadatosgce-container-declaration.- Uso
cloud-initpara ejecutar contenedores en VMs. ¿Me afecta este cambio? No. Esta baja no afecta a las VMs que se configuran con
cloud-init. Puedes seguir usandocloud-initpara configurar instancias. Para obtener más información, consulta Usa cloud-init con la configuración de Cloud.- ¿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 están 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_NAMEReemplaza 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-declarationen el resultado del comando, significa que esta VM se ve afectada por este cambio.- ¿Existe alguna forma de evitar la creación de VMs que usen el agente de inicio de contenedores?
Sí. Los administradores de la organización pueden aplicar la restricción de la política de la organización
compute.managed.disableVmsWithContainerStartupAgentpara inhabilitar la creación de recursos que usen el agente de inicio de contenedores y la clave de metadatosgce-container-declaration. También puedes aplicar esta política en el modo de ejecución de prueba para supervisar el uso antes de bloquear la creación de recursos. Para obtener más información, consulta Evita la creación de VMs que usen los metadatos de contenedores obsoletos.- ¿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 nuestras secuencias de comandos o soluciones administradas, tienes la flexibilidad de configurar parámetros de configuración 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 MIGs, ejecutar contenedores para pruebas y desarrollo, o ejecutar una carga de trabajo que conste de una sola VM, usa secuencias de comandos de inicio o cloud-init.
- Si tienes aplicaciones de contenedores sin estado y trabajos pequeños o medianos, considera 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 Batch. También puedes usar secuencias de comandos de inicio .
- Si necesitas control y escalabilidad avanzados, o no puedes cumplir con tus requisitos con las otras opciones, considera 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, la flexibilidad y las capacidades de administración avanzadas mejoradas.
Estos son algunos de los beneficios clave:
- Reduce la sobrecarga de administración: Como servicios completamente administrados,Google Cloud se encarga de la infraestructura subyacente (VMs, aplicación de parches, escalamiento). Este enfoque libera tiempo valioso del personal y reduce tu carga operativa.
- Escala automáticamente y garantiza la elasticidad: Estos servicios ajustan automáticamente los recursos según 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 la rentabilidad 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.
- Utiliza la disponibilidad del nivel gratuito: GKE, Cloud Run y Batch ofrecen un nivel gratuito, lo 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-initcomo reemplazo directo no cambia de forma inherente los costos de Compute Engine. Aún pagas por los recursos subyacentes de la VM.Servicios administrados: La migración a servicios como Cloud Run o Batch puede ofrecer ahorros de costos, en especial para las aplicaciones con uso variable. A diferencia de las VMs que cobran 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 temporales más pequeñas.
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 significa que las imágenes de Container-Optimized OS dejarán de estar disponibles y, por lo tanto, si queremos ejecutar Dockers en VMs de Compute Engine, deberemos configurar nuestra propia plantilla de VM?
No, las imágenes de Container-Optimized OS no dejarán de estar disponibles. 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 de contenedores que inicia contenedores con la clave de metadatos
gce-container-declaration. Esto significa que las imágenes de Container-Optimized OS seguirán estando disponibles y admitidas. Sin embargo, debes actualizar tu VM para usar una secuencia de comandos de inicio o una configuración decloud-initpara implementar contenedores en lugar de usar la clave de metadatosgce-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 cargas de trabajo nuevas: 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 MIGs ya no es posible.
- Fecha límite final de 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, cuando se retire por completo el método de implementación directa.
- ¿Debo migrar a una de las soluciones recomendadas o hay alternativas que puedo usar?
Admitimos tu flexibilidad para adoptar cualquier solución que se alinee con las necesidades de tu empresa y que tenga asistencia 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 exportación de datos siempre es una práctica recomendada fundamental para la seguridad de los datos y la continuidad de la empresa, no es un paso necesario para este proceso de migración.
- ¿Cuánto tiempo tardaré en migrar a una de las alternativas y hay factores que podrían afectar mi compromiso de tiempo?
Secuencia de comandos de inicio de implementación de contenedores: La configuración y las pruebas iniciales con secuencias de comandos de inicio deberían tardar entre 1 y 2 horas. Las implementaciones posteriores solo deberían tardar unos minutos cada una.
Servicios administrados: Optar por Google Cloud soluciones como Cloud Run, Batch o GKE, que son ofertas de PaaS sin servidores y completamente administradas, puede 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 asegurarte de 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, ¿implica interrupciones o tiempo de inactividad para Google Cloud proyectos, VMs, servicios y apps?
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, para evitar interrupciones, te recomendamos que configures VMs nuevas con la configuración alternativa y que cambies el tráfico una vez que se prueben.
- ¿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 de forma explícita 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 metadatosgce-container-declaration. Para obtener instrucciones detalladas sobre cómo implementar este cambio, consulta Migra los contenedores que se implementaron en VMs durante la VM VMs.
Obtén asistencia
- ¿Con quién debo comunicarme en Compute Engine si tengo preguntas sobre el proceso de migración?
- Si tienes alguna pregunta o necesitas asistencia, comunícate con la Asistencia de Google Cloud.
- ¿Qué recursos están disponibles para brindarme asistencia con la migración y orientación técnica?
- Estas 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.