Déployer une charge de travail Linux vers un cluster cible

Après avoir migré une charge de travail depuis votre plate-forme source, vous pouvez utiliser des artefacts de déploiement générés par ce processus pour déployer le conteneur de la charge de travail migrée vers un autre cluster.

Avant de commencer

Pour déployer votre charge de travail, vous devez d'abord effectuer les opérations suivantes :

Migrer la charge de travail à l'aide des outils Migrate for Anthos and GKE
Examiner les fichiers de déploiement générés
Avant d'exécuter vos charges de travail migrées, vous devez installer migctl avec la compatibilité des environnements d'exécution pour les nœuds Container-Optimized OS sur votre cluster :
```
migctl setup install --runtime
```

Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker

Dans le cadre d'une migration, Migrate for Anthos and GKE importe des images Docker représentant une VM migrée dans un registre Docker. Ces images Docker représentent les fichiers et répertoires de la VM en cours de migration.

Pour le registre Docker, vous pouvez choisir d'utiliser :

Google Container Registry (GCR)
ECR

Remarque : Ne spécifiez ECR comme registre d'images Docker que si vous utilisez des clusters Anthos sur AWS comme clusters de traitement. Ne l'utilisez pas pour les clusters Anthos sur Google Cloud ni pour les clusters Anthos sur VMware.
Tout registre Docker compatible avec l'authentification de base

Voir Définir des dépôts de données pour plus d'informations.

Pour déployer une charge de travail migrée vers un cluster cible, exécutez la commande suivante :

kubectl apply -f deployment_spec.yaml

Où deployment_spec.yaml est le fichier YAML contenant les informations de déploiement de votre charge de travail migrée. Dans deployment_spec.yaml, la propriété containers spécifie l'emplacement de l'image et du registre Docker.

Exemple :

    spec:
      containers:
      - image: gcr.io/PROJECT_ID/quickstart-instance:v1.0.0
        name: quickstart-instance

Dans cet exemple, deployment_spec.yaml spécifie que le registre d'images Docker utilise Google Container Registry (GCR).

Avant de pouvoir déployer une charge de travail migrée sur un cluster cible, vous devez vous assurer que le cluster dispose d'un accès en lecture au registre Docker. Les sections suivantes expliquent comment activer l'accès aux différents types de registres.

Déployer des charges de travail sur le cluster de traitement

Vous pouvez déployer la charge de travail migrée sur le cluster utilisé pour effectuer la migration, appelé cluster de traitement Migrate for Anthos and GKE. Dans la plupart des situations, aucune configuration supplémentaire n'est requise sur le cluster de traitement, car il dispose déjà d'un accès en lecture/écriture au registre Docker pour effectuer la migration.

Toutefois, si vous utilisez ECR comme registre d'images Docker avec des clusters Anthos sur AWS, vous devez activer l'accès en lecture au pool de nœuds AWS avant de pouvoir déployer la charge de travail. Pour en savoir plus, consultez la section Déployer sur un cluster cible en utilisant ECR comme registre Docker ci-dessous.

Déployer sur un cluster cible en utilisant GCR comme registre Docker

Pour vous assurer qu'un cluster cible a accès à Google Container Registry (GCR), créez un secret Kubernetes contenant les identifiants requis pour accéder à GCR :

Créez un compte de service pour déployer une migration, comme décrit dans la section Créer un compte de service pour accéder à Container Registry et à Cloud Storage.

Ce processus vous permet de télécharger un fichier de clé JSON nommé m4a-install.json.
Créez un secret Kubernetes contenant les identifiants requis pour accéder à GCR :
```
kubectl create secret docker-registry gcr-json-key \
 --docker-server=gcr.io --docker-username=_json_key --docker-password="$(cat ~/m4a-install.json)" \
 --docker-email=account@project.iam.gserviceaccount.com
```
où :
- docker-registry spécifie le nom du secret Kubernetes, gcr-json-key dans cet exemple.
- docker-server=gcr.io spécifie GCR comme serveur.
- docker-username=_json_key indique que le nom d'utilisateur est contenu dans le fichier de clé JSON.
- docker-password indique d'utiliser un mot de passe du fichier de clé JSON.
- docker-email spécifie l'adresse e-mail du compte de service.

