Installation von KubeVirt auf einem Kubernetes-Cluster

Einführung

Sie verfügen über einen Kubernetes-Cluster, auf dem Ihre containerisierten Workloads ausgeführt werden. Nun möchten Sie virtuelle Maschinen hinzufügen – vielleicht haben Sie Legacy-Anwendungen, die ein vollständiges Betriebssystem benötigen, oder Sie prüfen einen Migrationspfad weg von VMware. In jedem Fall müssen Sie KubeVirt installieren und in Betrieb nehmen.

In diesem Tutorial installieren Sie KubeVirt und den Containerized Data Importer (CDI) auf einem bestehenden Kubernetes-Cluster und richten den virtctl Befehlszeilen-Tool und starten Sie Ihre erste virtuelle Maschine, um zu überprüfen, ob alles funktioniert. Am Ende verfügen Sie über eine voll funktionsfähige KubeVirt-Installation mit einer laufenden VM, auf die Sie über die Konsole zugreifen können.

Der gesamte Vorgang dauert etwa 20 Minuten, sofern Ihr Cluster bereits läuft. Der Großteil dieser Zeit entfällt auf das Warten darauf, dass die Pods die Images abrufen und in den laufenden Zustand übergehen.

Folgendes werden Sie einrichten:

KubeVirt-Operator und benutzerdefinierte Ressource – die zentrale Virtualisierungsschicht
Containerized Data Importer (CDI) – zum Importieren von Festplatten-Images in PersistentVolumes
virtctl CLI – das Befehlszeilentool für VM-spezifische Vorgänge
Eine Test-VM – um zu überprüfen, ob alles durchgängig funktioniert

Schritt 1: Überprüfen Sie die Unterstützung für Hardware-Virtualisierung

Bevor Sie irgendetwas installieren, müssen Sie sicherstellen, dass Ihre Cluster-Knoten Hardware-Virtualisierung unterstützen. KubeVirt nutzt intern KVM, und KVM erfordert entweder Intel VT-x- oder AMD-V-Erweiterungen auf CPU-Ebene.

Wenn Sie SSH-Zugriff auf einen Clusterknoten haben, führen Sie diesen Befehl aus:

grep -cE 'vmx|svm' /proc/cpuinfo

Die Ausgabe ist eine Zahl. Ist diese größer als 0, ist Hardware-Virtualisierung verfügbar. Die Zahl selbst gibt an, wie viele CPU-Kerne diese Funktion unterstützen – auf einem Rechner mit 4 Kernen und aktiviertem VT-x würde man sehen 4.

Wenn die Ausgabe lautet 0Entweder unterstützt Ihre CPU keine Virtualisierung oder diese ist deaktiviert. Überprüfen Sie bei physischen Servern die BIOS-/UEFI-Einstellungen – die Hardware-Virtualisierung ist manchmal standardmäßig deaktiviert. Bei Cloud-VMs benötigen Sie einen Instanztyp, der verschachtelte Virtualisierung unterstützt.

Wenn Sie sich nicht direkt per SSH bei Ihren Knoten anmelden können, können Sie dies innerhalb des Clusters überprüfen, indem Sie einen privilegierten Pod ausführen:

kubectl run virt-check --image=alpine --restart=Never --rm -it \
  --overrides='{"spec":{"containers":[{"name":"virt-check","image":"alpine","command":["sh","-c","grep -cE vmx\\|svm /proc/cpuinfo"],"securityContext":{"privileged":true}}]}}' \
  -- sh -c "grep -cE 'vmx|svm' /proc/cpuinfo"

Sie können auch überprüfen, ob die /dev/kvm Das Gerät ist auf dem Knoten vorhanden:

kubectl run kvm-check --image=alpine --restart=Never --rm -it \
  --overrides='{"spec":{"containers":[{"name":"kvm-check","image":"alpine","command":["ls","-la","/dev/kvm"],"securityContext":{"privileged":true}}]}}' \
  -- ls -la /dev/kvm

Wenn /dev/kvm Wenn das vorhanden ist, kannst du loslegen.

