Red Hat Summit Red Hat SummitSupportoConsoleSviluppatoriInizia una provaContatti

Questo contenuto non è disponibile nella lingua selezionata.

Chapter 15. Updating OpenShift Container Storage

15.1. Overview of the OpenShift Container Storage update process
Copia collegamento

You can upgrade Red Hat OpenShift Container Storage and its components, either between minor releases like 4.5 and 4.6, or between batch updates like 4.6.0 and 4.6.1.

You need to upgrade the different parts of OpenShift Container Storage in a specific order.

  1. Update OpenShift Container Platform according to the Updating clusters documentation for OpenShift Container Platform.

  2. Update OpenShift Container Storage.

    1. Update the OpenShift Container Storage operator, using the appropriate process for your setup:

    2. If you use local storage:

      1. Update the Local Storage operator.

        See Checking for Local Storage Operator deployments if you are unsure.

      2. Perform post-update configuration changes for clusters backed by local storage.

        See Post-update configuration for clusters backed by local storage for details.

Update considerations

Review the following important considerations before you begin.

  • Red Hat recommends using the same version of Red Hat OpenShift Container Platform with Red Hat OpenShift Container Storage.

    See the Interoperability Matrix for more information about supported combinations of OpenShift Container Platform and OpenShift Container Storage.

  • The Local Storage Operator is fully supported only when the Local Storage Operator version matches the Red Hat OpenShift Container Platform version.

15.2. Preparing to update in a disconnected environment
Copia collegamento

When your Red Hat OpenShift Container Storage environment is not directly connected to the internet, some additional configuration is required to provide the Operator Lifecycle Manager (OLM) with alternatives to the default Operator Hub and image registries.

See the OpenShift Container Platform documentation for more general information: Updating an Operator catalog image.

To configure your cluster for disconnected update:

  1. Configure authentication for an alternative registry.
  2. Build and mirror the Red Hat operator catalog.
  3. Creating Operator imageContentSourcePolicy
  4. Updating redhat-operator catalogsource

When these steps are complete, Continue with update as usual.

15.2.1. Adding mirror registry authentication details
Copia collegamento

Prerequisites

  • Verify that your existing disconnected cluster uses OpenShift Container Platform 4.3 or higher.
  • Verify that you have an oc client version of 4.4 or higher.
  • Prepare a mirror host with a mirror registry. See Preparing your mirror host for details.

Procedure

  1. Log in to the OpenShift Container Platform cluster using the cluster-admin role.

  2. Locate your auth.json file.

    This file is generated when you use podman or docker to log in to a registry. It is located in one of the following locations:

    • ~/.docker/auth.json
    • /run/user/<UID>/containers/auth.json
    • /var/run/containers/<UID>/auth.json

  3. Obtain your unique Red Hat registry pull secret and paste it into your auth.json file. It will look something like this. 

    {
    "auths": {
        "cloud.openshift.com": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "quay.io": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "registry.connect.redhat.com": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "registry.redhat.io": {
            "auth": "*****************",
            "email": "user@example.com"
        }
    }
  }

  4. Export environment variables with the appropriate details for your setup. 

    $ export AUTH_FILE="<location_of_auth.json>"
$ export MIRROR_REGISTRY_DNS="<your_registry_url>:<port>"

  5. Use podman to log in to the mirror registry and store the credentials in the ${AUTH_FILE}. 

    $ podman login ${MIRROR_REGISTRY_DNS} --tls-verify=false --authfile ${AUTH_FILE}

    This adds the mirror registry to the auth.json file. 

    {
    "auths": {
        "cloud.openshift.com": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "quay.io": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "registry.connect.redhat.com": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "registry.redhat.io": {
            "auth": "*****************",
            "email": "user@example.com"
        },
        "<mirror_registry>": {
            "auth": "*****************",
        }
    }
  }

15.2.2. Building and mirroring the Red Hat operator catalog
Copia collegamento

Follow this process on a host that has access to Red Hat registries to create a mirror of those registries.

Prerequisites

  • Run these commands as a cluster administrator.
  • Be aware that mirroring the redhat-operator catalog can take hours to complete, and requires substantial available disk space on the mirror host.