Définissez le secret Kubernetes de l'une des manières suivantes :

Modifiez la valeur imagePullSecrets par défaut :

kubectl patch serviceaccount default -p '{"imagePullSecrets": [{"name": "gcr-json-key"}]}'

Modifiez le fichier deployment_spec.yaml pour ajouter la valeur imagePullSecrets à la définition spec.template.spec, comme indiqué ci-dessous :

spec:
  containers:
  - image: gcr.io/PROJECT_ID/mycontainer-instance:v1.0.0
    name: mycontainer-instance
    ...
  volumes:
  - hostPath:
      path: /sys/fs/cgroup
      type: Directory
    name: cgroups
  imagePullSecrets:
  - name: gcr-json-key

Déployer sur un cluster cible en utilisant ECR comme registre Docker

Si vos clusters Anthos sur AWS utilisent ECR en tant que registre, vous pouvez accorder au cluster l'accès en lecture au registre.

Lorsque vous créez des clusters Anthos sur AWS, vous pouvez modifier le fichier staging-nodepools.yaml afin de personnaliser la définition des pools de nœuds du cluster. Pour en savoir plus, consultez la section Créer un cluster d'utilisateur personnalisé.

Le fichier staging-nodepools.yaml contient la propriété iamInstanceProfile qui spécifie le nom du profil d'instance AWS EC2 attribué aux nœuds du pool :

iamInstanceProfile: NODE_IAM_PROFILE

Assurez-vous que le profil spécifié dispose du rôle AmazonEC2ContainerRegistryReadOnly pour autoriser l'accès en lecture à ECR.

Déployer sur un cluster cible en utilisant un registre Docker avec une authentification de base

Si vous utilisez un registre Docker pour stocker des images de migration, celui-ci doit être compatible avec l'authentification de base à l'aide d'un nom d'utilisateur et d'un mot de passe. Dans la mesure où il existe de nombreuses manières de configurer une connexion en lecture seule à un registre Docker, vous devez utiliser la méthode appropriée pour votre plate-forme de cluster et votre registre Docker.

Déployer une charge de travail dans un projet GCP autre que celui utilisé pour la migration

Il s'agit souvent de plusieurs projets Google Cloud dans votre environnement. Si vous effectuez une migration dans un projet GCP, puis que vous souhaitez déployer la charge de travail migrée vers un cluster d'un autre projet, vous devez vous assurer que les autorisations sont correctement configurées.

Par exemple, vous effectuez la migration dans le projet A. Dans ce cas, la charge de travail migrée est copiée dans un bucket GCR du projet A. Exemple :

gcr.io/project-a/image_name:image_tag

Vous souhaitez ensuite déployer la charge de travail sur un cluster du projet B. Si vous ne configurez pas les autorisations correctement, le pod de la charge de travail ne parvient pas à s'exécuter, car le cluster du projet B ne dispose pas d'un accès en extraction d'images au projet A. Vous verrez ensuite un événement sur le pod contenant un message sous la forme suivante :

Failed to pull image "gcr.io/project-a/image_name:image_tag...
pull access denied...
repository does not exist or may acquire 'docker login'...

Tous les projets qui ont activé l'API Compute Engine disposent d'un compte de service par défaut Compute Engine, qui possède l'adresse e-mail suivante :

PROJECT_NUMBER-compute@developer.gserviceaccount.com

Où PROJECT_NUMBER est le numéro du projet B.

Pour contourner ce problème, assurez-vous que le compte de service par défaut Compute Engine du projet B dispose des autorisations nécessaires pour accéder au bucket GCR. Par exemple, vous pouvez utiliser la commande gsutil suivante pour activer l'accès :

gsutil iam ch serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com:objectViewer gs://artifacts.project-a.appspot.com

Appliquer le fichier YAML de déploiement généré

