Upgrade Methods and Strategies

Introduction to Upgrading Clusters

When new versions of OpenShift Container Platform are released, you can upgrade your existing
cluster to apply the latest enhancements and bug fixes.
This includes upgrading from previous minor versions, such as release 3.7 to
3.9, and applying asynchronous errata updates within a minor version (3.9.z
releases). See the OpenShift Container Platform 3.10 Release Notes to review the latest changes.

Due to the core architectural changes
between the major versions, OpenShift Enterprise 2 environments cannot be
upgraded to OpenShift Container Platform 3 and require a fresh installation.

The OpenShift Container Platform upgrade process uses Ansible playbooks to automate the tasks
needed to upgrade your cluster. You must use the
inventory file
that you used during initial installation or during the last time that the
upgrade was successful to run the upgrade playbook. Using this method allows you
to choose between either upgrade strategy: in-place upgrades or blue-green
deployments.

Unless noted otherwise, node and masters within a major version are forward and
backward compatible
across one minor version,
so upgrading your cluster should go smoothly. However, you should not run
mismatched versions longer than necessary to upgrade the entire cluster.

Before upgrading, ensure that all OpenShift Container Platform services are running well. In
the event of a control plane upgrade failure, check the versions of your masters
to ensure that all versions are the same. If your masters are all the same
version, re-run the upgrade. If they differ, downgrade the masters to match the
lower versioned master, then re-run the upgrade.

Upgrade Strategies

There are two strategies you can take for performing the OpenShift Container Platform cluster
upgrade: in-place upgrades or blue-green deployments.

In-place Upgrades

With in-place upgrades, the cluster upgrade is performed on all hosts in a
single, running cluster: first masters and then nodes. Pods are evacuated off of
nodes and recreated on other running nodes before a node upgrade begins; this
helps reduce downtime of user applications.

Blue-green Deployments

The
blue-green deployment upgrade method follows a similar flow to the in-place method:
masters and etcd servers are still upgraded first, however a parallel
environment is created for new nodes instead of upgrading them in-place.

This method allows administrators to switch traffic from the old set of nodes
(e.g., the "blue" deployment) to the new set (e.g., the "green" deployment)
after the new deployment has been verified. If a problem is detected, it is also
then easy to rollback to the old deployment quickly.