Procedure

  1. Build the catalog for redhat-operators.

    Set --from to the ose-operator-registry base image using the tag that matches the target OpenShift Container Platform cluster major and minor version. 

    $ oc adm catalog build --appregistry-org redhat-operators \
  --from=registry.redhat.io/openshift4/ose-operator-registry:v4.6 \
  --to=${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
  --registry-config=${AUTH_FILE} \
  --filter-by-os="linux/amd64" --insecure

  2. Mirror the catalog for redhat-operators.

    This is a long operation and can take 1-5 hours. Make sure there is 100 GB available disk space on the mirror host. 

    $ oc adm catalog mirror ${MIRROR_REGISTRY_DNS}/olm/redhat-operators:v2 \
${MIRROR_REGISTRY_DNS} --registry-config=${AUTH_FILE} --insecure

15.2.3. Creating Operator imageContentSourcePolicy
Copia collegamento

After the oc adm catalog mirror command is completed, the imageContentSourcePolicy.yaml file gets created. The output directory for this file is usually, ./[catalog image name]-manifests). Use this procedure to add any missing entries to the .yaml file and apply them to cluster.

Procedure

  1. Check the content of this file for the mirrors mapping shown as follows: 

    spec:
  repositoryDigestMirrors:
    - mirrors:
      - <your_registry>/ocs4
      source: registry.redhat.io/ocs4
    - mirrors:
      - <your_registry>/rhceph
      source: registry.redhat.io/rhceph
    - mirrors:
      - <your_registry>/openshift4
      source: registry.redhat.io/openshift4
    - mirrors:
      - <your_registry>/rhscl
      source: registry.redhat.io/rhscl
  2. Add any missing entries to the end of the imageContentSourcePolicy.yaml file.

  3. Apply the imageContentSourcePolicy.yaml file to the cluster. 

    $ oc apply -f ./[output dir]/imageContentSourcePolicy.yaml

    Once the Image Content Source Policy is updated, all the nodes (master, infra, and workers) in the cluster need to be updated and rebooted. This process is automatically handled through the Machine Config Pool operator and take up to 30 minutes although the exact elapsed time might vary based on the number of nodes in your OpenShift cluster. You can monitor the update process by using the oc get mcp command or the oc get node command.

15.2.4. Updating redhat-operator CatalogSource
Copia collegamento

Procedure

  1. Recreate a CatalogSource object that references the catalog image for Red Hat operators.

    Note

    Make sure you have mirrored the correct catalog source with the correct version (that is, v2).

    Save the following in a redhat-operator-catalogsource.yaml file, remembering to replace <your_registry> with your mirror registry URL: 

    apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: redhat-operators
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  icon:
    base64data: PHN2ZyBpZD0iTGF5ZXJfMSIgZGF0YS1uYW1lPSJMYXllciAxIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAxOTIgMTQ1Ij48ZGVmcz48c3R5bGU+LmNscy0xe2ZpbGw6I2UwMDt9PC9zdHlsZT48L2RlZnM+PHRpdGxlPlJlZEhhdC1Mb2dvLUhhdC1Db2xvcjwvdGl0bGU+PHBhdGggZD0iTTE1Ny43Nyw2Mi42MWExNCwxNCwwLDAsMSwuMzEsMy40MmMwLDE0Ljg4LTE4LjEsMTcuNDYtMzAuNjEsMTcuNDZDNzguODMsODMuNDksNDIuNTMsNTMuMjYsNDIuNTMsNDRhNi40Myw2LjQzLDAsMCwxLC4yMi0xLjk0bC0zLjY2LDkuMDZhMTguNDUsMTguNDUsMCwwLDAtMS41MSw3LjMzYzAsMTguMTEsNDEsNDUuNDgsODcuNzQsNDUuNDgsMjAuNjksMCwzNi40My03Ljc2LDM2LjQzLTIxLjc3LDAtMS4wOCwwLTEuOTQtMS43My0xMC4xM1oiLz48cGF0aCBjbGFzcz0iY2xzLTEiIGQ9Ik0xMjcuNDcsODMuNDljMTIuNTEsMCwzMC42MS0yLjU4LDMwLjYxLTE3LjQ2YTE0LDE0LDAsMCwwLS4zMS0zLjQybC03LjQ1LTMyLjM2Yy0xLjcyLTcuMTItMy4yMy0xMC4zNS0xNS43My0xNi42QzEyNC44OSw4LjY5LDEwMy43Ni41LDk3LjUxLjUsOTEuNjkuNSw5MCw4LDgzLjA2LDhjLTYuNjgsMC0xMS42NC01LjYtMTcuODktNS42LTYsMC05LjkxLDQuMDktMTIuOTMsMTIuNSwwLDAtOC40MSwyMy43Mi05LjQ5LDI3LjE2QTYuNDMsNi40MywwLDAsMCw0Mi41Myw0NGMwLDkuMjIsMzYuMywzOS40NSw4NC45NCwzOS40NU0xNjAsNzIuMDdjMS43Myw4LjE5LDEuNzMsOS4wNSwxLjczLDEwLjEzLDAsMTQtMTUuNzQsMjEuNzctMzYuNDMsMjEuNzdDNzguNTQsMTA0LDM3LjU4LDc2LjYsMzcuNTgsNTguNDlhMTguNDUsMTguNDUsMCwwLDEsMS41MS03LjMzQzIyLjI3LDUyLC41LDU1LC41LDc0LjIyYzAsMzEuNDgsNzQuNTksNzAuMjgsMTMzLjY1LDcwLjI4LDQ1LjI4LDAsNTYuNy0yMC40OCw1Ni43LTM2LjY1LDAtMTIuNzItMTEtMjcuMTYtMzAuODMtMzUuNzgiLz48L3N2Zz4=
    mediatype: image/svg+xml
  image: <your_registry>/olm/redhat-operators:v2
  displayName: Redhat Operators Catalog
  publisher: Red Hat

  2. Create a catalogsource using the redhat-operator-catalogsource.yaml file: 

    $ oc apply -f redhat-operator-catalogsource.yaml

  3. Verify that the new redhat-operator pod is running. 

    $ oc get pod -n openshift-marketplace | grep redhat-operators

