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 autopilot-arm ComputeClass pour les charges de travail à usage général. Pour demander du matériel spécifique, utilisez les Performance ou Scale-Out classes de calcul.
• Mode Standard GKE : à 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 la section 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 sur leur préparation au déploiement, consultez les sections suivantes :

• Choisir les charges de travail à exécuter sur Arm : tenez compte des avantages des options suivantes lorsque vous choisissez les 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 fournit 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 un calcul basé sur Arm qui équilibre le prix et les performances.
    • Les nœuds T2A conviennent aux charges de travail plus flexibles ou aux charges de travail 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 la section 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 la page Déployer les charges de travail Autopilot sur l'architecture Arm.
  • Clusters standards : consultez la page Préparer une charge de travail Arm pour le déploiement.

Conditions requises et limites

• Les nœuds Arm sont disponibles dans les Google Cloud emplacements compatibles avec l' architecture Arm. Pour en savoir plus, consultez la section 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 l'instance c4a-highmem-96-metal Bare Metal (aperçu), respectivement :
  • VM C4A :
    • Pour créer un cluster qui utilise Autopilot mode, l'autoscaling de cluster, le provisionnement automatique des 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 disques 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 Hyperdisk plutôt. Consultez Types de disques compatibles pour C4A)
      • Virtualisation imbriquée
      • GPU
  • L'instance Bare Metal C4A, c4a-highmem-96-metal (aperçu) :
    • Pour créer un cluster qui utilise Autopilot mode, cluster autoscaling, node auto-provisioning, ou ComputeClasses qui créent automatiquement des pools de nœuds, utilisez la version 1.35.3-gke.1389000 ou ultérieure. Les points suivants s'appliquent également :
      • Pour configurer des pools de nœuds créés automatiquement qui utilisent c4a-highmem-96-metal, vous devez spécifier explicitement le type de machine. Si vous ne spécifiez que 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.
    • Pour créer un cluster 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 avec c4a-highmem-96-metal (aperçu) :
      • Disques SSDlocaux.
      • Provisionnement de 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 la section Gérer les interruptions des nœuds GKE qui ne migrent pas à chaud.

• Consultez les exigences et les limites suivantes pour N4A :

  • Pour créer un cluster avec des nœuds N4A qui utilise Autopilot mode, 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 Hyperdisk plutôt. Consultez Types de disques compatibles pour N4A)
    • Virtualisation imbriquée
    • Pages énormes de 1 Go (seules les pages énormes de 2 Mo sont acceptées)

• Consultez les exigences et les limites suivantes pour 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

Étape suivante

• 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