azure: implicit nic creation + public ip support #2056
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The is a rework of the networking code. Currently we manage NICs explicitly, which requires a lot of code that is prone to race conditions and resource leaks. This PR changes the code to create NICs implicitly when creating a VM, the network resource will be managed as part of the VM lifecycle.
Public IPs
There's also an opt-in toggle to attach (a implicitly-managed public ip) to the podvm. This option is mostly relevant for development purposes, there are obvious risks to expose a podvm's services to the internet in production environments. A given kubernetes deployment might not allow nodes (and hence the kata runtime) to connect to a podvm on the internet, further network configuration is required in those cases.
PodVM internet access
In the current Pod VM deployment method, the VMs rely on a feature called Default Outbound Access. This will equip a machine with a transparent public ip if no other outbound connectivity means are configured. This feature is being retired due to security considerations. Today implicit NIC-management does not support this feature any more.
A PodVM might rely on internet connectivity e.g. for guest-pull from public registries like DockerHub (note: the pod traffic itself is namespaced and routed through the node, so a Pod itself will share the outbound connectivity of the other pods in a cluster)
Outbound access should be explicitly configured, the following would be an example for AKS, where create a dedicated peerpod subnet on the Worker Node's VNet, to which we attach a NAT gateway with a public ip:
Successful e2e test run here