Embedded spec.vpa on VMAgent generates a VPA that fails the topmost-controller check (targets owned Deployment instead of the CR)

[voron]

Describe the bug

Embedded spec.vpa on VMAgent generates a VerticalPodAutoscaler targeting the operator-owned Deployment. The VPA admission/recommender rejects that target because of its topmost-controller rule: it walks ownership from the Deployment up to the VMAgent CR, whose CRD declares a scale subresource with specReplicasPath: .spec.shardCount. Both possible states fail:

• shardCount unset — GET /scale on the CR returns an apiserver error (the spec replicas field ".spec.shardCount" does not exist; VMAgent + VPA: scale subresource lookup fails when .spec.shardCount is unset (follow-up to #693) #2229's v0.71 fix only defaults .status.shards), so the ownership walk errors out. Observed status on the generated VPA (operator v0.73.1, K8s v1.35.2, VPA 1.5.1):

  type: ConfigUnsupported
  message: 'Error checking if target apps/v1.Deployment/vmagent-staging-vmagent
    is a topmost well-known or scalable controller: unhandled targetRef
    operator.victoriametrics.com/v1beta1 / VMAgent / staging-vmagent,
    last error Internal error occurred: the spec replicas field
    ".spec.shardCount" does not exist'
  type: NoPodsMatched            # → no recommendations, VPA permanently inert
  

• shardCount set — /scale resolves, so the VMAgent CR is recognized as a scalable controller, which makes the targeted Deployment by definition not topmost → VPA likewise reports ConfigUnsupported ("pods should be managed by the topmost controller").

So the embedded-VPA feature can never produce a functional VPA for VMAgent (and presumably VMAnomaly, which shares the sharding/scale machinery). A standalone VPA with targetRef pointing at the VMAgent CR itself (plus shardCount set so /scale works) is accepted by VPA and works — which suggests the fix.

Expected behavior

For CRDs that declare a scale subresource, the operator-generated VPA should set targetRef to the CR (operator.victoriametrics.com/v1beta1 / VMAgent / <name>), not the owned workload — that is the topmost scalable controller VPA requires. For sharded deployments this likely means one VPA targeting the CR rather than per-shard workload-targeted VPAs, or per-shard label-based matching via a different mechanism.

Related: GET /scale erroring when spec.shardCount is unset (follow-up to #2229) is what forces users to set shardCount: 1 explicitly even for non-sharded agents; fixing that would make the CR-targeted shape work out of the box.

To Reproduce

1. Operator v0.73.1 with VM_VPA_API_ENABLED=true and VPA RBAC granted.
2. VMAgent without shardCount, with any valid spec.vpa (updatePolicy + resourcePolicy).
3. Operator logs creating VPA=<ns>/vmagent-<name> targeting the Deployment; the VPA object goes ConfigUnsupported / NoPodsMatched and never emits recommendations.

Version

operator v0.73.1 (chart 0.66.2), Kubernetes v1.35.2, vertical-pod-autoscaler 1.5.1. Embedded VPAs on VMCluster roles (vmstorage/vmselect/vminsert) work correctly in the same setup — those workloads' CRD owner has no scale subresource, so the workload passes the topmost check.

[AndrewChubatiuk]

fix was included into release 0.74.0