Skip to content

README.md

Latest commit

 

History

History
39 lines (28 loc) · 3.56 KB

README.md

File metadata and controls

39 lines (28 loc) · 3.56 KB

hvpa-controller

CI Build status Go Report Card

Goals

  1. The goal of HVPA is to re-use the upstream components HPA and VPA as much as possible for scaling components horizontally and vertically respectively.
    1. HPA for recommendation and scaling horizontally.
    2. VPA for recommendation for scaling vertically.
  2. Where there are gaps in using HPA and VPA simultaneously to scale a given component, introduce functionality to fill those gaps.
    1. HPA and VPA are recommended to be mixed only in case HPA is used for custom/external metrics as mentioned here. But in some scenarios it might make sense to use them both even for CPU and memory (e.g. kube-apiserver or ingress etc.)
    2. VPA updates the pods directly (via webhooks) which may confuse HPA (especially, when used for the same scaling metrics) as it may not see the changes in the upstream targetRefs.
  3. Where there is functionality missing in either HPA or VPA, introduce them to provide more flexibility during horizontal and vertical scaling. Especially, for the components that experience disruption during scaling.
    1. Horizontally and vertically silmultaneously
    2. Support for configurable (at the resource level) threshold levels to trigger VPA (and possibly HPA) updates to minimize unnecessary scaling of components. Especially, if scaling is disruptive
    3. Support for configurable (at the resource level) stabilisation time window in both the directions (up/down) to stabilize scaling of components. Especially, if scaling is disruptive
    4. Support for configurable maintenance window for scaling (especially, scaling in/down) for components that do not scale well smoothly (mainly, etcd, but to a lesser extent kube-apiserver as well for WATCH requests). This could be as an alternative or complementary to the stabilisation window mentioned above
    5. Custom resource support for VPA updates.
      • At the beginning, this would be with some well-defined annotations to describe which part of the CRD to update the resource requests.
      • But eventually, we can think of proposing a Resource subresource (per container) along the lines of Scale subresource.

Non-goals

  • It is not a goal of HVPA to duplicate the functionality of the upstream components like HPA and VPA.

Design of HVPA Controller

See the design documentation in the ./docs/ here.

Custom Resource Definition

🚧 Work in progress

Types

[DEPRECATED] See here.

Example

[DEPRECATED] See here.