Konteynerin genel bulut üzerindeki iniş duruşu
1. Kapların yetersiz içsel izolasyonu
1.1 Konteyner, bir sanallaştırma teknolojisi değil, bir süreç izolasyon teknolojisidir
Konteyner bir sanallaştırma teknolojisi değil, süreçleri çekirdek alanı, kaynaklar ve güvenlik yönlerinden izole eden bir süreç izolasyon teknolojisidir.
Linux kapsayıcıları, Linux kontrol gruplarını (cgroups) ve ad alanlarını (ad alanı) kullanır; burada cgroups, bir işlemin ne kullanabileceğini (CPU, bellek, ağ ve diğer kaynaklar) tanımlar ve ad alanı, bir işlemin neler görebileceğini tanımlar (uid, gid, pid, mount, dosya sistemi vb.). Bir yandan, tüm sistem kaynakları bu mekanizmalar tarafından kontrol edilemez (örneğin zaman ve anahtarlık, https://blog.jessfraz.com/post/two-objects-not-namespaced-linux-kernel/).
Öte yandan, Linux kapsayıcılarında çalışan uygulamalar, sistem kaynaklarına normal (kapsayıcıya alınmamış) uygulamalarla aynı şekilde erişir; sistem çağrıları doğrudan ana bilgisayar çekirdeğine yapılır. Çekirdek, ayrıcalıklı bir modda çalışır ve gerekli donanımla etkileşime girmesine ve sonuçları olumsuz uygulamaya döndürmesine izin verir. Bu nedenle, birçok kısıtlamayla bile, çekirdek hala kötü amaçlı programlara çok fazla saldırı yüzeyi açmaktadır.
Cgroups ve ad alanlarına ek olarak, Linux kapsayıcıları seccomp gibi teknolojileri de kullanır. Seccomp, bir işlemin çekirdek sistem çağrılarına erişimini kısıtlayan ve uygulama ile çekirdek arasında daha iyi izolasyon sağlayan, ancak kullanıcıların önceden tanımlanmış bir sistem çağrıları beyaz listesi oluşturmalarını gerektiren bir çekirdek güvenlik duvarıdır. Pratikte, uygulamanın gerektirdiği tüm sistem çağrılarını önceden listelemek zordur. Aramanız gereken sistem çağrısında boşluklar varsa, bu tür filtrelerin çalışması da zordur.
Bu nedenle, konteynerlerin sanal makineler ve sanbox'lar ile aynı izolasyon yeteneklerine sahip olduğu düşünülmez. Kapsayıcılar, sanal makineler ve korumalı alanlar arasındaki farkla ilgili olarak, Jessie'nin bu blog yazısı (Düzgün Kaydı Ayarlamak: kapsayıcılar, Bölgeler, Hapishaneler ve Sanal Makineler) iyi bir açıklama sağlar.
1.2 Kubernetes'te çok kiracılı izolasyon
Jessie Frazelle (blog adresi https://blog.jessfraz.com, şiddetle tavsiye edilir) çok kiracılı izolasyon modelini iki kategoriye ayırır:
- Yumuşak çoklu kiracılık: Aynı kuruluştaki birden çok kullanıcı aynı kümeyi kullanır. Bu izolasyon modunda, kullanıcılar aynı organizasyonda oldukları için varsayılan olarak bir güven ilişkisine girerler, ancak kötü niyetli çalışanlar gibi olası durumlar da vardır. Bu izolasyon modunun temel amacı, bu tür kötü niyetli olayları önlemektir.
- Sabit çoklu kiracılık: Farklı kuruluşlardan birden çok kullanıcı aynı kümeyi kullanır. Bu izolasyon modunda, varsayılan olarak tüm kullanıcıların potansiyel olarak kötü niyetli olduğu varsayılır, bu nedenle bu modun ana amacı kiracılar arasında karşılıklı erişimi önlemektir.
Yukarıdaki tanımdan da görülebileceği gibi, temel olarak özel bulutun izolasyon modu zayıf izolasyon modudur, genel bulutun izolasyon modu ise güçlü izolasyon modudur.
Kapsayıcılar doğası gereği yeterince izole edilmediğinden, yalnızca geleneksel Linux kapsayıcıları kullanılıyorsa, genel bulutlar genellikle güçlü yalıtım elde etmek için her kullanıcı için bir Kubernetes kümesi oluşturma yöntemini kullanır:
Jessie Frazelle'in bu resmi, K8S'nin farklı ana bilgisayarlarda farklı K8S kümeleri oluşturup yönetebileceğini varsayar (o sırada K8S gerçekten bir küme işletim sistemi haline geldi). Aslında, mevcut rol genellikle genel bulutun kendi bulut yönetim platformu tarafından uygulanır ve ardından her kullanıcı için birkaç sanal veya fiziksel makinede eksiksiz bir Kubernetes kümesi oluşturulur ve her küme, müşterinin uygulamalarını çalıştırmak için geleneksel Linux kapsayıcılarını kullanır. . Geleneksel Linux kapsayıcılarının yetersiz izolasyonu nedeniyle, her kullanıcının kapsayıcısına özel bir ortamda izin verilmelidir.
Bununla birlikte, işletim ortamı geleneksel bir Linux kapsayıcısından bir mikro sanal makineye (bir kata kabı gibi) değiştirilirse, mikro sanal makinenin kendisi güçlü yalıtım yeteneklerine sahip olduğundan, bir ana makinede farklı kullanıcılar için bu tür bir işletim ortamı oluşturmak mümkündür. Bu ortamlar kümede karışıktır.
2. Kapsayıcı AWS'de nasıl uygulanır (Lambda'yı örnek olarak alın)
AWS'deki birçok hizmet kapsayıcılar kullanır. Örneğin, Lambda geleneksel Linux kapsayıcılarını kullanırken ECS ve EKS Docker kapsayıcılarını kullanır. Örnek olarak Lambda'yı ele alarak, AWS'de container'ların geçmiş ve şimdiki yollarına bir göz atalım.
2.1 Geçmişte, Lambda'da kaplar nasıl kullanıldı?
Kullanıcı işlevleri, özel bir EC2 sanal makinede bir Linux kapsayıcısında çalışır
Aşağıdaki şekil Lambda'nın teknik mimarisini göstermektedir:
Adından, temel olarak her bileşenin ne yaptığını anlayabilirsiniz. Bunların arasında bir Çalışan, kullanıcı işlevlerini gerçekten çalıştırmak için güvenli bir ortamdır. Önceden, çalışan bir EC2 bulut sunucusuydu ve işletim sistemi Amazon Linux'du.
Aşağıdaki şekil, yaratılan İşçinin ve işçiye gönderilen işlevin temel akışıdır:
Bunların arasında, Çalışan yönetimi, çalışanların yaratılması ve yönetilmesinden sorumludur ve Yerleştirme hizmeti, kullanıcı işlevlerinin bir veya birkaç işçi üzerinde çalışacak şekilde planlanmasından sorumludur.
Şu anda, Lambda'nın güçlü izolasyon modunun uygulanması aşağıdaki şekilde gösterilmektedir:
Bu resim hala basit ve net, bu yüzden ayrıntılı olarak açıklamayacağım.
AWS Lambda ekip mühendisine alıntı yapacak olursak, CPU tabanlı donanım sanallaştırma teknolojisi, AWS'deki kullanıcılar arasında izolasyon için minimum gereksinimdir. Bu nedenle, AWS'de kapsayıcı kullanan birçok hizmet gibi Lambda da kullanıcılar arasında güçlü bir yalıtım sağlamak için EC2 sanal makinelerini kullanır.
Ancak, aşağıdaki gibi sınırlamaları açıktır:
- Kaynak israfı: kullanıcının basit bir test işlevi de bir sanal makineyi işgal edecektir)
- Karmaşık yönetim: karmaşık kaynakları ve güvenlik modellerini yönetme ihtiyacı
- Başlangıç hızı yeterince hızlı değil: EC2 sanal makinenin oluşturulma süresi nedeniyle
2.2 Konteyner, Firecracker mikro sanal makinesinde çalıştırılan Lambda kullanıcı işlevlerinde şimdi nasıl uygulanıyor?
Amazon, 2018 re: invent konferansında yeni bir açık kaynak projesi olan Firecracker'ı duyurdu ve Lambda ve Fargate hizmetlerinde kullanıldı. Firecracker, Linux çekirdek tabanlı sanal makine (KVM) teknolojisini kullanan açık kaynaklı bir sanal makine monitörüdür (VMM). Firecracker, mikro sanal makinelerin (microVM) oluşturulmasından ve yönetilmesinden sorumludur. Firecracker mikro sanal makinesi, verimliliği ve kullanımı iyileştirmiştir ve bellek ek yükü son derece düşüktür, bu da tek bir fiziksel sunucuda binlerce mikro sanal makine oluşturmayı mümkün kılar. Daha sonra tanıtacağım.
Firecracker kullanıldıktan sonra Lambda izolasyon modeli:
Faydaları kendi kendini açıklayıcı niteliktedir, örneğin:
- Kullanıcılar arasında güçlü izolasyon sağlamak için CPU donanım sanallaştırmasını kullanın.
- Fiziksel donanım kaynak kullanımını iyileştirin.
- Fonksiyon çalışmasının başlama süresini kısaltın.
- Güvenlik modeli basitleştirildi.
- Lambda programlama modeli basitleştirildi.
3. Firecracker nedir
Havai fişek, Çince'de "kestane fişeği" anlamına gelir. Adından da anlaşılacağı gibi, AWS'nin genel bir bulutta bir konteyner çalıştırmanın havai fişekleri ateşlemeye benzediğini düşünüyor mu bilmiyorum. Renkli görünüyor, ancak yapmazsa yangına neden olur.
Sadece Firecracker'ı büyük ölçüde basitleştirilmiş bir QEMU olarak düşünün. QEMU gibi, sanal makineleri oluşturmak ve yönetmek için KVM kullanır. Bu tür bir sanal makine Sunucusuz senaryolarla karşı karşıya olduğundan ve geçici ve kısa ömürlü süreçleri çalıştırmak için uygun olduğundan, buna mikro sanal makine veya microVM denir.
Çünkü genel bulut, mikro sanal makinelerin geleneksel sanal makinelerle aynı izolasyon özelliklerine ve Linux kapsayıcıları gibi hafif özelliklere (düşük donanım ek yükü ve hızlı başlatma) sahip olmasını gerektirir. Bu nedenle, Firecracker'ın tasarım fikri:
- Yerleşik güvenlik: Çok kiracılı iş yüklerini destekleyen ve müşteriler tarafından yanlışlıkla devre dışı bırakılmayan bir bilgi işlem güvenlik engeli sağlar. Müşteri iş yükleri hem kutsal (dokunulmaz) hem de kötü (kapatılmalıdır) olarak kabul edilir.
- Hafif sanallaştırma: Uzun süreli veya sürekli iş yükleri yerine geçici veya durumsuz iş yüklerine dikkat edin. Firecracker'ın donanım kaynak ek yükü açık ve garantilidir.
- İşlevsel minimalizm: AWS görevlerinin açıkça gerektirmediği özellikler oluşturmaz. Her işlev için yalnızca bir öğe uygulanır.
- Hesaplamalı aşırı puanlama: Firecracker'ın konuklara açtığı tüm donanım bilgi işlem kaynaklarına güvenli bir şekilde fazla puan verilebilir.
Havai fişek, yalın tasarım ilkesine bağlı kalır, yalnızca güvenli ve hafif bir sanal makineyi çalıştırmak için gereken bileşenleri içerir. Firecracker, tasarım sürecinin tüm yönlerinde güvenlik, hız ve verimlilik gereksinimlerine göre optimize edilmiştir. Örneğin, yalnızca nispeten yeni Linux çekirdeğini başlatın ve yalnızca belirli bir yapılandırma seçenekleri kümesiyle derlenen çekirdeği başlatın (1000'den fazla çekirdek derleme yapılandırma seçeneği vardır). Buna ek olarak, herhangi bir grafik kartı veya hızlandırıcı türünü desteklemez, donanım şeffaf iletimini desteklemez ve (çoğu) eski aygıtı desteklemez. Yalnızca dört tür cihaz sanallaştırma desteklenir (virtio-net, virtio-block, seri konsol ve yalnızca bir düğmeyle klavye denetleyicisi).
Bunun sonucu da çok açıktır, örneğin:
- Her bir mikro sanal makinenin bellek ek yükü 5 MiB'den azdır.
- Fiziksel bir makinede başlatılabilen mikro sanal makinelerin sayısı sınırı yalnızca bir donanım sınırıdır ve sayı binler olabilir.
- AWS'nin bir seferde 4000 mikro sanal makine başlatmaya yönelik gösterisinde, en uzun mikro sanal makine yalnızca 219 milisaniye, en kısası ise yalnızca 125 milisaniye sürdü.
Projenin açık kaynak adresi https://firecracker-microvm.github.io/ şeklindedir. Daha fazla bilgi için daha fazla makale okuyabilir ve hatta kaynak kodunu okuyabilirsiniz.
Dördüncüsü, geleceğe bak
AWS, açık kaynaklı Firecracker'ın sektörde büyük ilgi gördüğünü duyurdu. Mevcut Kata kapsayıcısına (Intel, Hyper.sh ve OpenStack liderliğindeki) ve gVisor'a (Google tarafından açık kaynaklı) ek olarak, mikro sanal makineler giderek daha fazla ilgi gördü. Kişisel anlayışa dayanarak, geleceğe dair biraz sorumsuz bir tahmin yapın:
- Genel bulutların konteynırları indirmek için mikro sanal makineleri kullanması yaygın bir uygulama haline gelecektir. Alibaba Cloud'un doğası gereği, yakında takip edeceklerine ve AWS'ye benzer bir teknoloji uygulamasını başlatacaklarına inanıyorum. Bir projenin açık kaynaklı olması da muhtemeldir.
- AWS, birleşik konteyner iniş modeli olarak Firecracker'ı kullanacaktır.
- Mikro-sanal makine ekosisteminde (Kata kapsayıcısı, gVisor ve Firecracker) birçok ilginç değişiklik olacak. Şu anda, her projenin kendine özgü senaryo odaklı vardır. Teknik olmayan bir bakış açısıyla, AWSnin açık kaynağa yönelik tutumu "ağırlıklı olarak ben" olması gerektiğinden, Firecracker AWS tarafından yönetilmeye devam edecek ve çoğunlukla AWS üzerindeki hizmetler tarafından kullanılmaya devam edecek; gVisor Google'dan geliyor ve Google'ın da genel bulutları var. Buna ek olarak, Kubernetes de Google'dan geldi, fiili bir mikro-sanal makine standardına dönüşüp dönüşmeyeceğini bilmiyorum; Kata kapsayıcısı gelecekte esas olarak özel bulut senaryoları için olabilir (OpenStack'in Kata mikro sanal makinelerini ve K8S'yi desteklediğini hayal edin gVisor mikro sanal makine, ikisi arasındaki PK, orkestrasyon yeteneğinin PK'si haline gelir mi?).
Referans bağlantısı:
- https://docs.google.com/document/d/1PjlsBmZw6Jb3XZeVyZ0781m6PV7-nSUvQrwObkvz7jg/edit
- https://blog.jessfraz.com/post/containers-zones-jails-vms/
- https://www.youtube.com/watch?v=QdzV04T_kec
- https://www.slideshare.net/AmazonWebServices/a-serverless-journey-aws-lambda-under-the-hood-srv409r1-aws-reinvent-2018
- https://aws.amazon.com/blogs/opensource/firecracker-open-source-secure-fast-microvm-serverless/
Yazar: Sammy Liu, tanınmış bulut bilişim blog yazarı.
