Closed alk-rniveau closed 4 years ago
Hi alk-rniveau, AKS bot here :wave: Thank you for posting on the AKS Repo, I'll do my best to get a kind human from the AKS team to assist you.
I might be just a bot, but I'm told my suggestions are normally quite good, as such: 1) If this case is urgent, please open a Support Request so that our 24/7 support team may help you faster. 2) Please abide by the AKS repo Guidelines and Code of Conduct. 3) If you're having an issue, could it be described on the AKS Troubleshooting guides or AKS Diagnostics? 4) Make sure your subscribed to the AKS Release Notes to keep up to date with all that's new on AKS. 5) Make sure there isn't a duplicate of this issue already reported. If there is, feel free to close this one and '+1' the existing issue. 6) If you have a question, do take a look at our AKS FAQ. We place the most common ones there!
@alk-rniveau the deployment you linked is for running your own (unmanaged) cluster-autoscaler in an AKS cluster. In the managed autoscaler case which you enable via --enable-cluster-autoscaler
in CLI or enableAutoScaling
in ARM templates - the only applicable resource you can view in your cluster is the configmap that gets created.
Thanks for your answer but here is my issue:
I would like to pause the CA during some periods as we can see here https://github.com/hellofresh/eks-rolling-update/ (yes it's for eks).
Why can't we watch deployment with the managed solution ?
@alk-rniveau it seems that this assumes the existence of cluster autoscaler in your cluster. With the managed solution, the actual autoscaling component .
Some alternatives you can consider:
az aks nodepool --disable-cluster-autoscaler
scan-interval
in seconds.I'm interested in your use-case, what's your use case? Are you trying to prevent scale down? If so, we can expose another parameter that allows you to disable scale down completely.
My use case is the following:
Sometime I redeploy many deployments in the same time. This manipulation can cause a useless scaleup node. This is useless because once the burn phase is over (after the deployment), this node is scaled down.
It's not a load from bigger usage of the platform, but just due to the max surge behavior.
@alk-rniveau would setting new-pod-scale-up
delay overcome that case for you then? This basically says "wait until pods are x age old" before considering a scale-up.
this parameter is not is the doc https://docs.microsoft.com/fr-fr/azure/aks/cluster-autoscaler. I think this parameter come from this issue https://github.com/Azure/AKS/issues/1716. Sad :( Do you know if terraform provider will be updated ? https://github.com/terraform-providers/terraform-provider-azurerm
Following up on the doc update now.
For the Terraform provider, it's better to open up an issue there. The Go SDK for the September API should be available and ready to consume by Terraform.
What happened:
Based on this example https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/cloudprovider/azure/examples/cluster-autoscaler-aks.yaml, it seems when we enable cluster-autoscaler, some elements are created within the cluster.
Currently, I can only get the config map and watch events. I would like to know if it's possible to get other elements with kubectl (I can't see nothing)
What you expected to happen:
Have a vision about pod or other elements which compose the cluster-autoscaler.
Environment: