1
0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 12:46:18 +01:00
Files
openshift-docs/modules/ztp-image-based-upgrade-procedure-steps.adoc
2025-02-17 16:56:58 +00:00

193 lines
5.7 KiB
Plaintext

// Module included in the following assemblies:
// * edge_computing/image-based-upgrade/ztp-image-based-upgrade.adoc
:_mod-docs-content-type: CONCEPT
[id="ztp-image-based-upgrade-procedure-steps_{context}"]
= Performing an image-based upgrade on managed clusters at scale in several steps
For use cases when you need better control of when the upgrade interrupts your service, you can upgrade a set of your managed clusters by using the `ImageBasedGroupUpgrade` CR with adding actions after the previous step is complete.
After evaluating the results of the previous steps, you can move to the next upgrade stage or troubleshoot any failed steps throughout the procedure.
include::snippets/ibu-supported-action-combinations.adoc[]
.Prerequisites
* You have logged in to the hub cluster as a user with `cluster-admin` privileges.
* You have created policies and `ConfigMap` objects for resources used in the image-based upgrade.
* You have installed the {lcao} and OADP Operators on all managed clusters through the hub cluster.
.Procedure
. Create a YAML file on the hub cluster that contains the `ImageBasedGroupUpgrade` CR:
+
--
[source,yaml]
----
apiVersion: lcm.openshift.io/v1alpha1
kind: ImageBasedGroupUpgrade
metadata:
name: <filename>
namespace: default
spec:
clusterLabelSelectors: # <1>
- matchExpressions:
- key: name
operator: In
values:
- spoke1
- spoke4
- spoke6
ibuSpec:
seedImageRef: # <2>
image: quay.io/seed/image:4.16.0-rc.1
version: 4.16.0-rc.1
pullSecretRef:
name: "<seed_pull_secret>"
extraManifests: # <3>
- name: example-extra-manifests
namespace: openshift-lifecycle-agent
oadpContent: # <4>
- name: oadp-cm
namespace: openshift-adp
plan: # <5>
- actions: ["Prep"]
rolloutStrategy:
maxConcurrency: 2
timeout: 2400
----
<1> Clusters to upgrade.
<2> Target platform version, the seed image to be used, and the secret required to access the image.
+
[NOTE]
====
If you add the seed image pull secret in the hub cluster, in the same namespace as the `ImageBasedGroupUpgrade` resource, the secret is added to the manifest list for the `Prep` stage. The secret is recreated in each spoke cluster in the `openshift-lifecycle-agent` namespace.
====
+
<3> Optional: Applies additional manifests, which are not in the seed image, to the target cluster. Also applies `ConfigMap` objects for custom catalog sources.
<4> List of `ConfigMap` resources that contain the {oadp-short} `Backup` and `Restore` CRs.
<5> Upgrade plan details.
--
. Apply the created file by running the following command on the hub cluster:
+
[source,terminal]
----
$ oc apply -f <filename>.yaml
----
. Monitor the status updates by running the following command on the hub cluster:
+
--
[source,terminal]
----
$ oc get ibgu -o yaml
----
.Example output
[source,yaml]
----
# ...
status:
clusters:
- completedActions:
- action: Prep
name: spoke1
- completedActions:
- action: Prep
name: spoke4
- failedActions:
- action: Prep
name: spoke6
# ...
----
The previous output of an example plan starts with the `Prep` stage only and you add actions to the plan based on the results of the previous step.
{cgu-operator} adds a label to the clusters to mark if the upgrade succeeded or failed.
For example, the `lcm.openshift.io/ibgu-prep-failed` is applied to clusters that failed the `Prep` stage.
After investigating the failure, you can add the `AbortOnFailure` step to your upgrade plan.
It moves the clusters labeled with `lcm.openshift.io/ibgu-<action>-failed` back to the `Idle` stage.
Any resources that are related to the upgrade on the selected clusters are deleted.
--
. Optional: Add the `AbortOnFailure` action to your existing `ImageBasedGroupUpgrade` CR by running the following command:
+
[source,terminal]
----
$ oc patch ibgu <filename> --type=json -p \
'[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
----
.. Continue monitoring the status updates by running the following command:
+
[source,terminal]
----
$ oc get ibgu -o yaml
----
. Add the action to your existing `ImageBasedGroupUpgrade` CR by running the following command:
+
[source,terminal]
----
$ oc patch ibgu <filename> --type=json -p \
'[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["Upgrade"], "rolloutStrategy": {"maxConcurrency": 2, "timeout": 30}}}]'
----
. Optional: Add the `AbortOnFailure` action to your existing `ImageBasedGroupUpgrade` CR by running the following command:
+
[source,terminal]
----
$ oc patch ibgu <filename> --type=json -p \
'[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["AbortOnFailure"], "rolloutStrategy": {"maxConcurrency": 5, "timeout": 10}}}]'
----
.. Continue monitoring the status updates by running the following command:
+
[source,terminal]
----
$ oc get ibgu -o yaml
----
. Add the action to your existing `ImageBasedGroupUpgrade` CR by running the following command:
+
[source,terminal]
----
$ oc patch ibgu <filename> --type=json -p \
'[{"op": "add", "path": "/spec/plan/-", "value": {"actions": ["FinalizeUpgrade"], "rolloutStrategy": {"maxConcurrency": 10, "timeout": 3}}}]'
----
.Verification
* Monitor the status updates by running the following command:
+
--
[source,terminal]
----
$ oc get ibgu -o yaml
----
.Example output
[source,yaml]
----
# ...
status:
clusters:
- completedActions:
- action: Prep
- action: AbortOnFailure
failedActions:
- action: Upgrade
name: spoke1
- completedActions:
- action: Prep
- action: Upgrade
- action: FinalizeUpgrade
name: spoke4
- completedActions:
- action: AbortOnFailure
failedActions:
- action: Prep
name: spoke6
# ...
----
--