---
name: containers-host-maintenance
title: Preparing IBM Cloud host maintenance updates security enhancements
description: Learn how to prepare your IBM Cloud workers for host maintenance updates, minimize disruptions, and ensure security enhancements are applied smoothly.
last-updated: 2026-09-28
---

> ## Documentation Index
> The table of contents for this documentation set is at https://cloud.ibm.com/docs/containers?format=markdown
> The index for all IBM Cloud docs is at: https://cloud.ibm.com/docs/llms.txt
> Use these files to discover more information as needed.

# Preparing IBM Cloud host maintenance updates security enhancements
{: #host-maintenance}

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

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
{: #worker-maintenance-list}

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. 
{: shortdesc}

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.

```sh
**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

```
{: screen}


## Actions to take before the maintenance period
{: #worker-maintenance-actions}

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. 
{: shortdesc}

### Workers in Classic clusters 
{: #worker-maintenance-classic}

Follow the steps to reboot the worker before the maintenance period begins.
{: shortdesc}

1. Cordon the worker.


    ```sh
    kubectl cordon <worker_id>
    ```
    {: pre}




2. Drain the worker.



    Example drain command
    ```sh
    kubectl drain <worker_id>
    ```
    {: pre}

    Example drain command for Cloud Pak for Data
    ```sh
    kubectl drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets
    ```
    {: pre}





3. Reboot the worker. Make sure that you include the `--hard` option.
    ```sh
    ibmcloud ks worker reboot --cluster <cluster_name_or_id> --worker <worker_id> --hard
    ```
    {: pre}

4. Mark the worker as available to be scheduled.


    ```sh
    kubectl uncordon <worker_id>
    ```
    {: pre}




### Workers in VPC clusters
{: #worker-maintenance-vpc}

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 ks worker get --worker <worker_id> --cluster <cluster_name_or_id>`.
{: shortdesc}

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

1. Cordon the worker.



    ```sh
    kubectl cordon <worker_id>
    ```
    {: pre}




2. Drain the worker. In some scenarios, such as Cloud Pak for Data, you might need to specify additional drain options.



    Example drain command
    ```sh
    kubectl drain <worker_id>
    ```
    {: pre}

    Example drain command for Cloud Pak for Data
    ```sh
    kubectl drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets
    ```
    {: pre}






3. Replace the worker.
    ```sh
    ibmcloud ks worker replace --cluster <cluster_name_or_id> --worker <worker_id>
    ```
    {: pre}

4. Mark the worker as available to be scheduled.


    ```sh
    kubectl uncordon <worker_id>
    ```
    {: pre}




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.
{: note}

#### Part 1: Prepare the worker for maintenance
{: #bm-part1}

1. 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.

2. Cordon the worker to prevent new workloads from being scheduled on it.



    ```sh
    kubectl cordon <worker_id>
    ```
    {: pre}




3. 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
    ```sh
    kubectl drain <worker_id>
    ```
    {: pre}

    Example drain command for Cloud Pak for Data
    ```sh
    kubectl drain <worker_id> --force --delete-emptydir-data --ignore-daemonsets
    ```
    {: pre}




#### Part 2: Apply maintenance
{: #bm-part2}

4. Reload the worker. The node is reloaded in place on a host that is not undergoing maintenance and retains its IP address.

    ```sh
    ibmcloud ks worker reload --cluster <cluster_name_or_id> --worker <worker_id>
    ```
    {: pre}

    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.

    ```sh
    ibmcloud ks worker replace --cluster <cluster_name_or_id> --worker <worker_id>
    ```
    {: pre}