Virtink is a Kubernetes add-on for running Cloud Hypervisor virtual machines. By using Cloud Hypervisor as the underlying hypervisor, Virtink enables a lightweight and secure way to run fully virtualized workloads in a canonical Kubernetes cluster.
Compared to KubeVirt, Virtink:
- does not use libvirt or QEMU. By leveraging Cloud Hypervisor, VMs has lower memory (≈30MB) footprints, higher performance and smaller attack surface.
- does not require a long-running per-Pod launcher process, which further reduces runtime memory overhead (≈80MB).
- is an especially good fit for running fully isolated Kubernetes clusters in an existing Kubernetes cluster. See our Cluster API provider and the knest tool for more details.
Virtink consists of 3 components:
virt-controller
is the cluster-wide controller, responsible for creating Pods to run Cloud Hypervisor VMs.virt-daemon
is the per-Node daemon, responsible for further controlling Cloud Hypervisor VMs on Node bases.virt-prerunner
is the per-Pod pre-runner, responsible for preparing VM networks and building Cloud Hypervisor VM configuration.
NOTE: Virtink is still a work in progress, its API may change without prior notice.
A few requirements need to be met before you can begin:
- Kubernetes cluster v1.16 ~ v1.24
- Kubernetes apiserver must have
--allow-privileged=true
in order to run Virtink's privileged DaemonSet. It's usually set by default. - cert-manager v1.0 ~ v1.8 installed in Kubernetes cluster. You can install it with
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.8.2/cert-manager.yaml
.
Virtink currently supports the following container runtimes:
- Docker
- containerd
Other container runtimes, which do not use virtualization features, should work too. However, they are not tested officially.
Hardware with virtualization support is required. You should check if /dev/kvm
exists on each Kubernetes nodes.
- Minimum: v4.11
- Recommended: v5.6 or above
Install all Virtink components:
kubectl apply -f https://github.com/smartxworks/virtink/releases/download/v0.11.0/virtink.yaml
Once you have deployed Virtink, you can create your virtual machines.
Apply the following manifest to Kubernetes. Note it uses a container rootfs and as such doesn’t persist data.
cat <<EOF | kubectl apply -f -
apiVersion: virt.virtink.smartx.com/v1alpha1
kind: VirtualMachine
metadata:
name: ubuntu-container-rootfs
spec:
instance:
memory:
size: 1Gi
kernel:
image: smartxworks/virtink-kernel-5.15.12
cmdline: "console=ttyS0 root=/dev/vda rw"
disks:
- name: ubuntu
- name: cloud-init
interfaces:
- name: pod
volumes:
- name: ubuntu
containerRootfs:
image: smartxworks/virtink-container-rootfs-ubuntu
size: 4Gi
- name: cloud-init
cloudInit:
userData: |-
#cloud-config
password: password
chpasswd: { expire: False }
ssh_pwauth: True
networks:
- name: pod
pod: {}
EOF
Like starting pods, it will take some time to pull the image and start running the VM. You can wait for the VM become running as follows:
kubectl wait vm ubuntu-container-rootfs --for jsonpath='{.status.phase}'=Running --timeout -1s
The easiest way to access the VM is via a SSH client inside the cluster. You can access the VM created above as follows:
export VM_NAME=ubuntu-container-rootfs
export VM_POD_NAME=$(kubectl get vm $VM_NAME -o jsonpath='{.status.vmPodName}')
export VM_IP=$(kubectl get pod $VM_POD_NAME -o jsonpath='{.status.podIP}')
kubectl run ssh-$VM_NAME --rm --image=alpine --restart=Never -it -- /bin/sh -c "apk add openssh-client && ssh ubuntu@$VM_IP"
Enter password
when you are prompted to enter password, which is set by the cloud-init data in the VM manifest.
Virtink supports various VM power actions. For example, you can power off the VM created above as follows:
export VM_NAME=ubuntu-container-rootfs
export POWER_ACTION=PowerOff
kubectl patch vm $VM_NAME --subresource=status --type=merge -p "{\"status\":{\"powerAction\":\"$POWER_ACTION\"}}"
You can also Shutdown
, Reset
, Reboot
or Pause
a running VM, or Resume
a paused one. To start a powered-off VM, you can PowerOn
it.
- VM lifecycle management
- Container disks
- Direct kernel boot with container rootfs
- Pod network
- Multus CNI networks
- Persistent volumes
- CDI data volumes
- ARM64 support
- VM live migration
- SR-IOV NIC passthrough
- GPU passthrough
- Dedicated CPU placement
- VM devices hot-plug
This project is distributed under the Apache License, Version 2.0.