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
  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"

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

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"

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

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 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 n’est pas applicable aux volumes root, mais il est requis pour les autres types de volumes.

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 sera redémarrée de force 5 minutes après le dernier battement de cœur (heartbeat) du nœud. Si le nœud n’est pas dans l’état ready 5 minutes après le redémarrage, il est remplacé.

  • Si false, aucune action automatique n’est prise.

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

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.

Pages connexes

Exporter en PDF