gVisor Google , sebuah sandbox runtime kontena yang menjanjikan keselamatan yang dipertingkatkan melalui emulasi kernel, sedang bergelut untuk mendapat penggunaan yang meluas walaupun pendekatan inovatifnya terhadap pengasingan kontena. Teknologi ini, yang bertindak sebagai kernel sistem pengendalian perantara antara kontena dan sistem hos, telah menunjukkan hasil yang bercampur-campur dalam pelaksanaan dunia sebenar.
Perbandingan Keselamatan gVisor vs Kontainer Tradisional:
- Docker Tradisional: Berkongsi kernel hos secara langsung, terdedah kepada eksploitasi kernel seperti CVE-2019-5736
- gVisor: Memintas panggilan sistem melalui komponen " Sentry ", mengurangkan pendedahan kernel hos
- Permukaan Serangan: gVisor melaksanakan subset panggilan sistem Linux dalam bahasa Go yang selamat memori
- Pengasingan: Memecah keluar dari gVisor memerlukan kompromi kedua-dua lapisan aplikasi dan Sentry
 |
|---|
| Sesi terminal ini menggambarkan interaksi antara bekas Docker dan sistem pengendalian hos, mencerminkan kerumitan runtime bekas seperti gVisor |
Perkhidmatan Awan Utama Beralih Daripada gVisor
Beberapa perkhidmatan Google Cloud berprofil tinggi telah berundur daripada pelaksanaan gVisor . Google Cloud Functions dan Cloud Run kedua-duanya bermula dengan sandbox gVisor tetapi sejak itu telah berhijrah ke runtime gen2 yang memulakan mesin maya penuh sebaliknya. Punca utama di sebalik penghijrahan ini adalah prestasi input/output yang lemah dan panggilan sistem yang hilang yang menjadikan tingkah laku aplikasi tidak dapat diramalkan sebelum pelaksanaan.
Corak ini meluas melampaui perkhidmatan Google sendiri. Peralihan ini mencerminkan pendekatan Microsoft dengan Windows Subsystem for Linux , yang beralih daripada pendekatan lapisan terjemahan WSL 1 kepada model virtualisasi penuh WSL 2 . Tema berulang menunjukkan cabaran asas dalam mereplikasi fungsi kernel Linux yang lengkap melalui emulasi.
Migrasi Perkhidmatan Utama Meninggalkan gVisor:
- Google Cloud Run: Berpindah daripada gVisor kepada runtime berasaskan VM gen2
- Google Cloud Functions: Bertukar daripada sandbox gVisor kepada mesin maya penuh
- Windows WSL: Corak yang serupa - WSL 1 (lapisan terjemahan) kepada WSL 2 (VM penuh)
- Sebab: Isu prestasi I/O dan tingkah laku aplikasi yang tidak dapat diramal disebabkan syscall yang hilang
Pertukaran Prestasi Mengehadkan Kes Penggunaan Praktikal
Perbincangan komuniti mendedahkan bahawa faedah keselamatan gVisor datang dengan kos prestasi yang ketara. Aplikasi yang melakukan operasi fail yang kerap atau tugas input/output yang intensif mengalami kelembapan yang ketara disebabkan lapisan abstraksi tambahan. Setiap panggilan sistem mesti melalui komponen Sentry gVisor sebelum mencapai kernel hos, mewujudkan overhed yang tidak dapat ditoleransi oleh banyak beban kerja pengeluaran.
Prestasi I/O yang lemah dan beberapa syscall yang hilang menjadikannya sukar untuk meramalkan bagaimana aplikasi anda akan berkelakuan sebelum anda melaksanakannya.
Walaupun terdapat batasan ini, gVisor telah menemui kejayaan dalam niche tertentu. Pengindeks semantik Kythe dalaman Google menggunakan gVisor untuk memproses pelbagai bahasa pengaturcaraan, dan teknologi ini telah terbukti berharga untuk sistem berbilang penyewa di mana keselamatan mengambil keutamaan berbanding prestasi mentah.
 |
|---|
| Output terminal ini menggambarkan bekas gVisor yang melaksanakan aplikasi ringkas, menonjolkan cabaran prestasi dalam penggunaan dunia sebenar |
Batasan Teknikal Berbanding Dengan Mesin Maya
Tidak seperti mesin maya tradisional, gVisor beroperasi sebagai proksi panggilan sistem dan bukannya mekanisme virtualisasi sebenar. Pilihan seni bina ini mewujudkan beberapa kekangan yang mengehadkan kebolehgunaannya. Teknologi ini tidak dapat menyokong ciri pengkomputeran sulit seperti penyulitan memori, dan kes tepi tertentu dalam pengendalian panggilan sistem kekal bermasalah.
Walau bagaimanapun, gVisor menawarkan kelebihan unik dalam senario tertentu. Ia boleh menyekat kerentanan kernel tertentu yang akan menjejaskan mesin maya, dan reka bentuk modularnya telah membolehkan projek lain mengekstrak komponen berguna, terutamanya tumpukan rangkaian ruang pengguna.
Komponen Seni Bina gVisor:
- Sentry: Komponen teras yang memintas dan mengendalikan panggilan sistem
- Runtime: Menggunakan seccomp-bpf untuk dasar keselamatan yang lebih ketat berbanding kernel biasa
- Bahasa: Ditulis dalam Go untuk keselamatan memori, mengelakkan kelemahan kernel berasaskan C
- Rangkaian: Timbunan rangkaian ruang pengguna lengkap tersedia sebagai komponen berdiri sendiri
Kesimpulan
Walaupun gVisor mewakili pendekatan inovatif terhadap keselamatan kontena, penggunaannya telah dihalang oleh isu prestasi dan liputan panggilan sistem yang tidak lengkap. Teknologi ini kelihatan paling sesuai untuk kes penggunaan khusus di mana keperluan keselamatan mengatasi kebimbangan prestasi, dan bukannya sebagai pengganti runtime kontena tujuan umum. Memandangkan penyedia awan utama terus memihak kepada penyelesaian virtualisasi penuh, masa depan gVisor mungkin terletak pada aplikasi niche dan bukannya orkestrasi kontena arus perdana.
Rujukan: What is gVisor?