15.2.5. Continue to update
Copia collegamento

After your alternative catalog source is configured, you can continue to the appropriate update process:

15.3. Updating OpenShift Container Storage in internal mode
Copia collegamento

Use the following procedures to update your OpenShift Container Storage cluster deployed in internal mode.

Use this procedure to enable automatic update approval for updating OpenShift Container Storage operator in OpenShift Container Platform.

Prerequisites

  • Under Persistent Storage in the Status card, confirm that the OCS Cluster and Data Resiliency has a green tick mark.
  • Under Object Service in the Status card, confirm that both the Object Service and Data Resiliency are in Ready state (green tick).
  • Update the OpenShift Container Platform cluster to the latest stable release of version 4.5.X or 4.6.Y, see Updating Clusters.

  • Switch the Red Hat OpenShift Container Storage channel from stable-4.5 to stable-4.6. For details about channels, see OpenShift Container Storage upgrade channels and releases.

    Note

    You are required to switch channels only when you are updating minor versions (for example, updating from 4.5 to 4.6) and not when updating between batch updates of 4.6 (for example, updating from 4.6.0 to 4.6.1).

  • Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads Pods from the left pane of the OpenShift Web Console. Select openshift-storage from the Project drop down list.

  • Ensure that you have sufficient time to complete the Openshift Container Storage update process, as the update time varies depending on the number of OSDs that run in the cluster.

Procedure

  1. Log in to OpenShift Web Console.
  2. Click Operators Installed Operators
  3. Select the openshift-storage project.
  4. Click the OpenShift Container Storage operator name.
  5. Click the Subscription tab and click the link under Approval.
  6. Select Automatic (default) and click Save.

  7. Perform one of the following depending on the Upgrade Status:

    • Upgrade Status shows requires approval.

      Note

      Upgrade status shows requires approval if the new OpenShift Container Storage version is already detected in the channel, and approval strategy was changed from Manual to Automatic at the time of update.

      1. Click on the Install Plan link.
      2. On the InstallPlan Details page, click Preview Install Plan.
      3. Review the install plan and click Approve.
      4. Wait for the Status to change from Unknown to Created.
      5. Click Operators Installed Operators
      6. Select the openshift-storage project.
      7. Wait for the Status to change to Up to date

    • Upgrade Status does not show requires approval:

      1. Wait for the update to initiate. This may take up to 20 minutes.
      2. Click Operators Installed Operators
      3. Select the openshift-storage project.
      4. Wait for the Status to change to Up to date

Verification steps

  1. Click Overview Persistent Storage tab and in the Status card confirm that the OCS Cluster and Data Resiliency has a green tick mark indicating it is healthy.
  2. Click Overview Object Service tab and in the Status card confirm that both the Object Service and Data Resiliency are in Ready state (green tick) indicating it is healthy.

  3. Click Operators Installed Operators OpenShift Container Storage Operator. Under Storage Cluster, verify that the cluster service status is Ready.

    Note

    Once updated from OpenShift Container Storage version 4.5 to 4.6, the Version field here will still display 4.5. This is because the ocs-operator does not update the string represented in this field.

  4. Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads Pods. Select openshift-storage from the Project drop down list.

  5. If verification steps fail, contact Red Hat Support.

Additional Resources

If you face any issues while updating OpenShift Container Storage, see the Commonly required logs for troubleshooting section in the Troubleshooting guide.

Use this procedure to update OpenShift Container Storage operator by providing manual approval to the install plan.

