Upgrades

The Kubernetes version follows the pattern A.B.C, where:

• A is a major version
• B is a minor version
• C is a patch version

For example, version 1.33.7 has major version 1, minor version 33, and patch version 7.

The Servers.com Customer Portal allows you to upgrade both patch and minor versions. We strongly recommend performing upgrades in a timely manner to maintain security and ensure access to the latest Kubernetes features.

Upgrade settings

You can configure your upgrade preferences from the Customer Portal when:

• Ordering a Kubernetes cluster — in the Upgrade settings block (defines the allowed time slot for patch version upgrades only).
• After a cluster is created — on its Details page → Version field → Upgrade button → Upgrade settings → Minor versions or Patch versions tab.

Settings for minor and patch versions are located on separate tabs.

Minor versions

Before starting a minor version upgrade, make sure your cluster meets the following requirements:

• The cluster has Active status
• There are no pending nodes (in cart, ordered, or being created)
• The current Kubernetes version is 1.28 or higher
• The Servers.com SSH keys on worker nodes have not been deleted
• The initial check has Passed status

The version upgrade notes walk you through breaking changes and key considerations for each Kubernetes minor version upgrade.

It is only possible to upgrade to one minor version higher than your current version. For example, if you have version 1.32, you can only upgrade to 1.33.

Key terms

A minor version upgrade involves pod-level processes, so it's important to understand the following key terms before configuring any settings.

An upgrade strategy is a set of conditions and rules applied during the upgrade process. A strategy primarily defines the behavior during the following operations:

• Drain — evict pods safely from a node before performing maintenance. See Kubernetes documentation and kubectl drain.
• Cordon — mark a node as unschedulable so that new pods cannot be created. Does not affect existing pods. See Kubernetes documentation.
• Uncordon — mark a node as schedulable so that new pods can be created. See Kubernetes documentation.
• Halt — pause the entire upgrade until manual intervention is carried out.
• Skip — continue the upgrade, bypassing one or several nodes.
• Force — perform the upgrade regardless of circumstances.

A batch is a group of worker nodes that are simultaneously upgraded.

Parameters

The Minor versions tab contains the following parameters:

• Status — displays the actuality of the Kubernetes version:
  • Latest version — the cluster has the newest available version
  • Upgrade available — a newer version is available for upgrade
  • Failed — the last upgrade was not completed; manual action is likely needed
  • Upgrading — the cluster is currently being upgraded
• Initial check — displays whether the cluster is ready for upgrade (nodes are reachable and no deprecated APIs are in use):
  • Check button — initiates the check process
  • Result — displays the check result: Passed, Failed, or Not checked
• Current version — Kubernetes version currently running on the cluster
• Target version — the version the cluster will be on after the upgrade
• Upgrade strategy:
  • drain_haltupgrade — try kubectl drain for up to 30 minutes; if pods cannot be evicted, keep the node cordoned and pause the entire upgrade until manual intervention
  • drain_skipnode — try kubectl drain for up to 30 minutes; if pods cannot be evicted, uncordon, skip, and continue with the cluster upgrade
  • drain_forceupgrade — try kubectl drain for up to 30 minutes; if pods cannot be evicted, stop draining and force the upgrade (pod restart, package update) even if pods remain
  • forceupgrade — perform package updates and restart kubelet without draining pods
• Batch size — the number of worker nodes to be simultaneously upgraded
• Batch delay — the time interval before taking a new batch

Getting started

To begin the upgrade using your specified settings, click the Upgrade button on the Upgrade Settings page under the Minor Versions tab. The process follows these steps:

1. Verification of version compatibility (you will be informed if there are any issues).
2. The cluster receives Upgrading status and the upgrade starts on the control plane.
3. Worker nodes are upgraded in batches. Each node receives Upgrading status and returns to Active only once the process is fully complete.
4. Once the last node has been upgraded, the cluster version is updated to the new one.

Skip node via annotation

You can use a cluster-side annotation to specify whether a worker node should be skipped during the upgrade. Assign the servers.com/upgrade-strategy=skipnode annotation to the node object:

apiVersion: v1
kind: Node
metadata:
  name: worker-node-01
  annotations:
    servers.com/upgrade-strategy: skipnode

Limitations

• A cluster is non-operational during the upgrade process and the process cannot be suspended.
• Downgrade to a lower version is not possible.

Patch versions

Before starting a patch version upgrade, make sure your cluster meets the following requirements:

• The cluster has Active status
• The Servers.com SSH keys on worker nodes have not been deleted

The patch version upgrade always targets the latest available patch within the current minor version. For example, if you have 1.32.1 and the latest is 1.32.7, you will get 1.32.7 after a single upgrade operation.

Parameters

The Patch versions tab contains the following parameters:

• Current version — Kubernetes version currently running on the cluster
• Target version — the version the cluster will be on after the upgrade
• Automatically upgrade checkbox — once enabled, allows setting a Maintenance frequency:
  • Anytime — upgrade can be performed at any time
  • On selected days — select specific weekdays and a time slot
  • Daily — upgrade can be performed every day within the selected time window

Getting started

There are two options to start a patch version upgrade:

• Manual (starts immediately) — click Force upgrade
• Automatic (starts at a specified time slot) — enable Automatically upgrade → set Maintenance frequency → click Save

The automatic upgrade procedure is as follows:

1. You will be notified about the upcoming upgrade by email.
2. When the upgrade begins, the cluster assumes Upgrading status and becomes temporarily unavailable.
3. Control plane nodes are upgraded one by one; worker nodes are upgraded in groups of up to 10 servers per group.

If the upgrade exceeds the maintenance window, it will be paused and the cluster will return to Active status. The Kubernetes version will remain unchanged. The upgrade resumes in the next available time slot and the version is updated only after the last worker node has been upgraded.

Limitations

• A cluster is non-operational during the upgrade process and the process cannot be suspended.
• Downgrade to a lower version is not possible.