Cette page explique comment préparer une charge de travail à planifier sur des nœuds Arm dans un cluster GKE Standard. Pour en savoir plus sur la planification des charges de travail Arm avec Autopilot, consultez la page Déployer des charges de travail Autopilot sur l'architecture Arm.
Pour planifier une charge de travail sur un nœud Arm, vous devez disposer des éléments suivants :
- une image de conteneur compatible avec Arm. Pour savoir comment le vérifier, consultez la section Ma charge de travail est-elle prête pour Arm ? ;
- des nœuds Arm sur lesquels vos charges de travail compatibles avec Arm peuvent être planifiées. Pour créer les ressources nécessaires, consultez la section Créer des clusters et des pools de nœuds avec des nœuds Arm.
- un cluster dans une Google Cloud région ou une zone disposant de machines virtuelles (VM) Arm disponibles. Pour obtenir un tableau filtrable des types de machines et des plates-formes, consultez la page Régions et zones disponibles.
Présentation
Par défaut, GKE ne planifie les charges de travail que sur les nœuds basés sur x86
(séries de machines Compute Engine avec
processeurs Intel ou
AMD) en plaçant un
rejet
(kubernetes.io/arch=arm64:NoSchedule) sur tous les nœuds Arm. Ce rejet empêche les charges de travail compatibles x86 d'être planifiées par inadvertance sur vos nœuds Arm.
Vous pouvez éventuellement supprimer ce rejet par défaut si vous souhaitez que les charges de travail compatibles x86 soient planifiées sur des nœuds Arm sans avoir besoin de la tolérance correspondante. Pour en savoir plus, consultez la section Configurer le rejet d'architecture Arm
par défaut.
Si vous souhaitez déployer une charge de travail sur un nœud Arm qui comporte le rejet par défaut, utilisez les champs décrits dans ce document pour guider le programmeur vers l'envoi de la charge de travail au type de nœud demandé.
Utilisez l'un des champs suivants :
- Un sélecteur de nœuds
- Une règle d'affinité de nœuds
Lorsque vous utilisez un sélecteur de nœud ou une règle d'affinité de nœuds, GKE ne planifie vos charges de travail compatibles avec Arm que lorsque vous avez déclaré que l'image de conteneur de la charge de travail peut s'exécuter sur l'architecture du nœud.
Si vous programmez une charge de travail compatible avec Arm avec un sélecteur de nœuds ou avec une règle d'affinité de nœuds comme décrit dans les sections suivantes, GKE ajoute automatiquement une tolérance à la configuration de la charge de travail, de sorte que les pods puissent s'exécuter sur les nœuds Arm.
Cette tolérance ajoutée à la charge de travail correspond au rejet (kubernetes.io/arch=arm64:NoSchedule) ajouté par défaut à tous les nœuds Arm pour permettre de programmer votre charge de travail sur des nœuds Arm.
Dans certaines situations, par exemple lorsque vous avez des images multi-architectures qui peuvent s'exécuter sur n'importe quel nœud, vous pouvez ajouter manuellement cette tolérance à la configuration de la charge de travail. Pour obtenir des instructions, consultez la section Utiliser la tolérance pour planifier des charges de travail multi-arch sur n'importe quelles architectures.
Utiliser un sélecteur de nœud pour planifier une charge de travail Arm
Ajoutez le sélecteur de nœuds suivant à la spécification :
nodeSelector:
kubernetes.io/arch: arm64
Le sélecteur de nœuds indique que cette charge de travail ne doit être planifiée que sur les nœuds portant le libellé arm64, que tous les nœuds Arm sur les clusters GKE comportent.
Lorsque ce sélecteur de nœuds est inclus dans la configuration de la charge de travail, GKE ajoute la tolérance pour correspondre au rejet, afin de permettre la programmation de la charge de travail sur les nœuds Arm.
Utiliser une règle d'affinité de nœuds pour planifier une charge de travail Arm
Vous pouvez également planifier votre charge de travail à l'aide de l'affinité de nœuds.
Planifier la charge de travail sur une seule architecture
Ajoutez l'affinité de nœuds suivante à la spécification :
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
La règle d'affinité de nœuds indique que la charge de travail ne doit être planifiée que sur les nœuds portant le libellé arm64, que tous les nœuds Arm sur les clusters GKE comportent.
Lorsque cette règle d'affinité de nœuds est incluse dans la configuration de la charge de travail, GKE ajoute la tolérance pour correspondre au rejet, afin de permettre la programmation de la charge de travail sur les nœuds Arm.
Programmer une charge de travail sur les architectures x86 et Arm
Si vous souhaitez programmer une charge de travail sur les architectures x86 (processeurs Intel et AMD) et Arm, et que vos pools de nœuds Arm utilisent le comportement de rejet par défaut, vous pouvez le spécifier de différentes manières. Les instructions suivantes supposent que vos pools de nœuds Arm utilisent le rejet par défaut.
Utiliser la tolérance pour planifier des charges de travail multi-arch sur n'importe quelles architectures
Si vous souhaitez programmer une image multi-architecture pour tout type d'architecture disponible dans un cluster Standard, il vous suffit d'ajouter la tolérance à la spécification de charge de travail. Vous n'avez pas besoin du sélecteur de nœuds ni des règles d'affinité de nœuds décrites sur cette page, car la charge de travail peut être programmée pour tous les types d'architecture.
Ajoutez la tolérance :
tolerations:
- key: kubernetes.io/arch
operator: Equal
value: arm64
effect: NoSchedule
À l'aide de cette tolérance, GKE peut planifier une charge de travail sur les nœuds de n'importe quel type d'architecture.
Par exemple, si vous disposez d'un cluster avec les pools de nœuds suivants :
- my-c4a-node-pool, avec des VM c4a-standard-16 (
arm64) - my-c2-node-pool, avec des VM c2-standard-8 (
amd64) - my-t2d-node-pool, avec des VM t2-standard-48 (
amd64)
Si vous déployez sur ce cluster une charge de travail qui utilise une image multi-architecture et la tolérance arm64 dans la configuration de la charge de travail, GKE peut programmer la charge de travail sur tous les pools de nœuds.
Utiliser une règle d'affinité de nœuds pour programmer des charges de travail multi-architectures sur n'importe quelles architectures
Si vous souhaitez programmer une charge de travail sur des nœuds de différents types d'architecture, y compris x86 et Arm, vous pouvez également utiliser une règle d'affinité de nœuds. Avec les règles d'affinité de nœuds, vous pouvez spécifier exactement les types d'architecture sur lesquels vous souhaitez planifier la charge de travail. Cette approche est recommandée pour programmer des charges de travail sur des clusters Autopilot. Pour en savoir plus, consultez la page Déployer des charges de travail Autopilot sur l'architecture Arm.
Avec les charges de travail basées sur les architectures x86, vous n'avez pas besoin de ces sélecteurs de nœuds, de règles d'affinité de nœuds ni de tolérances pour que la charge de travail soit programmée. Si vous souhaitez ne programmer une image que sur des nœuds basés sur une architecture x86, vous n'avez pas besoin d'utiliser ces champs.
Pour programmer des charges de travail sur n'importe quel type d'architecture, identifiez les occurrences de arm64 et amd64 dans la section values du champ d'affinité de nœuds. amd64 inclut tous les nœuds utilisant des processeurs x86.
L'exemple suivant indique que cette charge de travail peut être programmée sur des nœuds dotés de processeurs Arm ou x86 :
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/arch
operator: In
values:
- arm64
- amd64
Les libellés de chaque type d'architecture sont les suivants :
arm64pour les nœuds utilisant des processeurs Arm (par exemple, C4A)amd64pour les nœuds utilisant des processeurs AMD (par exemple, Tau T2D) ou pour les nœuds utilisant des processeurs Intel (par exemple, C2).
Par exemple, si vous disposez d'un cluster avec les pools de nœuds suivants et la règle d'affinité de nœuds donnée :
- my-c4a-node-pool, avec des VM c4a-standard-16 (
arm64) - my-c2-node-pool, avec des VM c2-standard-8 (
amd64) - my-t2d-node-pool, avec des VM t2-standard-48 (
amd64)
Si vous déployez sur ce cluster une charge de travail qui utilise une image multi-architecture et l'
affinité de nœuds avec arm64 figurant dans la liste values, GKE
ajoute la tolérance dans la configuration de la charge de travail, et peut la
programmer sur l'ensemble des pools de nœuds.
Configurer le rejet d'architecture Arm par défaut
Par défaut, GKE ajoute le rejet kubernetes.io/arch=arm64:NoSchedule à tous les nœuds Arm. Ce rejet empêche la programmation sur des nœuds Arm des charges de travail compatibles uniquement avec l'architecture x86, mais pas avec l'architecture Arm. Si vous disposez de charges de travail compatibles avec les architectures x86 et Arm, vous pouvez désactiver ce rejet pour permettre à GKE de programmer ces charges de travail sur des nœuds Arm sans avoir besoin d'une tolérance correspondant au rejet.
Vous ne pouvez modifier le comportement par défaut que dans les pools de nœuds Standard des clusters GKE où le plan de contrôle exécute la version 1.35.0-gke.2141000 ou une version ultérieure, ou avec des nœuds créés pour des ComputeClasses personnalisées. Pour en savoir plus, consultez la section Configurer le rejet d'architecture Arm par défaut. La modification du comportement de rejet ne s'applique pas au déploiement de charges de travail Arm avec Autopilot. Pour en savoir plus, consultez la section Déployer des charges de travail Autopilot sur l'architecture Arm.
Vous pouvez configurer ce comportement dans les situations suivantes avec des pools de nœuds Standard :
- Lors de la création du cluster, pour le pool de nœuds Standard par défaut
- Lorsque vous créez ou mettez à jour un pool de nœuds Standard
Si des charges de travail s'exécutent dans le cluster et ne sont pas compatibles avec Arm, ne supprimez pas le rejet par défaut, car des charges de travail incompatibles pourraient être programmées sur les nœuds Arm non rejetés.
Pour configurer le rejet de nœud par défaut pour les nœuds Arm, sélectionnez l'une des options suivantes :
gcloud CLI
Pour définir le comportement de rejet avec gcloud CLI, utilisez l'option --node-architecture-taint-behavior lorsque vous effectuez l'une des opérations suivantes :
Créer un cluster Standard avec un comportement de rejet spécifique pour le pool de nœuds par défaut à l'aide de la
gcloud container cluster createcommande :gcloud container cluster create CLUSTER_NAME --location=CONTROL_PLANE_LOCATION \ --node-architecture-taint-behavior=BEHAVIORCréer un pool de nœuds Standard à l'aide de la
gcloud container node-pools createcommande :gcloud container node-pools create POOL_NAME \ --cluster=CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --node-architecture-taint-behavior=BEHAVIORMettre à jour un pool de nœuds Standard à l'aide de la
gcloud container node-pools updatecommande :gcloud container node-pools update POOL_NAME \ --cluster=CLUSTER_NAME \ --location=CONTROL_PLANE_LOCATION \ --node-architecture-taint-behavior=BEHAVIOR
Pour ces commandes, remplacez les éléments suivants :
CLUSTER_NAME: nom du clusterCONTROL_PLANE_LOCATION: emplacement Compute Engine du plan de contrôle de votre cluster Indiquez une région pour les clusters régionaux ou une zone pour les clusters zonaux.POOL_NAME: nom de votre pool de nœudsBEHAVIOR: l'un des paramètres suivants :none: GKE omet le rejet par défautkubernetes.io/arch=arm64:NoSchedule.arm: définit explicitement le comportement par défaut, qui ajoute les rejetskubernetes.io/arch=arm64:NoSchedulepour tous les nœuds du pool de nœuds Arm.
Lorsque vous modifiez le comportement de rejet d'architecture de nœud pour un pool de nœuds Standard, GKE met immédiatement à jour les rejets sans avoir besoin de recréer les nœuds.
Terraform
Ajoutez le bloc taint_config suivant dans node_config pour configurer le comportement de rejet d'architecture :
taint_config {
architecture_taint_behavior = "BEHAVIOR"
}
Remplacez BEHAVIOR par l'un des paramètres suivants :
NONE: GKE omet le rejet par défautkubernetes.io/arch=arm64:NoSchedule.ARM: définit explicitement le comportement par défaut, qui ajoute les rejetskubernetes.io/arch=arm64:NoSchedulepour tous les nœuds du pool de nœuds Arm.
Un node_config complet pour un pool de nœuds Standard qui inclut ce bloc se présente comme suit :
resource "google_container_node_pool" "primary_preemptible_nodes" {
name = "NODE_POOL_NAME"
location = "NODE_POOL_LOCATION"
cluster = google_container_cluster.primary.name
node_count = 1
node_config {
preemptible = true
machine_type = "ARM_MACHINE_TYPE"
# Google recommends custom service accounts that have cloud-platform scope and permissions granted via IAM Roles.
service_account = google_service_account.default.email
oauth_scopes = [
"https://www.googleapis.com/auth/cloud-platform"
]
taint_config {
architecture_taint_behavior = "BEHAVIOR"
}
}
}
Dans cet exemple, NODE_POOL_NAME représente le nom du pool de nœuds, et NODE_POOL_LOCATION représente l'emplacement du plan de contrôle du cluster.
Déployer la charge de travail
Maintenant que vous avez spécifié l'emplacement où vos charges de travail compatibles avec Arm doivent être planifiées, vous pouvez déployer votre charge de travail.
Lorsque vous déployez une charge de travail sur un cluster GKE, les instructions sont les mêmes pour tous les types d'architecture. Vous pouvez déployer une charge de travail compatible avec Arm comme vous le feriez pour toute autre charge de travail, à condition d'avoir effectué les étapes préalables requises. Pour consulter des exemples de déploiement de charges de travail, consultez les pages suivantes :
Dépannage
Pour obtenir des informations sur les erreurs courante et le dépannage, consultez la section Résoudre les problèmes liés aux charges de travail Arm.