LXC mi KVM mi: Hangisini Seçmeli

Proxmox arayüzünde "Create VM" ve "Create CT" butonlarının yan yana durması, yeni başlayan herkesin aklına aynı soruyu getirir: LXC mi KVM mi? İkisi de sunucuda izole bir Linux ortamı verir, ikisi de kendi IP'siyle çalışır, ikisine de SSH ile bağlanırsınız. Yüzeyden bakınca fark yok gibi görünür; ama biri ana makinenin çekirdeğini paylaşan bir süreç grubudur, diğeri kendi çekirdeğini çalıştıran tam bir sanal bilgisayardır. Bu tek cümlelik fark, performanstan güvenliğe, yedeklemeden yükseltme stratejisine kadar her şeyi değiştirir.

Bu yazıda LXC ile KVM'i pazarlama sloganlarıyla değil, sistem yöneticisinin günlük olarak çarptığı sınırlarla karşılaştıracağım: bellek tüketimi gerçekte ne kadar farklı, izolasyon zayıflığı hangi durumda gerçek bir risk, hangi iş yükü LXC'de çalışmaz, snapshot ve migration davranışları nasıl ayrışır. Sonunda "şu durumda LXC, şu durumda KVM" diyebileceğiniz net bir karar tablosu çıkaracağız.

İki Teknoloji Aslında Ne Yapıyor#

KVM (Kernel-based Virtual Machine), Linux çekirdeğini bir hipervizöre dönüştüren bir modüldür. Bir KVM sanal makinesi oluşturduğunuzda, ana makine üzerinde sanal bir anakart, sanal bir CPU, sanal bir disk denetleyicisi ve sanal bir ağ kartı ortaya çıkar. Konuk işletim sistemi bunların gerçek donanım olduğunu sanır; kendi önyükleyicisini (GRUB), kendi çekirdeğini ve kendi sürücülerini yükler. Yani içeride Debian, Windows Server ya da FreeBSD çalıştırabilirsiniz — ana makinenin ne olduğunun hiçbir önemi yoktur.

LXC ise sanallaştırma değil, işletim sistemi seviyesinde izolasyondur. Bir LXC konteyneri açtığınızda yeni bir çekirdek başlamaz; ana makinenin çekirdeği üzerinde yeni bir namespace kümesi (PID, mount, network, user, UTS, IPC) ve bir cgroup ağacı oluşturulur. Konteynerin içindeki init süreci, aslında ana makinenin süreç ağacında görünen sıradan bir süreçtir; sadece kendi izole görünümüne sahiptir. Bunu kendiniz kanıtlayabilirsiniz:

# Ana makinede çalışan konteyner süreçlerini gör
ps -ef | grep lxc-start
# Konteyner içindeki bir süreç ana makinede de görünür:
pct exec 101 -- sleep 300 &
ps -ef | grep "sleep 300"
# Ana makinede aynı süreç listelenir - ayrı bir çekirdek yoktur

# Konteynerin gördüğü çekirdek, ana makinenin çekirdeğidir
pct exec 101 -- uname -r
uname -r
# İki çıktı BİREBİR aynıdır

Bu deneyi bir KVM makinesinde yaparsanız uname -r çıktıları farklı olur, çünkü konuk kendi çekirdeğini çalıştırır. Proxmox tarafında konteyner oluşturmanın pratik adımlarını daha önce görmediyseniz Proxmox LXC konteyner oluşturma yazısı iyi bir başlangıç noktasıdır.

Kaynak Tüketimi: Rakamlar Ne Söylüyor#

Aradaki farkın en somut göründüğü yer bellektir. Bir KVM makinesi, henüz hiçbir uygulama çalıştırmadan önce kendi çekirdeğini, initramfs'ini, systemd'sini ve temel servislerini belleğe yükler. Boş bir Debian KVM makinesi tipik olarak 150-250 MB RAM ile başlar; buna QEMU sürecinin ana makine tarafındaki ek yükü de eklenir. Aynı Debian'ın LXC hâli 40-80 MB civarında durur, çünkü çekirdek zaten çalışmaktadır ve konteyner yalnızca kendi kullanıcı alanı süreçlerini taşır.

