Skip to main content

​
Overview

When the vertical scaling admission webhook mutates a pod’s resource requests (or limits) in autonomous mode, it annotates the pod:
These are written once, at pod admission (CREATE), by the mutating webhook only — not by in-place resize, which patches running pods directly without going through admission.
This is scoped to the pod-mutating webhook, which covers both vertical AIScaleTarget rightsizing and initial resource seeding by a DaemonSetAutoscaler. Horizontal scaling (replica count), which mutates the */scale subresource instead of the pod, is a separate webhook and does not set these annotations.

​
What This Answers

thoras.ai/managed: "true" means “the webhook set this pod’s resources at admission,” and nothing stronger. Use it to answer: did Thoras’s mutating webhook write to this pod’s resources, as opposed to the controller’s pod template, another mutating webhook, or a manual kubectl edit. It does not mean “Thoras currently manages this pod.” Two situations produce a pod that is annotated managed: "true" but is no longer representative of Thoras’s current recommendation:

​
Pods Predate Autonomous Mode

An AIScaleTarget switched into autonomous mode only annotates pods that are admitted (created) after the switch. Pods that were already running keep being resized in place by the disruption worker and are never re-admitted, so they stay unannotated until they’re naturally recreated (a rollout, eviction, node drain, or manual restart). Once a pod turns over, it goes through the webhook and picks up the annotation on its next admission.

​
The Annotation Isn’t Cleared When Thoras Stops Managing a Pod

Switching an AIScaleTarget out of autonomous mode, or unenrolling it (see Stopping Autonomous Scaling), reverts running pods to their controller’s template values with an in-place resize wherever possible — the pods are not recreated, so they are never re-admitted and the webhook never runs again to clear the annotation. A reverted pod keeps thoras.ai/managed: "true" while sitting at template values. As with the case above, this self-heals the next time the pod is recreated for any reason: a fresh admission with nothing to mutate does not set the annotation. When the in-place revert can’t apply (for example, the template declares a different set of resource keys than the running pod, which would change its QoS class) and the update policy permits recreation, Thoras falls back to restarting the workload — those pods are recreated and come back without the annotation. Both cases are false positives on a pod Thoras did mutate at some earlier admission, consistent with the annotation’s actual meaning — never false positives claiming Thoras is currently managing a pod it isn’t.