autoscaler

autoscaler copied to clipboard

We decided to use VPA in our AKS cluster as a solution for estimating the App required resources for our developers, so that they can give the resource specification in accordance with the usage of the app and not with a random guess . We assume the values recommended by VPA is a trusted one and can be directly used as per its suggestion.

So here noticed that VPA is recommending very lower values in comparison with what we used, So would like to understand below points.

• What are the factors VPA will be considering when its providing a recommended values.

• The VPA recommended values are static or it will be different or dynamic with each point of time?

• In our case our spring boot applications are taking more resources during its startup, and the actual usage will be less.. So will VPA will consider the startup resource requirement also, else it may fail our applications with this lower recommendation.

• Can we generate or get a better view (in a table format) for each apps and its VPa recommendation based on namespace? so that it can be automated using azuredevops pipeline and will generate or post the resulted tab to Azure Wiki dynamically.

Below is an sample recommendation provided by VPA.

Recommendation:
    Container Recommendations:
      Container Name:  MyContainer
      Lower Bound:
        Cpu:     10m
        Memory:  978002549
      Target:
        Cpu:     11m
        Memory:  1038683533
      Uncapped Target:
        Cpu:     11m
        Memory:  1038683533
      Upper Bound:
        Cpu:           12m
        Memory:        1180712687
      Container Name:  istio-proxy
      Lower Bound:
        Cpu:     10m
        Memory:  93607494
      Target:
        Cpu:     11m
        Memory:  93633096
      Uncapped Target:
        Cpu:     11m
        Memory:  93633096
      Upper Bound:
        Cpu:     12m
        Memory:  106436446

What are the factors VPA will be considering when its providing a recommended values.

VPA bases it's recommendation on history of resource usage of containers in the target (often deployment).

The VPA recommended values are static or it will be different or dynamic with each point of time?

They change over time. VPA in default configuration uses 8 days of history (with more weight given to more recent samples) so the changes should be slow in most cases (over days or hours, we don't big minute-to-minute changes) (it's possible to build artificial scenarios when VPA recommendation for CPU oscillates rapidly between two very different values but they are extremely unlikely).

In our case our spring boot applications are taking more resources during its startup, and the actual usage will be less.. So will VPA will consider the startup resource requirement also, else it may fail our applications with this lower recommendation.

Currently VPA provides only 1 recommendation, based on historical usage of all pods in the target deployment (or a different controller). Which might not work well if your pods use significantly more resources during startup. We're aware of the problem and want to address it after we implement #4016 (then we can have 2 recommendations - 1 applied at pod creation and the other one after startup finishes).

Can we generate or get a better view (in a table format) for each apps and its VPa recommendation based on namespace? so that it can be automated using azuredevops pipeline and will generate or post the resulted tab to Azure Wiki dynamically.

Not sure what you're asking for here. Better view than what? You could for example use kubectl with -ojson to get results in a format that is usually good for processing.

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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 according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.