Node Pool Manifest Reference

A node pool manifest is a Kubernetes manifest applied to a set of worker nodes.

Node Pool Manifest

To create a node pool manifest, you need to create a YAML file following this structure:

Node Pool Manifest Structure
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

Volumes Manifest

You can specify volumes for your worker nodes, under the volumes section of the node pool manifest.

If the volumes are valid, they will be created with the VM for each worker node managed by the node pool, and mounted in the system. A filesystem will be created on the volumes. If the volumes are not valid, an error occurs, and no VM will be created.

This setting is limited by your current OKS plan and OUTSCALE account quotas.

In this example, we are adding a dedicated 300 GiB gp2 volume to use as a Longhorn volume. This volume synchronizes the data distributed between the nodes of the cluster, regardless of their Subregion, and stores the application data:

Volumes Manifest Sample: App Data
...
spec:
  volumes:
  - size: 300
    type: "gp2"
    dir: "/var/lib/longhorn"
    snapshot: snap-87654321

You can use a dedicated small standard volume for Filebeat:

Volumes Manifest Sample: Logs
...
spec:
  volumes:
  - device: xvdl
    size: 2
    type: "standard"
    dir: /var/spool/filebeat
    snapshot: snap-87654321

You can boost the booting performance of your pods by switching the disk of the worker node to io1 3000 IOPS:

Volumes Manifest Sample: Root
...
spec:
  volumes:
  - device: root
    size: 100
    iops: 3000
    type: "io1"
    dir: /
    snapshot: snap-87654321

Or place the Kubernetes related data on a dedicated fast volume:

Volumes Manifest Sample: kubelet
...
spec:
  volumes:
  - device: xvdl
    size: 100
    iops: 3000
    type: "io1"
    dir: /var/lib/kubelet
    snapshot: snap-87654321

This sample contains the following options that you need to specify:

  • (optional) device: The /dev/XXX device in which you want to locate the volume. It can be either root, xvdX or xvdXY, where X is a letter between b and z, and Y is a letter between a and z. If not specified, it is generated automatically.

  • type: The type of volume, among the volume types supported by 3DS OUTSCALE. It can either be standard (the default type), gp2 or io1.

  • size: The size of the volume, in gibibytes (GiB). This parameter is required and is set by default to 100 for the root volume.

  • (optional) iops: The number of I/O operations per second (IOPS). This parameter only needs to be specified if you create an io1 volume. The maximum number of IOPS allowed for io1 volumes is 13000 with a maximum performance ratio of 300 IOPS per gibibyte.

  • dir: The mount path for the volume. It should always be / for the root volumes, and may point to any directory for other volumes.

  • (optional) snapshot: The ID of the snapshot from which you want to create the volume.

For more information about volume types and parameters, see About Volumes > Volume Types and IOPS.

Zones Manifest

You can specify multiple worker node zones for higher availability, under the zones section of the node pool manifest.

In the case where multiple zones have been specified, the desiredNodes parameter controls VM creation in each specified zone.

Zones Manifest Sample
...
spec:
  zones:
  - eu-west-2a
  - eu-west-2b
...

Physical Placement Manifest

Node pools support physical placement options. These options are not strict and are mutually exclusive. They are listed in the table below.

Option Description

nodeRepulseServer

Places nodes with the same value on different servers.

nodeAttractServer

Places nodes with the same value on the same server.

nodeRepulseCluster

Places nodes with the same value on different Cisco UCS clusters.

nodeAttractCluster

Places nodes with the same value on the same Cisco UCS cluster.

The placement portion of the manifest must follow this structure:

Placement Manifest Sample
...
spec:
  physicalPlacement:
    nodeRepulseServer: application_2
...

Autohealing Manifest

Autohealing (autoHealing option) controls the management of NotReady nodes.

  • When set to true, the VM is forced to reboot 5 minutes after the last heartbeat time of the node. If the node is not in the ready state 5 minutes after reboot, it is replaced.

  • When set to false, no automatic actions are taken. This allows you to manually decide how to recover nodes that host workloads requiring controlled intervention (long-running machine learning (ML) processes, databases, load test environments, or legacy applications requiring consistency checks before restart).

AutoHealing Manifest Sample
...
spec:
  autoHealing: true

Upgrade Strategy Manifest

You can control the behavior of worker nodes in case of setting changes that influence type, volumes, and placement of the VMs, under the upgradeStrategy section of the node pool manifest.

The upgradeStrategy parameter serves the same function as in the ReplicaSet resource. The default value for both parameters is 25%.

UpgradeStrategy Manifest Sample
...
spec:
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0

Upgrade Triggers

Nodes are automatically upgraded when:

  • The Kubernetes version on the nodes differs from the cluster version.

  • The OMI ID on the nodes is different from the one configured in the node pool.

Automatic Node Upgrades

You can use the upgradeStrategy section to control whether nodes in a node pool are automatically recreated during cluster upgrade operations.

