The k3s-test workers never ran (they were stuck waiting for volume
binding) and will be re-added as microVMs, so remove their KubeVirt
configs and everything that only existed for KubeVirt guests:
- hosts/k8s/k3s-test-1-worker-{1,2,3} and their outputs
- lib/genKubeVirtGuestModule.nix and lib/genK3sAgentModule.nix (the
latter was only used by the workers)
- the KubeVirt image upload recipes (upload-vm, upload-idols,
upload-k3s-test) and the kubevirt image package in the idols outputs
- refresh the docs; keep only accurate historical mentions (e.g. the
restic backup path must stay as it is)
2.5 KiB
Kubernetes Clusters
WIP, not finished yet.
I'm running a Kubernetes cluster for testing and development.
I prefer to use k3s as the Kubernetes distribution, because it's lightweight, easy to install, and full featured(see what-have-k3s-removed-from-upstream-kubernetes for details).
VM Cluster
The VM cluster is running on physical machines, all my virtual machines are running on this cluster, including other Kubernetes clusters.
K3s Clusters
The control plane runs as NixOS microVMs (microvm.nix) on the physical hosts, not as KubeVirt
VMs. Each guest keeps its state in three sparse ext4 images under the host's
/var/lib/microvms/<name>/:
etc.img(64M) — the ssh host key (also the agenix age identity) andmachine-idvar.img(20G) — k3s state (/var/lib/rancher/k3s) and the NixOS uid/gid mapshome.img(4G) — the user's home
The guest's root is a tmpfs and /nix/store is the host's store shared read-only (virtiofs), so no
image has to be built or uploaded; only the volumes above persist. The guest's tap interface is
bridged onto br0, and its name is derived from the guest IP (e.g. 192.168.5.114 -> vm114, as
IFNAMSIZ caps interface names at 15 characters).
To move an existing VM over in place, copy the host key and machine-id from its disk into
etc.img, and /var/lib/rancher/k3s/server into var.img, before the first boot — then it
keeps its identity and etcd membership instead of bootstraping a new cluster.
k3s-test-1-master-{1,2,3}— running as microVMsk3s-test-1-worker-{1,2,3}— to be re-added as microVMs
TODO / Known issues
- Retire KubeVirt. aquamarine now runs natively on
youko, and the k3s-test masters run as microVMs. Remove KubeVirt/CDI/multus from the cluster (k8s-gitops) once nothing else needs them, and the Windows VM is the only VM left to move. - The USB HDD bridge is flaky. aquamarine's two HDDs sit behind a JMicron JMS567 USB-SATA bridge
that keeps resetting (
dmesgonyouko). Find out how often it resets and how much it matters before putting anything critical (e.g. an NFS export) on it.
Kubernetes Resources
Kubernetes resources are deployed and managed separately through ryan4yin/k8s-gitops.