[shimV2] added network controller implementation#2633
[shimV2] added network controller implementation#2633rawahars wants to merge 1 commit intomicrosoft:mainfrom
Conversation
This change adds the network controller implementation for V2 shims which manages the network lifecycle for a single pod running inside a UVM. Signed-off-by: Harsh Rawat <harshrawat@microsoft.com>
| // SetupOptions holds the configuration required to set up the network for a pod. | ||
| type SetupOptions struct { | ||
| // PodID is the identifier of the pod whose network is being configured. | ||
| PodID string |
There was a problem hiding this comment.
What is the need of the PodID for the network? Should it be the PodController -> Network mapping?
There was a problem hiding this comment.
The PodID is logged by the controller to provide immediate correlation between log messages, namespaces, and their respective pods in multi-pod deployments.
The network controller would be part of the PodController instance itself.
|
|
||
| // Hot-add all endpoints in the namespace to the guest. | ||
| for _, endpoint := range endpoints { | ||
| nicGUID, err := guid.NewV4() |
There was a problem hiding this comment.
The old code did this too. Do we have to generate new GUIDs or can we use the same ones from the endpoint so that the logs are easier to correlate? At the very least we need to log a pivot trace here, this endpoint id is this new guid.
There was a problem hiding this comment.
As we discussed for LM, we would have separate IDs for UVM resources than what was there on the host.
I can add both the IDs in context so that the same gets logged within GCS.
|
|
||
| if len(teardownErrs) > 0 { | ||
| // If any errors were encountered during teardown, mark the state as invalid. | ||
| m.netState = StateInvalid |
There was a problem hiding this comment.
Are retries safe in this state?
There was a problem hiding this comment.
Yes. The Invalid state is meant to signify that container is not in valid Configured state.
| // Ensure the endpoint named "eth0" is added first when multiple endpoints are present, | ||
| // so it maps to eth0 inside the guest. CNI results aren't available here, so we rely | ||
| // on the endpoint name suffix as a heuristic. | ||
| cmp := func(a, b *hcn.HostComputeEndpoint) int { |
There was a problem hiding this comment.
Uh... this wont work for multi-pod. Do we need to maintain this nomenclature?
There was a problem hiding this comment.
It would work for multi-pod since each pod would get it's own controller. This sorting is on the host side so that we can determine which NIC is added first. Once the NIC is added to the UVM, we will send guest request to move it into pod namespace. Therefore, even if the NIC is 3rd one on the guest side, it would be the first to be moved into pod namespace and hence becomes eth0 in that namespace.
2 participants
Summary
This change adds the network controller implementation for V2 shims which manages the network lifecycle for a single pod running inside a UVM. The implementation provides a clear lifecycle state machine, separates platform-specific logic for LCOW and WCOW. This controller will be initialized from VMController which can inject the low-level managers to perform VM host + guest network operations.
The main changes are grouped below.
Network controller implementation:
Controllerinterface and its concreteManagertype, providingSetupandTeardownmethods to manage HCN namespaces and endpoints for a pod (internal/controller/network/interface.go,internal/controller/network/network.go).Platform-specific guest operations:
internal/controller/network/network_lcow.go,internal/controller/network/network_wcow.go).Lifecycle state management:
Statetype to track the network lifecycle, including transitions for setup, teardown, and error handling (internal/controller/network/state.go).