Açılış süresi de benzer şekilde ayrışır. Bir LXC konteyneri saniyenin altında ayağa kalkar; KVM makinesi BIOS/UEFI taklidi, önyükleyici ve çekirdek başlatma aşamalarını geçmek zorunda olduğu için genellikle 8-25 saniye arasında sürer. Disk ve CPU tarafında ise fark sanıldığı kadar büyük değildir: modern KVM, VirtIO sürücüleriyle neredeyse çıplak donanım hızına yaklaşır. Bu konudaki ayrıntı için VirtIO sürücüleri ve disk performansı yazısına bakabilirsiniz — yanlış disk denetleyicisi seçilmiş bir KVM makinesinin LXC'ye göre yavaş görünmesinin sebebi genellikle sanallaştırmanın kendisi değil, IDE/SATA taklidinde kalmış olmasıdır.

Bu tablo LXC'yi otomatik olarak "daha iyi" yapmaz. Yoğunluk avantajı, aşağıda göreceğiniz izolasyon ve esneklik bedeliyle satın alınır. 8 GB RAM'li bir düğümde 40 LXC konteyneri rahatça çalıştırabilirsiniz ama aynı düğüme 40 KVM makinesi sığmaz; buna karşılık o 40 konteynerin hepsi aynı çekirdek çöktüğünde birlikte gider.

İzolasyon ve Güvenlik Sınırı#

Güvenlik konuşurken tek soru şudur: bir konuk sistemden kaçış olursa saldırgan nereye düşer? KVM'de kaçış için QEMU/KVM'in kendisinde ya da sanal donanım taklidinde bir açık bulunması gerekir; bu, oldukça dar ve iyi denetlenen bir yüzeydir. LXC'de ise izolasyonu sağlayan şey doğrudan Linux çekirdeğinin namespace ve cgroup mekanizmalarıdır — yani saldırganın hedefi devasa bir çekirdek sistem çağrısı yüzeyidir.

Bu yüzden LXC'de unprivileged (yetkisiz) konteyner kullanmak pazarlık konusu değildir. Yetkisiz bir konteynerde konteyner içindeki root (UID 0), ana makinede yüksek numaralı ve yetkisiz bir UID'ye (örneğin 100000) eşlenir. Konteynerden kaçan bir saldırgan, ana makinede hiçbir şeye yetkisi olmayan bir kullanıcı olarak çıkar. Yapılandırmayı kontrol etmek kolaydır:

# Konteynerin yetkisiz olup olmadığını kontrol et
pct config 101 | grep unprivileged
# unprivileged: 1   -> güvenli varsayılan

# Ana makinede eşleme tablosunu gör
cat /etc/subuid
# root:100000:65536

Buna karşılık bazı iş yükleri privileged (yetkili) konteyner ister: NFS sunucusu çalıştırmak, bazı FUSE tabanlı dosya sistemleri, ya da doğrudan blok cihaz erişimi gerektiren araçlar. O noktada durup düşünmek gerekir — çünkü privileged bir LXC konteyneri, güvenlik açısından "ayrı bir sunucu" değildir; ana makinenizin biraz kısıtlanmış bir parçasıdır. Müşteriye kiraladığınız, üçüncü tarafın root erişimine sahip olduğu hiçbir ortamı LXC ile vermeyin. Böyle bir senaryoda KVM tek doğru cevaptır. Nitekim VDS ve sanal sunucu paketleri de tam da bu nedenle KVM tabanlıdır.

LXC'de Çalışmayan ya da Zorlanan İş Yükleri#

Bir işi LXC'ye taşımadan önce şu listeye bakın; buradaki maddeler LXC'yi ya imkânsız ya da bakımı yorucu hâle getirir.

