Preparing IBM Cloud host maintenance updates security enhancements

Learn how to prepare your IBM Cloud workers for host maintenance updates, minimize disruptions, and ensure security enhancements are applied smoothly.

IBM engineers perform host maintenance to improve stability, provide security enhancements, and support upcoming new features. IBM Cloud infrastructure providers perform maintenance on the hosts that house the Virtual Servers that are used as workers in your cluster, which might cause some of your workers to briefly go offline. However, there are actions you can take before the maintenance period that can minimize disruptions to your worker nodes. A notification with maintenance details and a list of affected workers is sent to customers before the maintenance window. Follow these steps to prepare your workers for an upcoming maintenance period.

Identifying your affected workers

If your workers are scheduled to undergo maintenance, you receive a notification before the maintenance window begins. A list of the workers that are affected is included in the notification.

The list of impacted components might look similar to the following example. The steps documented here apply to the workers listed in the IBM Kubernetes Service or Red Hat OpenShift on IBM Cloud Workers section.

**Virtual Server Instances scheduled for maintenance**

    Virtual Server Instances in your account:

           ID                                           Name
           1111_1a111aaa-1a1a-1aa1-1111-a11a111a1111    my_vpc_cluster_1

    Virtual Server Instances in service accounts:

        Application Load Balancer
            alb-11aa111a-1111111
    
        IBM Kubernetes Service or Red Hat OpenShift on IBM Cloud workers
            kube-aaaa1aaa111aa11aa11a-aaaaaaaaaaa-aaaaaaa-00001a11
            kube-aaaa2aaa222aa22aa22a-aaaaaaaaaaa-aaaaaaa-00002a22
            kube-aaaa3aaa333aa33aa33a-aaaaaaaaaaa-aaaaaaa-00003a33

Actions to take before the maintenance period

Follow these steps to prepare your workers for the maintenance period. Workers can't be scheduled on hosts that are scheduled for maintenance. You can avoid disruptions to your workload by rebooting or replacing your workers so that they move to different hosts that are not undergoing maintenance.

Workers in Classic clusters

Follow the steps to reboot the worker before the maintenance period begins.

Cordon the worker.
```
oc adm cordon <worker_id>
```

Drain the worker.

Example drain command

oc adm drain <worker_id>

Example drain command for Cloud Pak for Data

oc adm drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets

Reboot the worker. Make sure that you include the --hard option.

ibmcloud oc worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard

Mark the worker as available to be scheduled.
```
oc adm uncordon <worker_id>
```

Workers in VPC clusters

For workers in VPC clusters, the steps to take depend on the flavor of the worker node. To check a worker node's flavor, run ibmcloud oc worker get --worker <worker_id> --cluster <cluster_name_or_id>.

For VPC virtual server instance (VSI) workers (workers without local storage):

Cordon the worker.
```
oc adm cordon <worker_id>
```
Drain the worker. In some scenarios, such as Cloud Pak for Data, you might need to specify additional drain options.

Example drain command
```
oc adm drain <worker_id>
```
Example drain command for Cloud Pak for Data
```
oc adm drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets
```

Replace the worker.

ibmcloud oc worker replace --cluster <cluster_name_or_id> --worker <worker_id>

Mark the worker as available to be scheduled.
```
oc adm uncordon <worker_id>
```

For VPC bare metal workers:

VPC bare metal workers support the worker reload command, which reloads the node in place without provisioning a new worker node. The node retains its IP address and other identifiers. If a firmware update is pending, it is applied automatically as part of the reload and can add 30 minutes or more to the total reload time. If your bare metal worker has local storage, back up any data that is not stored on persistent storage before you begin, as data on local disks is lost during a reload.

Part 1: Prepare the worker for maintenance

If your worker has local storage, back up any data that you want to preserve before you proceed. Data on local disks is lost during a reload.
Cordon the worker to prevent new workloads from being scheduled on it.
```
oc adm cordon <worker_id>
```
Drain the worker to evict existing workloads. In some scenarios, such as Cloud Pak for Data, you might need to specify additional drain options.

Example drain command
```
oc adm drain <worker_id>
```
Example drain command for Cloud Pak for Data
```
oc adm drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets
```

Part 2: Apply maintenance

Reload the worker. The node is reloaded in place on a host that is not undergoing maintenance and retains its IP address.
```
ibmcloud oc worker reload --cluster <cluster_name_or_id> --worker <worker_id>
```
Alternatively, you can replace the worker instead of reloading it. Replacing the worker deletes the existing node and provisions a new one with a new IP address.
```
ibmcloud oc worker replace --cluster <cluster_name_or_id> --worker <worker_id>
```