Prerequisites

  • Under Persistent Storage in the Status card, confirm that the OCS Cluster and Data Resiliency has a green tick mark.
  • Under Object Service in the Status card, confirm that both the Object Service and Data Resiliency are in Ready state (green tick).
  • Update the OpenShift Container Platform cluster to the latest stable release of version 4.5.X or 4.6.Y, see Updating Clusters.

  • Switch the Red Hat OpenShift Container Storage channel from stable-4.5 to stable-4.6. For details about channels, see OpenShift Container Storage upgrade channels and releases.

    Note

    You are required to switch channels only when you are updating minor versions (for example, updating from 4.5 to 4.6) and not when updating between batch updates of 4.6 (for example, updating from 4.6.0 to 4.6.1).

  • Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads Pods from the left pane of the OpenShift Web Console. Select openshift-storage from the Project drop down list.

  • Ensure that you have sufficient time to complete the Openshift Container Storage update process, as the update time varies depending on the number of OSDs that run in the cluster.

Procedure

  1. Log in to OpenShift Web Console.
  2. Click Operators Installed Operators
  3. Select the openshift-storage project.
  4. Click the OpenShift Container Storage operator name.
  5. Click the Subscription tab and click the link under Approval.
  6. Select Manual and click Save.
  7. Wait for the Upgrade Status to change to Upgrading.
  8. If the Upgrade Status shows requires approval, click on requires approval.
  9. On the InstallPlan Details page, click Preview Install Plan.
  10. Review the install plan and click Approve.
  11. Wait for the Status to change from Unknown to Created.
  12. Click Operators Installed Operators
  13. Select the openshift-storage project.
  14. Wait for the Status to change to Up to date

Verification steps

  1. Click Overview Persistent Storage tab and in the Status card confirm that the OCS Cluster and Data Resiliency has a green tick mark indicating it is healthy.
  2. Click Overview Object Service tab and in the Status card confirm that both the Object Service and Data Resiliency are in Ready state (green tick) indicating it is healthy.

  3. Click Operators Installed Operators OpenShift Container Storage Operator. Under Storage Cluster, verify that the cluster service status is Ready.

    Note

    Once updated from OpenShift Container Storage version 4.5 to 4.6, the Version field here will still display 4.5. This is because the ocs-operator does not update the string represented in this field.

  4. Ensure that all OpenShift Container Storage Pods, including the operator pods, are in Running state in the openshift-storage namespace.

    To view the state of the pods, click Workloads Pods from the left pane of the OpenShift Web Console. Select openshift-storage from the Project drop down list.

  5. If verification steps fail, contact Red Hat Support.

Additional Resources

If you face any issues while updating OpenShift Container Storage, see the Commonly required logs for troubleshooting section in the Troubleshooting guide.

15.4. Post-update configuration changes
Copia collegamento

In some cases, additional configuration steps are required after an update to ensure that all features work as expected.

15.4.1. Post-update configuration for clusters backed by local storage
Copia collegamento

In Red Hat OpenShift Container Platform 4.6 and onward, the Local Storage operator provides new custom resource types for managing local storage:

  • LocalVolumeDiscovery
  • LocalVolumeSet

These resource types are not automatically handled as part of an update from earlier versions, and must be created manually.

Create a LocalVolumeDiscovery custom resource to ensure that the device management user interface can discover the state of local devices and provide information about devices that are available on cluster nodes.

Prerequisites

  • Administrative access to the OpenShift Container Platform cluster.

Procedure

  1. Change into the project that has Local Storage operator installed. 

    $ oc project local-storage-project

    Replace local-storage-project with the name of your Local Storage project.

    In version 4.5 and earlier the name of the default local storage project is local-storage. In version 4.6 and later, the name of the default local storage project is openshift-local-storage.

  2. Define the LocalVolumeDiscovery custom resource.

    For example, define the following in a local-volume-discovery.yaml file. 

    apiVersion: local.storage.openshift.io/v1alpha1
kind: LocalVolumeDiscovery
metadata:
  name: auto-discover-devices
spec:
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
              - worker1.example.com
              - worker2.example.com
              - worker3.example.com

  3. Create the LocalVolumeDiscovery custom resource. 

    $ oc create -f local-volume-discovery.yaml

Verification steps

  1. Log in to the OpenShift web console.
  2. Click Compute Node and click on the name of the node.
  3. Click the Disks tab and check that you can see the devices available on that node.

15.4.1.2. Creating a LocalVolumeSet custom resource using the command line
Copia collegamento

Create a LocalVolumeSet custom resource to automatically provision certain storage devices as persistent volumes based on criteria that you specify. Persistent volumes are created for any devices that match the deviceInclusionSpec criteria on any node that matches the nodeSelector criteria.