1. Farklı bir çekirdek gerektiren her şey. Konteyner ana makinenin çekirdeğini kullanır; özel bir çekirdek modülü yükleyemez, sysctl ayarlarının çoğunu değiştiremez, farklı bir çekirdek sürümüne geçemezsiniz. WireGuard, ZFS ya da özel bir ağ modülü gerektiren kurulumlar burada takılır.
2. Linux olmayan işletim sistemleri. Windows Server, FreeBSD, OPNsense gibi sistemler LXC'de kesinlikle çalışmaz. Bunlar KVM işidir.
3. Docker ve iç içe konteynerleştirme. Teknik olarak mümkündür (features: nesting=1) ama katman katman izolasyon hem performans hem güvenlik açısından karmaşıklaşır. Docker düğümünü KVM makinesi olarak vermek çok daha temiz bir çözümdür.
4. Doğrudan donanım erişimi. GPU, RAID kartı, ses kartı gibi cihazları temiz biçimde vermek için PCI passthrough gerekir ve bu mekanizma KVM'e özgüdür.
5. Kernel seviyesinde ayar isteyen veritabanı ayarları. vm.swappiness, vm.overcommit_memory, huge pages gibi ayarlar konteynerde ana makineden miras alınır; bir konteyner için değiştirdiğinizde diğer hepsini etkilersiniz.

Buna karşılık LXC'nin parladığı yerler nettir: reverse proxy (nginx, HAProxy), DNS önbelleği, izleme ajanları, küçük web uygulamaları, geliştirme/test ortamları, Git sunucuları, statik site barındırma ve bir düğüme onlarcasını sığdırmak istediğiniz her hafif servis.

Snapshot, Yedekleme ve Taşıma Davranışı#

Günlük operasyonda iki teknolojinin ayrıştığı ikinci büyük alan budur ve genellikle sonradan fark edilir. KVM makineleri canlı snapshot alabilir: RAM durumu da diske yazılır, makine çalışmaya devam eder ve bir hataya düştüğünüzde tam olarak snapshot anına saniyeler içinde dönebilirsiniz. Bu, bir sürüm yükseltmesinden önce sahip olabileceğiniz en güçlü güvenlik ağıdır.

LXC'de canlı snapshot, depolama katmanına bağlıdır. ZFS veya LVM-thin üzerinde snapshot alabilirsiniz ama RAM durumu dahil edilmez; konteyner snapshot anındaki disk durumuna döner, çalışan süreçler kaybolur. dir tipi (düz dizin) depolamada ise snapshot hiç desteklenmez. Yedekleme tarafında ise LXC daha rahattır: vzdump bir konteynerin dosya sistemini olduğu gibi arşivler, tek tek dosya çıkarmak kolaydır.

# KVM makinesi için anlık görüntü (RAM dahil)
qm snapshot 200 yukseltme-oncesi --vmstate 1

# LXC konteyneri için anlık görüntü (yalnızca disk, ZFS/LVM-thin gerekir)
pct snapshot 101 yukseltme-oncesi

# Her ikisinde de yedek alma - sıkıştırmalı, anlık görüntü modunda
vzdump 101 200 --mode snapshot --compress zstd --storage yedek

Canlı taşıma (live migration) tarafında da fark vardır: KVM makineleri paylaşımlı depolama ya da yerel disk üzerinde çalışırken kesintisiz olarak başka düğüme taşınabilir. LXC konteynerlerinde Proxmox varsayılan olarak restart migration uygular; yani konteyner durur, taşınır, yeniden başlar. Birkaç saniyelik bir kesinti çoğu servis için sorun değildir ama bunu bilerek planlamanız gerekir. Yedekleme stratejisini sunucu dışına da uzatmak istiyorsanız Borg ile sunucu yedekleme yazısındaki yaklaşım ikisiyle de uyumlu çalışır.

