Atualize as cargas de trabalho do contentor para um tempo de execução melhorado

Se tiver cargas de trabalho de contentores existentes criadas com as versões 1.7.x e 1.8.x do Migrate to Containers, pode convertê-las para usar o gestor de serviços Linux simplificado. Esta conversão permite-lhe executar estes contentores em clusters do GKE Autopilot.

Para fazer a conversão, edite o Dockerfile e o ficheiro deployment_spec.yaml criado quando fez a migração original. Depois de editado, pode implementar a carga de trabalho do contentor em clusters do Autopilot.

Acerca da conversão de cargas de trabalho de contentores

O procedimento para converter cargas de trabalho existentes depende de estar a converter uma carga de trabalho sem estado ou uma carga de trabalho com estado.

Uma carga de trabalho com estado é aquela que mantém ou armazena informações de estado. Para cargas de trabalho com estado, monta frequentemente volumes adicionais através de StatefulSet em spec.containers.volumeMounts. Certifique-se de que mantém as volumeMountsdefinições e as remove para /sys/fs/cgroup. Consulte o artigo Montar volumes externos para mais informações.

O processo geral de conversão de uma carga de trabalho existente requer que edite o seguinte:

  • Ficheiro Docker

    • Defina a versão do Migrate to Containers como 1.15.0.
    • Insira dois comandos ADD para copiar o ficheiro logs.yaml para a imagem do contentor.
    • Insira um comando RUN para o utilitário servicemanager_generate_config.

  • deployment_spec.yaml ficheiro para:

    • Eliminar as definições de hostPath e volumeMounts para /sys/fs/cgroup.
    • Elimine a definição securityContext.
    • Elimine a definição readinessProbe.
    • Pode deixar as definições mountPath e configMap para logs-config. No entanto, o registo não funciona atualmente com o gestor de serviços Linux simplificado.

Para o processo de conversão específico, consulte as secções abaixo:

Converta uma carga de trabalho sem estado

O exemplo seguinte mostra como converter uma carga de trabalho de contentor sem estado:

  1. Localize o diretório que contém os artefactos de migração existentes, incluindo o ficheiro deployment_spec.yaml.

  2. Edite o Dockerfile para definir a versão do produto, copiar o ficheiro logs.yaml e executar o utilitário 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. Abra o ficheiro deployment_spec.yaml num editor. Por exemplo:

    vi  deployment_spec.yaml

  4. Localize a seguinte secção no ficheiro e elimine as linhas 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. Adicione as linhas abaixo para definir a variável de ambiente 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. Guarde o ficheiro.

  7. Certifique-se de que o cluster de destino tem acesso de leitura ao registo de imagens de Docker, conforme descrito em Certifique-se de que o cluster de destino tem acesso de leitura ao registo de imagens de Docker.

  8. Crie a imagem atualizada e envie-a para o Container Registry com uma etiqueta de versão atualizada, garantindo que permite tempo suficiente para a criação terminar. No exemplo seguinte, a imagem está no diretório atual:

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

  9. Implemente o contentor: 

    kubectl apply -f deployment_spec.yaml

    Se aplicar a especificação de implementação a um cluster do Autopilot sem as alterações necessárias em deployment_spec.yaml, é apresentada uma mensagem de erro no seguinte 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. Veja os pods que estão a ser implementados no cluster. 

    kubectl get pods

Converta uma carga de trabalho com estado

O exemplo seguinte mostra como converter uma carga de trabalho de contentor com estado:

  1. Localize o diretório que contém os artefactos de migração existentes, incluindo o ficheiro deployment_spec.yaml.

  2. Edite o Dockerfile para definir a versão do produto e executar o utilitário 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. Abra o ficheiro deployment_spec.yaml num editor. Por exemplo: 

    vi  deployment_spec.yaml

  4. Localize as três secções seguintes no ficheiro e elimine as linhas 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

    Repare que remove apenas as definições volumeMounts e volumes para cgroups e deixa as restantes definições.

  5. Adicione as seguintes linhas para definir a variável de ambiente 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. Guarde o ficheiro.

  7. Certifique-se de que o cluster de destino tem acesso de leitura ao registo de imagens de Docker, conforme descrito em Certifique-se de que o cluster de destino tem acesso de leitura ao registo de imagens de Docker.

  8. Crie a imagem atualizada e envie-a para o Container Registry com uma etiqueta de versão atualizada, garantindo que permite tempo suficiente para a criação terminar. No exemplo seguinte, a imagem está no diretório atual:

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

  9. Implemente o contentor:

    kubectl apply -f deployment_spec.yaml

    Se aplicar a especificação de implementação a um cluster do Autopilot sem as alterações necessárias em deployment_spec.yaml, é apresentada uma mensagem de erro no seguinte 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. Veja os pods que estão a ser implementados no cluster.

    kubectl get pods

Tarefas pós-conversão

Depois de converter uma migração existente para usar o gestor de serviços Linux simplificado, pode querer modificá-la para:

  • Atualize os serviços usados pela carga de trabalho migrada.
  • Adicionar novos serviços.

Em ambos os cenários, tem de editar o Dockerfile e, em seguida, reconstruir a imagem do contentor.

Atualize os serviços

Nesta secção, edita o Dockerfile para atualizar o ficheiro services-config.yaml no contentor com base nas alterações feitas em /etc/systemd na carga de trabalho migrada.

Para atualizar a imagem do contentor para uma alteração a um serviço existente:

  1. Adicione o comando servicemanager_generate_config no 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. Crie a imagem atualizada e envie-a para o Container Registry com uma etiqueta de versão atualizada, garantindo que permite tempo suficiente para a criação terminar. No exemplo seguinte, a imagem está no diretório atual:

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

  3. Implemente a imagem criada recentemente:

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

Adicionar serviços

Para adicionar um serviço à imagem do contentor:

  1. Adicione o comando servicemanager_generate_config no 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. Crie a imagem atualizada e envie-a para o Container Registry com uma etiqueta de versão atualizada, garantindo que permite tempo suficiente para a criação terminar. No exemplo seguinte, a imagem está no diretório atual:

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

  3. Implemente a imagem criada recentemente:

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

Sintaxe de servicemanager_generate_config

O utilitário servicemanager_generate_config aceita as seguintes opções:

  • build-all -o /.m4a/: recompila a migração e escreve a configuração no diretório m4a. Não altere o nome do diretório.

    Use esta forma do comando quando converter inicialmente a migração para usar o gestor de serviços do Linux simplificado.

  • update -u /.m4a/: atualize a lista de serviços existentes no diretório m4a. Não altere o nome do diretório.

  • add SERVICE_NAME -u /.m4a/: adiciona o nome do serviço à migração e escreve a configuração no diretório m4a. Não altere o nome do diretório.

    Para adicionar vários serviços, adicione vários comandos RUN /servicemanager_generate_config, um por serviço.

O que se segue?