Giriş:
Konteynerler aslında çok büyülü şeyler değil, Linux çekirdeğinde (kernel) bulunan namespaces ve cgroups özelliklerini kullanan bir izolasyon katmanından ibaretler. Bu sayede sistemin kendisinden, çalıştırdığınız konteyner ve içerisinde yürüyen işlemleri bir miktar izole ediyorlar. VM (virtual machine) kullanmaktan farkları ise, mevcut sisteminin üzerinde ayrı ve yeni bir sistem kaldırmak yerine, çekirdeği ortak kullanarak daha hızlı kalkış ve kolay bir kullanım sağlıyorlar.
Namespace kısmı alttaki sistemin yürüyen parçalarından üstteki konteyneri ayırıyor. Ana parçalarına örnek olarak:
- PID -> konteyner PID 1 (root işlemi) alttaki sistemdeki işlemleri bilmiyor
- NET -> konteyner alttaki sistemdeki ağı, portları, yönlendirme işlemlerini bilmiyor
- MNT -> konteyner alttaki sistemden belirli dosya yollarını görüp kullanabiliyor, fakat izin verilenin haricinde hiçbirini bilmiyor
- IPC -> konteyner kendi işlemleri haricinde altaki sistemdeki paylaşılan bellek yollarına ve IPC kaynaklarına ulaşamıyor
- UTS -> konteyner alttaki sistemden farklı bir hostname'e sahip olabilir
- USER -> konteyner içerisindeki bir kullanıcı veya grup alttaki sistemde çok daha az yetkisi olan bir kullanıcı veya gruba eşlenebiliyor
Cgroups kısmı ise bu konteynere cpu, ram vb. kaynaklarda sınır koymaya yarıyor
Neden Kata Containers/Runtime:
Standart docker konteynerleri aslında mükemmel, hafif ve çok hızlı bir şekilde boot edebiliyorlar. Fakat alttaki sistemin çekirdeğini kullanıyorlar (host kernel). Bir şekilde bu konteynerden kaçmayı başaran (container escape) çekirdek içerisindeki açıklardan yararlanarak alttaki sisteme veya diğer konteynerlere erişebilir. Kata Containers aslında burada bir çözüm sağlıyor. Konteyneri bildiğimiz şeklinden bir microVM e çevirip alttaki sistemden bir miktar daha ayırıyor. Elbette her güvenlik basamağının getirdiği performans kayıpları gibi bunun da bazı yerlerde kayıpları olacak. Bu microVMler için qemu, cloud-hypervisor, firecracker(AWS) kullanıyor.Aşağıda ufak, basit bir benchmark sonuçları paylaşacağım, bakalım temel kayıplar nelermiş. Konteyner içerisinde hız testi çok mantıklı olmayacaktır, onun yerine bakılabilecek şeyler konteynerin ayağa kalkma süresi ve kapladığı bellek olabilir.
Docker için kullanılabilecek başka runtimelar da mevcut, buradaki link üzerinden inceleyebilirsiniz.
Test:
Test edilen runtimelar:
- kata (qemu)
- kata (cloud-hypervisor)
- docker default (runc)
Test Şekli: Yukarıda belirtilen runtimelar için
- nginx:alpine konteyneri ayağa kalkacak ve curl den varsayılan sayfayı döndürebileceği kadar beklenecek, bu süre not edilecek.
- docker stats tarafından dönen mem değeri alınacak
- hipervizör işleminin rss değeri alınacak (resident set size)
Her bir runtime cloud-hypervisor, qemu, runc sırasıyla 2 tur dönecek şekilde, her turda 10 kere tekrarlanacak. Toplamda 20 ölçümün ortalaması alınacak.
Ortam:
- Kata Containers Versiyon: 3.32.0 link
- Docker Versiyon: 29.6.1, build 8900f1d
- Host OS: Ubuntu 24.04.4 Linux 6.8.0-134-generic #134-Ubuntu SMP PREEMPT_DYNAMIC
- Host Özellik: 8 vCPU 1 Numa Node, 16GB ram
Test Sonuçları:
| Runtime | Boot->Ready sn | Konteyner Bellek MiB | Hipervizör Bellek MiB |
|---|---|---|---|
| kata(qemu) | 4.074s | 3.0782 MiB | 266.7675 MiB |
| kata(cloud-hypervisor) | 2.959s | 3.0254 MiB | 145.08 MiB |
| docker(runc) | 0.230s | 7.2831 MiB | 0-N/A MiB |
Sonuç:
Küçük bir uygulama için Kata MicroVM konteyner kullanımının boot ve bellek kullanımında oluşturduğu farkı görmemek imkansız. Boot 12-17 katına çıkarken konteyner başına fazladan kaybedilen 145-266MB bellek, nginx gibi bir uygulama için aşırı fazla.
Kata-Kata karşılaştırmasında Cloud-Hypervisor, QEMU'dan %30 daha hızlı açılıyor ve yarısı kadar bellek kullanıyor. Kata Containers kullanımı için öncelikli tercih cloud-hypervisor tarafında olabilir. Yine de yüzlerce konteyner koşacak sunucular için oluşacak yük gerçekten yüksek. Bu karşılaştırmaya kata runtimelarından,Firecracker VMM de eklenmeli, belki serverless yaklaşımı sebebiyle orada Firecracker daha düşük bellek kullanımına erişebilir.
Özet olarak Kata-Containers kullanımı, neden bu tercihi yaptığımızı bilerek atılması gereken bir adım. VM seviyesinde izolasyona ihtiyacımız varsa gerçekten anlamlı... Böyle bir ihtiyaç yoksa ve yoğun (dense) kullanım mevcut yerlerde seçilirse farklı konularda sorunlar yaratacağı kesin. Unutmayalım güvenlik sürekli düşünülmesi gereken bir süreç. Bu tercih bile kvm escape konusunda açıklarla karşılaşabilir.
Referanslar:
Teşekkür: Ana fotoğraf: Regine Tholen orijinaline Unsplash üzerinden ulaşabilirsiniz.