Karar Tablosu: Hangi İş Yükünde Hangisi#

Aşağıdaki tabloyu yıllar içinde biriken pratiklerden çıkardım; tereddüde düştüğünüzde buraya bakmak çoğu tartışmayı bitirir.

Pratikte çoğu Proxmox düğümü karma çalışır: altyapı servisleri LXC'de, müşteri veya üretim iş yükleri KVM'de. Bunu bir "ya o ya bu" savaşı olarak görmeyin; aynı sunucuda ikisini birlikte kullanmak en verimli düzendir.

Sık Yapılan Hatalar ve Tuzaklar#

En çok karşılaştığım ilk hata, LXC'yi "hafif VDS" sanmaktır. Konteyner içinde free -h çalıştırdığınızda cgroup limiti değil bazen ana makinenin toplam belleği görünür (lxcfs kurulu değilse); top çıktısı yanıltıcı olur; dmesg ana makinenin çekirdek günlüğünü gösterebilir. Bunlar hata değil, tasarımın doğal sonucudur — ama izleme sistemi kurarken yanlış alarm üretir.

İkinci hata privileged konteyneri kolaya kaçmak için seçmektir. Bir mount noktası çalışmadığında ya da bir izin hatası alındığında refleks olarak konteyneri privileged yapmak sorunu kapatır ama izolasyon sınırını da siler. Doğru yaklaşım, sorunun kaynağını bulmak ve gerekiyorsa yalnızca ilgili yeteneği (features: mount=nfs gibi) açmaktır.

Üçüncü hata, KVM makinesini varsayılan disk denetleyicisiyle bırakmaktır. IDE veya SATA taklidinde kalan bir makine, LXC'ye göre kat kat yavaş görünür ve insanlar bundan "sanallaştırma yavaş" sonucunu çıkarır. Doğru cevap VirtIO SCSI'ye geçmektir. Aynı şekilde konuk sisteme QEMU Guest Agent kurmadan çalışmak, tutarlı snapshot ve düzgün kapatma imkânını elinizden alır.

Dördüncü hata yedekleme testini hiç yapmamaktır. LXC yedeği geri yüklerken UID eşlemesi yüzünden dosya sahiplikleri bozulabilir (özellikle privileged↔unprivileged geçişlerinde). Yedeğinizi ilk günden bir kez geri yükleyip doğrulamadıysanız, elinizde yedek değil bir umut vardır.

Sıkça Sorulan Sorular#

LXC KVM'den ne kadar hızlıdır#

Ham CPU ve disk performansında fark, doğru yapılandırılmış bir KVM makinesiyle karşılaştırıldığında genellikle yüzde birkaçtır; yani gündelik iş yüklerinde hissedilmez. Asıl fark açılış süresinde ve boşta bellek tüketiminde ortaya çıkar: LXC saniyenin altında açılır ve üçte bir kadar RAM harcar. Eğer bir KVM makinesi belirgin biçimde yavaş görünüyorsa, sebep neredeyse her zaman IDE/SATA taklidinde kalmış disk denetleyicisi ya da eksik VirtIO sürücüleridir.

LXC konteynerinde Docker çalıştırabilir miyim#

Teknik olarak evet: Proxmox'ta konteynerin seçeneklerinden nesting özelliğini açmanız ve genellikle keyctl iznini de vermeniz gerekir. Ancak bunu üretim ortamı için önermiyorum. İç içe iki izolasyon katmanı hem hata ayıklamayı zorlaştırır hem de Docker'ın ihtiyaç duyduğu bazı çekirdek ayarlarını konteynerden yapamazsınız. Docker düğümlerini KVM makinesi olarak kurmak uzun vadede çok daha az sorun çıkarır.

Müşteriye kiraladığım sunucu için LXC kullanabilir miyim#

