Chapter 4. Update


You update OpenShift sandboxed containers by updating the OpenShift Container Platform cluster and the OpenShift sandboxed containers Operator.

Then, you update the pod virtual machine (VM) image by deleting and re-creating KataConfig custom resource (CR). Updating the OpenShift sandboxed containers Operator when enablePeerpods: true is set in the KataConfig CR does not update the pod VM image automatically.

You must perform the following steps:

  1. Update your OpenShift Container Platform cluster to update the Kata runtime and its dependencies.

    The RHCOS extension sandboxed containers contains the required components to run OpenShift sandboxed containers, such as the Kata containers runtime, the hypervisor QEMU, and other dependencies. You update the extension by updating the cluster to a new release of OpenShift Container Platform.

  2. Update the OpenShift sandboxed containers Operator.
  3. Delete the KataConfig CR.
  4. Verify that the image ID in the peer pods config map is empty.
  5. Re-create the KataConfig CR.

You can update the OpenShift sandboxed containers Operator by using the command line interface (CLI).

Procedure

  1. Create an osc-subscription.yaml manifest file:

    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: sandboxed-containers-operator
      namespace: openshift-sandboxed-containers-operator
    spec:
      channel: stable
      installPlanApproval: Automatic
      name: sandboxed-containers-operator
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      startingCSV: sandboxed-containers-operator.v1.12.0
  2. Create the subscription by running the following command:

    $ oc create -f osc-subscription.yaml
  3. Verify that the Operator is correctly installed by running the following command:

    $ oc get csv -n openshift-sandboxed-containers-operator

    This command can take several minutes to complete.

  4. Watch the process by running the following command:

    $ watch oc get csv -n openshift-sandboxed-containers-operator

    Example output

    NAME                             DISPLAY                                  VERSION   REPLACES    PHASE
    openshift-sandboxed-containers   openshift-sandboxed-containers-operator  1.12.0    1.11.1      Succeeded

4.2. Deleting the KataConfig custom resource

You must delete the KataConfig custom resource (CR).

Deleting the KataConfig CR automatically reboots the worker nodes. Reboot can take from 10 to 60 minutes. The following factors can affect the reboot time:

  • A larger OpenShift Container Platform deployment with a greater number of worker nodes.
  • Activation of the BIOS and Diagnostics utility.
  • Deployment on a hard drive rather than an SSD.
  • Deployment on physical nodes such as bare metal, rather than on virtual nodes.
  • A slow CPU and network.

Prerequisites

  • You have deleted all pods that use the kata-remote runtime class.

Procedure

  1. Delete the KataConfig CR by running the following command:

    $ oc delete kataconfig example-kataconfig

    The OpenShift sandboxed containers Operator removes all resources that were initially created to enable the runtime on your cluster.

    Important

    When you delete the KataConfig CR, the CLI stops responding until all worker nodes reboot. You must wait for the deletion process to complete before performing the verification.

  2. Verify the CR removal by running the following command:

    $ oc get kataconfig example-kataconfig

    Example output

    No example-kataconfig instances exist

4.3. Verifying empty peer pod image ID

You must verify that the image ID in the peer pods config map is empty.

Procedure

  1. Obtain the value of the PODVM_AMI_ID in the peer pods config map by running the following command:

    $ oc get configmap -n openshift-sandboxed-containers-operator peer-pods-cm -o jsonpath="{.data.PODVM_AMI_ID}"
  2. If the value is not empty, update the value and patch the config map by running the following command:

    $ oc patch configmap peer-pods-cm -n openshift-sandboxed-containers-operator -p '{"data":{"PODVM_AMI_ID":""}}'

4.4. Create the KataConfig custom resource

You must create the KataConfig custom resource (CR) to install kata-remote as a runtime class on your worker nodes.

Prerequisites

  • Creating the KataConfig CR automatically reboots the worker nodes. The reboot can take from 10 to more than 60 minutes depending on your deployment size, hardware type, and other factors.

Procedure

  1. Create an example-kataconfig.yaml manifest file according to the following example:

    apiVersion: kataconfiguration.openshift.io/v1
    kind: KataConfig
    metadata:
      name: example-kataconfig
    spec:
      logLevel: info
    #  kataConfigPoolSelector:
    #    matchLabels:
    #      <label_key>: '<label_value>'
    <label_key>: '<label_value>'
    Optional: If you have applied node labels to install kata-remote on specific nodes, specify the key and value, for example, kata-remote: 'true'.
  2. Create the KataConfig CR by running the following command:

    $ oc create -f example-kataconfig.yaml

    The new KataConfig CR is created and installs kata-remote as a runtime class on the worker nodes.

    Wait for the kata-remote installation to complete and the worker nodes to reboot before verifying the installation.

  3. Monitor the installation progress by running the following command:

    $ watch "oc describe kataconfig | sed -n /^Status:/,/^Events/p"

    When the status of all workers under kataNodes is installed and the condition InProgress is False without specifying a reason, the kata-remote is installed on the cluster.

  4. Verify the daemon set by running the following command:

    $ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-ds
  5. Verify the runtime classes by running the following command:

    $ oc get runtimeclass

    +

NAME           HANDLER             AGE
kata            kata                 34m
{runtime}         {runtime-handler}            152m

+ You can also see the default kata runtime class in addition to kata-remote.

Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top