From 2ee9ebea2ba882cdf536c46f219454145fbf8e43 Mon Sep 17 00:00:00 2001 From: AdamDang Date: Wed, 28 Mar 2018 21:29:25 +0800 Subject: [PATCH] Update pricing.md "n1-standard-..." should be changed to "N1-standard-..." In this doc, mostly using "N1-standard-...", but there are several "n1-standard-...", too. It's better to use same format. --- cluster-autoscaler/proposals/pricing.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/cluster-autoscaler/proposals/pricing.md b/cluster-autoscaler/proposals/pricing.md index 3a1b773422..548e03aa08 100644 --- a/cluster-autoscaler/proposals/pricing.md +++ b/cluster-autoscaler/proposals/pricing.md @@ -66,9 +66,9 @@ W1 * C/T + W2 * NodeUnFitness ``` While this linear combination sounds cool it is a bit problematic. -For small or single pods C/T strongly prefers smaller machines that may not be the best for the overall cluster well-being. For example C/T for a 100m pod with n1-standard-8 is ~80. -C/T for n2-standard-2 is 20. Assuming that n1-standard-8 would be a node of choice if 100 node clusters W2*NodeUnFitness would have to be 60 (assuming, for simplicity, W1 = 1). -N1-standard-2 is only 4 times smaller than n1-standard-8 so W2 = 15. But then everything collapses with even smaller pod. For a 50milli cpu pod W2 would have to be 30. So it’s bad. C/T is not good for the linear combination. +For small or single pods C/T strongly prefers smaller machines that may not be the best for the overall cluster well-being. For example C/T for a 100m pod with N1-standard-8 is ~80. +C/T for n2-standard-2 is 20. Assuming that N1-standard-8 would be a node of choice if 100 node clusters W2*NodeUnFitness would have to be 60 (assuming, for simplicity, W1 = 1). +N1-standard-2 is only 4 times smaller than N1-standard-8 so W2 = 15. But then everything collapses with even smaller pod. For a 50milli cpu pod W2 would have to be 30. So it’s bad. C/T is not good for the linear combination. So we need something better. @@ -119,7 +119,7 @@ NodeUnfitness*(C + X)/(T+X) | N1-standard-8 | 1 * (0.380 + 0.016) / (0.003*15 + 0.016) | 6.49 | | N1-standard-2+GPU | 4 * (0.795 + 0.016) / (0.003*15 + 0.016) | 52 | -Looks better. So we are able to promote having bigger nodes if needed. However, what if we were to create 50 N1-standard-8 nodes to accommodate 50 x 1.5 cpu pods with strict PodAntiAffinity? Well, in that case we should probably go for n1-standard-2 nodes, however the above formula doesn’t promote that, because it considers the node unfit. So when requesting a larger number of nodes (in a single scale-up) we should probably suppress NodeUnfitness a bit. The suppress function should reduce the effect of NodeUnfitness when there is a good reason to do it. One of the good reasons is that the other option is significantly cheaper. In general the more nodes we are requesting the bigger the price difference can be. And if we are requesting just a single node +Looks better. So we are able to promote having bigger nodes if needed. However, what if we were to create 50 N1-standard-8 nodes to accommodate 50 x 1.5 cpu pods with strict PodAntiAffinity? Well, in that case we should probably go for N1-standard-2 nodes, however the above formula doesn’t promote that, because it considers the node unfit. So when requesting a larger number of nodes (in a single scale-up) we should probably suppress NodeUnfitness a bit. The suppress function should reduce the effect of NodeUnfitness when there is a good reason to do it. One of the good reasons is that the other option is significantly cheaper. In general the more nodes we are requesting the bigger the price difference can be. And if we are requesting just a single node then this node should be well fitted to the cluster (than to the pod) so that other pods can also use it and the cluster administrator has less types of nodes to focus on. We are looking for a function suppress(NodeUnfitness, NodeCount) that: