ci: [Service Tags] add public ips with service tags for LBs during cluster creation

[k-routhu]

Reason for Change:

Adding service tags to all public ips. This change adds public ips and attaches these ips as load balancer outbound ips during cluster creation. Branch spathak/add-service-tags is where all the changes were made and tested -- created this branch based off of that one.

Testing:

• All testing was done on branch spathak/add-service-tags
• We had a couple of PRs out by Esteban and Shubham to update service tags. However, all of the PRs targeted hack/aks/Makefile, so I went ahead and made all of the updates in this branch.
• Also added ipv6 public ips to load balancer outbound ips for dualstack clusters to resolve errors

Tested changes in a couple of Cilium pipelines:

Cilium Nightly Pipeline
The public ips created have service tags attached to them, and the ips fall within the allowed ranges for the locations they were created

CNI Release Test
All of the public ips created have service tags attached to them, and the ips fall within the allowed ranges for the locations they were created

CNI - LSG Integration Test
The clusters get created here successfully with the correct public ips. The integration tests do fail, but I checked with John Payne -- he mentioned that the integration tests fail frequently because they're heavily dependent on a partner team (Canonical). He suggested running Cilium Private Test pipelines on v1.14 and v1.16 (the next two on the list) and the remaining pipelines with the service tags. The remaining pipelines look good and create public ips as expected, so I believe we should be good to go on that front.

ACN PR Pipeline
All of the public ips created have service tags attached to them, and the ips fall within the allowed ranges for the locations they were created

[thomasricci]

Did we request IPV6 ips for our test ST ?

[k-routhu]

discussed offline, should be good to go on ipv6

[rbtr]

are these strings pre-determined?

[k-routhu]

IP_TAG is predetermined, but IP_PREFIX is not -- I believe that's just a variable Shubham had created for naming the public ips we create and tag for this workflow

[rbtr]

why are you reinvoking Make for this? unless you are overriding or changing args and options versus the Make invocation you are already in, you could make the IP target a dependency here, like rg-up etc.

[timraymond]

Why are we using make for this? Can't most of this be done more predictably by Bicep/ARM?

[rbtr]

Why are we using make for this? Can't most of this be done more predictably by Bicep/ARM?

@timraymond yes and no.
AzCLI is basically a wrapper to ARM when used like this and that's what it actually sends, so in a literal sense, yes. Bicep would be even better for declarative infrastructure.

I originally wrote this Makefile because I needed to build infra that required certain subscription flags enabled (which ARM may be able to do, but was documented as AzCLI commands), and a certain preview CLI installed locally and/or a preview AZ AKS plugin installed locally. This made it easy for everyone to deploy infra identically without copy/pasting out of some install steps OneNote every time.
And, more importantly to me at the time, AzCLI (including ARM, Bicep, and anything that depends on it) was and is still completely busted on Fedora. Platforming everything in the azure-cli container makes this totally portable.

I also find it nice to have a central list of capabilities. We could write Bicep for everything here, but I think I would still want the Makefile to exist as the single entrypoint to all of the bicep apply <scenario> so that it's all easy to find (and to wrap in the azcli image so that IT WORKS AT ALL 😤)

[github-actions]

This pull request is stale because it has been open for 2 weeks with no activity. Remove stale label or comment or this will be closed in 7 days

[github-actions]

Pull request closed due to inactivity.

[k-routhu]

re-opening PR

[jpayne3506]

Line up ?=

[jpayne3506]

Lgtm.

[rbtr]

/azp run Azure Container Networking PR

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).