Charges de travail Arm sur GKE

Autopilot Standard

Ce document explique comment exécuter des charges de travail Arm sur Google Kubernetes Engine (GKE). Vous pouvez exécuter des charges de travail Arm de différentes manières :

• Mode Autopilot GKE : sur la plate-forme de calcul optimisée pour les conteneurs Autopilot, demandez explicitement l'architecture Arm et la ComputeClass autopilot-arm pour les charges de travail à usage général. Pour demander du matériel spécifique, utilisez les classes de calcul Performance ou Scale-Out.
• Mode GKE Standard : à l'aide des séries de machines C4A, N4A ou Tau T2A.

Vous pouvez exécuter des images Arm à architecture unique ou des images multi-architecture (multi-arch) compatibles avec les processeurs x86 et Arm. Pour en savoir plus sur les avantages d'Arm, consultez VM Arm sur Compute.

Exécuter des charges de travail Arm sur GKE

Pour en savoir plus sur le choix des charges de travail à déployer sur Arm et la préparation de ces charges de travail en vue du déploiement, consultez les ressources suivantes :

• Choisir des charges de travail à exécuter sur Arm : tenez compte des avantages des options suivantes lorsque vous choisissez des charges de travail à exécuter sur Arm :

  • Plate-forme de calcul optimisée pour les conteneurs Autopilot : recommandée pour les charges de travail Arm à usage général dans les clusters Autopilot. Elle offre une facturation et une élasticité basées sur les pods sans que vous ayez à gérer des types de machines spécifiques.

  • Familles de machines spécifiques : pour les charges de travail nécessitant des caractéristiques matérielles spécifiques, envisagez les types de machines suivants. Pour en savoir plus, consultez le tableau de la section Famille de machines à usage général pour Compute Engine :

    • Les nœuds C4A fournissent un calcul basé sur Arm qui offre des performances constamment élevées pour vos charges de travail basées sur Arm les plus sensibles aux performances.
    • Les nœuds N4A fournissent des ressources de calcul basées sur Arm qui offrent un équilibre entre prix et performances.
    • Les nœuds T2A conviennent aux charges de travail plus flexibles ou à celles qui reposent sur un scaling horizontal.

• Déploiement sur plusieurs architectures : avec GKE, vous pouvez utiliser des images multi-arch pour déployer un fichier manifeste d'image sur des nœuds avec différentes architectures, y compris Arm.

  • Pour vous assurer que votre image de conteneur est compatible avec Arm et peut s'exécuter sur vos architectures ciblées, consultez Créer des images multi-architecture pour les charges de travail Arm.
  • Pour suivre un tutoriel sur l'utilisation d'images multi-arch à déployer dans plusieurs architectures, consultez la page Migrer l'application x86 sur GKE vers multi-arch avec Arm.

• Préparer des charges de travail Arm pour le déploiement : une fois que vous disposez d'une image compatible avec Arm, utilisez des règles d'affinité de nœuds et des sélecteurs de nœuds pour vous assurer que votre charge de travail est planifiée sur des nœuds avec un type d'architecture compatible.

  • Clusters Autopilot : consultez Déployer des charges de travail Autopilot sur l'architecture Arm.
  • Clusters standards : consultez Préparer une charge de travail Arm pour le déploiement.

Conditions requises et limites

