Esegui l'upgrade dei carichi di lavoro dei container per un runtime migliorato

Se hai carichi di lavoro dei container esistenti creati utilizzando Migrate to Containers nelle versioni 1.7.x e 1.8.x, puoi convertirli in modo che utilizzino il gestore dei servizi Linux semplificato. Questa conversione ti consente di eseguire questi container su cluster GKE Autopilot.

Nota: conversione di un carico di lavoro di container creato utilizzando Migrate to Containers le versioni precedenti alla 1.7.0 non sono supportate.

Per eseguire la conversione, modifica il Dockerfile e il file deployment_spec.yaml creato durante l'esecuzione della migrazione originale. Dopo la modifica, puoi il deployment del carico di lavoro dei container sui cluster Autopilot.

Informazioni sulla conversione dei carichi di lavoro dei container

La procedura per convertire i carichi di lavoro esistenti dipende dal fatto che tu stia convertendo un carico di lavoro stateless o stateful.

Un carico di lavoro stateful conserva o archivia le informazioni sullo stato. Per i carichi di lavoro stateful, spesso installi volumi aggiuntivi utilizzando StatefulSet in spec.containers.volumeMounts. Assicurati di conservare le definizioni di volumeMounts rimuovendole al contempo per /sys/fs/cgroup. Per ulteriori informazioni, consulta la sezione Montaggio di volumi esterni.

Il processo generale di conversione di un carico di lavoro esistente richiede la modifica dei seguenti elementi:

• Dockerfile

  • Imposta la versione di Migrate to Containers su 1.15.0.
  • Inserisci due comandi ADD per copiare il file logs.yaml nell'immagine container.
  • Inserisci un comando RUN per l'utilità servicemanager_generate_config.

• File deployment_spec.yaml a:

  • Elimina le definizioni di hostPath e volumeMounts per /sys/fs/cgroup.
  • Elimina la definizione di securityContext.
  • Elimina la definizione di readinessProbe.
  • Puoi lasciare le definizioni mountPath e configMap per logs-config, tuttavia il logging al momento non funziona con il gestore di servizi Linux semplificato.

Per il processo specifico di conversione, consulta le sezioni di seguito:

• Convertire un carico di lavoro stateless
• Converti un carico di lavoro stateful

Converti un carico di lavoro stateless

L'esempio seguente mostra come convertire un carico di lavoro del contenitore senza stato:

1. Individua la directory contenente gli artefatti di migrazione esistenti, tra cui il file deployment_spec.yaml.

2. Modifica il Dockerfile per impostare la versione del prodotto, per copiare il file logs.yaml, ed eseguire l'utilità 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. Apri il file deployment_spec.yaml in un editor. Ad esempio:

   vi  deployment_spec.yaml

4. Individua la seguente sezione nel file ed elimina le righe indicate:

   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. Aggiungi le righe riportate di seguito per impostare la variabile di ambiente HC_V2K_SERVICE_MANAGER.

   Attenzione: se utilizzi Migrate to Containers 1.10 o versioni successive, salta questo passaggio.

   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. Salva il file.

7. Assicurati che il cluster di destinazione abbia accesso in lettura al registro delle immagini Docker come descritto in Assicurarsi che il cluster di destinazione abbia accesso in lettura al registro di immagini Docker.

8. Crea l'immagine aggiornata ed esegui il push in Container Registry con un tag della versione aggiornato, assicurandoti di attendere il tempo necessario per il completamento della build. Nella Nell'esempio seguente, l'immagine si trova nella directory attuale:

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

9. Esegui il deployment del container:

   kubectl apply -f deployment_spec.yaml

   Se applichi la specifica del deployment a un cluster Autopilot senza modifiche in deployment_spec.yaml, viene visualizzato un messaggio di errore nel modulo:

   "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. Visualizza i pod di cui viene eseguito il deployment nel cluster.

    Nota: il caricamento dei nodi e il pull dell'immagine potrebbero richiedere alcuni minuti.

    kubectl get pods

Convertire un carico di lavoro stateful

L'esempio seguente mostra come convertire un carico di lavoro del contenitore con stato:

1. Individua la directory contenente gli artefatti di migrazione esistenti, tra cui il file deployment_spec.yaml.

2. Modifica il Dockerfile per impostare la versione del prodotto ed esegui l'utilità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. Apri il file deployment_spec.yaml in un editor. Ad esempio:

   vi  deployment_spec.yaml

4. Individua le tre sezioni seguenti nel file ed elimina le righe indicate:

   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

   Tieni presente che rimuovi solo volumeMounts e volumes le definizioni di cgroups e lascia le altre definizioni.

5. Aggiungi le seguenti righe per impostare la variabile di ambiente HC_V2K_SERVICE_MANAGER:

   Attenzione: se utilizzi Migrate to Containers 1.10 o versioni successive, salta questo passaggio.

   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. Salva il file.

7. Assicurati che il cluster di destinazione abbia accesso in lettura al registro delle immagini Docker come descritto in Assicurati che il cluster di destinazione abbia accesso in lettura al registro delle immagini Docker.

8. Crea l'immagine aggiornata ed esegui il push a Container Registry con una versione aggiornata in modo da lasciare tempo sufficiente per il completamento della build. Nella Nell'esempio seguente, l'immagine si trova nella directory attuale:

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

9. Esegui il deployment del contenitore:

   kubectl apply -f deployment_spec.yaml

   Se applichi le specifiche di deployment a un cluster Autopilot senza le modifiche necessarie in deployment_spec.yaml, viene visualizzato un messaggio di errore nel modulo:

   "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. Visualizza i pod di cui viene eseguito il deployment nel cluster.

    Nota: il caricamento dei nodi e l'estrazione dell'immagine potrebbero richiedere alcuni minuti.

    kubectl get pods

Attività di post conversione

Dopo aver convertito una migrazione esistente per usare il gestore di servizi Linux semplificato, potresti volerlo modificare in:

• Aggiorna i servizi utilizzati dal carico di lavoro sottoposto a migrazione.
• Aggiungi nuovi servizi.

Per entrambi gli scenari, devi modificare il Dockerfile e poi ricreare l'immagine container.

Aggiornamento servizi

In questa sezione modifichi il file Dockerfile per aggiornare il file services-config.yaml nel contenitore in base alle modifiche apportate in /etc/systemd al carico di lavoro sottoposto a migrazione.

Per aggiornare l'immagine container per una modifica a un servizio esistente:

1. Aggiungi il comando servicemanager_generate_config nel Dockerfile:

   Nota: aggiungi il comando servicemanager_generate_config direttamente nel Dockerfile. Non tentare di eseguirlo all'interno del carico di lavoro del contenitore.

   ...
   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 l'immagine aggiornata ed esegui il push a Container Registry con una versione aggiornata in modo da lasciare tempo sufficiente per il completamento della build. Nella Nell'esempio seguente, l'immagine si trova nella directory attuale:

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

3. Esegui il deployment dell'immagine appena creata:

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

Aggiungi servizi

Per aggiungere un servizio all'immagine container:

1. Aggiungi il comando servicemanager_generate_config nel Dockerfile:

   Nota: aggiungi il comando servicemanager_generate_config direttamente nel Dockerfile. Non tentare di eseguirlo all'interno del carico di lavoro del contenitore.

   ...
   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 l'immagine aggiornata ed esegui il push a Container Registry con una versione aggiornata in modo da lasciare tempo sufficiente per il completamento della build. Nella Nell'esempio seguente, l'immagine si trova nella directory attuale:

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

3. Esegui il deployment dell'immagine appena creata:

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

Sintassi servicemanager_generate_config

L'utilità servicemanager_generate_config prevede le seguenti opzioni:

• build-all -o /.m4a/: ricostruisce la migrazione e scrive la configurazione nella directory m4a. Non modificare il nome della directory.

  Utilizza questa forma del comando la prima volta che esegui la conversione della migrazione per utilizzare il gestore dei servizi Linux semplificato.

• update -u /.m4a/: aggiorna l'elenco dei servizi esistenti nella directory m4a. Non modificare il nome della directory.

• add SERVICE_NAME -u /.m4a/: aggiunge il nome del servizio alla migrazione e scrive la configurazione nella directory m4a. Non modificare il nome della directory.

  Per aggiungere più servizi, aggiungi più comandi RUN /servicemanager_generate_config, uno per servizio.

Passaggi successivi

• Scopri di più sul nuovo runtime avanzato.