[WIP][DO NOT MERGE] Proposal: Auto-scaling #546
Conversation
|
/cc @rajatchopra @abhgupta @ironcladlou @pmorie @smarterclayton @bparees @mfojtik @akram Looking for feedback. I would like to integrate as much as possible with the idling discussions going on as well. |
|
You should reference the appropriate kube issues: kubernetes/kubernetes#1629 and some of the deep links |
| Data used for auto scaling is based upon routes and the requests for those routes. The auto-scaler cares about the following | ||
| data points: | ||
|
|
||
| 1. network statistics (Requests Per Second, Sessions Per Second, Bytes In, Bytes Out, CPU Usage, Avg Request Duration) |
There was a problem hiding this comment.
There will be other statistics types potentially - anticipated load, historical data, etc. Reference those as other types of input
|
|
||
| ### Auto-Scaling Configuration | ||
|
|
||
| Auto-scaling config parameters will be added to the `ReplicationController` |
There was a problem hiding this comment.
Upstream has already stated this won't happen - this config needs to be part of either annotations, or in a separate resource you create "AutoScaleController". That's part of the reason why this proposal should be targeted at upstream, because they are likely to have very specific opinions about some of these constructs.
|
@smarterclayton Does it make sense to break this up into two PRs: one for auto-scaling that needs to be created on the existing issue (kubernetes/kubernetes#1629) and one for how it integrates with OpenShift routers (prior to routers/routes moving upstream)? |
|
|
||
| Auto-scaling is a feature that allows users to increase capacity as needed by controlling the number of replicas deployed | ||
| within the system based on request statistics. Auto-scaling is bidirectional, it will scale up to a specified limit as | ||
| requests increase and scale down to minimal capacity as the requests decrease. |
There was a problem hiding this comment.
Need to spend more time talking about what the goals of this proposal are and reference use cases.
|
Yes - in the upstream describe routers and the Kube proxy as example sources of qps info, with the autoscalers using that to take action. Give the routers as an example and then describe more in the OpenShift issue.
|
|
Ok, thanks for the guidance. |
|
@smarterclayton This PR has been updated with a more Kube specific version of the proposal. If this passes initial muster then I will add it to the proposal you linked previously for open comments. |
| @@ -0,0 +1,201 @@ | |||
| ## Abstract | |||
| Auto-scaling is a data-driven feature that allows users to increase or decrease capacity as needed by controlling the number of replicas deployed | |||
There was a problem hiding this comment.
Auto-scaling of pods.
| Within Kubernetes a [kube proxy](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/services.md#ips-and-portals) | ||
| running on each node directs service requests to the underlying implementation. | ||
|
|
||
| External to the Kubernetes core infrastructure (but still within the Kubernetes ecosystem) lies the OpenShift routing layer. |
There was a problem hiding this comment.
This reads weird. Just say "while the proxy provides internal inter pod connections, there will be L3 and L7 proxies and load balancers that manage traffic to backends. OpenShift, for instance, adds a "route" resource for defining external to internal traffic flow. The "routers" are HAProxy or Apache load balancers that aggregate many different services and pods and can serve as a data source for the number of backends."
|
@rajatchopra @abhgupta @ironcladlou @pmorie @smarterclayton @bparees @mfojtik @akram - ready for another round of feedback based on the changes already made. If everyone is comfortable with what is currently documented then I'll close this and move to an upstream issue. |
|
Excellent - reads great. When you submit upstream be sure to make the pull to the docs/proposals dir |
|
Closing in favor of upstream PR kubernetes/kubernetes#2863 |
Auto-scaling is a feature that allows users to increase capacity as needed by controlling the number of replicas deployed within the system based on request statistics. Auto-scaling is bidirectional, it will scale up to a specified limit as requests increase and scale down to minimal capacity as the requests decrease.
https://github.com/pweil-/origin/blob/035e0351a838a6ec6dcd65cc1977c85fca98ae5f/docs/autoscaling.md