Skip to main content

Cluster upgrade

centron automatically installs patches and security updates for control plane and worker nodes. You control when this happens and how extensively the updates are applied automatically.

You can find all the settings in the Settings tab of the cluster.

Prerequisites​

  • Access to the centron Control Panel
  • A Kubernetes cluster with the status Running and a verified connection via kubectl

Automatic patch upgrades​

Under Automatically upgrade minor version patches, you can specify how new patch versions should be handled:

SettingDisplay in Control Panel
EnabledNew minor version patches are installed automatically.
DisabledOnly required updates will be installed automatically.

Regardless of this setting, centron will install any essential updates. The status is also displayed in the Overview tab, under the Version section.

To make changes, click Edit, select the option and confirm by clicking Save.

Tipp

For production clusters, Enabled is recommended. Patch versions contain bug fixes and security updates within the same minor version and do not alter any APIs – the risk of incompatibility is low, whilst the security benefits are immediate.

Upgrade window​

Under Upgrade window, you can specify the time period during which upgrades will be installed. Select the following via Edit:

  • Select Day – A day of the week or Any day
  • Select Time – Start time of the window

From the selected start time, a four-hour window is available. The display will then read something like Any day after 22:00 (GMT+2).

Choose a time when system utilisation is low – such as at night or at the weekend. Even though upgrades on adequately sized pools take place without any downtime, pods are moved between nodes during the process.

Surge Upgrades​

Under Surge upgrades, you can control whether additional nodes are temporarily provisioned during an upgrade:

SettingBehaviour
EnabledBefore old nodes are removed, additional nodes are temporarily provisioned (up to 10).
DisabledNodes are replaced one after the other, without any additional capacity.

With Surge Upgrades enabled, the cluster’s full capacity is maintained throughout the upgrade. Without them, one fewer node is available at times – which can lead to bottlenecks in tightly dimensioned pools.

The upgrade process​

Nodes are updated on a rolling basis, i.e. one after the other:

  1. A node is blocked from hosting new pods.
  2. Its pods are migrated to other nodes.
  3. The node is upgraded or replaced.
  4. The next node is processed.

To ensure there is no downtime, the following are required:

  • At least 2 nodes per node pool

  • Multiple replicas per production application

  • Readiness probes, to ensure that only pods that are ready receive traffic

  • Optionally, a PodDisruptionBudget:

    apiVersion: policy/v1
    kind: PodDisruptionBudget
    metadata:
      name: web-pdb
    spec:
      minAvailable: 2
      selector:
        matchLabels:
          app: web

Change to the minor version​

A change to the minor version – for example, from 1.32 to 1.33 – is a deliberate step and is not carried out automatically. Please check the following beforehand:

  • Whether the API versions used by your manifests are still available in the target version
  • Whether your kubectl version matches the target version (a one-minor-version difference is permitted)
  • Whether operators, Ingress controllers and Helm charts support the target version

You can see the installed version in the header of the cluster details view, next to ‘Project’ and ‘Region’.

Check status​

# Version von Client und Server
kubectl version

# Version je Node
kubectl get nodes

# Laufende Änderungen an Nodes
kubectl get nodes --watch

During an upgrade, nodes may temporarily display the statuses Provisioning or Deleting. You can track the progress for each node pool in the Resources tab.

Last updated on