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 archivologs.yaml
en la imagen del contenedor. - Inserta un comando
RUN
para la utilidadservicemanager_generate_config
.
Archivo
deployment_spec.yaml
a:- Elimina las definiciones de
hostPath
yvolumeMounts
de/sys/fs/cgroup
. - Elimina la definición de
securityContext
. - Elimina la definición de
readinessProbe
. - Puedes dejar las definiciones de
mountPath
yconfigMap
paralogs-config
, pero el registro no funciona actualmente con el gestor de servicios de Linux simplificado.
- Elimina las definiciones de
Para ver el proceso de conversión específico, consulta las secciones siguientes:
- Convertir una carga de trabajo sin estado
- Convertir una carga de trabajo con reconocimiento del estado
Convertir una carga de trabajo sin estado
En el siguiente ejemplo se muestra cómo convertir una carga de trabajo de contenedor sin estado:
Busca el directorio que contiene los artefactos de migración, incluido el archivo
deployment_spec.yaml
.Edita el archivo Dockerfile para definir la versión del producto, copiar el archivo
logs.yaml
y ejecutar la utilidadservicemanager_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" ]
Abre el archivo
deployment_spec.yaml
en un editor. Por ejemplo:vi deployment_spec.yaml
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.
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"
Guarda el archivo.
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.
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 .
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"
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:
Busca el directorio que contiene los artefactos de migración, incluido el archivo
deployment_spec.yaml
.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" ]
Abre el archivo
deployment_spec.yaml
en un editor. Por ejemplo:vi deployment_spec.yaml
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
yvolumes
paracgroups
y dejar las definiciones restantes.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
Guarda el archivo.
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.
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 .
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"
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:
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" ]
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 .
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:
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" ]
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 .
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 directoriom4a
. 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 directoriom4a
. 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 directoriom4a
. 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
- Consulta información sobre el nuevo tiempo de ejecución mejorado.