Actualiza las cargas de trabajo de los contenedores para mejorar el entorno de ejecución

Si tienes cargas de trabajo de contenedores existentes que usan las versiones 1.7.x y 1.8.x de Migrate to Containers, puedes convertirlas para que usen el administrador de servicios de Linux simplificado. Esta conversión te permite ejecutar estos contenedores en clústeres de GKE Autopilot.

Nota: No se puede convertir una carga de trabajo de contenedor que se creó mediante versiones de Migrate to Containers anteriores a la 1.7.0.

Para realizar la conversión, edita el Dockerfile y el archivo deployment_spec.yaml que se creó cuando realizaste la migración original. Una vez editado, puedes implementar la carga de trabajo del contenedor en los clústeres de Autopilot.

Sobre la conversión de cargas de trabajo de contenedores

El procedimiento para convertir cargas de trabajo existentes depende de si conviertes una carga de trabajo sin estado o una con estado.

Una carga de trabajo con estado es la que mantiene o almacena información de estado. Para cargas de trabajo con estado, a menudo activas volúmenes adicionales mediante StatefulSet en spec.containers.volumeMounts. Asegúrate de conservar las definiciones volumeMounts mientras las quitas para /sys/fs/cgroup. Consulta Activa volúmenes externos para obtener más información.

El proceso general de conversión de una carga de trabajo existente requiere que edites lo siguiente:

• Dockerfile

  • Establece la versión de Migrate to Containers en 1.15.0.
  • Inserta dos comandos ADD para copiar el archivo logs.yaml en la imagen de contenedor.
  • Inserta un comando RUN para la utilidad servicemanager_generate_config.

• Archivo deployment_spec.yaml en:

  • Borra las definiciones hostPath y volumeMounts para /sys/fs/cgroup.
  • Borra la definición securityContext.
  • Borra la definición readinessProbe.
  • Puedes dejar las definiciones mountPath y configMap para logs-config. Sin embargo, el registro no funciona actualmente con el administrador de servicios de Linux simplificado.

Para el proceso de conversión específico, consulta las siguientes secciones:

• Convierte una carga de trabajo sin estado
• Convierte una carga de trabajo con estado

Convierte una carga de trabajo sin estado

En el siguiente ejemplo, se muestra cómo convertir una carga de trabajo de contenedor sin estado:

1. Ubica el directorio que contiene los artefactos de migración existentes, incluido el archivo deployment_spec.yaml.

2. Edita el Dockerfile a fin de configurar la versión del producto, copiar el archivo logs.yaml y ejecutar la utilidad servicemanager_generate_config:

   ...
   # Set the product version to 1.15.0:
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   # Insert the ADD commands to copy the `logs.yaml` file to the container image:
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD logs.yaml /code/config/logs/logs.yaml
   
   # Insert the RUN command for servicemanager_generate_config:
   RUN /servicemanager_generate_config build-all -o /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

3. Abre el archivo deployment_spec.yaml en un editor. Por ejemplo:

   vi  deployment_spec.yaml

4. Ubica la siguiente sección en el archivo y borra las líneas indicadas:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     creationTimestamp: null
     name: IMAGE_NAME
        …
       spec:
         containers:
         - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
           name: IMAGE_NAME
   # Delete the following lines:
           readinessProbe:
             exec:
               command:
               - /code/ready.sh
           resources: {}
           securityContext:
             privileged: true
           volumeMounts:
           - mountPath: /sys/fs/cgroup
             name: cgroups
           - mountPath: /code/config/logs
             name: logs-config
         volumes:
         - hostPath:
             path: /sys/fs/cgroup
             type: Directory
           name: cgroups
         - configMap:
             name: suitecrm-crddefault-logs
           name: logs-config
   # Stop the delete here.

5. Agrega las siguientes líneas para configurar la variable de entorno HC_V2K_SERVICE_MANAGER.

   Precaución: Si usas Migrate for Containers 1.10 o una versión posterior, omite este paso.

   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Add the following lines:
       env:
         - name: HC_V2K_SERVICE_MANAGER
           value: "true"

