Skip to content

Preparing to update from OpenShift Container Platform 4.18 to a newer version

Before you update from OpenShift Container Platform 4.18 to a newer version, learn about some of the specific concerns around Red Hat Enterprise Linux (RHEL) compute machines.

Migrating workloads off of package-based RHEL worker nodes

With the introduction of OpenShift Container Platform 4.19, package-based RHEL worker nodes are no longer supported. If you try to update your cluster while those nodes are up and running, the update will fail.

You can reschedule pods running on RHEL compute nodes to run on your RHCOS nodes instead by using node selectors.

For example, the following Node object has a label for its operating system information, in this case RHCOS:

Sample Node object with RHCOS label
kind: Node
apiVersion: v1
metadata:
  name: ip-10-0-131-14.ec2.internal
  selfLink: /api/v1/nodes/ip-10-0-131-14.ec2.internal
  uid: 7bc2580a-8b8e-11e9-8e01-021ab4174c74
  resourceVersion: '478704'
  creationTimestamp: '2019-06-10T14:46:08Z'
  labels:
    kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/zone: us-east-1a
    node.openshift.io/os_version: '4.19'
    node-role.kubernetes.io/worker: ''
    failure-domain.beta.kubernetes.io/region: us-east-1
    node.openshift.io/os_id: rhcos 
    beta.kubernetes.io/instance-type: m4.large
    kubernetes.io/hostname: ip-10-0-131-14
    beta.kubernetes.io/arch: amd64
#...
  1. The label identifying the operating system that runs on the node, to match the pod node selector.

Any pods that you want to schedule to new RHCOS nodes must contain a matching label in its nodeSelector field. The following procedure describes how to add the label.

Procedure

  1. Deschedule the RHEL node currently running your existing pods by entering the following command:

    $ oc adm cordon <rhel-node>

  2. Add an rhcos node selector to a pod:

    • To add the node selector to existing and future pods, add the node selector to the controller object for the pods by entering the following command:

      Example Deployment object with rhcos label
      $ oc patch dc <my-app> -p '{"spec":{"template":{"spec":{"nodeSelector":{"node.openshift.io/os_id":"rhcos"}}}}}'

      Any existing pods under your Deployment controlling object will be re-created on your RHCOS nodes.

    • To add the node selector to a specific, new pod, add the selector to the Pod object directly:

      Example Pod object with rhcos label
      apiVersion: v1
kind: Pod
metadata:
  name: <my-app>
#...
spec:
  nodeSelector:
    node.openshift.io/os_id: rhcos
#...

      The new pod will be created on RHCOS nodes, assuming the pod also has a controlling object.

Identifying and removing RHEL worker nodes

With the introduction of OpenShift Container Platform 4.19, package-based RHEL worker nodes are no longer supported. The following procedure describes how to identify RHEL nodes for cluster removal on bare-metal installations. You must complete the following steps to successfully update your cluster.

Procedure

  1. Identify nodes in your cluster that are running RHEL by entering the following command:

    $ oc get -l node.openshift.io/os_id=rhel
    Example output
    NAME                        STATUS    ROLES     AGE       VERSION
rhel-node1.example.com      Ready     worker    7h        v1.33.4
rhel-node2.example.com      Ready     worker    7h        v1.33.4
rhel-node3.example.com      Ready     worker    7h        v1.33.4

  2. Continue with the node removal process. RHEL nodes are not managed by the Machine API and have no compute machine sets associated with them. You must unschedule and drain the node before you manually delete it from the cluster.

    For more information on this process, see How to remove a worker node from Red Hat OpenShift Container Platform 4 UPI.

Provisioning new RHCOS worker nodes

If you need additional compute nodes for your workloads, you can provision new ones either before or after you update your cluster. For more information, see the following machine management documentation:

For installer-provisioned infrastructure installations, automatic scaling adds RHCOS nodes by default. For user-provisioned infrastructure installations on bare metal platforms, you can manually add RHCOS compute nodes to your cluster.