Actualizar cargas de trabajo de contenedores para mejorar el tiempo de ejecución

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

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

Acerca de la conversión de cargas de trabajo de contenedores

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

Una carga de trabajo con reconocimiento del estado es aquella que mantiene o almacena información de estado. En el caso de las cargas de trabajo con reconocimiento del estado, a menudo se montan volúmenes adicionales mediante StatefulSet en spec.containers.volumeMounts. Asegúrate de conservar las definiciones de volumeMounts y, al mismo tiempo, eliminarlas de /sys/fs/cgroup. Para obtener más información, consulta Montar volúmenes externos.

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

  • Dockerfile

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

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

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

Convertir una carga de trabajo sin estado

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

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

  2. Edita el archivo Dockerfile para definir 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. Busque la siguiente sección en el archivo y elimine 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. Añade las líneas siguientes para definir la variable de entorno HC_V2K_SERVICE_MANAGER.

    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. Guarda el archivo.

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

  8. Crea la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada. Asegúrate de que el proceso de compilación tenga tiempo suficiente para completarse. 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. Despliega el contenedor:

    kubectl apply -f deployment_spec.yaml

    Si aplicas la especificación 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. Consulta los pods que se están desplegando en el clúster.

    kubectl get pods

Convertir una carga de trabajo con reconocimiento del estado

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

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

  2. Edita el archivo Dockerfile para definir 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. Busca las tres secciones siguientes en el archivo y elimina 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 debes eliminar las definiciones de volumeMounts y volumes para cgroups y dejar las definiciones restantes.

  5. Añade las siguientes líneas para definir la variable de entorno HC_V2K_SERVICE_MANAGER:

    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. Guarda el archivo.

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

  8. Crea la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada. Asegúrate de que el proceso de compilación tenga tiempo suficiente para completarse. 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. Despliega el contenedor:

    kubectl apply -f deployment_spec.yaml

    Si aplicas el archivo de 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. Consulta los pods que se están desplegando en el clúster.

    kubectl get pods

Tareas posteriores a la conversión

Después de convertir una migración para que use el gestor de servicios de Linux simplificado, puede que quieras modificarla para hacer lo siguiente:

  • Actualiza los servicios que usa la carga de trabajo migrada.
  • Añade nuevos servicios.

En ambos casos, debes editar el Dockerfile y, a continuación, volver a compilar la imagen de contenedor.

Actualizar servicios

En esta sección, edita el Dockerfile para actualizar el archivo services-config.yaml del contenedor en función de los cambios realizados en /etc/systemd en la carga de trabajo migrada.

Para actualizar la imagen de contenedor de un servicio que ya tienes, sigue estos pasos:

  1. Añade el comando servicemanager_generate_config al Dockerfile:

    ...
    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. Crea la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada. Asegúrate de que el proceso de compilación tenga tiempo suficiente para completarse. 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. Despliega la imagen recién creada:

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

Añadir servicios

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

  1. Añade el comando servicemanager_generate_config al Dockerfile:

    ...
    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. Crea la imagen actualizada y envíala a Container Registry con una etiqueta de versión actualizada. Asegúrate de que el proceso de compilación tenga tiempo suficiente para completarse. 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. Despliega la imagen recién creada:

    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 acepta 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 por primera vez tu migración para usar el gestor de servicios de Linux simplificado.

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

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

    Para añadir varios servicios, añade varios comandos RUN /servicemanager_generate_config, uno por cada servicio.

Siguientes pasos