Warnung: KubeVirt kann auf Software-Emulation zurückgreifen, wenn keine Hardware-Virtualisierung verfügbar ist, doch der Leistungseinbruch ist erheblich – rechnen Sie mit einer 10- bis 100-fach langsameren Ausführung. Software-Emulation ist für schnelle Tests oder Entwicklungsumgebungen akzeptabel, in denen Sie lediglich Manifests und Workflows validieren müssen. Für Produktions-Workloads oder Szenarien, in denen die Leistung der VMs entscheidend ist, ist sie nicht geeignet. Wenn Sie auf Cloud-VMs bereitstellen, überprüfen Sie in der Dokumentation Ihres Anbieters, welche Instanztypen verschachtelte Virtualisierung unterstützen (zum Beispiel, .metal Instanzen auf AWS oder N2/C2-Instanzen mit aktivierter „Nested Virt“-Funktion auf GCP).

Schritt 2: Den KubeVirt Operator bereitstellen

Sobald die Hardware-Virtualisierung bestätigt ist, können Sie KubeVirt installieren. Die Installation folgt dem üblichen Kubernetes-Operator-Muster: Zunächst stellen Sie den Operator bereit, dann erstellen Sie eine benutzerdefinierte Ressource, die dem Operator mitteilt, was bereitgestellt werden soll.

Flussdiagramm LR
    A["kubectl create
kubevirt-operator.yaml"] --> B[virt-operator
Pod läuft]
    B -->|wartet auf| C["kubectl apply
KubeVirt CR"]
    C --> D[virt-operator führt Abgleich durch]
    D --> E[virt-api
Deployment]
    D --> F[virt-controller
Deployment]
    D --> G[virt-handler
DaemonSet]

Laden Sie zunächst die neueste stabile Version herunter und stellen Sie den Operator bereit:

export KUBEVIRT_VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | grep tag_name | cut -d '"' -f 4)
echo "Installing KubeVirt ${KUBEVIRT_VERSION}"
kubectl create -f "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml"

Dadurch werden mehrere Ressourcen in der kubevirt Namensraum:

Die kubevirt der Namespace selbst
Benutzerdefinierte Ressourcendefinitionen (CRDs) für „VirtualMachine“, „VirtualMachineInstance“ und verwandte Typen
Die virt-operator Deployment, die Komponente der Steuerungsebene, die alle anderen KubeVirt-Komponenten verwaltet
ServiceAccounts, ClusterRoles und ClusterRoleBindings für die RBAC-Berechtigungen des Operators

Der Betreiber hat noch keine VM-bezogenen Komponenten bereitgestellt. Er wartet darauf, dass Sie eine KubeVirt benutzerdefinierte Ressource – das ist das Signal für die Bereitstellung des gesamten Stacks. Dieser zweistufige Ansatz gibt Ihnen die Möglichkeit, die Konfiguration anzupassen, bevor weitere Komponenten bereitgestellt werden.

Warten Sie, bis der Operator-Pod bereit ist, bevor Sie fortfahren:

kubectl -n kubevirt wait--for=condition=Readypod -l kubevirt.io=virt-operator--timeout=180s

Schritt 3: Erstellen der benutzerdefinierten KubeVirt-Ressource

Erstellen Sie nun die KubeVirt eine benutzerdefinierte Ressource, die den Operator anweist, alle Komponenten bereitzustellen:

apiVersion: kubevirt.io/v1
kind: KubeVirt
metadata:
  name: kubevirt
  namespace: kubevirt
spec:
  certificateRotateStrategy: {}
  configuration:
    developerConfiguration:
      useEmulation: false
  customizeComponents: {}
  imagePullPolicy: IfNotPresent

Als speichern kubevirt-cr.yaml und wenden Sie es an:

kubectl apply -f kubevirt-cr.yaml

Tipp: Wenn Ihre Knoten keine Hardware-Virtualisierung unterstützen und Sie zu Testzwecken mit einer Software-Emulation fortfahren möchten, ändern Sie useEmulation: false zu useEmulation: true im obigen Manifest. Beachten Sie, dass dies nur für die Entwicklung und das Testen geeignet ist – niemals für den Produktivbetrieb.

Sobald Sie diese Ressource anwenden, liest der virt-operator sie ein und beginnt mit der Bereitstellung der KubeVirt-Komponenten:

