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:
Update your OpenShift Container Platform cluster to update the
Kataruntime and its dependencies.The RHCOS extension
sandboxed containerscontains 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.- Update the OpenShift sandboxed containers Operator.
-
Delete the
KataConfigCR. - Verify that the image ID in the peer pods config map is empty.
-
Re-create the
KataConfigCR.
4.1. Updating the OpenShift sandboxed containers Operator Copy linkLink copied to clipboard!
You can update the OpenShift sandboxed containers Operator by using the command line interface (CLI).
Procedure
Create an
osc-subscription.yamlmanifest 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.0Create the subscription by running the following command:
$ oc create -f osc-subscription.yamlVerify that the Operator is correctly installed by running the following command:
$ oc get csv -n openshift-sandboxed-containers-operatorThis command can take several minutes to complete.
Watch the process by running the following command:
$ watch oc get csv -n openshift-sandboxed-containers-operatorExample 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 Copy linkLink copied to clipboard!
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-remoteruntime class.
Procedure
Delete the
KataConfigCR by running the following command:$ oc delete kataconfig example-kataconfigThe OpenShift sandboxed containers Operator removes all resources that were initially created to enable the runtime on your cluster.
ImportantWhen you delete the
KataConfigCR, the CLI stops responding until all worker nodes reboot. You must wait for the deletion process to complete before performing the verification.Verify the CR removal by running the following command:
$ oc get kataconfig example-kataconfigExample output
No example-kataconfig instances exist
4.3. Verifying empty peer pod image ID Copy linkLink copied to clipboard!
You must verify that the image ID in the peer pods config map is empty.
Procedure
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}"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 Copy linkLink copied to clipboard!
You must create the KataConfig custom resource (CR) to install kata-remote as a runtime class on your worker nodes.
Prerequisites
-
Creating the
KataConfigCR 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
Create an
example-kataconfig.yamlmanifest 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-remoteon specific nodes, specify the key and value, for example,kata-remote: 'true'.
Create the
KataConfigCR by running the following command:$ oc create -f example-kataconfig.yamlThe new
KataConfigCR is created and installskata-remoteas a runtime class on the worker nodes.Wait for the
kata-remoteinstallation to complete and the worker nodes to reboot before verifying the installation.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
kataNodesisinstalledand the conditionInProgressisFalsewithout specifying a reason, thekata-remoteis installed on the cluster.Verify the daemon set by running the following command:
$ oc get -n openshift-sandboxed-containers-operator ds/osc-caa-dsVerify 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.