VPA: Improve Custom Resource Traversal in the Ownership Chain

[iamzili]

Which component are you using?

/area vertical-pod-autoscaler

Is your feature request designed to solve a problem? If so describe the problem this feature should solve:

Using the latest VPA code, the updater and the admission controller do not work for Pods when the ownerReferences chain has the following shape:

ParentObject (implements /scale)
  -> IntermediateObject (does NOT implement the /scale subresource)
    -> Pods

When the VPA object sets targetRef to the topmost object (the ParentObject), the updater and the admission controller cannot resolve the parent object starting from a Pod. In the source code, this object is referred to as controllingVpa (updater, admission controller).

The current logic requires every object in the ownership chain to implement the /scale subresource. Because of this requirement, the following ownership chains works:

ParentObject (implements /scale)
    -> Pods

or:

ParentObject (implements /scale)
  -> IntermediateObject (implements /scale)
    -> Pods

However, the logic fails when the intermediate object (or the parent) does not implement /scale.

The following two recently opened issues report this problem when the intermediate object does not implement the /scale subresource:

• VPA Custom Resource Traversal #8849
• VPA for KafkaNodePool returns "No pods found." #9061

Describe the solution you'd like:

At the moment, I can see two possible solutions:

1. Require /scale only on the topmost object: This option changes the code so that only the topmost (parent) object must implement the /scale subresource, i.e. intermediate objects do not need to implement /scale.The related code path is here. When the code traverses the ownerReferences chain starting from a Pod, it returns a nil owner and a NotFound error if an intermediate object does not implement /scale.

2. Re-evaluate the need to require /scale resources in VPA: This option may investigates why VPA needs to fetch /scale resources at all. VPA does not read the replica count and does not modify that field. I can imagine that there are some ownerReferences chains in which /scale is not used and VPA is still desired (though I'm not sure how common this is). In this case, even if we implement the first option, VPA would not work in their setup.

[iamzili]

/assign

cc @omerap12 @adrianmoisey I would like to hear your thoughts on this, thanks!

[omerap12]

In my opinion, we should not change this behavior.

VPA is designed to follow with Kubernetes /scale subresource (similar to how HPA works but not quite) as mentioned in our [docs] https://github.com/kubernetes/autoscaler/blob/master/vertical-pod-autoscaler/docs/faq.md#how-can-i-apply-vpa-to-my-custom-resource).

if an object manages Pods, it should implement the /scale subresource.

VPA is strict for a reason - to safely evict Pods, we must verify the ownership chain through the /scale subresource. This ensures that a controller is actually managing the Pods and will recreate them. The best fix is for the Custom Resource to implement the /scale subresource as required.

[iamzili]

In my opinion, we should not change this behavior.

I think I agree with you on keeping the /scale, but what is your opinion on "relaxing" this behavior by requiring /scale only at the parent level, and not for intermediate objects, i.e.:

ParentObject (implements /scale)
  -> IntermediateObject (does NOT implement the /scale subresource)
    -> Pods

[adrianmoisey]

However, the logic fails when the intermediate object (or the parent) does not implement /scale.

This is something I'd like to explore more.

If the Pod's owner is not a well-known resource, it fetches the scale subresource, and from that resource, fetches that resources owner.
Here's the code (see line 298 where it says "scale.OwnerReferences":

autoscaler/vertical-pod-autoscaler/pkg/target/controller_fetcher/controller_fetcher.go

Lines 282 to 305 in 2a1c663

	func (f *controllerFetcher) getOwnerForScaleResource(ctx context.Context, groupKind schema.GroupKind, namespace, name string) (*ControllerKeyWithAPIVersion, error) {
	if wellKnownController(groupKind.Kind) == node {
	// Some pods specify nodes as their owners. This causes performance problems
	// in big clusters when VPA tries to get all nodes. We know nodes aren't
	// valid controllers so we can skip trying to fetch them.
	return nil, ErrNodeInvalidOwner
	}
	mappings, err := f.mapper.RESTMappings(groupKind)
	if err != nil {
	return nil, err
	}
	var lastError error
	for _, mapping := range mappings {
	groupResource := mapping.Resource.GroupResource()
	scale, err := f.getScaleForResource(ctx, namespace, groupResource, name)
	if err == nil {
	return getOwnerController(scale.OwnerReferences, namespace), nil
	}
	lastError = err
	}
	// nothing found, apparently the resource doesn't support scale (or we lack RBAC)
	return nil, lastError
	}

However, I don't believe that the OwnerRef is available via the scale subresource API.
Ie:

k get rs hamster-7996dbb57 --subresource=scale -o yaml
apiVersion: autoscaling/v1
kind: Scale
metadata:
  creationTimestamp: "2026-01-19T17:17:32Z"
  name: hamster-7996dbb57
  namespace: default
  resourceVersion: "506"
  uid: 5667d223-1aac-4acd-80cd-b660cdd99d75
spec:
  replicas: 2
status:
  replicas: 2
  selector: app=hamster,pod-template-hash=7996dbb57

This is a ReplicaSet, so it should contain a ownerRef, but, notice how it doesn't.
EDIT: See https://github.com/kubernetes/kubernetes/blob/cb077823fb053eb3dff39334f5d9d44d7512477e/pkg/registry/apps/replicaset/storage/storage.go#L265-L288

I think I agree with you on keeping the /scale, but what is your opinion on "relaxing" this behaviour by requiring /scale only at the parent level, and not for intermediate objects, i.e.:

I assume this is possible, but, requires the VPA to have read access to all resource types. Having a scale subresource allows the VPA to have access to */scale, which solves for all types with a scale subresource.

[omerap12]

I assume this is possible, but, requires the VPA to have read access to all resource types. Having a scale subresource allows the VPA to have access to */scale, which solves for all types with a scale subresource.

This is the main point. We cannot give the VPA read access to all resources in the cluster (yeah even if it's read-only access)
Because of this, we use the scale subresource, which is what VPA and HPA work with.

[adrianmoisey]

Because of this, we use the scale subresource, which is what VPA and HPA work with.

Well, "work" isn't exactly the case, it's what they use.
From what I understand, VPA supports this:
Pod -> Custom Resource Owner

It doesn't support this:
Pod -> Custom Resource Owner -> Custom Resource Owner

The reason for this is that we can't determine the owner of the middle "Custom Resource Owner", since the scale subresource doesn't return it (well, I guess a custom resource's scale subresource could return owner, but the resources in k/k don't return the owner)

[omerap12]

Because of this, we use the scale subresource, which is what VPA and HPA work with.

Well, "work" isn't exactly the case, it's what they use. From what I understand, VPA supports this: Pod -> Custom Resource Owner

It doesn't support this: Pod -> Custom Resource Owner -> Custom Resource Owner

The reason for this is that we can't determine the owner of the middle "Custom Resource Owner", since the scale subresource doesn't return it (well, I guess a custom resource's scale subresource could return owner, but the resources in k/k don't return the owner)

Correct. this is why I think that this problem should be solved in the k/k level so that both components can utilize that.