virt-api – ein Deployment, das die Kubernetes-API-Erweiterung für VM-Operationen bereitstellt. Es verarbeitet Anfragen für Unterressourcen wie Konsolenzugriff, VNC und Migrationsauslöser. Außerdem führt es eine Zulassungsprüfung für VM-Manifeste durch, bevor diese dauerhaft gespeichert werden.
virt-controller – ein Deployment, das auf Ressourcen vom Typ „VirtualMachine“ und „VirtualMachineInstance“ überwacht. Wenn Sie eine VM erstellen, erstellt virt-controller den entsprechenden virt-launcher-Pod und koordiniert den Lebenszyklus der VM auf Cluster-Ebene.
virt-handler – ein DaemonSet, das auf jedem Knoten läuft, der für die Ausführung von VMs geeignet ist. Es handelt sich um den Agenten auf Knotenebene, der die eigentliche Interaktion zwischen KVM und libvirt verwaltet. Wenn ein virt-launcher-Pod auf einem Knoten landet, konfiguriert und startet virt-handler den VM-Prozess darin.

Jede VM läuft in einem eigenen „virt-launcher“-Pod. Der Pod sorgt für die Isolationsgrenze – cgroups, Namespaces, Ressourcenbeschränkungen –, während der eigentliche VM-Prozess als QEMU/KVM-Instanz läuft, die von libvirt innerhalb dieses Pods verwaltet wird.

Schritt 4: Warten, bis KubeVirt bereitgestellt ist

Der Betreiber benötigt einige Minuten, um die Bilder abzurufen und alle Komponenten in Betrieb zu nehmen. Verwenden Sie die integrierte Zustandsprüfung, um zu warten:

kubectl -n kubevirt wait kv kubevirt --for condition=Available--timeout=300s

Wenn dieser Befehl erfolgreich ausgeführt wurde, ist KubeVirt einsatzbereit. Sollte es zu einer Zeitüberschreitung kommen, überprüfen Sie die Operator-Protokolle auf Fehler:

kubectl -n kubevirt logs -l kubevirt.io=virt-operator--tail=50

Überprüfen Sie, ob alle Pods laufen:

kubectl get pods -n kubevirt

Die Ausgabe sollte in etwa so aussehen:

NAME                               BEREIT   STATUS    NEUSTARTE   ALTER
virt-api-7fc5db8b6-4xz8m          1/1     Läuft   0          2m
virt-api-7fc5db8b6-n9hkl          1/1     Läuft   0          2m
virt-controller-6b9f5d4c7-8qjrw   1/1     Läuft   0          2m
virt-controller-6b9f5d4c7-txz5k   1/1     Läuft   0          2m
virt-handler-7kpnz                 1/1     Läuft   0          2m
virt-handler-qm4x8                 1/1     Läuft   0          2m
virt-operator-5f8bc4c5d-jn7xr     1/1     Läuft   0          4m
virt-operator-5f8bc4c5d-zw2lp     1/1     Läuft   0          4m

Die genauen Pod-Namen können variieren, und die Anzahl der virt-handler-Pods entspricht der Anzahl der Knoten in Ihrem Cluster (da es sich um ein DaemonSet handelt). Entscheidend ist, dass alle Pods Folgendes anzeigen: Laufen mit 1/1 fertig.

Sie können den Status der KubeVirt-Ressource auch direkt überprüfen:

kubectl get kubevirt -n kubevirt

Die PHASE Die Spalte sollte anzeigen Eingesetzt.

Schritt 5: Installieren Sie den Containerized Data Importer (CDI)

KubeVirt kümmert sich um die Ausführung von VMs. VMs benötigen jedoch Festplatten-Images – ISOs, QCOW2-Dateien, VMDKs – und diese Images müssen in PersistentVolumes eingebunden werden, die die VMs mounten können. Hier kommt der Containerized Data Importer ins Spiel.

