---
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-08-12
---

> ## 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 workers with the `cx2.`, `bx2.`, or `mx2.` flavors:

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 workers with the `cx2d.`, `bx2d.`, or `mx2d.` flavors:

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. A new worker node is provisioned on a host that is not undergoing maintenance.

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