Added more info here.

> $ oc patch deploy cluster-autoscaler-operator --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/1/volumeMounts/0","value": {"mountPath":"etc/cluster-autoscaler-operator/tls/service-ca","name":"cert","readOnly":true}}]'
> deployment.apps/cluster-autoscaler-operator patched

There are two issues for the patch config:
1) mountPath, which cause the pod `CreateContainerError`, after changing "etc/cluster-autoscaler-operator/tls/service-ca" to "/etc/cluster-autoscaler-operator/tls/service-ca", the pod running well.

2) duplicate volumeMounts, which cause cvo fail to remove the unrecognized volume mounts. The two volumeMount have the same name `cert`. 
$ oc get deployment.apps/cluster-autoscaler-operator -n openshift-machine-api -ojson|jq .spec.template.spec.containers[1].volumeMounts
[
  {
    "mountPath": "etc/cluster-autoscaler-operator/tls/service-ca",
    "name": "cert",
    "readOnly": true
  },
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls",
    "name": "cert",
    "readOnly": true
  }
]

So cvo keep report the invalid config when trying to restore:
I1125 03:17:42.281040       1 sync_worker.go:925] Update error 330 of 818: UpdatePayloadResourceInvalid Could not update deployment "openshift-machine-api/cluster-autoscaler-operator" (330 of 818): the object is invalid, possibly due to local cluster configuration (*errors.StatusError: Deployment.apps "cluster-autoscaler-operator" is invalid: spec.template.spec.containers[1].volumeMounts[1].mountPath: Invalid value: "/etc/cluster-autoscaler-operator/tls": must be unique)

After changing the name of added volumeMount to a different name, cvo will update the deployment to required state as expected. 

So the issue here is that, if patch the deployment successfully even with invalid config, cvo should restore the update to required status no matter the in-cluster resource valid or not as long as the patch succeed.

(In reply to liujia from comment #1)
> 
> So the issue here is that, if patch the deployment successfully even with
> invalid config, cvo should restore the update to required status no matter
> the in-cluster resource valid or not as long as the patch succeed.

This is standard CVO behaviour whenever the API rejects a resource as being invalid. If I'm understanding what you mean by "restore the update to required status" and CVO simply stomped on the change and restored the resource a less than engaged user may not notice and believe their change was applied. Even if we were to make such a change to CVO it would be an RFE and not a bug.

From my poor understanding, cvo is always stomping on the changes unless the resource is set to unmanned in spec.overrides. And cvo's main responsibility is to translate/maintain the cluster to that target state(required status according to manifest). So from end user's perspective, cvo should always remove "unrecognized volume mounts".

Now when adding unrecognized volume mount cert(/etc/cluster-autoscaler-operator-invalid/service-ca):
# ./oc -n openshift-machine-api patch deploy cluster-autoscaler-operator --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/1/volumeMounts/0","value":{"mountPath":"/etc/cluster-autoscaler-operator/tls/service-ca","name":"cert","readOnly":true}}]'
deployment.apps/cluster-autoscaler-operator patched

# ./oc get deployment.apps/cluster-autoscaler-operator -n openshift-machine-api -ojson|jq .spec.template.spec.containers[1].volumeMounts
[
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls/service-ca",
    "name": "cert",
    "readOnly": true
  },
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls",
    "name": "cert",
    "readOnly": true
  }
]
It will do nothing with the added unrecognized volume mount there.

But if adding unrecognized volume mount auth-proxy-config(/etc/cluster-autoscaler-operator-invalid/service-ca):
# ./oc -n openshift-machine-api patch deploy cluster-autoscaler-operator --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/1/volumeMounts/0","value":{"mountPath":"/etc/cluster-autoscaler-operator/tls/service-ca","name":"auth-proxy-config","readOnly":true}}]'
deployment.apps/cluster-autoscaler-operator patched
# ./oc get deployment.apps/cluster-autoscaler-operator -n openshift-machine-api -ojson|jq .spec.template.spec.containers[1].volumeMounts
[
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls/service-ca",
    "name": "auth-proxy-config",
    "readOnly": true
  },
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls",
    "name": "cert",
    "readOnly": true
  }
]
It will stomp it directly(also without notice to engaged user), and the unrecognized volume mount will be erased.
# ./oc get deployment.apps/cluster-autoscaler-operator -n openshift-machine-api -ojson|jq .spec.template.spec.containers[1].volumeMounts
[
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls",
    "name": "cert",
    "readOnly": true
  }
]

So the inconsistent behavior make us thought it's a bug.

Ah, because the current logic assumes that volumeMount entries are uniquely identified by name [1], but instead we should have been using mountPath [2].

[1]: https://github.com/openshift/cluster-version-operator/blob/85f767cd663e738b6b9aacec74d010cfbc32993a/lib/resourcemerge/core.go#L325
[2]: https://github.com/kubernetes/api/blob/1d6faf224f146dd002553f55cd9fcaaaa0dc00cb/core/v1/types.go#L2367

Verified
clusterversion: 4.10.0-0.nightly-2021-12-06-201335
$ oc patch deploy cluster-autoscaler-operator --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/1/volumeMounts/0","value":{"mountPath":"etc/cluster-autoscaler-operator/tls/service-ca","name":"cert","readOnly":true}}]'
deployment.apps/cluster-autoscaler-operator patched
        
After update, check autoscaler pod and deployment, work as expected.
$ oc get po                                                                                                                           
NAME                                          READY   STATUS    RESTARTS   AGE
cluster-autoscaler-operator-5ff8cd67f-lg58p   2/2     Running   0          33m
cluster-baremetal-operator-7bcc96c877-r7sgm   2/2     Running   0          33m
machine-api-controllers-5c58b566b7-mc5jl      7/7     Running   0          33m
machine-api-operator-644d9f94c5-ndl2c         2/2     Running   0          33m

$ oc get deployment.apps/cluster-autoscaler-operator -n openshift-machine-api -ojson|jq .spec.template.spec.containers[1].volumeMounts
[
  {
    "mountPath": "/etc/cluster-autoscaler-operator/tls",
    "name": "cert",
    "readOnly": true
  }
]

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2022:0056