Description
This control checks that Utho Kubernetes clusters are kept current on Kubernetes minor and patch versions so that known vulnerabilities in the control plane, kubelet, and container runtime are closed promptly.
Utho does not provide an automatic-upgrade toggle or an in-place minor-version upgrade action. Its built-in lever is recycling a node pool, which replaces the pool's nodes with new ones running the most recent patch of the cluster's current Kubernetes version. Recycling is also the documented path used when moving between minor versions and when debugging a node. Because there is no automation, the control is satisfied by an owned, recurring recycle/upgrade schedule rather than by a platform setting.
It passes when the cluster runs a currently-supported release and a documented recurring recycle/upgrade process exists; it fails when the cluster lags on an unsupported version with no upgrade cadence.
Clusters running an old or end-of-life Kubernetes minor version.
Node pools whose kubelet patch level lags the cluster's current version.
Absence of any recurring recycle/upgrade schedule or change ticket.
Rationale
A cluster left on an old Kubernetes minor or patch version keeps known, publicly documented CVEs in the API server, kubelet, and container runtime open for exploitation. Once a version falls out of upstream support it stops receiving security patches entirely, so exposure only grows over time.
Because Utho has no auto-upgrade, staying current is an operational discipline: recycle node pools as patches ship, and plan blue-green migrations for new minor versions. A staging cluster catches breaking API changes before they reach production, which is what makes a regular upgrade cadence safe to run.
Closes known CVEs in api-server, kubelet, and runtime as fixes are released.
Keeps the cluster on a supported release that still receives patches.
Aligns kubelet versions with the control plane, avoiding skew-policy breakage.
Impact
Pros:
Known vulnerabilities are patched on a predictable cadence.
The cluster stays on a supported, patch-receiving release.
Regular recycles also refresh nodes, clearing drift and transient node issues.
Cons:
No automation: someone must own the schedule and run recycles/migrations.
Recycling reschedules pods, so workloads need PodDisruptionBudgets to avoid disruption.
Minor-version moves may need a blue-green cluster migration and staging validation, which is effort.
Default Value
Utho has no automatic-upgrade option; a cluster stays on the version selected at creation, and patching happens only when you manually recycle a node pool (which moves it to the newest patch of the current version).
Pre-Requisite
Utho console access to the cluster's manage page (or API) to read the current version.
kubectl access to confirm control-plane and node versions.
A staging cluster for validating minor-version changes.
A change/ownership process to schedule recurring recycles and migrations.
Remediation
Test Plan
Using the Utho Console:
In the Utho console open Kubernetes and click Manage on the cluster.
Read the current Kubernetes/Cluster Version shown on the manage page.
Run 'kubectl version' and 'kubectl get nodes -o wide' to confirm the control-plane and kubelet versions.
Check for a documented recurring recycle/upgrade schedule or recent change ticket covering patch cadence.
Pass: the cluster runs a currently-supported release and a recurring recycle/upgrade process is documented.
Fail: the cluster is on an old/unsupported version, or node kubelet versions lag with no upgrade cadence in place.
Using the Utho API:
Read the cluster's current version from the Utho API; version currency is then judged against the supported-release list.
curl -s -H 'Authorization: Bearer $UTHO_API_TOKEN' https://api.utho.com/v2/kubernetes/<cluster_id>
Pass if the returned cluster version is a currently-supported Kubernetes release; Fail if it is an old/unsupported minor version. (The API cannot report whether auto-upgrade is on because Utho has no such feature; the recycle cadence is evidenced out of band.)
Implementation Steps
Using the Utho Console:
In the Utho console open Kubernetes, click Manage on the cluster, and scroll to Manage Node Worker Pools.
Recycle each node pool to replace its nodes with ones on the most recent patch of the cluster's current version, and record this as a recurring scheduled task as patches ship.
For a new minor version (which recycle does not move you to), validate on a staging cluster first, then plan a blue-green migration: stand up a new cluster on the target version and shift workloads across.
When moving versions, bring the control plane / new cluster up first, then recycle or replace node pools so kubelet versions align with the control plane.
After upgrading, confirm 'kubectl version' and node versions report the intended release.
Using the Utho API:
Utho has no upgrade/auto-upgrade API; patching is driven by the console recycle action (and blue-green migration for minor versions). The API can create the replacement cluster/pools used in a blue-green move.
curl -s -X POST -H 'Authorization: Bearer $UTHO_API_TOKEN' -H 'Content-Type: application/json' https://api.utho.com/v2/kubernetes/deploy -d '{"dcslug":"<datacenter>","cluster_label":"prod-vNEXT","cluster_version":"<target_version>","nodepools":[{"label":"pool-1","size":"<size_id>","count":"2"}],"vpc":"<vpc_id>","subnetRequired":true,"network_type":"private"}'
Backout Plan:
Perform version changes in staging first; keep the previous cluster (blue) running until the new one (green) is validated so you can shift traffic back.
If a recycle destabilizes a pool, roll workloads back to the retained previous pool/cluster and investigate before retrying.
Because recycling and minor upgrades are one-way, treat the retained old cluster as the rollback target rather than attempting an in-place downgrade.