Mettre à niveau les charges de travail en conteneur pour l'environnement d'exécution amélioré
Si vous avez des charges de travail de conteneurs existantes créées à l'aide des versions 1.7.x et 1.8.x de Migrate to Containers, vous pouvez les convertir afin d'utiliser le gestionnaire de services Linux simplifié. Cette conversion vous permet ensuite d'exécuter ces conteneurs sur des clusters GKE Autopilot.
Pour effectuer la conversion, modifiez les fichiers Dockerfile et deployment_spec.yaml
créés lors de la migration d'origine. Une fois la modification effectuée, vous pouvez déployer la charge de travail du conteneur sur les clusters Autopilot.
À propos de la conversion des charges de travail de conteneurs
La procédure de conversion des charges de travail existantes varie selon que vous convertissez une charge de travail sans état ou avec état.
Une charge de travail avec état est une charge qui conserve ou stocke des informations d'état. Pour les charges de travail avec état, vous installez souvent des volumes supplémentaires en utilisant StatefulSet
dans spec.containers.volumeMounts
.
Veillez à conserver les définitions volumeMounts
tout en les supprimant pour /sys/fs/cgroup
.
Pour en savoir plus, consultez la page Installer des volumes externes.
Le processus général de conversion d'une charge de travail existante nécessite de modifier les éléments suivants :
Dockerfile
- Définissez la version de Migrate to Containers sur la version 1.14.1.
- Insérez deux commandes
ADD
pour copier le fichierlogs.yaml
dans l'image de conteneur. - Insérez une commande
RUN
pour l'utilitaireservicemanager_generate_config
.
Fichier
deployment_spec.yaml
:- Supprimez les définitions
hostPath
etvolumeMounts
pour/sys/fs/cgroup
. - Supprimez la définition
securityContext
. - Supprimez la définition
readinessProbe
. - Vous pouvez conserver les définitions
mountPath
etconfigMap
pourlogs-config
, mais la journalisation ne fonctionne actuellement pas avec le gestionnaire de services Linux simplifié.
- Supprimez les définitions
Pour en savoir plus sur le processus de conversion spécifique, consultez les sections ci-dessous :
Convertir une charge de travail sans état
L'exemple suivant montre comment convertir une charge de travail de conteneur sans état :
Recherchez le répertoire contenant vos artefacts de migration existants, y compris le fichier
deployment_spec.yaml
.Modifiez le fichier Dockerfile pour définir la version du produit, pour copier le fichier
logs.yaml
et pour exécuter l'utilitaireservicemanager_generate_config
:... # Set the product version to 1.14.1: FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 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" ]
Ouvrez le fichier
deployment_spec.yaml
dans un éditeur. Exemple :vi deployment_spec.yaml
Localisez la section suivante dans le fichier et supprimez les lignes indiquées :
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.
Ajoutez les lignes ci-dessous pour définir la variable d'environnement
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"
Enregistrez le fichier.
Assurez-vous que le cluster cible dispose d'un accès en lecture au registre d'images Docker comme décrit dans la section Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker.
Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :
gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
Déployez le conteneur :
kubectl apply -f deployment_spec.yaml
Si vous appliquez la spécification de déploiement à un cluster Autopilot sans les modifications nécessaires dans
deployment_spec.yaml
, un message d'erreur s'affiche sous la forme :"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"
Affichez les pods en cours de déploiement sur le cluster.
kubectl get pods
Convertir une charge de travail avec état
L'exemple suivant montre comment convertir une charge de travail de conteneur avec état :
Recherchez le répertoire contenant vos artefacts de migration existants, y compris le fichier
deployment_spec.yaml
.Modifiez le fichier Dockerfile pour définir la version du produit et exécuter l'utilitaire
servicemanager_generate_config
:... # Set the product version to 1.14.1: FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 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" ]
Ouvrez le fichier
deployment_spec.yaml
dans un éditeur. Exemple :vi deployment_spec.yaml
Recherchez les trois sections suivantes dans le fichier et supprimez les lignes indiquées :
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
Notez que vous ne supprimez que les définitions
volumeMounts
etvolumes
pourcgroups
et laissez les définitions restantes.Ajoutez les lignes suivantes pour définir la variable d'environnement
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
Enregistrez le fichier.
Assurez-vous que le cluster cible dispose d'un accès en lecture au registre d'images Docker comme décrit dans la section Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker.
Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :
gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
Déployez le conteneur :
kubectl apply -f deployment_spec.yaml
Si vous appliquez la spécification de déploiement à un cluster Autopilot sans les modifications nécessaires dans
deployment_spec.yaml
, un message d'erreur s'affiche sous la forme :"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"
Affichez les pods en cours de déploiement sur le cluster.
kubectl get pods
Tâches post-conversion
Après avoir converti une migration existante pour utiliser le gestionnaire de services Linux simplifié, vous pouvez la modifier pour :
- mettre à jour les services utilisés par la charge de travail migrée ;
- ajouter de nouveaux services.
Dans les deux cas, vous devez modifier le fichier Dockerfile, puis recréer l'image de conteneur.
Mettre à jour des services
Dans cette section, vous allez modifier le fichier Dockerfile pour mettre à jour le fichier services-config.yaml
dans le conteneur en fonction des modifications apportées dans /etc/systemd
sur la charge de travail migrée.
Pour mettre à jour l'image de conteneur en cas de modification d'un service existant, procédez comme suit :
Ajoutez la commande
servicemanager_generate_config
dans le fichier Dockerfile :... FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 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" ]
Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :
gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
Déployez la nouvelle image :
kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record
Ajouter des services
Pour ajouter un service à l'image du conteneur, procédez comme suit :
Ajoutez la commande
servicemanager_generate_config
dans le fichier Dockerfile :... FROM anthos-migrate.gcr.io/v2k-run-embedded:v1.14.1 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" ]
Créez l'image mise à jour, puis transférez-la dans Container Registry avec un tag de version mise à jour, en veillant à laisser suffisamment de temps pour que la compilation se termine. Dans l'exemple suivant, l'image se trouve dans le répertoire actuel :
gcloud builds submit --timeout 4h --tag gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL .
Déployez la nouvelle image :
kubectl set image deployment/myWorkload my-app=gcr.io/PROJECT_NAME/IMAGE_NAME:LABEL --record
servicemanager_generate_config syntax
L'utilitaire servicemanager_generate_config
accepte les options suivantes :
build-all -o /.m4a/
: recompile la migration et écrit la configuration dans le répertoirem4a
. Ne modifiez pas le nom du répertoire.Utilisez ce format de la commande lorsque vous convertissez pour la première fois votre migration afin d'utiliser le gestionnaire de services Linux simplifié.
update -u /.m4a/
: met à jour la liste des services existants dans le répertoirem4a
. Ne modifiez pas le nom du répertoire.add SERVICE_NAME -u /.m4a/
: ajoute le nom du service à la migration et écrit la configuration dans le répertoirem4a
. Ne modifiez pas le nom du répertoire.Pour ajouter plusieurs services, ajoutez plusieurs commandes
RUN /servicemanager_generate_config
, une par service.