Exécuter des charges de travail Arm dans GKE sur AWS

GKE sur AWS vous permet d'exécuter des charges de travail Arm conçues pour les processeurs AWS Graviton basés sur Arm.

Limites

  • Les pools de nœuds Arm exécutant des versions de Kubernetes antérieures à 1.24.8-gke.1300 ajoutent automatiquement un rejet lors de la création du pool de nœuds pour empêcher la planification des charges de travail Arm sur des nœuds non Arm. Les pools de nœuds Arm des clusters exécutant la version 1.24.8-gke.1300 ou ultérieure n'ajoutent plus cette altération. Si vous effectuez une mise à niveau à partir d'un cluster antérieur à la version 1.24.8-gke.1300, vous devez créer cette altération vous-même ou en tenir compte lors de la mise à niveau.

  • Les pools de nœuds Arm sur GKE sur AWS ne sont pas compatibles avec Cloud Service Mesh, Config Sync ni Policy Controller. Vous devez exécuter ces produits sur un pool de nœuds x86.

  • Les clusters exécutant la version 1.24 de Kubernetes ont besoin d'un pool de nœuds x86 pour exécuter l'agent Connect. Si votre cluster exécute Kubernetes 1.25 ou une version ultérieure, vous n'avez pas besoin d'un pool de nœuds x86.

Cette page explique comment créer un pool de nœuds Arm, présente la raison pour laquelle les images multi-architecture sont les méthodes recommandées pour déployer des charges de travail Arm, et explique comment planifier des charges de travail Arm.

Avant de commencer

Avant de créer des pools de nœuds pour vos charges de travail Arm, vous avez besoin des ressources suivantes :

  • Un cluster AWS existant dans lequel créer le pool de nœuds. Ce cluster doit exécuter Kubernetes version 1.24 ou ultérieure.
  • Un profil d'instance IAM pour les VM de pool de nœuds.
  • Un sous-réseau dans lequel exécuter les VM du pool de nœuds.

  • Si votre cluster exécute la version 1.24 de Kubernetes, un pool de nœuds x86 pour exécuter l'agent Connect.

    Pour en savoir plus sur la création d'un pool de nœuds dans GKE sur AWS, consultez la page Créer un pool de nœuds.

Créer un pool de nœuds Arm

GKE sur AWS est compatible avec les pools de nœuds créés sur l'image de nœud minimal arm64 Canonical Ubuntu et l'environnement d'exécution containerd.

Pour créer un pool de nœuds Arm et l'ajouter à un cluster existant, exécutez la commande suivante :

gcloud container aws node-pools create NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --instance-type INSTANCE_TYPE \
    --root-volume-size ROOT_VOLUME_SIZE \
    --iam-instance-profile NODEPOOL_PROFILE \
    --node-version NODE_VERSION \
    --min-nodes MIN_NODES \
    --max-nodes MAX_NODES \
    --max-pods-per-node MAX_PODS_PER_NODE \
    --location GOOGLE_CLOUD_LOCATION \
    --subnet-id NODEPOOL_SUBNET \
    --ssh-ec2-key-pair SSH_KEY_PAIR_NAME \
    --config-encryption-kms-key-arn CONFIG_KMS_KEY_ARN

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom que vous avez choisi pour votre pool de nœuds.
  • CLUSTER_NAME : nom du cluster auquel associer le pool de nœuds.

  • INSTANCE_TYPE : l'un des types d'instance suivants :

    • m6g
    • m6gd
    • t4g
    • r6g
    • r6gd
    • c6g
    • c6gd
    • c6gn
    • x2gd
    • c7g
    • im4gn

    • g5g

      Ces types d'instances reposent sur des processeurs AWS Graviton basés sur Arm. Vous devez également spécifier la taille d'instance souhaitée. Par exemple, m6g.medium. Pour obtenir la liste complète, consultez la section Types d'instances AWS compatibles.

  • ROOT_VOLUME_SIZE : taille souhaitée pour le volume racine de chaque nœud, en Go.

  • NODEPOOL_PROFILE : profil d'instance IAM pour les VM de pool de nœuds.

  • NODE_VERSION : version de Kubernetes à installer sur chaque nœud du pool de nœuds, qui doit être la version 1.24 ou une version ultérieure. Exemple : 1.24.3-gke.200.

  • MIN_NODES : nombre minimal de nœuds que le pool de nœuds peut contenir.

  • MAX_NODES : nombre maximal de nœuds que le pool de nœuds peut contenir.

  • MAX_PODS_PER_NODE : nombre maximal de pods pouvant être créés sur un nœud unique du pool.

  • GOOGLE_CLOUD_LOCATION: nom du Google Cloud

    à partir duquel ce pool de nœuds sera géré.

  • NODEPOOL_SUBNET : ID du sous-réseau sur lequel le pool de nœuds sera exécuté. Si ce sous-réseau se trouve en dehors du bloc CIDR principal du VPC, vous devez effectuer des étapes supplémentaires. Pour en savoir plus, consultez la section Groupes de sécurité.

  • SSH_KEY_PAIR_NAME : nom de la paire de clés SSH AWS créée pour l'accès SSH (facultatif).

  • CONFIG_KMS_KEY_ARN : nom de ressource Amazon (ARN) de la clé KMS AWS qui chiffre les données utilisateur.

Comprendre les images multi-architectures

Les images de conteneur doivent être compatibles avec l'architecture du nœud sur lequel vous souhaitez exécuter les charges de travail Arm. Pour vous assurer que votre image de conteneur est compatible avec l'architecture Arm, nous vous recommandons d'utiliser des images multi-architectures ("multi-arch").

Une image multi-arch est une image qui est compatible avec plusieurs architectures. Elle ressemble à une seule image avec un seul tag, mais contient un ensemble d'images à exécuter sur différentes architectures de machine. Les images multi-arch sont compatibles avec Image Manifest V2 Scheme 2 de Docker et avec les spécifications Image Index d'OCI.

Lorsque vous déployez une image multi-arch sur un cluster, l'environnement d'exécution du conteneur choisit automatiquement l'image qui est compatible avec l'architecture du nœud sur lequel vous effectuez le déploiement. Une fois que vous disposez d'une image multi-arch pour une charge de travail, vous pouvez déployer cette charge de travail dans plusieurs architectures. Planifier une image à architecture unique sur un nœud incompatible entraîne une erreur au moment du chargement.

Pour en savoir plus sur l'utilisation d'images multi-arch avec des charges de travail Arm, consultez la page Créer des images multi-architecture pour les charges de travail Arm dans la documentation de Google Kubernetes Engine (GKE).

Étapes suivantes