Automatic Upgrade Strategy Sample
...
upgradeStrategy:
  autoUpgradeEnabled: false

This sample contains the following options that you need to specify:

  • upgradeStrategy: Defines how nodes in the node pool are managed during upgrade operations.

  • autoUpgradeEnabled: Controls whether nodes are automatically recreated during cluster upgrades.

    • When set to true, nodes can be automatically recreated during upgrade operations, according to the configured upgrade strategy and maintenance window.

    • When set to false, nodes are not automatically recreated during cluster upgrades. This lets you manually control node recreation for workloads that require controlled intervention, such as long-running ML processes, databases, or applications that must not be interrupted automatically.

Disabling automatic node upgrades does not disable autohealing. To prevent automatic recovery actions on NotReady nodes, set autoHealing to false. For more information, see Autohealing Manifest.

Maintenance Window

When autoUpgradeEnabled is set to true, you can restrict automatic upgrade operations to specific time windows. Two mutually exclusive scheduling modes are available: a simple weekly schedule using weekDay and startHour, or an RFC 5545–based recurrence rule.

Weekly Upgrade Window Sample
...
upgradeStrategy:
  autoUpgradeEnabled: true
  autoUpgradeMaintenance:
    durationHours: 1
    startHour: 12
    weekDay: Tue

This sample contains the following options that you need to specify:

  • autoUpgradeMaintenance: Defines the maintenance window during which automatic upgrade operations are allowed to proceed.

  • durationHours: Duration of the maintenance window, in hours. During this time, upgrades are allowed to proceed.

  • startHour: Start time of the window, in 24-hour format (0–23).

  • weekDay: Day of the week when the window applies. Valid values are: Mon, Tue, Wed, Thu, Fri, Sat, and Sun.

RRULE-Based Recurrence Sample
...
upgradeStrategy:
  autoUpgradeEnabled: true
  autoUpgradeMaintenance:
    durationHours: 1
    rrule: FREQ=DAILY;WKST=TU;BYHOUR=12

This sample contains the following options that you need to specify:

  • autoUpgradeMaintenance: Defines the maintenance window during which automatic upgrade operations are allowed to proceed.

  • durationHours: Duration of the maintenance window, in hours. During this time, upgrades are allowed to proceed.

  • rrule: A recurrence rule (in RFC 5545 format) to define more advanced upgrade windows. For example, FREQ=DAILY;WKST=TU;BYHOUR=12 defines an upgrade window that occurs every day at 12:00, with Tuesday set as the start of the week.

If no maintenance window is specified, nodes may be upgraded at any time.

Maintenance and Downscaling Annotations

Nodes with attached local volumes (e.g., via hostPath) are excluded from maintenance operations to prevent data loss. To allow their removal, you can manually annotate them under the nodeAnnotations section of your manifest.

Node Pool Annotation Sample
...
spec:
  nodeAnnotations:
    cluster-autoscaler.kubernetes.io/safe-to-evict: "true"
    nplc.oks.outscale.com/safe-to-delete: "true"

This sample contains the following annotations that you may need to specify:

  • nplc.oks.outscale.com/safe-to-delete: Bypasses maintenance upgrade limitations. Required when more than one custom volume is defined in the node pool spec (only the root volume is allowed) or when pods with hostPath volumes (not daemonsets/static pods) are present. Can be applied at the node pool level (nodeAnnotations), directly on nodes, or on affected pods.

  • cluster-autoscaler.kubernetes.io/safe-to-evict: Applied to pods with hostPath volumes to allow eviction during upgrades. Has the same effect as setting nplc.oks.outscale.com/safe-to-delete: "true".

GPU Support Manifest

Node pools allow worker nodes to allocate, attach, and use flexible GPUs in OKS clusters. For more information about GPUs, see About Flexible GPUs and Using fGPUs With OKS.

You can configure GPU support under the fgpu section of the node pool manifest.

GPU Manifest Sample
spec:
  fgpu:
    model: "nvidia-p6"
    k8s-operator: true

This sample contains the following parameters that you need to specify:

  • model: The GPU model to allocate.

  • k8s-operator: Whether the official NVIDIA GPU operator in the gpu-operator namespace is installed on the cluster (true | false). Deleting the node pool does not uninstall the operator.

Autoscaling Manifest (Beta)

You can enable autoscaling by adding the following options to your node pool manifest:

This feature is currently in beta. For more information about beta services, see the Glossary and our General Terms and Conditions of Sale.
Autoscaling Manifest Sample
spec:
  minNodes: X
  maxNodes: Y
  autoscaling: true

This sample contains the following parameters that you need to specify:

  • minNodes: The minimum number of nodes the autoscaler is allowed to maintain.

  • maxNodes: The maximum number of nodes the autoscaler can scale up to.

  • autoscaling: Whether the node pool should be managed by the autoscaler. Must be set to true to enable autoscaling.

For more information, see Tutorial: Autoscaling Your Node Pools (Beta).

Related Pages

Export to PDF