CDI ist ein eigenständiges Projekt, das parallel zu KubeVirt läuft. Es bietet eine deklarative Methode, um VM-Festplatten-Images aus verschiedenen Quellen (HTTP-Endpunkte, Container-Registries, S3-Buckets oder lokale Uploads) in PersistentVolumeClaims zu importieren. Ohne CDI müssten Sie PVCs vor der Erstellung von VMs manuell bereitstellen und befüllen – CDI automatisiert diesen gesamten Arbeitsablauf.

Installieren Sie CDI auf dieselbe Weise wie KubeVirt – zuerst den Operator, dann die benutzerdefinierte Ressource:

export CDI_VERSION=$(curl -s https://api.github.com/repos/kubevirt/containerized-data-importer/releases/latest | grep tag_name | cut -d '"' -f 4)
echo "Installing CDI ${CDI_VERSION}"
kubectl create -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-operator.yaml"
kubectl create -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-cr.yaml"

Der erste Befehl stellt den CDI-Operator bereit. Der zweite erstellt die CDI benutzerdefinierte Ressource in der cdi Namensraum, der den Operator dazu veranlasst, alle CDI-Komponenten bereitzustellen.

Warten Sie, bis CDI verfügbar ist:

kubectl wait--for=condition=Available--timeout=300scdi/cdi -n cdi

Überprüfen Sie, ob die CDI-Pods laufen:

kubectl get pods -n cdi

Sie sollten den CDI-Operator, den API-Server, den Deployment-Pod und den Upload-Proxy-Pod alle in einem Laufen Zustand.

CDI spielt eine wichtige Rolle, sobald Sie mit echten VM-Images arbeiten – sei es beim Importieren von Cloud-Images über öffentliche URLs, beim Konvertieren von VMDK-Dateien aus VMware-Exporten oder beim Klonen bestehender Festplatten. Für die Test-VM in diesem Tutorial verwenden Sie eine Container-Festplatte, für die kein CDI erforderlich ist; wenn Sie CDI jedoch installiert haben, sind Sie für echte Workloads gerüstet.

Schritt 6: Installieren Sie virtctl

virtctl ist das KubeVirt-Befehlszeilentool, das VM-spezifische Vorgänge ausführt, die kubectl das ist standardmäßig nicht möglich. Du benötigst es für:

Zugriff auf die serielle Konsole oder die VNC-Anzeige einer VM
Starten und Beenden von VMs
Live-Migration von VMs zwischen Knoten
Portweiterleitung zu VM-Ports
SSH-Zugriff auf VMs
Disk-Images hochladen

Installieren Sie es, indem Sie die Binärdatei herunterladen, die zu Ihrer KubeVirt-Version passt:

curl -L -o virtctl "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/virtctl-${KUBEVIRT_VERSION}-linux-amd64"
chmod +x virtctl
sudo mv virtctl /usr/local/bin/

Für macOS ersetzen Sie linux-amd64 mit darwin-amd64 (Intel) oder darwin-arm64 (Apple Silicon):

curl -L -o virtctl "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/virtctl-${KUBEVIRT_VERSION}-darwin-arm64"
chmod +x virtctl
sudo mv virtctl /usr/local/bin/

Überprüfen Sie die Installation:

virtctl-Version

Wenn Sie es vorziehen, kubectl-Plugins über krew zu verwalten, können Sie virtctl stattdessen als kubectl-Plugin installieren:

kubectl krew install virt

Damit können Sie kubectl virt statt virtctl — Die Funktionalität ist identisch. Beide Ansätze funktionieren; wählen Sie den, der am besten zu Ihrem Arbeitsablauf passt.

Schritt 7: Starten Sie Ihre erste virtuelle Maschine

Nun ist es an der Zeit, die Installation durch das Starten einer virtuellen Maschine zu überprüfen. Sie verwenden dazu eine CirrOS-Container-Festplatte – eine minimalistische Linux-Distribution, die speziell für Cloud-Tests entwickelt wurde. Bei diesem Ansatz wird ein VM-Image in ein Container-Image eingebunden, sodass keine storage bereitgestellt storage Festplatten-Images importiert werden müssen. Dies ist der schnellste Weg, um eine VM zu Validierungszwecken zum Laufen zu bringen.

Erstellen Sie eine Datei mit dem Namen testvm.yaml mit folgendem Inhalt:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  running: true
  template:
    metadata:
      labels:
        kubevirt.io/vm: testvm
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
            - name: default
              masquerade: {}
        resources:
          requests:
            memory: 1Gi
      networks:
        - name: default
          pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: quay.io/kubevirt/cirros-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userDataBase64: SGVsbG8sIFdvcmxkIQ==

Anwenden:

kubectl apply -f testvm.yaml

Ein paar Dinge, die man zu diesem Manifest wissen sollte:

spec.running: true weist KubeVirt an, die VM unmittelbar nach ihrer Erstellung zu starten. Wenn Sie dies auf falsch… wird die VirtualMachine-Ressource zwar erstellt, die VM startet jedoch erst, wenn Sie sie explizit mit virtctl start testvm.
containerDisk ist ein Volumentyp, der ein als Container-Image verpacktes VM-Disk-Image lädt. Das Image quay.io/kubevirt/cirros-container-disk-demo enthält ein CirrOS-Disk-Image. Container-Disks sind kurzlebig – alle Daten, die innerhalb der VM geschrieben werden, gehen verloren, wenn die VM gelöscht wird. Sie eignen sich ideal für Tests und zustandslose Workloads.
cloudInitNoCloud bietet eine grundlegende Cloud-init-Konfiguration. Der hier angegebene Base64-kodierte Wert ergibt nach der Dekodierung „Hello, World!“ – eine minimale Nutzlast an Benutzerdaten. In Produktions-VMs würden Sie dies nutzen, um SSH-Schlüssel einzufügen, das Netzwerk zu konfigurieren, Pakete zu installieren und Einrichtungsskripte auszuführen.
Maskenball Netzwerken nutzt NAT, um die VM mit dem Pod-Netzwerk zu verbinden. Die VM erhält eine interne IP-Adresse und kann externe Dienste erreichen. Für eingehende Verbindungen ist eine explizite Portweiterleitung oder ein Kubernetes-Service erforderlich.
Bus: Virtio bezieht sich auf paravirtualisierte Festplattencontroller, die eine deutlich bessere E/A-Leistung bieten als emulierte IDE- oder SATA-Controller. CirrOS enthält standardmäßig Virtio-Treiber. Bei Windows-VMs müssen Virtio-Treiber möglicherweise separat installiert werden.

Beobachten Sie, wie die VM hochfährt:

kubectl get vmi -w

Die VirtualMachineInstance (VMI) durchläuft mehrere Phasen: In Bearbeitung, Terminplanung, Geplantund schließlich Laufen. Sobald du siehst Laufen… ist die VM hochgefahren und betriebsbereit.

Sie können auch den „virt-launcher“-Pod überprüfen, auf dem die VM gehostet wird:

kubectl get pods -l kubevirt.io/vm=testvm

Schritt 8: Auf die VM-Konsole zugreifen

Stellen Sie bei laufender VM eine Verbindung zur seriellen Konsole her:

virtctl console testvm

Es erscheint die CirrOS-Startmeldung, gefolgt von einer Anmeldeaufforderung. Melden Sie sich mit den Standard-Anmeldedaten an:

Benutzername: Cirros
Passwort: gocubsgo

Führen Sie nach der Anmeldung einige Befehle aus, um zu überprüfen, ob die VM ordnungsgemäß funktioniert:

Hostname
IP-Adresse
uname -a

Der Hostname sollte auf testvm, eine Netzwerkschnittstelle mit einer IP-Adresse aus dem internen Netzwerk der VM sowie die Linux-Kernel-Version, mit der CirrOS ausgeliefert wird.

Um die Konsole zu verlassen, drücken Sie Strg+].

Bei Bedarf können Sie auch über VNC auf die grafische Konsole der VM zugreifen:

virtctl vnc testvm

Dadurch wird ein VNC-Viewer geöffnet, sofern einer auf Ihrem lokalen Rechner installiert ist. Bei einer CirrOS-VM ohne grafische Benutzeroberfläche ist dies nicht besonders nützlich, aber es erweist sich als wertvoll, wenn Sie mit Desktop-Betriebssystemen oder VMs mit grafischen Installationsprogrammen arbeiten.

Schritt 9: Aufräumen

Sobald Sie sich vergewissert haben, dass die VM funktioniert, bereinigen Sie sie:

kubectl delete vm testvm

Dadurch werden sowohl die Ressource „VirtualMachine“ als auch die zugehörige „VirtualMachineInstance“ gelöscht. Der „virt-launcher“-Pod wird beendet und die Container-Festplatte wird freigegeben.

Tipp: Durch das Löschen einer virtuellen Maschine wird auch die zugehörige VirtualMachineInstance gelöscht und die VM angehalten. Wenn Sie die VM nur anhalten möchten, ohne die Definition zu löschen, verwenden Sie virtctl stop testvm stattdessen. Du kannst es dann später wieder starten mit virtctl start testvm. Dies entspricht dem Unterschied zwischen dem Herunterfahren und dem Löschen einer VM in herkömmlichen Hypervisoren – die „Hardware-Definition“ bleibt auch dann erhalten, wenn die VM ausgeschaltet ist.