Utilisez kubectl pour appliquer les spécifications de déploiement à votre cluster cible, tel qu'un cluster de production.

kubectl

Assurez-vous que le cluster cible dispose d'un accès en lecture au registre d'images Docker comme décrit ci-dessus dans la section Vérifier que le cluster cible dispose d'un accès en lecture au registre Docker.
Déployez le conteneur :
```
kubectl apply -f deployment_spec.yaml
```
Une fois que vous avez terminé vos tests de validation sur la charge de travail migrée pour vous assurer que celle-ci fonctionne correctement, vous devez supprimer la migration afin de libérer des ressources. Pour en savoir plus, consultez la section Supprimer une migration.
Remarque : Si vous avez installé Migrate for Compute Engine lors de la migration d'une VM à partir de VMware, AWS ou Azure, vous devez supprimer la migration pour libérer le contrôle de la VM à partir de Migrate for Compute Engine.

Supprimer une migration

Après avoir validé et testé la charge de travail migrée pour vous assurer qu'elle fonctionne correctement, vous devez supprimer la migration. En supprimant la migration, vous libérez toute ressource utilisée par la migration.

migctl

Supprimez une migration terminée à l'aide de la commande suivante :
```
migctl migration delete MIGRATION_NAME
```
où MIGRATION_NAME est le nom de la migration.

Console

Ouvrez la page Migrate for Anthos and GKE dans Cloud Console.

Accéder à la page "Migrer vers des conteneurs"
Cliquez sur l'onglet Migrations pour afficher un tableau contenant les migrations disponibles.
Pour supprimer la migration, cliquez sur l'icône à trois points, , à droite du tableau, puis sélectionnez Supprimer la migration.

Configurer Workload Identity avec AWS

Workload Identity pour Anthos clusters on AWS vous permet d'associer des comptes de service Kubernetes à des comptes AWS IAM avec des autorisations spécifiques. Workload Identity se sert des autorisations AWS IAM pour bloquer les accès indésirables aux ressources cloud.

Avec Workload Identity, vous pouvez attribuer différents rôles IAM à chaque charge de travail. Ce contrôle précis des autorisations vous permet de suivre le principe du moindre privilège.

Utiliser Workload Identity avec Migrate for Anthos and GKE

Migrate for Anthos and GKE vous permet de déployer vos charges de travail migrées sur Anthos clusters on AWS. Si vous avez activé Workload Identity sur votre cluster de déploiement, vous devez vous assurer que votre environnement de déploiement est configuré pour être compatible avec Migrate for Anthos and GKE.

Vous devez définir deux variables d'environnement pour les services utilisant Workload Identity :

AWS_ROLE_ARN : nom de la ressource Amazon (ARN) du rôle IAM.
AWS_WEB_IDENTITY_TOKEN_FILE : chemin d'accès au jeton stocké.

Remarque : Pour les charges de travail migrées, définissez AWS_WEB_IDENTITY_TOKEN_FILE sur /kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token et non sur la norme suivante d'Anthos clusters on AWS : /var/run/secrets/eks.amazonaws.com/serviceaccount/token. Pour plus d'informations, consultez la page Créer un cluster d'utilisateur avec Workload Identity.

Les étapes à effectuer dépendent du système init de votre cluster. Pour connaître la procédure à suivre pour systemd, SysV et Upstart, reportez-vous aux informations ci-dessous.

Configurer à l'aide de kubectl exec

Les sections ci-dessous décrivent comment configurer un service Workload Identity démarrée par le système init. Pour exécuter des commandes qui utilisent Workload Identity dans l'interface système du conteneur à partir de kubectl exec, vous devez d'abord exécuter la commande suivante sur le pod déployé :

ln -s /kubernetes-info/secrets /var/run/secrets

Si le montage /var/run est supprimé (par un processus du pod ou par une réinitialisation du pod), vous devrez peut-être exécuter à nouveau la commande.

Configurer le système init

Suivez les étapes ci-dessous correspondant à votre système init spécifique.

