Problem
Today, compute tightly couples workload networking to internal networking resources that were never meant to be a stable interface. This creates two problems:
-
Networking is shared across instances in a deployment, not per-instance. A single network allocation is reused by every instance in a deployment, which means instances can't have their own IP addresses. There is an existing TODO in the code acknowledging this is wrong.
-
Instance IP addresses are never populated. Instance.status.networkInterfaces[*].assignments.networkIP is declared and exposed as a print column but nothing ever writes to it. Users have no way to see what IP address their instance received.
What we're building
This issue tracks compute's side of the integration with the network services operator's new NetworkInterfaceClaim and NetworkInterface resources (tracked in datum-cloud/network-services-operator#164).
Per-instance network allocation
Each instance gets its own network interface claim. When a workload deployment creates instances, it creates a NetworkInterfaceClaim for each instance NIC. The networking scheduling gate that holds instances back from being scheduled is removed per-instance once that instance's own claim is fulfilled — not when a shared allocation becomes ready.
IP addresses on instances
Once a NetworkInterface is bound to a claim, its assigned IP address is written back to Instance.status.networkInterfaces[*].assignments.networkIP. Users will be able to see the IP address of their instance via kubectl get instance or the platform API.
API changes
Two small additions to the instance network interface spec are needed:
ipFamily — allows users to specify which IP family to request. Defaults to IPv6.reclaimPolicy (follow-on) — allows users to retain an IP across instance deletion, similar to how Kubernetes persistent volumes work.
Depends on
Problem
Today, compute tightly couples workload networking to internal networking resources that were never meant to be a stable interface. This creates two problems:
Networking is shared across instances in a deployment, not per-instance. A single network allocation is reused by every instance in a deployment, which means instances can't have their own IP addresses. There is an existing TODO in the code acknowledging this is wrong.
Instance IP addresses are never populated.
Instance.status.networkInterfaces[*].assignments.networkIPis declared and exposed as a print column but nothing ever writes to it. Users have no way to see what IP address their instance received.What we're building
This issue tracks compute's side of the integration with the network services operator's new
NetworkInterfaceClaimandNetworkInterfaceresources (tracked in datum-cloud/network-services-operator#164).Per-instance network allocation
Each instance gets its own network interface claim. When a workload deployment creates instances, it creates a
NetworkInterfaceClaimfor each instance NIC. The networking scheduling gate that holds instances back from being scheduled is removed per-instance once that instance's own claim is fulfilled — not when a shared allocation becomes ready.IP addresses on instances
Once a
NetworkInterfaceis bound to a claim, its assigned IP address is written back toInstance.status.networkInterfaces[*].assignments.networkIP. Users will be able to see the IP address of their instance viakubectl get instanceor the platform API.API changes
Two small additions to the instance network interface spec are needed:
ipFamily— allows users to specify which IP family to request. Defaults toIPv6.reclaimPolicy(follow-on) — allows users to retain an IP across instance deletion, similar to how Kubernetes persistent volumes work.Depends on
NetworkInterfaceClaimandNetworkInterfaceresources must exist before this work begins