Wenn Sie die gesamte KubeVirt-Installation später entfernen möchten (nicht empfohlen, falls Sie die Serie fortsetzen möchten), ist die Reihenfolge der Entfernung entscheidend – löschen Sie zuerst die benutzerdefinierten Ressourcen und anschließend die Operatoren:

kubectl delete -f kubevirt-cr.yaml
kubectl delete -f "https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml"
kubectl delete -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-cr.yaml"
kubectl delete -f "https://github.com/kubevirt/containerized-data-importer/releases/download/${CDI_VERSION}/cdi-operator.yaml"

Behebung häufiger Installationsprobleme

Falls bei der Installation Probleme aufgetreten sind, finden Sie hier die häufigsten Probleme und deren Lösungen.

KVM-Gerät nicht gefunden

Wenn virt-handler-Pods mit folgenden Fehlern fehlschlagen: /dev/kvm Da dieser nicht gefunden wurde, steht für den Knoten keine Hardware-Virtualisierung zur Verfügung. Überprüfen Sie Folgendes:

Die physische CPU unterstützt Intel VT-x oder AMD-V
Die Virtualisierung ist im BIOS/UEFI aktiviert
Bei Ausführung auf Cloud-VMs ist die verschachtelte Virtualisierung für diesen Instanztyp aktiviert
Die KVM-Kernelmodule werden geladen: lsmod | grep kvm

Als vorübergehende Abhilfe für Testzwecke können Sie die benutzerdefinierte Ressource „KubeVirt“ bearbeiten, um die Software-Emulation zu aktivieren:

kubectl edit kubevirt kubevirt -n kubevirt

Satz spec.configuration.developerConfiguration.useEmulation zu richtig. Das System nimmt die Neukonfiguration der Komponenten automatisch vor.

Pods, die im Status „Ausstehend“ hängen geblieben sind

Wenn KubeVirt-Pods in In Bearbeitung In diesem Fall sind die häufigsten Ursachen:

Unzureichende Ressourcen — Die Pods „virt-handler“ und „virt-launcher“ haben Ressourcenanforderungen. Überprüfen Sie, ob auf Ihren Knoten genügend CPU-Leistung und Arbeitsspeicher verfügbar sind, indem Sie kubectl describe nodes.
Ressourcenkontingente — Wenn in Ihrem Namespace „ResourceQuotas“ konfiguriert sind, können diese die Erstellung von Pods blockieren. Überprüfen Sie dies unter kubectl get resourcequota -n kubevirt.
Knoten-Taints – virt-handler ist ein DaemonSet, das auf Worker-Knoten ausgeführt werden muss. Wenn Ihre Knoten Taints aufweisen, müssen Sie möglicherweise Tolerationen zur KubeVirt-Konfiguration hinzufügen.
PodSecurityPolicy oder PodSecurity-Zulassung — virt-handler benötigt privilegierten Zugriff. Wenn Ihr Cluster Pod-Sicherheitsstandards durchsetzt, müssen Sie möglicherweise Ausnahmen für den kubevirt Namensraum.

Fehler bei CDI-Importer-Pods

Falls der Import von CDI-Daten fehlschlägt, überprüfen Sie bitte die folgenden häufigen Ursachen:

