Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implemented Linear Controller and added unit test. #5

Merged
merged 2 commits into from
Nov 3, 2016

Conversation

MrHohn
Copy link
Member

@MrHohn MrHohn commented Oct 19, 2016

The autoscaler are now supporting one more control pattern: linear mode. An example for the ConfigMap params as below:

data:
  linear: |-
    { 
      "coresPerReplica": 2,
      "nodesPerReplica": 1,
      "min": 1,
      "max": 100
    }

Because serious performance evaluation of kube-dns might not be finished soon, I would like to use this simple pattern for the DNS horizontal scaling for now (will tune the specific params). Details for this new pattern are updated in README.

@bowei @thockin @bprashanth
cc @matchstick

@thockin
Copy link

thockin commented Oct 20, 2016

this is net simpler, which is good. I forget why Girish wanted the ladder mode. Do we need to keep it?

@MrHohn
Copy link
Member Author

MrHohn commented Oct 20, 2016

I don't think he gave out the reason. But I think it does not harm to keep it.

@thockin
Copy link

thockin commented Oct 20, 2016

Dead code is a liability - keeping it around means we support it and debug
it and compile it and test it. If we really think linear is sufficient,
and I don't see why not, we should remove the ladder. YAGNI.

https://dougseven.com/2014/04/17/knightmare-a-devops-cautionary-tale/

On Wed, Oct 19, 2016 at 5:46 PM, Zihong Zheng notifications@github.com
wrote:

I don't think he gave out the reason. But I think it does not harm to keep
it.


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVB0BYG-Kqe_GfKkt2l--DhsbKS81ks5q1rn4gaJpZM4KairZ
.

@MrHohn
Copy link
Member Author

MrHohn commented Oct 20, 2016

Your concern totally makes sense, but I vote for keeping the ladder mode:

  • I won't say ladder mode is completely useless. It is, in my opinion, another common and intuitive control pattern.
  • linear mode might be sufficient for kube-dns scaling. But I would like to see other applications also use this autoscaler and they may have different requirements.
  • ladder mode does something that linear mode can not do. It provides users more flexibility and customization. Before we have better substitute for it, I would like to support this pattern.

@bowei
Copy link
Contributor

bowei commented Oct 20, 2016

I would agree with keeping ladder as it is a way out for people to implement their own arbitrary scaling function

@thockin
Copy link

thockin commented Oct 25, 2016

OK.

On Thu, Oct 20, 2016 at 3:24 PM, Bowei Du notifications@github.com wrote:

I would agree with keeping ladder as it is a way out for people to
implement their own arbitrary scaling function


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFVgVEkwsdukB4SD4I6bO_JQpg8lqtMWks5q1-omgaJpZM4KairZ
.

Max int `json:"max"`
}

func (c *LinearController) SyncConfig(configMap k8sclient.ConfigMap) error {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this seems to be duplicated from ladder controller. Can we move this to a common base struct or move the version change logic out.

See https://play.golang.org/p/fBLkWIZR01

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Moved out the version change logic.

}

// parseParams Parse the params from JSON string
func parseParams(data []byte) (params *linearParams, err error) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you don't reference params or err, probably should leave them anonymous

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

numResources int
expReplicas int
}{
{testController, 0, 2},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is testController the same for all the testcases? can we remove this field from the struct?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed.

}
}

func TestControllerScaler(t *testing.T) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no testing of max between linear on nodes and linear on pods

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added one more test.

Copy link
Contributor

@bowei bowei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

some doc nits

}
```

The idea of linear control mode is simple: how many cores or nodes could be taking care by one replica?
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should put the equation and then give the example

replicas = max( cores * 1/coresPerReplica , nodes * 1/nodesPerReplica )

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, an equation will explain the idea more clearly. Added.

@@ -77,7 +77,7 @@ spec:
app: autoscaler
spec:
containers:
- image: gcr.io/google_containers/cluster-proportional-autoscaler-amd64:0.7.2
- image: gcr.io/google_containers/cluster-proportional-autoscaler-amd64:0.8.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is the patch number still .2? I would think this will be 0.8.0

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

app: autoscaler
spec:
containers:
- image: gcr.io/google_containers/cluster-proportional-autoscaler-amd64:0.8.2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix it here as well

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed.

Copy link
Contributor

@bowei bowei left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@MrHohn
Copy link
Member Author

MrHohn commented Nov 3, 2016

Thanks! Self merging.

@MrHohn MrHohn merged commit 7a0a4e2 into kubernetes-sigs:master Nov 3, 2016
@MrHohn MrHohn deleted the linear_controller branch October 5, 2017 00:59
sftim pushed a commit to sftim/cluster-proportional-autoscaler that referenced this pull request Feb 27, 2023
coredns: Add customlabels to configmap
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants