Kubernetes upgrades

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

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

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

The servers.com customer portal allows you to upgrade patch and minor versions. Each case is considered in more detail below. We strongly recommend performing upgrades in a timely manner to maintain security and ensure access to the latest Kubernetes features.

Upgrade settings

You can set up your upgrade preferences from the customer portal when:

• ordering a Kubernetes cluster in the Upgrade settings block; it will define an allowed time slot for patch version upgrades only
• 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 vary and are located on different tabs.

Minor versions

Before starting a minor version upgrade, make sure that 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 haven't been deleted
• The initial check must have the Passed status

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

Key terms

A minor version upgrade is complex and involves pod-level processes, which is why it's important to introduce the 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 that will occur during the following operations:

• Drain - to evict pods safely from a node before performing maintenance. More in Kubernetes documentation and here.
• Cordon - to mark a node as unschedulable so that new pods can't be created. This operation doesn't affect existing pods. More in Kubernetes documentation.
• Uncordon - to mark a node as schedulable so that new pods can be created. More in Kubernetes documentation.
• Halt - to pause the entire upgrade until manual intervention can be carried out.
• Skip - to continue the upgrade, bypassing one or several nodes.
• Force - to perform the upgrade regardless of circumstances.

A batch is a group of worker nodes that need to be simultaneously upgraded.

Parameters

The Minor versions tab contains the following parameters:

• Status - this status displays actuality of the Kubernetes version:
  • Latest version - a cluster has the newest available version
  • Upgrade available - there is a newer version for upgrade
  • Failed - the last upgrade wasn't completed, and manual actions are most likely needed
  • Upgrading - a cluster is currently being upgraded
• Initial check - this status displays if a cluster is ready for upgrade (if nodes are reachable and there is no deprecated API):
  • Check button - initiates the check process
  • Result - displays check result: Passed, Failed, Not checked
• Current version - Kubernetes version on a cluster
• Target version - a version to be after upgrade
• Upgrade strategy
  • drain_haltupgrade - try kubectl drain for up to 30 minutes; if pods can't 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 can't be evicted, uncordon, skip, and move on with the cluster
  • drain_forceupgrade - try kubectl drain for up to 30 minutes; if pods can't be evicted, stop draining and force the upgrade (pod restart, package update) even if pods remain; pods may also restart
  • forceupgrade - perform package updates and restart kubelet without draining pods
• Batch size - the quantity of worker nodes to be simultaneously upgraded
• Batch delay - time interval before taking a new batch

Getting started

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

• Verification of version compatibility (you'll be informed if there are any issues).
• The cluster being upgraded will be issued Upgrading status and the upgrade will start in the control plane.
• Worker nodes will be upgraded in batches. Each worker node will be issued Upgrading status and will only return to Active status once the process is fully complete.
• Once the last node has been upgraded, the cluster version will be changed 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. To do that, assign the servers.com/upgrade-strategy=skipnode annotation to a node object. For example:

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 this process can't be suspended.
• Downgrade to a lower version is not possible.

Patch versions

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

• The cluster has active status
• The servers.com SSH keys on worker nodes haven't been deleted

The patch version upgrade is performed to the latest available patch version within the current minor version. If you have the 1.32.1 and the latest one 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 on a cluster)
• Target version (the version after the upgrade)
• Automatically upgrade checkbox (once enabled, allows to set Maintenance frequency)
  • Anytime (upgrade can be performed anytime)
  • On selected days (weekdays and time for the upgrade slot)
  • Daily (upgrade can be performed everyday within the selected time)

Getting started

There are two options to start with the patch version upgrade:

• Manual (upgrade starts right away): click Force upgrade
• Automatic (upgrade starts in a specified time slot): click Automatically upgrade → Maintenance frequency → select a necessary option and click Save

The automatic upgrade procedure is as follows:

• You will be notified about the coming upgrade by email.
• When a cluster is being upgraded, it will assume the Upgrading status and will become temporarily unavailable.
• Control plane nodes are upgraded one by one, and worker nodes are upgraded by groups with a maximum of 10 servers per group.

If a Kubernetes upgrade exceeds the maintenance window, it will be paused and the cluster will return to the Active status, becoming available again. The Kubernetes cluster version will remain the same. The upgrade will then resume in the next available time slot, changing to the Upgrading status again. The Kubernetes version will be changed only after the last worker node has been upgraded.

Limitations

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

Suggested Articles