chore: remove azure-vnet binaries which are installed from container

[rbtr]

What type of PR is this?
/kind cleanup

What this PR does / why we need it:
Remove azure-vnet-cni-swift and azure-vnet-cni-overlay tarballs which have been superseded by dropgz images.

Which issue(s) this PR fixes:

Fixes #

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Special notes for your reviewer:

Release note:

none

[coveralls]

Pull Request Test Coverage Report for Build 9274280896

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 75.969%

---

Totals
Change from base Build 9273907364:	0.0%
Covered Lines:	2627
Relevant Lines:	3458

---

💛 - Coveralls

[AbelHu]

Should we always not install cni for swift and overlay cni on WIndows nodes?
Currently we always call Install-VnetPlugins to install azurecni set in VNetCNIPluginsURL.
If we do not need to install swift and overlay cni, I think that rp can set it to empty and we can ignore it in Windows CSE.
Same question for Set-AzureCNIConfig
https://github.com/Azure/AgentBaker/blob/master/staging/cse/windows/azurecnifunc.ps1

[rbtr]

Should we always not install cni for swift and overlay cni on WIndows nodes?

The CNI binary is being installed via init-container in swift and overlay, on Linux and Windows, and we don't need to bake it in to the Nodes anymore. It will also be installed via init-container in node-subnet/legacy for k8s 1.30+, so I left it there for now to keep supporting <=1.29.

However, I forgot that these tarballs also have the CNI conflist. We still need the conflist baked in for Windows nodes, so I am reverting what I changed on Windows for now. If we can move the conflist responsibility to CNS like we have done on Linux then we can remove them in the future.

[rbtr]

@AbelHu can you remove the block, I have reverted any change to Windows VHD for now.

[anujmaheshwari1]

lgtm, thanks!

[paulgmiller]

Need to follow rp release with best effort.

[paulgmiller]

but yes lets go!

stale

[james-bjss]

We have noticed after updating our nodes that the /etc/cni/net.d/10-azure.conflist file (CNI Config) is no longer present on the system. The daemonset config for the dropz init container is also missing the argument to generate this file. This breaks chaining CNI plugins like Kuma.

Example of our Daemonset:

   initContainers:
      - args:
        - deploy
        - --skip-verify
        - azure-vnet
        - -o
        - /opt/cni/bin/azure-vnet
        - azure-vnet-telemetry
        - -o
        - /opt/cni/bin/azure-vnet-telemetry
        - azure-swift.conflist
        - -o
        - /etc/cni/net.d/15-azure-swift.conflist

Elsewhere we can see in the azure-container-networking repositories that this is created by dropz where it has the following args to generate 10-azure.conflist. See: https://github.com/Azure/azure-container-networking/blob/de225e4d34f824c641a7cce906039addf8f64d49/.pipelines/mdnc/azure-cns-cni-1.5.4.yaml#L102C10-L102C208

Is this intentional or a regression? Newer nodes don't seem to have the 10-azure.conflist file and it looks like this may have started happening since the change on this PR or similar.

[wedaly]

Is this intentional or a regression? Newer nodes don't seem to have the 10-azure.conflist file and it looks like this may have started happening since the change on this PR or similar.

hi @james-bjss I don't think the issue you described is related to this PR. Could you please create a new GitHub issue in https://github.com/Azure/AKS and tag me?

It would be helpful to include this information about your cluster (which you can get from az aks show)

• k8s version
• networkPlugin
• networkPluginMode
• podSubnetId (if any)

Thanks!

[james-bjss]

Is this intentional or a regression? Newer nodes don't seem to have the 10-azure.conflist file and it looks like this may have started happening since the change on this PR or similar.

hi @james-bjss I don't think the issue you described is related to this PR. Could you please create a new GitHub issue in https://github.com/Azure/AKS and tag me?

It would be helpful to include this information about your cluster (which you can get from az aks show)

• k8s version
• networkPlugin
• networkPluginMode
• podSubnetId (if any)

Thanks!

Sure my colleague @fozturner is going to pick this up and raise a new issue. Agreed, we did some further testing and it seems unlikely its related to the above.

Done: Azure/AKS#4349