Azure Kubernetes Service (AKS)
Have feedback for Azure Kubernetes Service (AKS)? Submit your idea or vote up an idea submitted by others. All of the feedback you share here will be monitored and reviewed by the AKS team. Remember that this site is only for feature suggestions and ideas. If you have technical questions or issues, please submit them to our GitHub issues page or on StackOverflow.
-
Please create all the kubernetes related resources in the same resource group.
The policies in the company don't allow custom naming for azure resource groups. This is really getting the way of using AKS for production use.
148 votes -
Support multiple availability zones for HA (high-availability) clusters
Allow k8s nodes/agent pool to be created in different/multiple availability zones, to support a highly-available (HA) cluster
120 votes -
Support non-interactive login for AAD-integrated clusters
Currently if your cluster is integrated with AAD, any kubectl command will prompt you for an interactive login, even after logging in via Azure CLI and obtaining Kubectl credentials using 'az aks get-credentials'.
This won't work for anything using automation (e.g. a CI server such as Jenkins).
Ideally one could log in using a service principal who is then mapped to roles using RBAC. Once you are logged in via the Azure CLI, you could obtain the credentials and execute Kubectl commands as normal.
Original issue here: https://github.com/Azure/AKS/issues/556
A similar issue was raised here, but I would like to be…
92 votes -
low priority VMs (and VMSS)
It would be really nice if AKS could support low priority VM scale sets.
It seems that support for VMSS is already in the works and available as a preview.
The original request was mentioned here:
https://github.com/Azure/AKS/issues/29050 votes -
Support for Azure Monitor Autoscale
Provide support for Azure Monitor Autoscale that automatically adds instances based on a metric.
This would allow us to mitigate issues and create awareness about them without any manual action.
Bonus points if we can remove instances as well.
49 votesPlease take a look at the Kubernetes cluster autoscaler and let us know if you see the need for additional capabilities or a different approach.
-
Support VM Disk Encryption
Azure Security Recommendations notice that the disks provisioned as part of the Kubernetes Service cluster are not encrypted. And according to the AKS FAQ (https://docs.microsoft.com/en-us/azure/aks/faq),
"Modifying the resources under the MC_* in the AKS cluster breaks the SLO."A method to encrypt the disks should be made available.
25 votes -
Allow LoadBalancers to bind to Static IPs, created in the AKS Resource Group
At the moment LoadBalancers can only bind to IPs, created in the automatically created AKS ResourceGroup (the one starting with MC_).
As I'm not a fan of manually editing automatically created resources. I would like to be able create IPs besides the AKS resource and let my LoadBalancers bind to them.
22 votes -
Support for Event Grid events
Provide support for Event Grid events so that it provides integration points
First events that come to my mind:
- Deployment Created
- Deployment Succeeded
- Cluster Scaling Initiated
- Pod Scaling Initiated
- Pod Starting
- Pod Failed
- ...18 votes -
Option to assign public IPv4 addresses to AKS nodes
Please add support to automatically allocate (and associate) public IPv4 addresses with each AKS worker node. Currently the only way to do this is to manually add an Public Ipv4 address to the primary NIC (when using Advanced Networking).
The need is that our application (a UDP based streaming platform) needs direct Internet addressability in order to be able to stream using custom protocols. This needs to be done in combination with Advanced Networking to get good performance.
17 votes -
AKS should add new nodes to the clcuster when existing nodes crash/get deleted
AKS should add new nodes to the cluster when existing nodes crash/get deleted
16 votes -
Allow IP range changes
Currently it is not possible to change the pod nor service IP ranges (CIDR subnets) after an AKS cluster has been created. Therefore it is necessary to over-size IP ranges in case plans change and more services & pods are needed. If IP addresses run out, the only option available is to recreate the cluster entirely.
If AKS allowed changes to these IP ranges, fewer cluster recreations and better sizing would be possible.
13 votes -
Adding data disks to AKS nodes
Copied from https://github.com/Azure/AKS/issues/401
It could be possible to add data disks to nodes in AKS at provisioning time? Pretty much like
"diskSizesGB": [30, 30],
in acs-engine, or the option --data-disk-sizes-gb for the az vm create command. I'm playing around with OpenEBS, and it's easy to setup distributed storage on separated partitions, but it'll be easier if I have those disks mounted at boot (now I need to manually create/attach managed disks, and ssh into each node).11 votes -
Make Kubernetes Dashboard Deployment Optional
It is not desirable to have the kubernetes-dashboard deployed by default in all scenarios and it should be the decision of the end-user to determine if it should be installed or not (assuming it is not required for ongoing support by Microsoft).
Examples of mis-configured dashboards include https://redlock.io/blog/cryptojacking-tesla and whilst we don't forsee a problem with the current setup ideally we would stop deploying a service we do not require.
If we choose to remove the kubernetes-dashboard deployment from our current implementation the addon-manager will re-deploy it effectively undoing the removal.
9 votes -
Run custom script extension when provisioning new agent nodes
It would be useful to customise agent deployment at a very early stage.
For example: configuring a proxy for Docker, or sending a command to open a firewall during the install, adding privates certificates to Docker etc.
Using Daemonsets is not accurate to tune the system before kubernetes start.
4 votes -
Auto generated tags via deployment manifests
Description:
When a service is created in AKS such as a load balancer, or a disk, which ties back to an Azure resource, add the ability to tag the resource right in the deployment manifest. For organizations requiring strict tagging policies on resources in their Azure accounts, the creation of resources within AKS leaves un-tagged resources in the account.The outcome of this would be that you, Microsoft, would be empowering your customers with the ability to dynamically organize your resources in the account as they're dynamically created in AKS.
4 votes -
Support Standard SSDs as storage class
Currently it seems that only Standard HDD and Premium SSD is supported to be used in a storage class. We would like to select a standard SSD for our test databases also.
4 votes -
Restarting Nodes or Scaling Shouldn't Reset Network Security Group Inbound Rules to Default
Similar to GKE, restarting a node or scaling should not overwrite any user changes to network security group rules. This would allow users to easily lock down externally facing services to a range of IP addresses.
4 votes -
Secure Kubernetes Dashboard with Azure Active Directory
Should be able to have a Kubernetes dashboard secured by and use rights from a proxy with an Azure AD token.
2 votes -
Having the ability to let Service Principal (non-interactive apps) to consume AKS API without device login when AAD integration is used.
When AAD integration is used on an RBAC AKS cluster [1], you can assign roles to users and groups. These users will have to **interactively** authenticate with devicelogin the first time they try to access the AKS API.This is good for humans but not that much for automation processes using Service Principals.
Service Principal based applications need to go through devicelogin page to consule AKS API's.
It would be nice to have a way to allow Service Principals to gain RBAC access to AKS API's **without** device login
[1] Like this way: https://docs.microsoft.com/en-us/azure/aks/aad-integration
1 vote -
Set the DNS name of a static IP for an AKS Service of Type: LoadBalancer so it can be used in Traffic Manager
When pointing an Azure Traffic Manager endpoint at an AKS Service of Type: LoadBalancer, Traffic Manager will not allow you to use the Load Balancer's IP as an endpoint because the DNS name is not set by default and there's practically no documentation on the error message you get. Because of this, you need to set the DNS name outside of Kubernetes. If the DNS name were set by default, the LoadBalancer's IP could be used without the extra steps or unexpected error message.
1 vote
- Don't see your idea?