Kullanmamanızı tavsiye ederim. LXC'de izolasyon sınırı ana makinenin çekirdeğidir; bir çekirdek açığı, tüm konteynerlerin ve ana makinenin birlikte etkilenmesi anlamına gelir. Root erişimini üçüncü bir tarafa verdiğiniz her senaryoda KVM kullanın. Bu yüzden ticari VDS ürünleri neredeyse istisnasız KVM tabanlıdır.

LXC konteynerini KVM makinesine dönüştürebilir miyim#

Doğrudan bir dönüştürme komutu yoktur, çünkü konteynerde önyükleyici ve çekirdek bulunmaz. Pratik yöntem şudur: hedef KVM makinesini aynı dağıtımla temiz kurun, sonra konteynerin /etc, uygulama dizinleri ve veri klasörlerini rsync ile taşıyın, paket listesini yeniden kurun. Yani veri taşıması yaparsınız, imaj dönüştürmesi değil. Ters yön (KVM'den LXC'ye) de aynı mantıkla işler.

LXC ile Docker konteyneri aynı şey mi#

Aynı çekirdek teknolojilerini (namespace, cgroup) kullanırlar ama amaçları farklıdır. LXC bir sistem konteyneridir: içinde systemd çalışır, birden fazla servis barındırır ve bir sunucu gibi davranır. Docker ise uygulama konteyneridir: tek bir süreci çalıştırmak, katmanlı imajlarla dağıtılmak ve durumsuz olmak üzere tasarlanmıştır. LXC'yi hafif bir sunucu, Docker'ı taşınabilir bir uygulama paketi olarak düşünün.

Aynı Proxmox düğümünde hem LXC hem KVM çalıştırabilir miyim#

Evet, hatta önerilen kullanım budur. Proxmox ikisini de aynı arayüzden yönetir, aynı depolama havuzlarını ve aynı yedekleme mekanizmasını (vzdump) paylaşırlar. Tipik bir düzende altyapı servisleri (proxy, DNS, izleme) LXC konteynerlerinde, müşteri veya üretim iş yükleri KVM makinelerinde çalışır. Kaynak planlaması yaparken yalnızca toplam RAM ve CPU bütçesini birlikte hesaplamayı unutmayın.

Hangisi daha kolay yedeklenir#

İkisi de vzdump ile yedeklenir ama LXC yedeğinden tek bir dosyayı çıkarmak daha kolaydır, çünkü yedek doğrudan dosya sistemi arşividir. KVM yedeği ise disk imajı içerir; içinden tek dosya almak için imajı bağlamanız gerekir. Buna karşılık KVM'de RAM durumu dahil canlı snapshot alabilirsiniz, LXC'de bu mümkün değildir. Yani "kolay geri yükleme" LXC'nin, "tam duruma dönüş" KVM'in avantajıdır.

Kapanış#

LXC mi KVM mi sorusunun tek bir doğru cevabı yok; doğru cevap iş yüküne bağlı. Aklınızda kalması gereken dört pratik alışkanlık şunlar: farklı bir çekirdek, Linux dışı bir sistem ya da donanım erişimi gerekiyorsa tereddütsüz KVM seçin; üçüncü tarafa root verdiğiniz her ortamı KVM ile izole edin; LXC kullanacaksanız unprivileged varsayılanından ayrılmayın; ve KVM makinelerinde VirtIO ile guest agent'ı ilk günden kurun, sonradan eklemek her zaman daha zahmetlidir.

İkisini birlikte kullanmak en verimli düzendir ve altyapıyı kendiniz kurmak istiyorsanız tam root erişimli VDS ve sanal sunucu paketlerimizle kendi Proxmox düğümünüzü kurabilirsiniz. Daha fazla yalıtım ve tam donanım kontrolü gerekiyorsa dedicated sunucu, esnek ölçeklenme istiyorsanız bulut sunucu tarafına bakabilirsiniz. Kurulum ve bakım yükünü devretmek isterseniz sunucu yönetimi hizmetimiz hipervizör katmanını da kapsıyor.