Prerequisites

  • Administrative access to the OpenShift Container Platform cluster.

Procedure

  1. Define a LocalVolumeSet custom resource in a local-volume-set.yaml file. 

    apiVersion: local.storage.openshift.io/v1alpha1
kind: LocalVolumeSet
metadata:
  name: localblock
spec:
  nodeSelector:
    nodeSelectorTerms:
      - matchExpressions:
          - key: kubernetes.io/hostname
            operator: In
            values:
              - worker1.example.com
              - worker2.example.com
              - worker3.example.com
  storageClassName: localblock
  volumeMode: Block
  maxDeviceCount: 10 # optional, limit devices provisioned per node
  deviceInclusionSpec:
    deviceTypes: # list of types to allow
      - disk
      - part # omit this to use only whole devices
    deviceMechanicalProperty:
      - NonRotational
    minSize: 100Gi # optional, minimum size of device to allow
    maxSize: 100Ti # optional, maximum size of device to allow
    models: # (optional) list of models to allow
      - SAMSUNG
      - Crucial_CT525MX3
    vendors: # (optional) list of device vendors to allow
      - ATA
      - ST2000LM

    The above definition selects whole disks or partitions on specific models of non-rotational devices that are between 100 GB and 100 TB in size, provided by specific vendors, from the worker1, worker2 and worker3 nodes. The localblock storage class is created and persistent volumes are provisioned from discovered devices.

    Important

    Select an appropriate value for minSize to ensure system partitions are not selected.

  2. Create the LocalVolumeSet. 

    $ oc create -f local-volume-set.yaml

Verification steps

  1. Use the following command to track provisioning of persistent volumes for devices that match the deviceInclusionSpec. It can take a few minutes to provision persistent volumes. 

    $ oc describe localvolumeset localblock
[...]
Status:
  Conditions:
    Last Transition Time:          2020-11-17T05:03:32Z
    Message:                       DiskMaker: Available, LocalProvisioner: Available
    Status:                        True
    Type:                          DaemonSetsAvailable
    Last Transition Time:          2020-11-17T05:03:34Z
    Message:                       Operator reconciled successfully.
    Status:                        True
    Type:                          Available
  Observed Generation:             1
  Total Provisioned Device Count: 4
Events:
Type    Reason      Age          From                Message
----    ------      ----         ----                -------
Normal  Discovered  2m30s (x4    localvolumeset-     ip-10-0-147-124.us-east-
        NewDevice   over 2m30s)  symlink-controller  2.compute.internal -
                                                     found possible matching
                                                     disk, waiting 1m to claim
Normal  FoundMatch  89s (x4      localvolumeset-     ip-10-0-147-124.us-east-
        ingDisk     over 89s)    symlink-controller  2.compute.internal -
                                                     symlinking matching disk

  2. Verify the state of the provisioned persistent volumes. 

    $ oc get pv
                     ACCESS   RECLAIM             STORAGE
NAME       CAPACITY  MODES    POLICY   STATUS     CLASS       AGE
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
3584969f
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
3aee84fa
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
644d09ac
local-pv-  500Gi     RWO      Delete   Available  localblock  7m48s
c73cee1

15.4.1.3. Adding annotations
Copia collegamento

Use this procedure to add annotations to storage cluster to enable replacing of failed storage devices through the user interface when you upgraded to OpenShift Container Storage 4.6 from a previous version.

Procedure

  1. Log in to OpenShift Container Platform Web Console.
  2. Click Home Search.
  3. Search for StorageCluster in Resources and click on it.
  4. Beside ocs-storagecluster, click Action menu (⋮) Edit annotations.
  5. Add cluster.ocs.openshift.io/local-devices and true for KEY and VALUE respectively.
  6. Click Save.
Red Hat logoGithubredditYoutubeTwitter

Formazione

Prova, acquista e vendi

Community

Informazioni sulla documentazione di Red Hat

Aiutiamo gli utenti Red Hat a innovarsi e raggiungere i propri obiettivi con i nostri prodotti e servizi grazie a contenuti di cui possono fidarsi. Esplora i nostri ultimi aggiornamenti.

Rendiamo l’open source più inclusivo

Red Hat si impegna a sostituire il linguaggio problematico nel codice, nella documentazione e nelle proprietà web. Per maggiori dettagli, visita il Blog di Red Hat.

Informazioni su Red Hat

Forniamo soluzioni consolidate che rendono più semplice per le aziende lavorare su piattaforme e ambienti diversi, dal datacenter centrale all'edge della rete.

Theme

© 2026 Red HatTorna in cima