[BUG]Clusters uses wrong cmpdDef after RollOut

[shanshanying]

Kubernetes: v1.32.2
KubeBlocks: 1.1.0-beta.0

How to reproduce

1. create a mysql with 2 replicas

apiVersion: apps.kubeblocks.io/v1
kind: Cluster
metadata:
  name: mysql-cluster
  namespace: demo
spec:
  terminationPolicy: Delete
  componentSpecs:
    - name: mysql
      componentDef: "mysql-8.0"
      serviceVersion: 8.0.35
      disableExporter: false
      replicas: 2
      resources:
        limits:
          cpu: '0.5'
          memory: 0.5Gi
        requests:
          cpu: '0.5'
          memory: 0.5Gi
      volumeClaimTemplates:
        - name: data
          spec:
            storageClassName: ""
            accessModes:
              - ReadWriteOnce
            resources:
              requests:
                storage: 20Gi

2. when it is running, applying a REPLACE rollout

apiVersion: apps.kubeblocks.io/v1alpha1
kind: Rollout
metadata:
  name: mysql-replace-rollout
  namespace: demo
spec:
  clusterName: mysql-cluster
  components:
    - name: mysql
      serviceVersion: "8.0.37"
      strategy:
        replace:
          # Optional: specify scheduling policy for new instances
          schedulingPolicy:
            affinity:
              nodeAffinity:
                requiredDuringSchedulingIgnoredDuringExecution:
                  nodeSelectorTerms:
                  - matchExpressions:
                    - key: kubernetes.io/arch
                      operator: In
                      values:
                      - arm64
          # Wait 60 seconds between rolling out each instance
          perInstanceIntervalSeconds: 60
          # Wait 30 seconds before scaling down old instance after new one is ready
          scaleDownDelaySeconds: 30

3. when rollout status goes succeed, check its status. it is as expected.

status:
  components:
  - canaryReplicas: 0
    compDef: mysql-8.0-1.1.0-alpha.0
    lastScaleDownTimestamp: "2026-01-06T02:54:16Z"
    lastScaleUpTimestamp: "2026-01-06T02:53:18Z"
    name: mysql
    newReplicas: 2
    replicas: 2
    rolledOutReplicas: 2
    scaleDownInstances:
    - mysql-cluster-mysql-1
    - mysql-cluster-mysql-0
    serviceVersion: 8.0.35
  observedGeneration: 1
  state: Succeed

4. when rollout status goes succeed, the cluster spec is not as expected in two ways

spec:
  componentSpecs:
  - componentDef: mysql-orc-8.0-1.1.0-alpha.0  # 1. cmpDef is mysql-orc-8.0 instead of mysql-8.0
    disableExporter: false
    flatInstanceOrdinal: true
    instances:
    - compDef: mysql-orc-8.0-1.1.0-alpha.0  # 1. cmpDef is mysql-orc-8.0 instead of mysql-8.0
      name: b5d0cee7             # 2. instance tpl exists, prevent a next rollout to be performed.
      ordinals: {}
      replicas: 2
      schedulingPolicy:
        affinity:
          nodeAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              nodeSelectorTerms:
              - matchExpressions:
                - key: kubernetes.io/arch
                  operator: In
                  values:
                  - arm64
      serviceVersion: 8.0.37
    name: mysql
    ordinals: {}
    podUpdatePolicy: PreferInPlace

As listed above, there are two issues here

1. cmpdDef changes from mysql-8.0 to mysql-orc-8.0
2. template tpl still exits after rollout succeeded. and its existence prevents a future rollout.

[leon-inf]

You can specify the compDef as mysql-8.0 in the rollout CR to restrict the CMPDs that the new service version can match.