Output VMSS dynamic name within AKS

[minfeihe-tomtom]

What happened:

Currently VMSS of AKS is dynamically named and not outputted within AKS.

What you expected to happen:

We are using Infrastructure as Code to provision AKS cluster and enable VM insights for those VMSS. Therefore, we need to read the VMSS name outputted from AKS cluster.

How to reproduce it (as minimally and precisely as possible):

Provision AKS via IaC and no VMSS name in AKS outputs.

Anything else we need to know?: None

Environment:

• Kubernetes version (use kubectl version): 1.20.9 [AKS version]

[ghost]

Hi minfeihe-tomtom, 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!

[ghost]

Triage required from @Azure/aks-pm

[robincher]

Support this, it allow us to spin up App GW whenever AKS is up in a single IaC run.

It can be done easily in AWS ,not sure what stopping AKS from doing that.

[ghost]

Action required from @Azure/aks-pm

[bhavenst]

I was looking for a way to get (or set) the auto-created VMSS name within an ARM/bicep template in order to add a managed identity to the VMSS for metered billing, but wound up here. So I also request the VMSS name to be accessible (or settable) while deploying the cluster.

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[dc232]

Hey all +1 on this would be great to have this feature implemented, especially when vmss is being generated dynamically via the creation of aks clusters, when combined with the option of assigning public IPs to nodes not having this feature it becomes difficult to know what the public IP addresses are programmatically through tools like terraform when the nodes are being created through things like autoscalers so that additional provisioning/hardening of the nodes can take place

[ghost]

Issue needing attention of @Azure/aks-leads

[elkh510]

Hey all +1 on this.

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[elkh510]

hi any update ?

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[deantlvtech]

Hey all +1 on this. please add this feature, for all of us ..

[robincher]

Will unsubscribe from this.

I think we can just hope for the best , Azure product roadmap seems to be rigid and not really dev-friendly.

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[hatfarm]

Looks like this still needs attention. I see the bot has been asking for months, has anyone looked at this?

[ghost]

Issue needing attention of @Azure/aks-leads

[paulgmiller]

@phealy sicne two of these asks are network related. (app gateway and public ip)

In general though we're tyring to push customers away from touching things inside the node resource group.

[ghost]

Triage required from @Azure/aks-pm

[ghost]

Action required from @Azure/aks-pm

[elopsod]

@phealy sicne two of these asks are network related. (app gateway and public ip)

In general though we're tyring to push customers away from touching things inside the node resource group.

hi @hatfarm @paulgmiller we need to install Linux diagnostic extension if we wont to do this via terraform, we need to know vmss id for now this is not possible, because azure provider not allowed this so we don't need to change something in vmss, just get full details about it

[jkroepke]

As I know, Azure Policies can be used to install VM Extensions automaticly. (In some way, Azure Policies are some kind of MutatingWebhooks) (Maybe https://learn.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-enable-policy helps)

[elkh510]

@jkroepke hi

As I know, Azure Policies can be used to install VM Extensions automaticly. (In some way, Azure Policies are some kind of MutatingWebhooks) (Maybe https://learn.microsoft.com/en-us/azure/azure-monitor/vm/vminsights-enable-policy helps)

we tried this option - it doesn't work. why not just return reference information about the vmss? if this is such a big problem for azure, perhaps you can make a data source where you can pass the cluster id (or name) and get REFERENCE information about all vmss

[jkroepke]

if this is such a big problem for azure,

I mean, if you do changes on the default node pool, it will re-create your whole cluster. So do not expect such features in near future.

Not sure, why Azure policies wont work here ... I mention that Azure Policies also have some delay for new resources.

[elkh510]

@jkroepke hi

I mean, if you do changes on the default node pool, it will re-create your whole cluster

If change noodepool - yes But if change vmss - all good

Not sure, why Azure policies wont work here ... I mention that Azure Policies also have some delay for new resources.

Will try one more time, thank you

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[ghost]

Issue needing attention of @Azure/aks-leads

[kceiw]

We also need to add an extension to the vmss after the aks and the pool are created. Ideally doing that in ARM. It's impossible to know the name of the generated vmss name. In addition, the vmss is created in a separate resource group which also adds to the difficulty. The resource group issue is solvable but the vmss name is not so far. Ideally, we can get the vmss name from the result of a [reference] return object. We have them in different arm template files and they're not necessary chained together or it's not easily get the output from a previous arm template deployment.

[ghost]

Triage required from @Azure/aks-pm

[ghost]

Action required from @Azure/aks-pm

[ghost]

Action required from @chasewilson.

[stenneepro]

Any update? I have to add user managed identity to AKS virtual machine scale sets. As azurerm_kubernetes_cluster doesn't return vmss names, I have to manually assign identity to vmss in Azure portal. It's really annoying.

[pradorodriguez]

Is there any update about this request?