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
    filesystem: ext4
    snapshot: snap-87654321
  upgradeStrategy:
    maxUnavailable: 1
    maxSurge: 0
    autoUpgradeEnabled: true
    autoUpgradeMaintenance:
      durationHours: 1
      startHour: 12
      weekDay: Tue
  autoHealing: true

Volumes Manifest

You can specify custom values for the root volume and add non-root volumes to each VM managed by the node pool. You can also specify the filesystem to create and mount on each volume.

If the volume configuration is valid, the volumes are created with each VM managed by the node pool. Unless the raw filesystem value is used, the specified filesystem is created on each volume and the volume is mounted on the worker node. If the configuration is invalid, an error occurs and no VM is 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 using the ext4 filesystem 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"
    filesystem: ext4
    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: /
    filesystem: ext4
    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 device associated with 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. Set this parameter to root for the root volume. If not specified, the device name 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) filesystem: The filesystem to create and mount on the volume. Valid values are ext2, ext3, ext4, xfs, btrfs, and raw. The default value is ext4. If set to raw, no filesystem is created and the device is not mounted. When using a snapshot, the specified filesystem must match the filesystem of the snapshot.

  • (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 zones for your worker nodes to ensure higher availability, under the zones section of the node pool manifest.

When multiple zones are specified, the desiredNodes parameter defines the number of worker nodes created in each zone. The total number of worker nodes is therefore equal to the value of desiredNodes multiplied by the number of specified zones.

In the following example, with three zones and desiredNodes set to 3, a total of nine worker nodes are created, that is three in each zone.

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

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