Heute: Kube-OVN
In der Produktion von okadm plan verlangt. Mit dem parallelen OVN von OpenKeel trägt jeder Knoten zwei OVS/OVN-Stacks, die sich dasselbe Kernelmodul teilen: als fragil eingestuft.
Deployment
Labor und Produktion
Dasselbe Binary installiert ein kind-Labor mit einem Knoten oder einen Produktionscluster.
Zwei Modi: Labor und Produktion
| Labor | Produktion | |
|---|---|---|
| Cluster | kind spontan erstellt, 1 Knoten | Bestehender Cluster (Talos), 3 Knoten oder mehr |
| Replikate | 1, kein Autoscaling | 3, Autoscaling |
| Netzwerk | Das CNI des Clusters und ein eigenständiges zentrales OVN | Kube-OVN und Multus |
| Speicher | Standard-StorageClass, max. 5 Gi | Longhorn (RWO und RWX) |
| VMs | KubeVirt in Emulation (kein /dev/kvm) | KubeVirt mit KVM |
| Domain | Optional (nip.io) | --domain erforderlich |
Produktion: welches CNI für die Pods?
Empfohlen: Cilium
Ein Nicht-OVN-CNI für das Pod-Netz. Jeder Hypervisor hat dann einen einzigen OVS/OVN-Stack, den von OpenKeel; die VMs werden über Multus daran angebunden.
Status: offene Frage
Cilium oder Calico, oder Kube-OVN mit gemeinsam genutztem ovs-vswitchd (zu validieren). okadm plan erkennt Cilium bereits; im Labor bleibt das CNI des Clusters bestehen.
Rollentrennung: Cilium für die Pods der Plattform, das OVN von OpenKeel für die Mandantennetze. Cilium wird von okadm weder installiert noch getestet: Es ist die empfohlene Option, noch keine Entscheidung.