How can we improve the Azure Kubernetes Service (AKS)?

← Azure Kubernetes Service (AKS)

Support multiple node pool

We are currently blocked to using a single node pool in AKS. It would be good to allow us to create new node pool (in different region) and to allow us to have a different VM size (per pool). Google and Amazon are already offering that feature.

420 votes
Sign in
(thinking…)
Sign in with: Microsoft
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Mathieu Nadeau shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

36 comments

Sign in
(thinking…)
Sign in with: Microsoft
Forgot password?
Create a password
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Bob Rundle commented  ·   ·  Flag as inappropriate

    The problem with AKS now, in my view, is you cannot have a AKS cluster with only Windows agent nodes. The initial agent pool is always a Linux pool, it has to have at least one node and furthermore it cannot be deleted because it is the primary node pool.

    This is a serious problem in my view. It means that you have to pay for a Linux agent node that is doing nothing. This is a massive kluge and I am certain that the AWS version of Windows k8s clusters EKS will not have such a limitation.

  • Frankel, Gabe commented  ·   ·  Flag as inappropriate

    As advertised on the AKS info page: (https://azure.microsoft.com/en-us/services/kubernetes-service/) "AKS is 100-percent open-source Kubernetes, enabling you to take full advantage of the services and tools in the Kubernetes ecosystem."

    This is simply not the case. Kubernetes allows vertical scaling. This is a HUGE limitation in the Kubernetes implementation. Where is the response on this????

  • Gabriel Fonseca commented  ·   ·  Flag as inappropriate

    Any news on this issue? It was delayed from Q3 2018 to Q3 2018, then again to Q1 2019. Now Q1 2019 is gone and no one answer the thousand questions are posted here and in github...

  • Ben commented  ·   ·  Flag as inappropriate

    We Reached the end of Q1 2019. Can we please get an update ?

  • Joe commented  ·   ·  Flag as inappropriate

    This issue has been pretty hot and understandably so but I just give thanks to the AKS for being so transparent on this issue in this GitHub thread. It's not normal but it is really appreicated. Even when timelines are pushed - thank you!

    https://github.com/Azure/AKS/issues/287

  • Trent Telfer commented  ·   ·  Flag as inappropriate

    This feature definitely needed. What sort of progress has been made? It looks like work started quite a while ago with no update.

  • Matt commented  ·   ·  Flag as inappropriate

    Update the community that's paying for your services, please.

  • Anonymous commented  ·   ·  Flag as inappropriate

    Dear Azure k8 Team,

    My hope is that this thread is better moderated and controlled than those on GitHub. Regarding the topic of this thread, my comments have been blocked twice now:
    1. https://github.com/Azure/AKS/issues/132
    2. https://github.com/Azure/AKS/issues/287

    I will repaste the last comment here, and expect a clear response on why it was deleted:

    > @trdavidson These features are on the roadmap, for 1H 2019 and will be linked/added to the changelog and preview document in the repo. I am sorry we do not meet your needs with this at this time, however: This repository, all commentary, etc is governed by our Code of conduct. Calling things insane, insinuating the team is not working on this, or doesn't care is inappropriate. Therefore I'm deleting your comments from this thread. I am also locking this thread as vertical scale up is not supported or planned at this time. VMSS, Node Pools and Availability zones are the recommended horizontal scaling system(s) and will be coming this year.

    Responding here per closed thread issue #132 and [this thread](https://feedback.azure.com/forums/914020-azure-kubernetes-service-aks/suggestions/34917127-support-multiple-node-pool). @jnoller apologies if the word 'insane' was not in line with the Code of conduct currently in effect.

    I do not doubt that the team is working hard, and have had positive experience with the Azure k8 team in the past. however, the current line of communication from the k8 team warrants raising some concern - generally:

    * developers build/design systems based on two main assumptions (1) current capabilities of a provider, (2) reasonable timeline of improvement/change of provider's capabilities.
    * with (1) should be reasonably available from the current provider Docs for the latest stable version
    * yet for (2) we are reliant on the clear communication of the provider, and use a common sense prior on past confirmation of said communication.

    When (2) is not aligned with the realized future too many times, developers have a fiduciary duty to their current employer/investors to strongly recommend to **not** use a certain provider's offered resources. Especially since designing said systems takes time, resources, and often locks the end-user in to a specific provider.

    In this specific case, with the provider being Microsoft Azure, and the product managed k8 clusters, the (2) communication falls short. When the official line of communication signals Q3 2018, then Q4 2018, and currently (at the end of Q1 2019) signals Q1 2019, there is a problem.

    To censor raising such a concern is concerning.

← Previous 1

Azure Kubernetes Service (AKS): Support for Kubernetes features

Categories

Feedback and Knowledge Base

(thinking…)
Hosted by UserVoice