Oggi: Kube-OVN
Richiesto da okadm plan in produzione. Con l'OVN parallelo di OpenKeel, ogni nodo ospita due stack OVS/OVN che condividono lo stesso modulo del kernel: giudicato fragile.
Deployment
Laboratorio e produzione
Lo stesso binario installa un laboratorio kind a un nodo o un cluster di produzione.
Due modalità: laboratorio e produzione
| Laboratorio | Produzione | |
|---|---|---|
| Cluster | kind creato al volo, 1 nodo | Cluster esistente (Talos), 3 nodi o più |
| Repliche | 1, nessun autoscaling | 3, autoscaling |
| Rete | Il CNI del cluster e un OVN centrale autonomo | Kube-OVN e Multus |
| Storage | StorageClass predefinita, max 5 Gi | Longhorn (RWO e RWX) |
| VM | KubeVirt in emulazione (senza /dev/kvm) | KubeVirt con KVM |
| Dominio | Facoltativo (nip.io) | --domain obbligatorio |
Produzione: quale CNI per i Pod?
Consigliato: Cilium
Un CNI non OVN per la rete dei Pod. Ogni hypervisor ha così un unico stack OVS/OVN, quello di OpenKeel; le VM vi si collegano tramite Multus.
Stato: questione aperta
Cilium o Calico, oppure Kube-OVN condividendo il proprio ovs-vswitchd (da validare). okadm plan riconosce già Cilium; in laboratorio il CNI del cluster resta invariato.
Separazione dei ruoli: Cilium per i Pod della piattaforma, l'OVN di OpenKeel per le reti dei tenant. Cilium non viene né installato né testato da okadm: è l'opzione consigliata, non ancora una decisione.