The VPA 8,982 (github.com/kubernetes/autoscaler (https://github.com/kubernetes/autoscaler 8,982 ), Apache-2.0, 1.8.0) is an add-on: a CRD plus a recommender (usage history to target, lower- and upper-bound requests), an updater (evicts Pods, or resizes them in place, In-Place Pod Resizing) and a mutating admission controller (writes requests into new Pods). updateMode is Off, Initial, Recreate, InPlaceOrRecreate or the alpha InPlace; Auto has been a deprecated alias for Recreate since VPA 1.4. The recommender alone is harmless:
helm repo add autoscaler https://kubernetes.github.io/autoscaler >/dev/null
helm install vpa autoscaler/vertical-pod-autoscaler --version 0.13.0 -n kube-system \
--set admissionController.enabled=false,updater.enabled=false \
--set recommender.replicas=1 >/dev/null
kubectl apply -f - <<'EOF'
apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata: { name: api }
spec:
targetRef: { apiVersion: apps/v1, kind: Deployment, name: api }
updatePolicy: { updateMode: "Off" }
EOF
until kubectl get vpa api -o jsonpath='{.status.recommendation}' | grep -q target; do
sleep 10; done
kubectl get vpa api
helm uninstall vpa -n kube-system >/dev/null
kubectl delete crd verticalpodautoscalers.autoscaling.k8s.io \
verticalpodautoscalercheckpoints.autoscaling.k8s.io >/dev/null # Helm leaves a chart's CRDsverticalpodautoscaler.autoscaling.k8s.io/api created NAME MODE CPU MEM PROVIDED AGE api Off 25m 250Mi True 62s
The target, 25m of CPU and 250 MiB, is not a measurement: it is the recommender's floor (--pod-recommendation-min-cpu-millicores=25, --pod-recommendation-min-memory-mb=250), and the upper bound in its status was absurdly wide after a few minutes of idle data. Follow a VPA only after days of real traffic, and never let a VPA and an HPA both act on CPU or memory for one workload: each VPA change moves the HPA's percentages.