[Features] opsRequest upgrade operation can control the scope

[sunwsh]

describe

When performing an upgrade operation via opsRequest, we implement a phased upgrade approach. Since KubeBlocks manages objects in the hierarchy of cluster → component → instanceSet → pod, we upgrade components sequentially.

When upgrading an individual component, the process follows these steps:

1. Upgrade pods one at a time, verifying that the version updates are correct after each upgrade.
2. Use LabelSelector to define the upgrade scope (e.g., performing rolling upgrades by availability zone or rack). Conduct rolling upgrades with health checks - after each pod is upgraded, verify service availability before proceeding to the next.

example

There is an elasticsearch cluster below

$ kubectl get cluster -n test-pes-vdas -o wide
NAME        CLUSTER-DEFINITION   TERMINATION-POLICY   STATUS    AGE
test-vdas   elasticsearch         Delete               Running   45d
$ kubectl get component -n test-pes-vdas -o wide
NAME          DEFINITION                   SERVICE-VERSION   STATUS    AGE
test-vdas-d   elasticsearch-7              7.7.1             Running   45d
test-vdas-m   elasticsearch-7              7.7.1             Running   45d
$ kubectl get instanceSet -n test-pes-vdas -o wide
NAME          READY   DESIRED   UP-TO-DATE   AVAILABLE   AGE
test-vdas-d   6       6         6            6           45d
test-vdas-m   3       3         3            3           45d

$ kubectl get pod -n test-pes-vdas -o wide -L apps.kubeblocks.io/component-name,idc
NAME            READY   STATUS    RESTARTS   AGE   IP              NODE            NOMINATED NODE   READINESS GATES   COMPONENT-NAME   IDC
test-vdas-d-0   3/3     Running   0          45d   10.172.35.167   10.172.35.118   <none>           <none>            d                guangzhou
test-vdas-d-1   3/3     Running   0          45d   10.192.20.144   10.192.236.64   <none>           <none>            d                guangzhou
test-vdas-d-2   3/3     Running   0          12d   10.172.37.2     10.172.37.32    <none>           <none>            d                shenzhen
test-vdas-d-3   3/3     Running   0          12d   10.192.13.103   10.192.238.47   <none>           <none>            d                shenzhen
test-vdas-d-4   3/3     Running   0          12d   10.172.37.9     10.172.37.33    <none>           <none>            d                dongguan
test-vdas-d-5   3/3     Running   0          12d   10.192.13.104   10.192.238.45   <none>           <none>            d                dongguan
test-vdas-m-0   3/3     Running   0          45d   10.192.20.143   10.192.236.64   <none>           <none>            m                guangzhou
test-vdas-m-1   3/3     Running   0          45d   10.192.20.142   10.192.236.63   <none>           <none>            m                shenzhen
test-vdas-m-2   3/3     Running   0          45d   10.172.35.162   10.172.35.118   <none>           <none>            m                dongguan

upgrade

The recommended upgrade sequence is to upgrade the test-vdas-m component first, followed by the test-vdas-d component.

Phase 1: Upgrade the test-vdas-m component

1. Upgrade Pod test-vdas-m-0 and monitor the outcome. Initiate a rollback if any exceptions occur.
2. Perform a rolling upgrade on the remaining two Pods using the label selector apps.kubeblocks.io/component-name=m.

Phase 2: Upgrade the test-vdas-d component

1. Upgrade Pod test-vdas-d-0 and monitor the outcome. Initiate a rollback if any exceptions occur.
2. Perform a rolling upgrade on the Pods in the Guangzhou IDC using the label selector IDC=guangzhou.
3. Perform a rolling upgrade on the Pods in the Shenzhen IDC using the label selector IDC=shenzhen.

[shanshanying]

seems our rolleout APIs fits your needs:

• feat: support rollout of cluster instances #9456

It will be release in v1.1.0. please check the pr enclosed and see if there is any improvement we can do in APIs.