6. Guarde el archivo.

7. Asegúrate de que el clúster de destino tenga acceso de lectura al registro de imágenes de Docker, como se describió en Asegúrate de que el clúster de destino tenga acceso de lectura al registro de imágenes de Docker.

8. Compila la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada, lo que garantiza que haya tiempo suficiente para que la compilación finalice. En el siguiente ejemplo, la imagen está en el directorio actual:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

9. Implementa el contenedor:

   kubectl apply -f deployment_spec.yaml

   Si aplicas las especificaciones de implementación a un clúster de Autopilot sin los cambios necesarios en deployment_spec.yaml, verás un mensaje de error con el siguiente formato:

   "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

10. Visualiza los pods que se implementan en el clúster.

    Nota: Cargar los nodos y extraer la imagen puede tomar unos minutos.

    kubectl get pods

Convierte una carga de trabajo con estado

En el siguiente ejemplo, se muestra cómo convertir una carga de trabajo de contenedor con estado:

1. Ubica el directorio que contiene los artefactos de migración existentes, incluido el archivo deployment_spec.yaml.

2. Edita el Dockerfile para configurar la versión del producto y ejecutar la utilidad servicemanager_generate_config:

   ...
   # Set the product version to 1.15.0:
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   # Insert the ADD commands to copy the `logs.yaml` file to the container image:
   ADD logs.yaml /code/config/logs/logsArtifact.yaml
   ADD logs.yaml /code/config/logs/logs.yaml
   
   # Insert the RUN command for servicemanager_generate_config:
   RUN /servicemanager_generate_config build-all -o /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

3. Abre el archivo deployment_spec.yaml en un editor. Por ejemplo:

   vi  deployment_spec.yaml

4. Ubica las siguientes tres secciones en el archivo y borra las líneas indicadas:

   apiVersion: apps/v1
   kind: StatefulSet
   ...
   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Delete the following lines:
       readinessProbe:
         exec:
           command:
           - /code/ready.sh
       resources: {}
       securityContext:
         privileged: true
   # Stop the delete here.
       volumeMounts:
   # Delete the following lines:
       - mountPath: /sys/fs/cgroup
         name: cgroups
   # Stop the delete here.
       - mountPath: /opt/suitecrm-7.10.5-0/mysql/data
         name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5
         subPath: opt/suitecrm-7.10.5-0/mysql/data
     volumes:
   # Delete the following lines:
     - hostPath:
         path: /sys/fs/cgroup
         type: Directory
       name: cgroups
   # Stop the delete here.
     - name: data-pvc-2-d0af-48b3-9f5e09c25fa5
       persistentVolumeClaim:
         claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

   Ten en cuenta que solo quitas las definiciones volumeMounts y volumes para cgroups y dejas las definiciones restantes.

5. Agrega las siguientes líneas para configurar la variable de entorno HC_V2K_SERVICE_MANAGER:

   Precaución: Si usas Migrate for Containers 1.10 o una versión posterior, omite este paso.

   spec:
     containers:
     - image: gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL
       name: IMAGE_NAME
   # Add the following lines:
       env:
       - name: HC_V2K_SERVICE_MANAGER
         value: "true"
   # Stop the add here.
       volumeMounts:
       - mountPath: /opt/suitecrm-7.10.5-0/mysql/data
         name: data-pvc-0-1b12-d0af-48b3-9f5e-6c25fa5
         subPath: opt/suitecrm-7.10.5-0/mysql/data
     volumes:
     - name: data-pvc-2-d0af-48b3-9f5e09c25fa5
       persistentVolumeClaim:
         claimName: data-pvc-0-1a2-d0af-48b3-9f5e-605fa5

6. Guarde el archivo.

7. Asegúrate de que el clúster de destino tenga acceso de lectura al registro de imágenes de Docker, como se describió en Asegúrate de que el clúster de destino tenga acceso de lectura al registro de imágenes de Docker.