• Les nœuds Arm sont disponibles dans les emplacements Google Cloud compatibles avec l'architecture Arm. Pour en savoir plus, consultez Régions et zones disponibles.
• La famille de pods general-purpose-arm et la classe de calcul autopilot-arm ne sont disponibles que dans les régions suivantes : us-east1, us-west1, europe-west1, europe-west4 et us-central1.
• Config Connector et Config Controller ne sont pas compatibles avec les clusters comportant des pools de nœuds Arm.
• Consultez les exigences et les limites suivantes pour les machines virtuelles (VM) C4A et les instances Bare Metal, respectivement :
  • VM C4A :
    • Pour créer un cluster qui utilise le mode Autopilot, l'autoscaling de cluster, le provisionnement automatique de nœuds ou les ComputeClasses qui créent automatiquement des pools de nœuds, utilisez les versions suivantes ou ultérieures :
      • 1.30.7-gke.1136000
      • 1.31.3-gke.1056000
    • Pour créer un cluster Standard, utilisez la version 1.30.4-gke.1213000 ou ultérieure.
    • Pour utiliser des SSD locaux, utilisez les versions suivantes ou ultérieures :
      • 1.30.12-gke.1033000
      • 1.31.8-gke.1045000
      • 1.32.1-gke.1357000
    • GKE n'est pas compatible avec les fonctionnalités suivantes sur les VM C4A :
      • Nœuds Confidential GKE Node
      • Emplacement compact
      • Multithreading simultané (SMT)
      • Disques persistants (utilisez plutôt Hyperdisk, consultez Types de disques compatibles avec C4A)
      • Virtualisation imbriquée
      • GPU
  • Instances Bare Metal C4A, y compris c4a-standard-96-metal et c4a-highmem-96-metal :
    • Pour créer un pool de nœuds Standard, utilisez la version 1.35.0-gke.2232000 ou ultérieure.
    • En plus des limites des VM C4A, GKE n'est pas compatible avec les fonctionnalités suivantes sur les instances Bare Metal C4A :
      • Disques SSD locaux.
      • Provisionnez l'instance Bare Metal en optimisant les performances des pods Autopilot en choisissant une série de machines, car vous ne pouvez pas sélectionner explicitement le type de machine.
      • Migration à chaud. Pour en savoir plus, consultez Gérer les interruptions des nœuds GKE qui ne migrent pas à chaud.
    • Pour créer un cluster qui utilise c4a-highmem-96-metal et le mode Autopilot, l'autoscaling de cluster, le provisionnement automatique des nœuds ou les ComputeClasses qui créent automatiquement des pools de nœuds, utilisez la version 1.35.3-gke.1389000 ou ultérieure. c4a-standard-96-metal n'est pas compatible avec ces fonctionnalités. Les conditions suivantes s'appliquent également :
      • Pour configurer les pools de nœuds créés automatiquement qui utilisent c4a-highmem-96-metal, vous devez spécifier explicitement le type de machine. Si vous spécifiez uniquement la série de machines C4A, et non le type de machine, GKE provisionne des VM C4A, et non des instances Bare Metal. Ce comportement s'applique à la fois au provisionnement automatique des nœuds et aux ComputeClasses qui créent automatiquement des pools de nœuds.

• Voici les exigences et les limites applicables à N4A :

  • Pour créer un cluster avec des nœuds N4A qui utilise le mode Autopilot, utilisez GKE version 1.34.1-gke.3403001 ou ultérieure.

  • GKE n'est pas compatible avec les fonctionnalités suivantes sur les nœuds N4A :

    • Disques SSD locaux
    • Nœuds Confidential GKE Node
    • GPU
    • Emplacement compact
    • Multithreading simultané (SMT)
    • Disques persistants (utilisez plutôt Hyperdisk, consultez Types de disques compatibles avec N4A)
    • Virtualisation imbriquée
    • 1 GB hugepages (seules les hugepages de 2 Mo sont acceptées)

• Voici les exigences et les limites applicables à T2A :

  • GKE n'est pas compatible avec les fonctionnalités suivantes sur les nœuds T2A :

    • Nœuds Confidential GKE Node
    • GPU
    • Windows GKE
    • Disques SSD locaux
    • Policy Controller, Config Sync et Config Controller

Étapes suivantes

• Créer des clusters et des pools de nœuds avec des nœuds Arm
• Créer des images multi-architecture pour les charges de travail Arm
• Préparer une charge de travail Arm pour le déploiement
• Migrer l'application x86 sur GKE vers multi-arch avec Arm