Closed phillebaba closed 2 years ago
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle rotten
Please send feedback to sig-contributor-experience at kubernetes/community.
/close
@k8s-triage-robot: Closing this issue.
What would you like to be added:
Additional VPA metrics containing the resource request and limit made by a Deployment or Statefulset.
Why is this needed:
VPA currently exposes the metric
kube_verticalpodautoscaler_status_recommendation_containerrecommendations_target
which contains the recommended memory and cpu resource request for each Deployment and Statefulset. Each time series contains the labelstarget_kind
,target_name
, andcontainer
to identify the Deployment or Statefulset which the recommendation is for. Kube State Metrics on the other hand exposes the metrickube_pod_container_resource_requests
which contains the memory and cpu request made by a pod. Merging these time series with each other becomes a difficult process as they reference different resource names and kinds. This means that comparing the recommended value with the actual request is not easily achievable.Describe the solution you'd like
An optimal solution would be to have VPA expose an additional metric containing the current resource request/limit of the Deployment or Statefulset. I know that this is not an optimal solution as it does not consider updates to Deployments etc. but in this case I think that most people are only interested in the current value set, not if the Deployment has successfully rolled it out or not.
Issue #1536 gives some suggestions of how this can be solved with PromQL. My issue with that solution is that it becomes very complex and difficult to debug in the future.
Additional context
N/A