Today: Kube-OVN
Required by okadm plan in production. With OpenKeel's parallel OVN, each node carries two OVS/OVN stacks sharing the same kernel module: judged fragile.
Deployment
Lab and production
The same binary installs a one-node kind lab or a production cluster.
Two modes: lab and production
| Lab | Production | |
|---|---|---|
| Cluster | kind created on the fly, 1 node | Existing cluster (Talos), 3 nodes or more |
| Replicas | 1, no autoscaling | 3, autoscaling |
| Networking | The cluster's CNI and a standalone central OVN | Kube-OVN and Multus |
| Storage | Default StorageClass, 5 Gi max | Longhorn (RWO and RWX) |
| VMs | KubeVirt in emulation (no /dev/kvm) | KubeVirt with KVM |
| Domain | Optional (nip.io) | --domain required |
Production: which CNI for the Pods?
Recommended: Cilium
A non-OVN CNI for the Pod network. Each hypervisor then has a single OVS/OVN stack, OpenKeel's; the VMs attach to it through Multus.
Status: open question
Cilium or Calico, or Kube-OVN sharing its ovs-vswitchd (to validate). okadm plan already recognises Cilium; in a lab the cluster's CNI stays in place.
Separation of roles: Cilium for the platform Pods, OpenKeel's OVN for the tenant networks. Cilium is neither installed nor tested by okadm: it is the recommended option, not yet a decision.