Référence des manifestes de node pool

Un manifeste de node pool est un manifeste Kubernetes appliqué à un ensemble de worker nodes.

Manifeste de node pool

Pour créer un manifeste de node pool, vous devez créer un fichier YAML en suivant cette syntaxe :

Structure d’un manifeste de node pool
apiVersion: oks.dev/v1beta2
kind: NodePool
metadata:
  name: application-pool2-a
spec:
  desiredNodes: 2
  nodeType: tinav6.c2r4p2
  zones:
    - eu-west-2a
    - eu-west-2b
  volumes:
  - device: xvdl
    size: 2
    type: "standard"
    dir: /var/spool/filebeat
    snapshot: snap-87654321
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0
    autoUpgradeEnabled: true
    autoUpgradeMaintenance:
      durationHours: 1
      startHour: 12
      weekDay: Tue
  autoHealing: true

Manifeste de volumes

Vous pouvez spécifier des volumes pour vos worker nodes, sous la section volume du manifeste de node pool.

Si les volumes sont valides, ils seront créés avec la VM pour chaque worker node géré par le node pool, et montés dans le système. Un système de fichiers sera créé sur les volumes. Si les volumes ne sont pas valides, une erreur se produit, et aucune VM ne sera créée.

Ce paramètre est limité par votre offre OKS actuelle et les quotas de votre compte OUTSCALE.

Dans cet exemple, nous ajoutons un volume gp2 dédié de 300 Gio à utiliser comme volume Longhorn. Ce volume synchronise les données distribuées entre les nœuds du cluster, quelle que soit leur Sous-région, et stocke les données de l’application :

Exemple de manifeste de volumes : données d’application
...
spec:
  volumes:
  - size: 300
    type: "gp2"
    dir: "/var/lib/longhorn"
    snapshot: snap-87654321

Vous pouvez utiliser un petit volume standard dédié pour Filebeat :

Exemple de manifeste de volumes : logs
...
spec:
  volumes:
  - device: xvdl
    size: 2
    type: "standard"
    dir: /var/spool/filebeat
    snapshot: snap-87654321

Vous pouvez améliorer les performances de démarrage de vos pods en utilisant le disque du worker node avec io1 3000 IOPS :

Exemple de manifeste de volumes : root
...
spec:
  volumes:
  - device: root
    size: 100
    iops: 3000
    type: "io1"
    dir: /
    snapshot: snap-87654321

Ou en plaçant les données relatives à Kubernetes sur un volume rapide dédié :

Exemple de manifeste de volumes : kubelet
...
spec:
  volumes:
  - device: xvdl
    size: 100
    iops: 3000
    type: "io1"
    dir: /var/lib/kubelet
    snapshot: snap-87654321

Ce fichier contient les options suivantes que vous devez spécifier :

  • (optionnel) device : L’appareil /dev/XXX dans lequel vous voulez placer le volume. Les valeurs possibles sont soit root, xvdX ou xvdXY, où X est une lettre entre b et z, et Y est une lettre entre a et z. Si elle n’est pas spécifiée, elle est générée automatiquement.

  • type : Le type de volume, parmi les types de volumes pris en charge par 3DS OUTSCALE. Les valeurs possibles sont standard (le type par défaut), gp2 ou io1.

  • size : La taille du volume, en gibioctets (Gio). Ce paramètre est requis et est fixé à 100 par défaut pour le volume root.

  • (optionnel) iops : Le nombre d’opérations I/O (IOPS) par seconde. Vous devez spécifier ce paramètre uniquement lorsque vous créez un volume io1. Le nombre maximal d’IOPS autorisé pour les volumes io1 est 13000 avec un ratio de performance maximum de 300 IOPS par gibioctet.

  • dir : Le chemin de montage pour le volume. Il doit toujours être / pour les volumes root, et peut pointer vers n’importe quel chemin pour les autres volumes.

  • (optionnel) snapshot : L’ID du snapshot à partir duquel vous souhaitez créer le volume.

Pour en savoir plus sur les types de volumes et leurs paramètres, voir À propos des volumes > Types de volumes et IOPS.

Manifeste de zones

Vous pouvez spécifier plusieurs zones pour vos worker nodes pour une plus haute disponibilité, sous la section zones du manifeste de node pool.

Dans le cas où plusieurs zones ont été spécifiées, le paramètre desiredNodes contrôle la création de VM pour chaque zone spécifiée.

Exemple de manifeste de zones :
...
spec:
  zones:
  - eu-west-2a
  - eu-west-2b
...

Manifeste d’emplacement physique

Les node pools supportent des options d’emplacement physique. Ces options ne sont pas strictes et sont mutuellement exclusives. Elles sont listées dans le tableau ci-dessous.

Option Description

nodeRepulseServer

Place les nœuds avec la même valeur sur différents serveurs.

nodeAttractServer

Place les nœuds avec la même valeur sur le même serveur.

nodeRepulseCluster

Place les nœuds avec la même valeur sur différents clusters Cisco UCS.

nodeAttractCluster

Place les nœuds avec la même valeur sur le même cluster Cisco UCS.

Le fichier YAML doit suivre la syntaxe suivante :

Exemple de manifeste d’emplacement :
...
spec:
  physicalPlacement:
    nodeRepulseServer: application_2
...

Manifeste d’auto-réparation

L’auto-réparation (option autoHealing) contrôle la gestion des nœuds NotReady.

  • Si true, la VM est forcée de redémarrer 5 minutes après le dernier signal de présence du node. Si le node n’est pas dans l’état ready 5 minutes après le redémarrage, il est remplacé.

  • Si false, aucune action automatique n’est effectuée. Cela vous permet de décider manuellement comment restaurer les nodes hébergeant des charges de travail nécessitant une intervention contrôlée (processus d’apprentissage automatique de longue durée, bases de données, environnements de tests de charge, ou applications héritées nécessitant des vérifications de cohérence avant leur redémarrage).

Exemple de manifeste AutoHealing
...
spec:
  autoHealing: true

Manifeste de stratégie de mise à niveau

Vous pouvez contrôler le comportement des worker nodes en cas de changements de paramètres qui influencent le type, les volumes et l’emplacement des VM, dans la section upgradeStrategy du manifeste de node pool.

Le paramètre upgradeStrategy a la même fonction que la ressource ReplicaSet. La valeur par défaut pour les deux paramètres est de 25 %.

Exemple de manifeste UpgradeStrategy :
...
spec:
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0

Éléments déclencheurs de mise à niveau

Les nodes sont automatiquement mis à niveau lorsque :

  • La version Kubernetes sur les nodes diffère de la version du cluster.

  • L’ID de l’OMI sur les nodes est différent de celui configuré dans le node pool.

Mise à niveau automatique des nodes

Vous pouvez utiliser la section upgradeStrategy pour déterminer si les nœuds d’un node pool doivent être automatiquement recréés lors des opérations de mise à niveau du cluster.

Exemple de stratégie de mise à jour automatique
...
upgradeStrategy:
  autoUpgradeEnabled: false

Cet exemple contient les options suivantes que vous devez spécifier :

  • upgradeStrategy : Définit la manière dont les nodes du node pool sont gérés lors des opérations de mise à niveau.

    • autoUpgradeEnabled : Détermine si les nodes sont automatiquement recréés lors des mises à niveau du cluster. Si définie sur true, les nodes peuvent être recréés automatiquement lors des opérations de mise à niveau, conformément à la stratégie de mise à niveau et à la fenêtre de maintenance configurées. Si définie sur false, les nodes ne sont pas recréés automatiquement lors des mises à niveau du cluster. Cela vous permet de contrôler manuellement la recréation des nodes pour les charges de travail nécessitant une intervention contrôlée, telles que les processus d’apprentissage automatique de longue durée, les bases de données ou les applications qui ne doivent pas être interrompues automatiquement.

La désactivation de la mise à niveau automatique des nodes n’empêche pas leur réparation automatique. Pour empêcher les actions de récupération automatique sur les nodes NotReady, définissez autoHealing sur false. Pour en savoir plus, voir Manifeste d’auto-réparation.

Fenêtre de maintenance

Lorsque autoUpgradeEnabled est défini sur true, vous pouvez limiter les opérations de mise à niveau automatique à des plages horaires spécifiques. Deux modes de planification mutuellement exclusifs sont disponibles : une planification hebdomadaire simple à l’aide de weekDay et startHour, ou une règle de récurrence basée sur la norme RFC 5545.

Exemple de fenêtre de mise à niveau hebdomadaire
...
upgradeStrategy:
  autoUpgradeEnabled: true
  autoUpgradeMaintenance:
    durationHours: 1
    startHour: 12
    weekDay: Tue

