Google'ın yeni gVisor: Sanal makine kapsayıcı entegrasyon teknolojisi geldi
Yazarlar Qin Chenggang, Wu Qiyi, Yu Wang, Yang Wei
Düzenle Zhang Chan
Kaynak Verimli geliştirme ve işletme
2 Mayıs'ta Google, sanal makinelerden daha hafifken kapsayıcılar için daha güvenli yalıtım sağladığını iddia eden yeni bir korumalı alan kapsayıcı çalışma zamanı türü olan gVisor'u yayınladı. Kapsayıcılar, paylaşılan bir çekirdeğe dayalıdır.Güvenlik büyük bir sorundur. GVisor'un piyasaya sürülmesi, kapsayıcı izolasyonuna daha fazla dikkat çekecektir. Peki gVisor teknik olarak izolasyonu nasıl elde ediyor ve performansı nedir? Yandaki Alibaba'dan biri sizin için gVisor'un mimarisini ve bileşenlerini keşfetti ve performans analizi gerçekleştirdi.
Bu makale ilk olarak InfoQ'nun verimli geliştirme ve bakım için dikey resmi hesabında yayınlandı.İşletme ve bakım ve bulut bilişim alanıyla ilgilenen öğrenciler arama yapabilir ve takip edebilir!
Arka plan tanıtımı
GVisor'un açık kaynağı, güvenli konteynerlerin gerçekleştirilmesi için yeni bir fikir sağlar. Sözde güvenli konteynerin iki ana noktayı içermesi gerekir: güvenli izolasyon ve OCI uyumluluğu. Günümüzde çekirdeği paylaşan kaplar, güvenlik izolasyonu açısından hala nispeten zayıf. Çekirdek sürekli olarak kendi güvenlik özelliklerini geliştirse de, çekirdeğin kendisinin son derece karmaşık kodu nedeniyle, CVE güvenlik açıkları sonsuza dek ortaya çıkar. 2018'den bu yana, 63 çekirdekle ilgili güvenlik açığı, 2017'deki 453 ile karşılaştırıldığında açıklandı.
Herkes bir fikir birliğine varmıştır: İyi bir güvenlik izolasyonuna sahip olmak için, kaptaki programın fiziksel makinenin çekirdeğine bağımlılığını engellemek gerekir. Hyper, Clear Container ve ikisinin birleşimi olan KATA bu fikri takip eder. KATA konteyneri esasen sanal bir makinedir ancak OCI standardı ile uyumludur. Her konteynerin kendi Konuk Çekirdeği vardır. Qemu ve Guest Kernel'in derinlemesine optimizasyonu yoluyla KATA, VM başlatma hızının ve işletim verimliliğinin dezavantajlarını zayıflattı.
gVisor, kapsayıcıdaki kötü amaçlı kodun Ana Bilgisayar Çekirdeğine erişimini de izole eder, ancak başka bir yöntem kullanır. Bu yönteme süreç sanallaştırma diyoruz. Linux Kernel sistem çağrılarının çoğunu sağlayan, Sentry adlı çekirdeğin dışında bir "çekirdek süreci" uygular. Ve akıllıca bir şekilde, kaptaki sürecin sistem çağrısı bu "çekirdek işlemine" erişime dönüştürülür. Google, gVisor'ı güvenli bir kapsayıcı yerine bir "Korumalı Alan" olarak konumlandırır. Bunun bir nedeni, Sentry'nin Linux Kernel'i tamamen değiştirememesidir. Bazı sistem çağrılarının yine de Ana Makine Çekirdeğine aktarılması gerekir.
Google'ın mevcut açık kaynak gVisor sürümü daha çok bir Demo sürümü gibidir ve performansı bazı tipik uygulama senaryolarında KATA kadar iyi değildir. Ama görmek için adını parçalara ayıralım: gVisor = Google'ın yeni HyperVisor'u? Google'ın bir yedeği olacağını tahmin edin.
Bu makale kısaca gVisor'un teknik uygulamasını analiz etmektedir. Zamanın acelesi var ve makaledeki anlatımda kaçınılmaz olarak uygunsuz hatta hatalar var.Herkes bir göz atmaya hoş geldiniz.
Mimari analizi
Genel yapı
gVisor 3 bileşenden oluşur: Runsc, Sentry ve Gofer. RunC ve RunV'ye benzer şekilde, Runsc bir Runtime motorudur, Konteynerlerin yaratılmasından ve imhasından sorumludur. Sentry, yukarıda bahsedilen "çekirdek işlemidir" ve kapsayıcıdaki programların tüm sistem çağrılarını yönetir. Gofer, dosya sisteminin işletim aracısıdır ve IO istekleri, onun tarafından Ana Makineye aktarılacaktır. Bu üç bileşenin tümü Go dili tarafından uygulanmaktadır. Bunun avantajları ve dezavantajları vardır: Go dili geliştirme daha basittir ve tür güvenlidir, ancak gVisor'un performansını sınırlar. Bileşenler arasındaki ilişki Şekil 1'de gösterilmektedir.
Şekil 1: gVisor mimarisi
Runsc kavramının anlaşılması daha kolaydır, bu yüzden onun hakkında daha fazla konuşmayacağız. Runsc'ye dayalı olarak, bir gVisor konteyneri şu şekilde başlatılabilir:
$ docker run --runtime = Runsc hello-gVisorNöbetçi
Sentry, gVisor'un temel bileşenidir. Sistem çağrıları, süreç yönetimi ve bellek yönetimi gibi işlevleri sağlayan basit bir işletim sistemi çekirdeği gibidir.
Sistem çağrısı
GVisor'un ustaca bir tasarımı, sistem çağrıları için ele geçirme yöntemidir. Şu anda iki kaçırma modu vardır: KVM modu ve hız modu. Tempo modunun performansı KVM modu kadar iyi değil. Çünkü uygulamanın her SYSCALL'unun ptrace aracılığıyla Sentry'ye erişmesi gerekiyor. Açıkçası, KVM modu kadar güvenli değil. Ptrace modunun Google'ın orijinal demosu olduğundan ciddi şüphe duyulmaktadır.Bu makale çok fazla analiz yapmayacaktır.
KVM modunda, gVisor uygulamanın her sistem çağrısını durdurabilir ve işlenmesi için Sentry'ye iletebilir. VM ile karşılaştırıldığında, Qemu'yu göremiyoruz, Misafir Çekirdeğini göremiyoruz, Sentry gerekli tüm işlemleri hallediyor. Sanallaştırmaya yönelik bu yaklaşıma "süreç düzeyinde sanallaştırma" denir.
KVM'ye dayandığından, Sentry'nin birden fazla kimliği vardır. Bazen Misafir modunda Ring0 üzerinde çalışır, şu anda konteyner uygulamasının Kernel'i gibidir. Bazen Host modunda Ring 3 üzerinde çalışır, şu anda Host üzerindeki sıradan bir işlem gibidir. Sentry'nin durumu tamamen şu anda işlediği işe bağlıdır. Kapsayıcıdaki sistem çağrılarını işlerken, Misafir durumundadır. Ana Bilgisayar Çekirdeği ile etkileşime girmesi gerektiğinde, HLT komutu aracılığıyla Ana Bilgisayar moduna geri dönecektir.
Sentry şu anda yaklaşık 200 sistem çağrısı uygularken, Linux Kernel X86_64 (4.16 çekirdek) için 318 sistem çağrısı sağlar. Uygulama bu uygulanmayan sistem çağrılarını çağırdığında, Sentry doğrudan bir hata bildirecek ve geri dönecektir. Sistem çağrısı henüz tamamlanmadığından, bazı yazılımlar gVisor'da sorunsuz bir şekilde çalışamaz. Ayrıca, gVisor tarafından desteklenen bazı sistem çağrıları Ana Bilgisayar çekirdeğine dayanmalıdır. Bu sistem çağrılarını işlerken Sentry, Ana Bilgisayar moduna geri dönecektir.
Sentry'nin süreç yönetimi
Sentry, belirli süreç yönetimi sorumluluklarını üstlenir. GVisor kapsayıcısını başlattıktan sonra, Ana Bilgisayarda iki Runsc işlemi görebilirsiniz. Bir süreç, konteyner oluşturma ve IO'dan (Gofer) sorumludur ve diğeri, daha önce bahsettiğimiz "çekirdek işlemi" olan konteynerdeki uygulamalara sistem çağrısı desteği sağlar. Kaptaki tüm işlemler Runsc işleminin iş parçacıkları olarak mevcuttur. Bu biraz Qemu'ya benziyor. Runsc işlemi, başladığında belirli miktarda vCPU iş parçacığı oluşturur.
Sentry, go dilinin GMP modelini yeniden kullanıyor. Her uygulama iş parçacığı, yerleşik go dili programına (bakınız kernle.Task.Start işlevi), yani G. Duruma göre, go çalışma zamanı, Host çekirdeğinin yerel sys_clone'u aracılığıyla yeni bir M (çalışan iş parçacığı) oluşturmayı veya bir öncekini yeniden kullanmayı seçecektir. Burada vCPU, P. Son olarak, go çalışma zamanı zamanlayıcı, gorutini, vCPU ve çalışan iş parçacıklarını birleştirir. M ve P iş parçacığının programlanması Ana Bilgisayar çekirdeği tarafından çağrılır.
Hafıza yönetimi
Kaptaki uygulamanın tüm kodu Runsc işlemi tarafından eşlenir ve aracı tarafından yürütülür. gVisor, her uygulama süreci için bir Konuk sayfası tablosu tutar ve Runsc işleminin kendisi de bir Konuk sayfa tablosuna sahiptir. Bu, güvenlik nedeniyle yapılır ve her işlem ile Runsc arasındaki adres alanını izole eder. Bellekte birbirlerinin üzerine basmalarını önlemek için, Runsc üzerinde kötü niyetli kod saldırılarını da önler. Ancak bu mimari altında, uygulama bir sistem çağrısını her tetiklediğinde, buna Konuk sayfası tablosunun bir anahtarı eşlik edecektir. Sanallaştırmaya aşina olanlar, bunun çok önemli bir ek yük olduğunu bilirler.
Keskin bir karşıtlık Unikernel'dir.Tipik bir Unikernel mimarisi altında, tüm işlemler / çekirdekler aynı adres alanında çalışır ve bir sistem çağrısı bir işlev çağrısına eşdeğerdir. Ancak, uygulama programındaki herhangi bir dikkatsizlik, tüm sistemin çekirdeğinin düşmesine neden olabilir. Güvenlik ve performans her zaman Tradeoff olacaktır.
İnternet
GVisor'da görülen ağ aygıtı, docker kapsayıcıyı oluşturduğunda oluşturulan veth çiftidir ve sanal ağ aygıtı, kapsayıcı içinde eth0 olarak yeniden adlandırılır. Bu sıradan konteynerlerden pek farklı değil.
gVisor, ağ iletişimi için iki yol sağlar:
Ana bilgisayar TCP / IP protokol yığını aracılığıyla
GVisor aracılığıyla uygulanan kullanıcı modu TCP / IP protokol yığını (netstack)
Varsayılan yapılandırma netstack kullanmaktır.Daha yüksek ağ performansına ihtiyacınız varsa, yapılandırma dosyasını değiştirerek ana bilgisayarın TCP / IP protokol yığınını kullanmaya geçebilirsiniz.
GVisor'un netstack ağ iletişimi sayesinde, gVisor uygulama programının sistem çağrısını yakaladığında, ana bilgisayar sistem çağrısı arayüzünü kullanmaz, ancak netstack tarafından sağlanan soket arayüzünü çağırır. Netstack protokol yığınından geçtikten sonra, ana bilgisayarın ham Paketleri soket modunda gönderin ve alın.
Ana bilgisayar TCP / IP protokol yığını aracılığıyla ağ iletişimi için, tüm veri akışı yerel kapsayıcıyla aynıdır Tek fark, gVisor'ın uygulamanın ağ sistemi çağrılarını güvenli kapsayıcıda yakalaması gerektiğidir. Örneğin, dinle / kabul et / sendmsg vb. Daha sonra ağ iletişimi için ana bilgisayar sistem çağrılarına dönüştürülür.
Dosya sistemi
gVisor ayrıca linux gibi dosya sistemini özetler ve belirli dosya sistemlerinin uygulandığı bir VFS katmanı sağlar. 9p, tmpfs, procfs, sysfs vb. Vardır.
gVisor, OCI uyumludur, bu nedenle, rootf'lerinin dosya kaynağı, OCI görüntülerinin toplanmasından sonra rootf'lerden gelir. Konuk Uygulamasının Host sistem çağrılarına doğrudan bağımlılığını azaltmak için Sentry, 9pfs kullanır. Uygulama programı Runsc işlemi ile 9p protokolü aracılığıyla iletişim kurar (Gofer Sunucusunun işlevi içeride çalışır) ve Runsc aracılığıyla Host'un rootf'lerini dolaylı olarak çalıştırır.
gVisor kendi başına bir kitaplık sağlamaz ve kapsayıcıdaki uygulamalar doğrudan ayna kök dosya biçimindeki Kitaplığa bağlanabilir. Tüm ikili programların yeniden derlenmesi ve bağlanması gerekmez, bu da gVisor'un mevcut programlarla uyumluluğunu sağlar.
Ayrıca Sentry, esas olarak işletim performansını sağlamak için dahili tmpf'ler geliştirmiştir. Uygulamanın geçici dosyalarının 9pfs'den geçmesi gerekiyorsa, performans katlanılmaz olacaktır. Sentry ayrıca Linux'u taklit eder ve Linux ile uyumluluk sağlamak için / proc ve / sys dosya sistemlerinde bazı dosyalar geliştirir.
Performans testi
Veri karşılaştırması
GVisor'u sıradan container'lar, RunV (KATA'ya benzer) ve AliUK (Ali tarafından geliştirilen yeni nesil yürütme birimi) ile karşılaştırmak için memcached ve mysql kullandık.
1. memcached: Memcached'in ana maliyeti ağ üzerindedir. Memcached'deki gVisor'ın performans açığı, kendi protokol yığınının optimize edilmemiş olmasıdır.
gVisor (ptrace)
gVisor (kvm)
runc
runv
Aliuk
Memcached
11,8 milyon / sn
13,5 milyon / sn
66,5 milyon / sn
57,8 milyon / sn
82,7 milyon / sn
Yukarıdaki, memcached için birkaç modelin net_rate indeksidir. Değer ne kadar büyükse performans o kadar iyidir. GVisor'un (ptrace) gerçekten gVisor'dan (kvm) daha küçük ve runc / runv / aliuk'tan önemli ölçüde daha düşük olduğu bulunmuştur; aliuk en iyi performansa sahiptir.
2. mysql: Testimizde, mysql'in ana ek yükü IO işlemedir. GVisor'un kök dosya sistemi Sistem, Ana Bilgisayar'daki dosyalara 9p protokolü aracılığıyla erişir. 9p protokolünün performansı, runc konteynerinin yerel fs performansından ve hatta runv ve aliuk'un qcow2'sinin sanal disk performansından çok daha kötüdür.
gVisor (kvm)
runc
Aliuk
mysql
22773,19 ms
1371,44 ms
1673,86 ms
Yukarıdaki, gVisor (kvm), runc ve aliuk için sysbench kullanan mysql oltp.lua'nın karma testinin ortalama gecikmesidir. GVisor'ın performansı açıkça en düşüktür.
Ek olarak, Sentry'nin Ana Bilgisayar çekirdeğine bağımlılığı ve Syscall kaçırmanın verimsizliği de gVisor'un AliUK'tan daha kötü olmasının nedenlerinden biridir.
Fonksiyon karşılaştırması
runc konteyner
RunV
gVisor
AliUK
Uyarılar
Bağımsız
NA
tamamlayınız
Daha tamamlandı
tamamlayınız
GVisor'un bazı SYSCALL uygulamaları Ana Bilgisayar çekirdeğine bağlıdır
verim
yüksek
Daha yüksek
düşük
yüksek
Kaynak mesleği
az
az
az
az
uyumluluk
NA
kuvvetli
Daha güçlü
güçsüz
GVisor'ın bazı çekirdek işlevleri tam olarak desteklenmemektedir ve / proc / sys arayüzü Linux'tan oldukça farklıdır.
Emniyet
güçsüz
kuvvetli
Daha güçlü
kuvvetli
GVisor'ın bazı harici olmayan kaynak erişimi çekirdek işlevleri Host çekirdeğine bağlıdır, bu da güvenli konteynerin ve Host çekirdeğinin saldırı yüzeyini artırır.
Görünüm
gVisor, güvenli konteynerler için bir çözümdür. OCI uyumluluğu, ikili uyumluluk ve çoklu süreç açısından çok akıllıca uygulanmaktadır.SYSCALL'un iyileştirilmesi ve yazılım kodunun olgunlaşmasıyla birlikte, giderek daha fazla konteyner sorunsuz bir şekilde gVisor'a geçebilecektir.
Bununla birlikte, gVisor'un mevcut sürümü henüz performans açısından tatmin edici değil. Bir uygulama SYSCALL'ı her çağırdığında, buna bir sayfa tablosu anahtarı eşlik eder ve bazı işlevler de Ana Bilgisayar çekirdeğini kullanır ve Ana Bilgisayardan düşer. Aynı zamanda, IO için 9pfs'nin zayıf performansı kullanılır ve ağ protokol yığını optimize edilmemiştir. Tüm bunlar, sıradan konteynerlere kıyasla performansının büyük ölçüde azalmasına neden oldu. Daha yüksek performans gereksinimleri olan uygulamalar gVisor'a uygulanamaz.
Referanslar:
https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33
https://github.com/kata-containers
