Support bring your own Azure Network Interface

[dthorsen]

/kind feature

Describe the solution you'd like Add support for "bring your own" Azure Network Interface. In order to support applications that require IP addresses that never change, even across machine deletion/recreation, we would like to add support to create network interfaces outside of CAPZ and reference them for use by AzureMachines/AzureMachineTemplates. This way a stable network interface could be detached from one VM when it is deleted, and attached to the replacement VM when it is created.

I propose that we add the following fields to the NetworkInterface struct:

name: "<name of existing azure network interface>"
resourceGroup: "<name of the resource group containing the network interface>"

The controller would implement logic similar to the "bring your own" Virtual Network implementation. The name and resource group are optional fields, and if specified would be used to check for an existing network interface.

If the network interface exists in Azure, the controller would check for the CAPZ ownership tag, and if it is not present, it would not manage the resource, but would only use it for attachment to a virtual machine, and adding to load balancer backend pools as necessary.

If the network interface exists in Azure, and the CAPZ ownership tag is present, CAPZ would manage the lifecycle of network interface.

If the network interface specified in the optional fields does not exist in Azure, then it would be created as it is today, but with the user-specified network interface name and resource group, then attached to the virtual machine.

Anything else you would like to add: Currently, the NetworkInterface type is also used within the AzureMachinePool spec, but this feature is not applicable there. It is not possible in the Azure VMSS API to create a VMSS with a network profile that specifies a specific network interface. The AzureMachinePool resource would be changed to use its own VMSSNetworkInterface type that does not contain these new fields.

[dthorsen]

/assign

[Jont828]

/milestone next

[k8s-ci-robot]

@Jont828: You must be a member of the kubernetes-sigs/cluster-api-provider-azure-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Cluster API Provider Azure Maintainers and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone next

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[mboersma]

/milestone next

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten