Préparer le déploiement d'une charge de travail Arm dans un cluster Standard

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 :

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 des 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 les nœuds Arm sans avoir besoin de la tolérance correspondante. Pour en savoir plus, consultez Configurer la taint de l'architecture Arm par défaut.

Si vous souhaitez déployer une charge de travail sur un nœud Arm qui présente la contamination par défaut, utilisez les champs décrits dans ce document pour guider le planificateur vers l'envoi de la charge de travail au type de nœud demandé.

Utilisez l'un des champs suivants :

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 Armavec 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é à tous les nœuds Arm par défaut 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 taint 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 la contamination 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 :

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 la taint d'architecture Arm par défaut

Par défaut, GKE ajoute le taint kubernetes.io/arch=arm64:NoSchedule à tous les nœuds Arm. Ce rejet empêche les charges de travail compatibles uniquement avec l'architecture x86, mais pas avec l'architecture Arm, d'être planifiées sur des nœuds Arm. Si vous avez des charges de travail compatibles avec x86 et Arm, vous pouvez désactiver ce rejet pour permettre à GKE de planifier 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 des taints que dans les pools de nœuds standards. La mise à jour du comportement des taints ne s'applique pas au déploiement de charges de travail Arm avec Autopilot. Pour en savoir plus, consultez Déployer des charges de travail Autopilot sur l'architecture Arm.

Vous pouvez configurer ce comportement dans les situations suivantes :

  • Lors de la création d'un 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 planifiées sur les nœuds Arm non rejetés.

Pour configurer le taint de nœud par défaut pour les nœuds Arm, sélectionnez l'une des options suivantes :

CLI gcloud

Pour définir le comportement de la contamination avec gcloud CLI, utilisez l'indicateur --node-architecture-taint-behavior lorsque vous effectuez l'une des opérations suivantes :

  • Créez un cluster Standard avec un comportement de rejet spécifique pour le pool de nœuds par défaut à l'aide de la commande gcloud container cluster create :

    gcloud container cluster create CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Créez un pool de nœuds Standard à l'aide de la commande gcloud container node-pools create :

    gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --node-architecture-taint-behavior=BEHAVIOR

  • Mettez à jour un pool de nœuds standard à l'aide de la commande gcloud container node-pools update :

    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 cluster
  • CONTROL_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œuds.

  • BEHAVIOR : l'un des paramètres suivants :

    • none : GKE omet le rejet par défaut kubernetes.io/arch=arm64:NoSchedule.
    • arm : définit explicitement le comportement par défaut, qui ajoute les rejets kubernetes.io/arch=arm64:NoSchedule pour tous les nœuds du pool de nœuds Arm.

Lorsque vous modifiez le comportement du rejet d'architecture de nœud pour un pool de nœuds Standard, GKE met immédiatement à jour les rejets sans avoir à recréer les nœuds.

Terraform

Ajoutez le bloc taint_config suivant dans node_config pour configurer le comportement de taint de l'architecture :

taint_config {
  architecture_taint_behavior = "BEHAVIOR"
}

Remplacez BEHAVIOR par l'un des paramètres suivants :

  • NONE : GKE omet le rejet par défaut kubernetes.io/arch=arm64:NoSchedule.
  • ARM : définit explicitement le comportement par défaut, qui ajoute les rejets kubernetes.io/arch=arm64:NoSchedule pour tous les nœuds du pool de nœuds Arm.

Un node_config complet pour un pool de nœuds standard incluant 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.

Étape suivante