Ce fichier contient les options suivantes que vous devez spécifier :

  • autoUpgradeMaintenance : Définit la plage horaire de maintenance pendant laquelle les opérations de mise à niveau automatique sont autorisées.

  • durationHours : Durée de la fenêtre de maintenance, en heures. Pendant cette période, les mises à niveau sont autorisées.

  • startHour : Heure de début de la fenêtre, au format 24 heures (0-23).

  • weekDay : Jour de la semaine auquel la fenêtre s’applique. Les valeurs valides sont : Mon, Tue, Wed, Thu, Fri, Sat et Sun.

Exemple de récurrence basée sur RRULE
...
upgradeStrategy:
  autoUpgradeEnabled: true
  autoUpgradeMaintenance:
    durationHours: 1
    rrule: FREQ=DAILY;WKST=TU;BYHOUR=12

Ce fichier contient les options suivantes que vous devez spécifier :

  • autoUpgradeMaintenance : Définit la plage horaire de maintenance pendant laquelle les opérations de mise à niveau automatique sont autorisées.

  • durationHours : Durée de la fenêtre de maintenance, en heures. Pendant cette période, les mises à niveau peuvent être effectuées.

  • rrule : Règle de récurrence (au format RFC 5545) permettant de définir des fenêtres de mise à niveau plus avancées. Par exemple, FREQ=DAILY;WKST=TU;BYHOUR=12 définit une fenêtre de mise à niveau qui se produit tous les jours à 12h00, le mardi étant défini comme le début de la semaine.

Si aucune fenêtre de maintenance n’est spécifiée, les nodes peuvent être mis à niveau à tout moment.

Annotations de maintenance et de downscaling

Les nœuds auxquels sont associés des volumes locaux (par exemple, via hostPath) sont exclus des opérations et des mises à niveau de l’autoscaler afin d’éviter toute perte de données. Pour autoriser leur suppression, vous pouvez les annoter manuellement sous la section nodeAnnotations de votre manifeste.

Exemple d’annotation de node pool
...
spec:
  nodeAnnotations:
    cluster-autoscaler.kubernetes.io/safe-to-evict: "true"
    nplc.oks.outscale.com/safe-to-delete: "true"

  • nplc.oks.outscale.com/safe-to-delete : Contourne les limitations de mise à niveau de maintenance. Requis lorsque plusieurs volumes personnalisés sont définis dans les spécifications du node pool (seul le volume racine est autorisé) ou lorsque des pods avec des volumes hostPath (non des daemonsets/pods statiques) sont présents. Peut être appliqué au niveau du node pool (nodeAnnotations), directement sur les nœuds ou sur les pods concernés.

  • cluster-autoscaler.kubernetes.io/safe-to-evict : Appliqué aux pods avec des volumes hostPath pour permettre leur éviction pendant les mises à niveau. A le même effet que la configuration nplc.oks.outscale.com/safe-to-delete: "true".

Manifeste de support GPU

Les node pools permettent aux worker nodes d’allouer, attacher, et utiliser des flexible GPU. Actuellement, OKS permet d’attacher 1 GPU par nœud. Pour en savoir plus sur les GPU, voir À propos des flexible GPU.

La version actuelle du pilote CUDA utilisé avec les GPU est cuda_12.6.2_560.35.03.

Vous pouvez configurer le support GPU sous la section volume du manifeste de node pool.

Exemple de manifeste GPU :
spec:
  fgpu:
    model: "nvidia-p6"
    k8s-operator: true

Ce fichier contient les options suivantes que vous devez spécifier :

  • model : Le modèle GPU à allouer.

  • k8s-operator : L’opérateur GPU officiel de NVIDIA dans le namespace gpu-operator. La suppression du node pool ne désinstalle pas l’opérateur.

Manifeste de mise à l’échelle automatique (bêta)

Vous pouvez activer la mise à l’échelle automatique (ou autoscaling) en ajoutant les options suivantes à votre manifeste de node pool :

Cette fonctionnalité est actuellement en bêta. Pour en savoir plus sur les services bêta, voir le Glossaire et nos Conditions générales de ventes et d’utilisation.
Exemple de manifeste d’autoscaling
spec:
  minNodes: X
  maxNodes: Y
  autoscaling: true

Cet exemple contient les options suivantes que vous devez spécifier :

  • minNodes : Le nombre minimum de nœuds que l’autoscaler est autorisé à maintenir.

  • maxNodes : Le nombre maximum de nœuds que l’autoscaler peut atteindre.

  • autoscaling : Indique si le node pool doit être géré par l’autoscaler. Doit être défini sur true pour activer l’autoscaling.

Pour en savoir plus, voir Tutoriel : Redimensionner vos node pools avec l’autoscaling (bêta).

Pages connexes

Exporter en PDF