Change Worker Node Pool OS Image Version
Worker Nodes in an M-FKE cluster run on Ubuntu. From this release, you can choose Ubuntu 22.04 or Ubuntu 24.04 when creating a cluster or adding a Worker Group, and change the OS version of a running Worker Group directly on the Portal without recreating it.
This lets you move a workload to an OS version that still receives long-term security patches, or roll back to an older version if your application isn't compatible yet.
Who can do this
| Role | Description |
|---|---|
| Cluster Operator | View the OS version, choose the OS when creating a cluster or Worker Group, and change the OS version of a running Worker Group |
| Other VPC members | Follow the existing Worker Group edit permissions already in place on the Portal |
What you can do
| Capability | Description |
|---|---|
| Choose OS at creation | Select Ubuntu 22.04 or 24.04 for a new Worker Group, from the list valid for the cluster's Kubernetes version |
| Upgrade OS | Change a running Worker Group from Ubuntu 22.04 to 24.04 |
| Downgrade OS | Roll back to Ubuntu 22.04 if needed, with no limit on how many times |
| Change multiple Worker Groups at once | Change the OS version for several Worker Groups on the same screen |
| Auto Patch OS Image | Enable automatic security patches within the same OS version |
The OS versions available depend on the cluster's Kubernetes version:
| Kubernetes version | Supported OS | Default |
|---|---|---|
| Below v1.33 | Ubuntu 22.04 | Ubuntu 22.04 |
| v1.33 to v1.36 | Ubuntu 22.04 or Ubuntu 24.04 | Ubuntu 24.04 |
1. Choose the OS when adding a Worker Group
Step 1: On the Portal, open your Kubernetes cluster, select the Worker Group tab, and click Add Worker Group.
Step 2: Fill in the Worker Group configuration as usual (name, flavor, node count, disk).
Step 3: At the OS image field, the system shows Ubuntu and a Version dropdown. The list only contains versions valid for the cluster's Kubernetes version, with the recommended version pre-selected.
Step 4: Keep the recommended version, or choose a different one from the list.
Step 5: Click Create to create the Worker Group.
The new Worker Group is created with the OS version you chose. This version is shown on the Worker Group detail screen.
2. Change the OS version of a running Worker Group
Before you start, confirm the Worker Group is in Running or Succeeded state and that no other operation (resize, Kubernetes version upgrade) is in progress on it.
Step 1: Open the cluster's Worker Group tab and select the Worker Group you want to change.
Step 2: On the Worker Group detail screen, at the OS image field, open the Version dropdown. Versions not yet compatible with the cluster's Kubernetes version are grayed out and can't be selected.
Step 3: Select the version you want to switch to — a higher version to upgrade, or a lower one to roll back. Selecting a version applies the change directly; there's no separate confirm step.
Step 4: To change several Worker Groups at once, repeat these steps for each Worker Group.
The system then replaces the Worker Group's nodes with the new OS version one at a time. When it finishes, the Version field shows the new version. If the process fails, the Worker Group keeps its previous OS version so you can try again.
3. Enable Auto Patch OS Image
Auto Patch OS Image only applies security patches within the same OS version. It does not change the Worker Group's OS version on its own.
Step 1: Open the Worker Group detail screen.
Step 2: Turn on the Auto Patch OS Image toggle. Hover the info icon next to the field for an explanation.
Step 3: The system shows a banner reminding you that enabling this doesn't change the OS version.
On a cluster running Kubernetes v1.33 or later, Auto Patch OS Image isn't available yet, so the toggle doesn't appear.
UI reference
| Field | Meaning |
|---|---|
| OS image | The Worker Node's operating system. Currently fixed to Ubuntu |
| Version | Dropdown to choose the Ubuntu version. Incompatible versions are disabled |
| Beta label | The feature is in testing and still being refined |
| Auto Patch OS Image | Enables security patches within the same OS version, without changing the version |
Worker Group states
| State | Meaning |
|---|---|
| Running / Succeeded | The Worker Group is stable and its OS version can be changed |
| Updating | The system is replacing nodes one at a time with the new OS version |
| Error | The version change failed. The Worker Group keeps its previous OS version — you can try again |
Troubleshooting
| Situation | What to do |
|---|---|
| The version you want is grayed out in the dropdown | That version isn't compatible with the cluster's Kubernetes version yet. Upgrade the Kubernetes version first, or choose a different OS version |
| The version change failed | The Worker Group keeps its previous OS version. Check available VPC resources, then try again |
| Connection was lost while the OS version is changing | The process keeps running on the system side. Reload the page to see its progress |
| Auto Patch is on but the OS version didn't change | This is expected. Auto Patch only patches within the same version — to change version, select a different one in the Version dropdown |
Recommendations:
- Check your workload's PodDisruptionBudget and replica count before changing the OS version, since nodes are replaced one at a time.
- Try it on a small Worker Group first before applying it to a production one.
- Don't start an OS version change during peak hours.
- Once started, the process runs until it succeeds or fails — it can't be canceled midway.