We are excited to announce Virtual Node Cycling for Oracle Cloud Infrastructure Kubernetes Engine (OKE) Virtual Nodes. Virtual Node Cycling helps customers keep existing Virtual Nodes aligned with the latest Virtual Node Pool configuration, without manually replacing nodes one at a time.
Kubernetes environments change constantly. Security requirements evolve, platform versions advance, and workload placement needs shift over time. Virtual Node Pools make it easy to define how Virtual Nodes should be configured, including labels, taints, pod configuration, networking, and metadata.
However, updates to a Virtual Node Pool typically apply to newly created Virtual Nodes. Existing Virtual Nodes can continue running with older settings. Over time, this can create configuration drift within the same pool: some Virtual Nodes reflect the latest desired state, while others continue using older configuration.
Virtual Node Cycling closes that gap.
What is Virtual Node Cycling?
Virtual Node Cycling automates the process of refreshing outdated Virtual Nodes in a Virtual Node Pool.
When cycling is triggered, OKE identifies Virtual Nodes that no longer match the current pool configuration, creates replacement Virtual Nodes with the updated settings, and removes the stale ones. This helps bring running infrastructure back in line with the desired pool configuration with less manual effort.
Customers can control rollout pace with maximumSurge and maximumUnavailable, specified as integers or percentages. If cycling stops before completion, customers can trigger it again. OKE skips nodes that are already up to date and continues replacing only the remaining stale nodes.
The result is a more consistent Virtual Node environment, reduced configuration drift, and a simpler path for adopting pool-level updates.
How to use Virtual Node cycling ?
Virtual Node Cycling follows a simple two-step pattern:
- Update the Virtual Node Pool with the configuration you want new Virtual Nodes to inherit.
- Trigger a separate cycling request to replace older Virtual Nodes with new ones that use the latest configuration.
This keeps the pool’s desired state and running state aligned without requiring a manual node-by-node refresh.
Step 1: Update the Virtual Node Pool
First, update the Virtual Node Pool properties you want to roll out. For example, update labels, taints, pod configuration, networking, or metadata.
oci ce virtual-node-pool update \
–virtual-node-pool-id ocid1.virtualnodepool.oc1..xxx \
–display-name pool1 \
–initial-virtual-node-labels ‘[{“key”:”name”,”value”:”pool1″}]’
Step 2: Trigger Virtual Node Cycling
Next, send a separate update request with Virtual Node Pool cycling details enabled.
oci ce virtual-node-pool update \
–virtual-node-pool-id ocid1.virtualnodepool.oc1..xxx \
–virtual-node-pool-cycling-details file://virtual-node-pool-cycling-details.json
Example virtual-node-pool-cycling-details.json file:
{
“isVirtualNodeCyclingEnabled”: true,
“maximumSurge”: “1”,
“maximumUnavailable”: “0”
}
MaximumSurge and maximumUnavailable are optional. If omitted, the default behavior is:
maximumSurge: 1
maximumUnavailable: 0
If isVirtualNodeCyclingEnabled is set to false, the request is treated as a standard Virtual Node Pool update.
Step 3: Monitor the Work Request
For Virtual Node Pool updates that require Virtual Node replacement, OKE creates a separate work request with the operation type VIRTUALNODEPOOL_CYCLING.
Example response:
oci ce work-request get –work-request-id ocid1.clustersworkrequest.oc1.eu-frankfurt-1.xxxx {
“data”: {
“compartment-id”: “ocid1.compartment.oc1..xxx”,
“id”: “ocid1.clustersworkrequest.oc1.eu-frankfurt-1.xxx”,
“operation-type”: “VIRTUALNODEPOOL_CYCLING”,
“resources”: [
{
“action-type”: “UPDATING”,
“entity-type”: “virtualnodepool”,
“entity-uri”: null,
“identifier”: “ocid1.virtualnodepooldev.oc1.eu-frankfurt-1.xxx”
},
{
“action-type”: “RELATED”,
“entity-type”: “cluster”,
“entity-uri”: null,
“identifier”: “ocid1.clusterdev.oc1.eu-frankfurt-1.xxx”
}
],
“status”: “IN_PROGRESS”,
“time-accepted”: “2026-06-18T08:25:46+00:00”,
“time-finished”: “null”,
“time-started”: “2026-06-18T08:26:00+00:00”
}
}
Monitor the work request until it succeeds:
oci ce work-request get \
–work-request-id ocid1.clustersworkrequest.oc1.eu-frankfurt-1.xxx
The cycling work request tracks replacement progress and is marked complete after all stale Virtual Nodes have been replaced with Virtual Nodes using the latest configuration.
Conclusion
Virtual Node Cycling provides a simpler and safer way to keep Virtual Node infrastructure up to date. Instead of manually replacing outdated Virtual Nodes, customers can update the Virtual Node Pool configuration, trigger cycling, and let the platform refresh stale nodes in a controlled way.
This reduces operational effort, improves consistency, and helps teams keep running infrastructure aligned with their desired configuration as Kubernetes environments continue to evolve.
Useful links: