Testing urunc Compatibility with Flannel CNI
Following up on the exploration of alternative network plugins in #38 , here are the findings for Flannel.
To thoroughly evaluate Flannel's compatibility with urunc, this test was conducted in an isolated local kind (Kubernetes in Docker) cluster. This allowed us to verify the direct interaction between standard Kubernetes networking, Flannel's VXLAN overlay, and the TAP interfaces dynamically managed by urunc.
Methodology
- Cluster Provisioning: Bootstrapped a local
kind cluster with disableDefaultCNI: true to prevent the default kindnet from conflicting with Flannel.
- CNI Installation: Installed standard CNI plugins (
bridge, portmap, etc.) into /opt/cni/bin across the nodes, then deployed the official Flannel DaemonSet.
- urunc Installation: Deployed
urunc-deploy to the cluster to automatically install the hypervisors and configure the node's containerd.
- Validation: Deployed a standard NGINX unikernel using the
urunc RuntimeClass, then used an ephemeral Linux container (netshoot) to test HTTP routing across the Flannel overlay.
Results
Flannel correctly delegates IP allocation and successfully routes overlay traffic to the TAP interfaces generated by urunc. No source code modifications or custom CNI hacks were necessary to achieve full connectivity.
$ kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-urunc-9b67df86f-bwzrp 1/1 Running 0 15s 10.244.1.7 urunc-flannel-test-worker <none> <none>
$ kubectl run test-curl --rm -i --image=nicolaka/netshoot --restart=Never -- curl -s 10.244.1.7
<!DOCTYPE html>
<html>
<head>
<title>Hello, world!</title>
</head>
<body>
<h1>Hello, world!</h1>
<p>Powered by <a href="http://unikraft.org">Unikraft</a>.</p>
</body>
</html>
Key Takeaway for Flannel
Based on this evaluation, Flannel appears to work well with urunc in a local kind environment. The tested unikernel workload received pod networking through Flannel and was reachable from another pod without requiring any urunc-specific networking changes.
Testing
uruncCompatibility with Flannel CNIFollowing up on the exploration of alternative network plugins in #38 , here are the findings for Flannel.
To thoroughly evaluate Flannel's compatibility with
urunc, this test was conducted in an isolated localkind(Kubernetes in Docker) cluster. This allowed us to verify the direct interaction between standard Kubernetes networking, Flannel's VXLAN overlay, and the TAP interfaces dynamically managed byurunc.Methodology
kindcluster withdisableDefaultCNI: trueto prevent the defaultkindnetfrom conflicting with Flannel.bridge,portmap, etc.) into/opt/cni/binacross the nodes, then deployed the official Flannel DaemonSet.urunc-deployto the cluster to automatically install the hypervisors and configure the node'scontainerd.uruncRuntimeClass, then used an ephemeral Linux container (netshoot) to test HTTP routing across the Flannel overlay.Results
Flannel correctly delegates IP allocation and successfully routes overlay traffic to the TAP interfaces generated by
urunc. No source code modifications or custom CNI hacks were necessary to achieve full connectivity.Key Takeaway for Flannel
Based on this evaluation, Flannel appears to work well with urunc in a local kind environment. The tested unikernel workload received pod networking through Flannel and was reachable from another pod without requiring any urunc-specific networking changes.