KubeSilicon, KubeVirt tarzı sanal makineleri Apple Silicon Mac'lere getiriyor

Sorun: macOS'ta KVM yok

Kubernetes'e sanal makine desteği ekleyen, CNCF kuluçka sürecindeki proje KubeVirt, Apple Silicon Mac'lerde çalışamıyor. Matheus Thurler'ın bir dev.to yazısına göre nedeni oldukça basit: KubeVirt'in launcher bileşeni, Linux çekirdeğinin hypervisor'ı olan KVM'e bağımlı ve macOS'ta bunun bir karşılığı yok. Thurler, KubeVirt üzerine kurulu özel bir cloud operatörü olan VirtFoundry'ı geliştiriyor; bu da sanal makineler içeren her değişiklikte onu bir Linux sunucusuna zorluyordu, oysa M5 Pro makinesi kümenin kendisini barındırabilirdi.

Bunun yanıtı KubeSilicon: GitHub'da barındırılan, Apache-2.0 lisanslı bu proje, Linux ARM64 sanal makineleri doğrudan Mac üzerinde başlatıyor ve bunları yerel bir Kubernetes kümesindeki pod'lardan erişilebilir hale getiriyor.

Nasıl çalışıyor

Kullanıcılar, kubesilicon.io/v1 API grubu altında bir SiliconVM custom resource tanımlıyor. Manifest, KubeVirt kullanmış herkese tanıdık gelecektir: CPU sayısı, bellek, disk imajı kaynağı ve boyutu ile kullanıcılar ve SSH anahtarları gibi cloud-init kullanıcı verileri için alanlar.

kubesilicond adında bir daemon, kümenin dışında macOS host üzerinde çalışıyor. Kubernetes API üzerinden SiliconVM nesnelerini izliyor, disk imajını indirip dönüştürüyor, bir cloud-init ISO'su oluşturuyor ve guest'i Apple'ın Virtualization.framework'ü kullanarak başlatıyor. Her VM kendi başına ayrık (detached) bir süreç olarak çalışıyor ve daemon, status.phase ile status.ip alanlarını nesneye geri yazıyor. Ayrıca headless bir Kubernetes Service oluşturuyor, böylece demo.default.svc.cluster.local gibi bir isim herhangi bir pod'dan çözümlenebiliyor. VM süreçleri ayrık olduğu için daemon durdurulsa ya da çökse bile çalışan guest'ler etkilenmiyor.

Başlangıç üç komut sürüyor, diyor Thurler: bir kind kümesi oluşturmak, make install çalıştırmak ve örnek bir manifest uygulamak. Onun testlerinde, imajı önbelleğe alındıktan sonra bir VM yaklaşık altı saniyede Running durumuna ulaştı ve bir busybox pod'u ona bir ile iki milisaniye arası gecikmeyle ping attı.

Nerede çalışıyor, nerede çalışmıyor

Daemon'ın ihtiyacı olan yalnızca iki şey var: kümenin Kubernetes API'sine erişim ve pod'lardan VM'lere giden bir ağ yolu; VM'lere Mac üzerinde 192.168.64.x aralığında NAT adresleri atanıyor. Doğrulanmış tek kurulum, Docker Desktop üzerindeki kind. Minikube, Colima, OrbStack ve k3d aynı makinede bir VM ya da container içinde çalıştıkları için ilke olarak çalışmalı, ancak Thurler bunları test etmedi ve kullanıcılardan sonuçları bildirmelerini istiyor. Bulutta barındırılan kümeler tamamen kapsam dışı, çünkü VM'ler sizin Mac'inizde yaşıyor.

KubeVirt ile karşılaştırması

KubeSilicon açıkça KubeVirt değil ve onun CRD'lerini kullanmıyor, ancak API'si bilinçli olarak KubeVirt'ünkine benzer şekilde tasarlanmış. Farklılıklar önemli. KubeVirt KVM ve QEMU kullanır ve VM'leri Linux node'lardaki pod'lar içinde çalıştırır; KubeSilicon ise Apple'ın Virtualization.framework'ünü kullanır ve bunları kümenin dışında host süreçleri olarak çalıştırır. KubeVirt Linux, Windows ve diğer guest'leri destekler; ayrıca canlı göç (live migration), hotplug ve snapshot özellikleri vardır; KubeSilicon yalnızca Linux ARM64 guest'leriyle sınırlıdır ve bu özelliklerin hiçbirini sunmaz. Thurler'ın kendi çerçevesi şöyle: KubeVirt Linux sunucularda doğru seçim olmaya devam ederken, KubeSilicon laptop'u hedefliyor: geliştirme, demolar ve CI.

Ayrıca VirtFoundry'a olası bir köprü çiziyor; VirtFoundry hypervisor katmanının üzerinde durur ve tenant, VPC, IAM ve bir arayüz ekler. VirtFoundry'ın KubeVirt kaynak kullanımını SiliconVM'e eşlemek, sonraki aşamada keşfetmek istediği bir fikir, ancak henüz yapılmış bir şey yok.

Kararlılık ve mevcut sınırlar

Yazıda dürüst bir kararlılık notu da var. Erken testler rastgele guest çökmelerine yol açtı; Apple'ın varsayılan disk modunda dört önyüklemeden üçünde kernel oops raporları ve SIGILL hataları görüldü. Disk bağlantısını fsync'li önbellekli bir moda geçirince dokuz önyüklemede sıfır çökme yaşandı. Thurler örneklemın küçük olduğunu ve framework'ün altındaki nedenin bilinmediğini söyleyerek sonucu kesin değil ama işaret edici olarak nitelendiriyor; sayılar projenin doğrulama belgesine kaydedilmiş.

Diğer sınırlar da oldukça büyük: yalnızca tek bir Mac ve tek bir worker, çoklu Mac desteği bir özellik değil tasarım hedefi; headless Service hiçbir port açmıyor, bu yüzden kullanıcılar VM'lere IP üzerinden erişmek zorunda; launcher süreci ölen bir VM otomatik yeniden başlatılmıyor; macOS guest'ler kapsam dışı; ve v1 API değişecek.

Neden önemli

KubeVirt tarzı geliştirme fiilen Linux donanımı gerektiriyordu; bu da Apple Silicon kullanıcılarını sunucu kiralamaya, yedek bir Linux makinesi bulundurmaya ya da yerel VM testini tamamen atlamaya itiyordu. Sanal makine oluşturan operatörler ya da uygulamalar geliştiren herkes için KubeSilicon, tüm akışı tek bir makinede denemenin bir yolunu sunuyor. Erken aşama, tek geliştiricili bir yazılım ve üretimde KubeVirt'ün yerine geçmez; ama gerçek bir iş akışı boşluğunu kapatıyor ve Virtualization.framework disk modu kararlılığına dair bulguları, Apple'ın hypervisor yığını üzerine inşa eden başka herkesi ilgilendirebilir.