Nodes prüfen, bevor du irgendetwas installierst
KubeVirt startet die VMs als QEMU-Prozess in einem Pod. Ohne Hardware-Virtualisierung auf dem Node läuft das nur in Emulation, und die ist für Produktion unbrauchbar.
# Auf jedem Node, der VMs tragen soll
grep -Ec 'vmx|svm' /proc/cpuinfo
ls -l /dev/kvm
# Ausführlicher Check aus den libvirt-Tools
sudo dnf install -y libvirt-client # RHEL/Rocky/Alma
sudo apt install -y libvirt-clients # Debian/Ubuntu
sudo virt-host-validate qemuvirt-host-validate meldet fehlendes /dev/kvm, fehlende IOMMU-Unterstützung und cgroup-Controller, die nicht eingehängt sind. Alles, was dort auf FAIL steht, kostet dich später eine Nacht.
Vor der Installation geklärt
- CPU-Modelle der Worker sind vergleichbar oder du erzwingst ein gemeinsames CPU-Modell.Live-Migration bricht ab, wenn der Ziel-Node ein CPU-Flag nicht anbietet, das der Gast bereits benutzt. Gemischte Generationen ohne festes CPU-Modell machen Migration zur Glückssache.
- RAM ist real vorhanden, nicht überbucht.VMs reservieren ihren Speicher als Pod-Request. Die Überbuchung, die du aus vSphere kennst, gibt es hier nicht in derselben Form, und ein OOM-Kill trifft die ganze VM.
- Die KubeVirt-Version passt zur Kubernetes-Version des Clusters.KubeVirt unterstützt jeweils nur ein Fenster von Kubernetes-Versionen. Ein Cluster-Update ohne Blick auf die Matrix legt im schlimmsten Fall alle VMs gleichzeitig still.
- Es ist festgelegt, wer den Cluster patcht und wer die VMs verantwortet.Mit KubeVirt wird der Cluster zum Unterbau der VMs. Ein unabgestimmtes Node-Update ist ab sofort ein Eingriff in den VM-Betrieb.