Keine Standard-StorageClass — CDI muss PersistentVolumeClaims dynamisch erstellen. Stellen Sie sicher, dass Sie über eine Standard-StorageClass verfügen: kubectl get storageclass. Eines sollte markiert werden (Standard).
Unzureichender storage – CDI erstellt während Importvorgängen temporäre PVCs. Stellen Sie sicher, dass Ihr storage über ausreichende Kapazität verfügt.
Netzwerkbeschränkungen — Wenn Bilder von externen URLs importiert werden, benötigen die CDI-Importer-Pods einen ausgehenden Netzwerkzugang. Überprüfen Sie die Netzwerkrichtlinien, die den ausgehenden Datenverkehr von den cdi Namensraum.

virt-operator CrashLoopBackOff

Falls der virt-operator selbst abstürzt, überprüfen Sie die Protokolle:

kubectl -n kubevirt logs -l kubevirt.io=virt-operator--previous

Häufige Ursachen sind Fehlkonfigurationen von RBAC (insbesondere in Clustern mit strengen Sicherheitsrichtlinien) sowie Inkompatibilitäten zwischen der KubeVirt-Version und der Kubernetes-Version. Die Kompatibilitätsmatrix finden Sie auf der KubeVirt-Release-Seite.

Was Sie installiert haben

Hier ein kurzer Überblick darüber, was derzeit auf Ihrem Cluster läuft:

Komponente	Typ	Namensraum	Zweck
virt-operator	Bereitstellung	kubevirt	Verwaltet den Lebenszyklus der KubeVirt-Komponente
virt-api	Bereitstellung	kubevirt	API-Erweiterung für VM-Operationen
virt-controller	Bereitstellung	kubevirt	VM-Lebenszyklus-Controller auf Cluster-Ebene
virt-handler	DaemonSet	kubevirt	Agent zur Verwaltung von virtuellen Maschinen auf Knotenebene
cdi-operator	Bereitstellung	cdi	Verwaltet den Lebenszyklus von CDI-Komponenten
cdi-apiserver	Bereitstellung	cdi	API-Erweiterung für Datenimportvorgänge
cdi-Bereitstellung	Bereitstellung	cdi	Kern-CDI-Steuergerät
cdi-uploadproxy	Bereitstellung	cdi	Verarbeitet das Hochladen lokaler Disk-Images

Nächste Schritte

Ihr Cluster kann nun neben Containern auch virtuelle Maschinen ausführen. So geht es nun weiter:

Erstellen und Verwalten Ihrer ersten VM mit KubeVirt (in Kürze verfügbar) – das nächste Tutorial dieser Reihe, in dem Sie sich mit persistenten storage, Cloud-Images und realistischeren VM-Konfigurationen beschäftigen werden
Planung Ihrer Migration von VMware zu KubeVirt – Wenn Sie KubeVirt als Ersatz für VMware in Betracht ziehen, behandelt dieser Leitfaden die Planungs- und Evaluierungsphase
Fehlerbehebung bei KubeVirt – ein Leitfaden zur Diagnose und Behebung häufiger KubeVirt-Probleme in der Produktion

Zusammenfassung

Sie haben KubeVirt und den Containerized Data Importer auf einem Kubernetes-Cluster installiert und die virtctl CLI-Tool und haben eine Test-VM mit einer CirrOS-Container-Festplatte gestartet. Sie haben durch Zugriff auf die serielle Konsole überprüft, ob die VM korrekt hochgefahren ist.

Ihr Cluster ist nun in der Lage, virtuelle Maschinen neben Containern auszuführen, die über dieselbe Kubernetes-API und dieselben Tools verwaltet werden. Der KubeVirt-Operator verwaltet den Lebenszyklus der Komponenten, und CDI steht bereit, um Festplatten-Images zu importieren, wenn Sie persistenten storage für virtuelle Maschinen benötigen, und virtctl bietet Ihnen die CLI-Tools für den täglichen Betrieb von VMs.

Im nächsten Tutorial gehen Sie über Test-VMs hinaus und erstellen eine produktionsreife virtuelle Maschine mit persistenter storage, einer ordnungsgemäßen Netzwerkkonfiguration und einer Cloud-Init-Konfiguration.