8. Compila la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada, lo que garantiza que haya tiempo suficiente para que la compilación finalice. En el siguiente ejemplo, la imagen está en el directorio actual:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

9. Implementa el contenedor:

   kubectl apply -f deployment_spec.yaml

   Si aplicas las especificaciones de implementación a un clúster de Autopilot sin los cambios necesarios en deployment_spec.yaml, verás un mensaje de error con el siguiente formato:

   "Trying to run without root privileges is not possible. Did you try to use the new runtime? In that case please pass the environment variable HC_V2K_SERVICE_MANAGER=true to the pod"

10. Visualiza los pods que se implementan en el clúster.

    Nota: Cargar los nodos y extraer la imagen puede tomar unos minutos.

    kubectl get pods

Tareas posteriores a la conversión

Después de convertir una migración existente para que use el administrador de servicios simplificado de Linux, te recomendamos modificarla de la siguiente manera:

• Actualiza los servicios que usa la carga de trabajo migrada.
• Agregar nuevos servicios.

Para ambas situaciones, debes editar el Dockerfile y, luego, volver a compilar la imagen del contenedor.

Actualiza los servicios

En esta sección, editarás el Dockerfile para actualizar el archivo services-config.yaml en el contenedor según los cambios realizados en /etc/systemd en la carga de trabajo migrada.

Haz lo siguiente para actualizar la imagen del contenedor de un cambio a un servicio existente:

1. Agrega el comando servicemanager_generate_config al Dockerfile:

   Nota: Agrega el comando servicemanager_generate_config directamente al Dockerfile. No intentes ejecutarlo dentro de la carga de trabajo del contenedor.

   ...
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   
   # Use the update command for servicemanager_generate_config to update the configuration:
   RUN /servicemanager_generate_config update -u /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

2. Compila la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada, lo que garantiza que haya tiempo suficiente para que la compilación finalice. En el siguiente ejemplo, la imagen está en el directorio actual:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

3. Implementa la imagen recién compilada:

   kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Agregar servicios

Para agregar un servicio a la imagen del contenedor, sigue estos pasos:

1. Agrega el comando servicemanager_generate_config al Dockerfile:

   Nota: Agrega el comando servicemanager_generate_config directamente al Dockerfile. No intentes ejecutarlo dentro de la carga de trabajo del contenedor.

   ...
   FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.15.0 as migrate-for-anthos-runtime
   
   ...
   
   ADD blocklist.yaml /.m4a/blocklist.yaml
   
   # This example adds the redis-server service.
   # Add the following lines to install redis-server.
   RUN apt-get update && apt-get -y install redis-server
   
   # Use the servicemanager_generate_config add command to add
   # redis-server to the configuration:
   RUN /servicemanager_generate_config add redis-server -u /.m4a/
   
   # Migrate to Containers image includes entrypoint
   ENTRYPOINT [ "/.v2k.go" ]

2. Compila la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada, lo que garantiza que haya tiempo suficiente para que la compilación finalice. En el siguiente ejemplo, la imagen está en el directorio actual:

   gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .

3. Implementa la imagen recién compilada:

   kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record

Sintaxis de servicemanager_generate_config

La utilidad servicemanager_generate_config toma las siguientes opciones:

• build-all -o /.m4a/: Vuelve a compilar la migración y escribe la configuración en el directorio m4a. No cambies el nombre del directorio.

  Usa esta forma del comando cuando conviertas tu migración por primera vez para usar el administrador de servicios de Linux simplificado.

• update -u /.m4a/: Actualiza la lista de servicios existentes en el directorio m4a. No cambies el nombre del directorio.

• add SERVICE_NAME -u /.m4a/: Agrega el nombre del servicio a la migración y escribe la configuración en el directorio m4a. No cambies el nombre del directorio.

  Para agregar varios servicios, agrega varios comandos RUN /servicemanager_generate_config, uno por servicio.

¿Qué sigue?

• Obtén información sobre el nuevo entorno de ejecución mejorado.