Version Support Policy

The Kubernetes service is provided on a managed basis, which means the software needs to stay up to date. Once a Kubernetes version is no longer supported, service reliability can no longer be guaranteed. This policy is intended to explain and set clear timelines for a Kubernetes minor version lifecycle.

Key Terms

A managed Kubernetes cluster is one where the control plane is supported, maintained, and monitored, and automation is provided by Servers.com. You manage only worker nodes.

A self-managed Kubernetes cluster is one where you support and maintain both the control plane and worker nodes, without Servers.com automation or monitoring.

A supported version is a minor version within its active support window that receives regular patch releases. Kubernetes supports only the three most recent minor versions.

A maintenance period version is a minor version that has passed its standard support period but hasn't reached end-of-life yet. This gives you time to upgrade, and only critical security fixes may still be released.

An end-of-life (EOL) version is a minor version for which all support and maintenance has expired. It no longer receives patch releases, security updates, or bug fixes. You can find the full list of EOL versions in the Kubernetes documentation.

An automatic forced upgrade is an upgrade performed automatically if you didn't upgrade your cluster in time.

A forced upgrade date is the day when an automatic forced upgrade will be performed.

Conversion to self-managed is the process when your cluster moves from a managed to a self-managed service.

Overview

Servers.com follows Kubernetes version releases and monitors clusters so that they are upgraded in time. Once a version reaches end-of-life, it's no longer available for creating new clusters and existing clusters must undergo an upgrade.

You'll receive notifications about upcoming events and are expected to upgrade your cluster within the maintenance period. If a version isn't upgraded in time, the upgrade will be performed automatically. Clusters that can't be safely upgraded will be converted to self-managed. All events are preceded by advance notifications.

The best outcome is when you upgrade your clusters yourself, without waiting for an automatic upgrade.

Lifecycle

The version support policy runs automatically and includes the following stages:

• Notification when a maintenance period starts
• Notification when a maintenance period ends
• Notifications about an upcoming automatic forced upgrade (30 days and 3 days before the date)
• Automatic forced upgrade
• Notification about conversion to self-managed
• Conversion to self-managed

Lifespan timeline (counting from the version release):

• Supported version: 0–12 months
• Maintenance period: 12–14 months
• End-of-life: 14+ months
• Forced upgrade: 16 months
• Conversion to self-managed: 18 months

Automatic Forced Upgrade

If your cluster wasn't upgraded to a newer version before the deadline, a minor version upgrade will be performed automatically. To make this process as smooth and safe as possible, two checks are in place:

• Upgrade possibility check — the system verifies that the version jump is valid and that there are no deprecated APIs. If any issues are found, the upgrade won't proceed.
• Safe upgrade strategy — the upgrade runs in the safest way possible:
  • Pods are drained where possible, but can restart if eviction isn't available.
  • Skipnode annotations are respected.
  • The upgrade pauses if your intervention is needed.

The maintenance window guarantees the start time, not the completion time.

The forced upgrade runs in the time slot you set in Upgrade settings. It continues until a safe stopping point, even if that goes beyond the allowed window. If it doesn't finish, it will resume in the next allowed time slot. If no slot is set, upgrade times for all clusters on your account will be spread across the day.

Some upgrades require several version jumps (for example: 1.30 → 1.31 → 1.32 → 1.33 → 1.34):

• After each upgrade, the system checks whether the forced upgrade date for the new version has already passed.
• If it has, the next upgrade starts immediately.
• If not, the next upgrade will be scheduled for later.

Conversion to Self-Managed

This happens when an automatic forced upgrade wasn't completed in time or can't be performed. This enforcement is mostly applied to legacy versions that can't be safely upgraded. Conversion to self-managed does not cause any downtime — your existing nodes and workloads are preserved.

Here's what changes for you:

• Your cluster nodes become regular cloud and dedicated servers.
• Billing switches from Managed Kubernetes to regular cloud and dedicated servers.
• You receive SSH keys for the control plane and worker nodes, plus an admin kubeconfig.
• Automatic node creation/removal, automatic upgrades, and automatic cloud controller manager/ingress controller management are all disabled. Existing ones will keep working, and Load Balancers will remain.

Versions 1.19 and 1.24 are not compatible with the upgrade mechanism, so clusters on these versions are converted to self-managed by default, without a forced upgrade attempt.

Limitations

• Automatic forced upgrades are not possible if your cluster has deprecated APIs or incompatible versions.
• Conversion to self-managed is irreversible. Once completed, the only way to have a managed cluster again is to order a new one.

Changelog

Refer to Kubernetes releases to see the changelog between versions.