Configurer systemd

systemd permet de définir des variables d'environnement pour tous les services générés. Vous pouvez ajouter un fichier de configuration à l'aide du fichier Dockerfile ou l'automatiser dans le conteneur externe.

Par exemple, modifiez le fichier de configuration /etc/systemd/system.conf.d/10-default-env.conf pour définir les variables d'environnement :

[Manager]
DefaultEnvironment="AWS_ROLE_ARN=ROLE_ARN""AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token"

Où ROLE_ARN spécifie le nom de ressource Amazon (ARN) du rôle IAM tel que vous l'avez défini pour AWS_ROLE_ARN lorsque vous avez activé Workflow Identity.

Vous pouvez également modifier le fichier Dockerfile pour ajouter les éléments suivants :

RUN mkdir -p /etc/systemd/system.conf.d/
RUN echo '[Manager]' >> /etc/systemd/system.conf.d/10-default-env.conf
RUN echo 'DefaultEnvironment="AWS_ROLE_ARN=ROLE_ARN" "AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token" '>> /etc/systemd/system.conf.d/10-default-env.conf

Configurer SysV/Upstart pour les services qui ne s'exécutent pas en tant que racine.

Pour les systèmes utilisant SysV/Upstart dans lesquels les services ne s'exécutent pas en mode root, vous pouvez utiliser pam_env pour définir les variables d'environnement :

Ajoutez ce qui suit à /etc/pam.d/su :

session required pam_env.so
Ajoutez ce qui suit à /etc/environment :
```
AWS_ROLE_ARN=ROLE_ARN
AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token
```
Où ROLE_ARN spécifie le nom de ressource Amazon (ARN) du rôle IAM tel que vous l'avez défini pour AWS_ROLE_ARN lorsque vous avez activé Workflow Identity.

Vous pouvez également modifier le fichier Dockerfile pour ajouter les éléments suivants :

RUN echo "session        required      pam_env.so" >> /etc/pam.d/su
RUN echo 'AWS_ROLE_ARN=ROLE_ARN' >> /etc/environment
RUN echo 'AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token' >> /etc/environment

Configurer SysV/Upstart pour les services sans nouvel utilisateur

Les services SysV/Upstart sans nouvel utilisateur doivent configurer manuellement le service pour définir les éléments suivants :

AWS_ROLE_ARN=ROLE_ARN
AWS_WEB_IDENTITY_TOKEN_FILE=/kubernetes-info/secrets/eks.amazonaws.com/serviceaccount/token

Où ROLE_ARN spécifie le nom de ressource Amazon (ARN) du rôle IAM tel que vous l'avez défini pour AWS_ROLE_ARN lorsque vous avez activé Workflow Identity.

Définissez ces variables d'environnement en fonction de votre type de service :

SysV : ajoutez des lignes d'exportation à votre script d'initialisation pour définir AWS_ROLE_ARN et AWS_WEB_IDENTITY_TOKEN_FILE..
Upstart : consultez la section Variables d'environnement (en anglais) pour en savoir plus sur la configuration des variables d'environnement, telles que AWS_ROLE_ARN et AWS_WEB_IDENTITY_TOKEN_FILE..

Accéder au jeton de service à partir de services non exécutés en mode root à l'intérieur du conteneur

Quel que soit votre système init, vous devez accorder l'accès au jeton de service pour les services qui ne s'exécutent pas en mode root :

Ajoutez la ligne suivante au fichier Dockerfile :
```
RUN groupadd aws-token --gid ID_OF_CREATED_GROUP && usermod -a -G aws-token SERVICE_USER_NAME 
```
Où ID_OF_CREATED_GROUP correspond à un identifiant de votre choix, par exemple 1234.
Ajoutez ce qui suit à la spécification de déploiement :
```
securityContext:
    fsGroup: ID_OF_CREATED_GROUP
```

Pour plus d'informations, consultez la section Configurer un contexte de sécurité pour un pod ou un conteneur (en anglais).

Étapes suivantes

Surveiller les charges de travail migrées