Eine KubeVirt-VM verfügt über vier Lebenszyklus-Verben: Start, Stopp, Pauseund Wiedergabe fortsetzen. Stopp löscht die Virtuelle Maschineninstanz und dessen virt-launcher Pod – Speicher und CPU werden freigegeben. Pause „Freeze“ friert den Gast auf Hypervisor-Ebene ein, lässt den Pod und den Arbeitsspeicher jedoch unverändert. „Stop“ ist ressourcenschonend; „Pause“ erfolgt sofort.
Sie steuern den Lebenszyklus auf zwei Arten: virtctl aus ergonomischen Gründen oder kubectl patch gegen die VMs Ausführungsstrategie Feld für GitOps. Beide enden bei derselben Controller-Abgleichung. Verwenden Sie virtctl interaktiv. Verwenden Sie kubectl patch (oder idealerweise eine in die Versionskontrolle eingecheckte YAML-Datei), wenn Sie möchten, dass jeder Zustandswechsel in der Versionskontrolle erfasst wird.
Die vier Rechenoperationen
Beenden Sie die VM und warten Sie, bis das VMI-Fenster geschlossen ist:
virtctl stop testvm
kubectl wait--for=deletevmi/testvm--timeout=120s
Dann starte es erneut:
virtctl start testvm
kubectl wait--for=jsonpath='{.status.phase}'=Runningvmi/testvm--timeout=180s
Pause:
virtctl pause vm testvm
kubectl get vmi testvm -o jsonpath='{.status.conditions[?(@.type=="Paused")].status}'
Die Angehalten Die Bedingung wechselt zu Richtig. Wiedergabe fortsetzen:
virtctl unpause vm testvm
Der gleiche Ablauf über kubectl patch
virtctl start ist ein Wrapper. Die gleiche Änderung im Lebenszyklus tritt ein, wenn man umschaltet spec.runStrategy von Immer zu Angehalten oder zurück:
printf "spec:\n runStrategy: Halted\n" > /tmp/halted.yaml
kubectl patch vm testvm --type merge --patch-file /tmp/halted.yaml
printf "spec:\n runStrategy: Always\n" > /tmp/running.yaml
kubectl patch vm testvm --type merge --patch-file /tmp/running.yaml
Beide erreichen denselben Controller und gleichen das VMI entsprechend ab. Bei CI/CD-Pipelines ist die kubectl patch Das Formular macht virtctl überflüssig und lässt sich nahtlos in jedes Tool integrieren, das bereits Kubernetes unterstützt.
SSH statt der seriellen Konsole
Das erste Tutorial, das verwendet wurde virtctl-Konsole und ein Gastpasswort, das zwar zum Herumstöbern ausreicht, aber nicht die Art von Verbindung ist, die man sich eigentlich wünscht. Die Lösung von KubeVirt lautet cloudInitNoCloud — eine winzige virtuelle Festplatte, die dem Gast beim ersten Start bereitgestellt wird und die das cloud-init-Paket in Ubuntu als NoCloud-Datenquelle auswertet. Alles, was cloud-init versteht, funktioniert: Benutzer, Pakete, Dateien, runcmd und das, was wir hier benötigen, ssh_authorized_keys.
Cloud-init wird nur beim ersten Start ausgeführt. Um von einem Passwort auf einen SSH-Schlüssel umzustellen, musst du die VM daher löschen und neu erstellen. Stelle sicher, dass dein öffentlicher Schlüssel exportiert wurde:
export SSH_PUBKEY="$(cat ~/.ssh/id_ed25519.pub)"
echo "$SSH_PUBKEY"
Dann aktualisieren vm.yaml — Ersetze „cloudInitNoCloud“ Benutzerdaten Block aus dem vorherigen Tutorial durch:
Bände:
- name: containerdisk
containerDisk:
Image: quay.io/containerdisks/ubuntu:22.04
- name: cloudinitdisk
cloudInitNoCloud:
userData: |
#cloud-config
ssh_authorized_keys:
- FÜGEN SIE HIER IHREN ÖFFENTLICHEN SCHLÜSSEL EIN
Oder rendern Sie es anhand einer Vorlage, die $SSH_PUBKEY:
envsubst < vm.yaml.template > vm.yaml
grep -A2 ssh_authorized_keys vm.yaml
Löschen Sie die alte VM und führen Sie den Vorgang erneut durch:
kubectl delete vm testvm
kubectl apply -f vm.yaml
virtctl start testvm
kubectl wait--for=jsonpath='{.status.phase}'=Runningvmi/testvm--timeout=180s
Warten Sie eine Minute, nachdem der VMI den Status „Running“ erreicht hat, damit cloud-init die Bereitstellung des Schlüssels in /home/ubuntu/.ssh/authorized_keys, dann verbinden:
virtctl ssh -i ~/.ssh/id_ed25519 ubuntu@vmi/testvm
Du landest in einer Muschel — ubuntu@testvm:~$ — ohne Passwortabfrage. virtctl ssh Leitet virtctl einen lokalen SSH-Prozess über die Kubernetes-API an die VM weiter; Sie benötigen weder eine Portweiterleitung noch eine extern erreichbare VM-IP-Adresse. Die vmi/ Bei KubeVirt v1.5.x und neuer ist das Präfix erforderlich; das alte „bare“ <user>@<vm> Das Formular ist veraltet.
Vergewissere dich, dass der Schlüssel dort gelandet ist, wo du es erwartet hast:
whoami
cat ~/.ssh/authorized_keys
exit
Wie geht es weiter?
testvm wird nun per Schlüssel authentifiziert und ist erreichbar über virtctl ssh. Die nächsten Tutorials behandeln VM-Netzwerk (wie die Gast-IP mit der Pod-IP zusammenhängt, wie man einen in der VM laufenden Dienst nach außen verfügbar macht) und dauerhafter storage (damit Ihre Daten erhalten bleiben, wenn die VM beendet wird).