Beruntung

Kubernetes telah memainkan peran penting dalam pekerjaan saya, dan di masa depan itu akan menjadi lebih penting. Tapi 2018 hampir berakhir, jadi lupakan tentang kesederhanaan dan buat prediksi yang berani:

Masa depan Kubernetes adalah mesin virtual, bukan wadah

Menurut horoskop Cina, 2018 adalah tahun anjing, tetapi dalam teknologi itu adalah tahun Kubernet. Banyak yang sekarang belajar tentang teknologi revolusioner ini, dan departemen TI di mana-mana berusaha mengembangkan "strategi Kubernetes" [1]. Beberapa organisasi telah mentransfer beban kerja besar ke Kubernetes.

[1] Jika Anda mencoba mengembangkan strategi Kubernetes, Anda sudah gagal, tetapi ini adalah topik untuk artikel lain.

Dengan kata lain, ada banyak orang di Kubernetes di setiap langkah "Gartner Sensation Cycle". Beberapa terjebak dalam kekecewaan atau tenggelam dalam lubang keputusasaan.


Jeremykemp, Wikipedia . Creative Commons CC BY-SA 3.0

Saya penggemar berat wadah dan saya tidak akan mengatakan bahwa wadah sudah mati . Pada 2013, Docker memberi kami sebuah shell untuk Linux Containers: sebuah cara baru yang menakjubkan untuk membuat, mengemas, membagikan, dan menyebarkan aplikasi. Itu muncul pada saat yang tepat, ketika kami mulai menganggap serius pengiriman yang berkesinambungan. Model mereka menjadi ideal untuk rantai pengiriman dan berkontribusi pada munculnya platform PaaS, dan kemudian CaaS.



Insinyur Google melihat bahwa komunitas TI akhirnya siap untuk wadah. Google telah menggunakan kontainer untuk waktu yang sangat lama, dan dalam arti tertentu mereka dapat dianggap sebagai penemu containerisasi. Mereka mulai mengembangkan Kubernet. Seperti yang Anda ketahui sekarang, ini adalah reinkarnasi gratis dari platform Borg Google sendiri.

Segera, dukungan untuk Kubernetes disediakan oleh semua awan besar (GKE, AKS, EKS). Layanan di tempat juga dengan cepat meningkatkan platform berdasarkan Kubernetes (Layanan Kontainer Penting, Openshift, dll.).

Multi-tenancy lunak

Itu perlu untuk menyelesaikan satu masalah yang menjengkelkan, yang dapat dianggap kurangnya wadah ... ini adalah multi-tenancy.

Wadah Linux tidak dibuat sebagai kotak pasir aman (seperti Solaris Zone atau FreeBSD Jails). Sebagai gantinya, mereka membangun model kernel umum yang menggunakan fungsi-fungsi kernel untuk menyediakan isolasi proses dasar. Seperti yang dikatakan Jesse Frazel , "wadah bukan barang asli."


Ini diperparah oleh fakta bahwa sebagian besar komponen Kubernet tidak mengetahui penyewa. Tentu saja, Anda memiliki ruang nama Pod dan kebijakan keamanan , tetapi tidak ada hal seperti itu di API. Serta di komponen internal seperti kubelet atau kube-proxy . Ini mengarah pada fakta bahwa Kubernet mengimplementasikan model "sewa lunak" (sewa lunak).


Arsitektur Kubernetes

Abstraksi merembes lebih jauh. Sebuah platform di atas kontainer mewarisi banyak aspek dari sewa lunak. Platform di atas mesin virtual multi-tenant mewarisi sewa tangguh ini (VMware, Amazon Web Services, OpenStack, dll.).

Model sewa lunak Kubernetes menempatkan penyedia layanan dan distribusi pada posisi yang aneh. Cluster Kubernetes sendiri menjadi garis “sewa keras”. Bahkan di dalam organisasi yang sama, ada banyak alasan untuk menuntut sewa keras antara pengguna (atau aplikasi). Karena cloud publik menyediakan Kubernet yang dikelola sepenuhnya sebagai layanan, mudah bagi pelanggan untuk mengambil cluster mereka sendiri dan menggunakan batas cluster sebagai titik isolasi.

Beberapa distribusi Kubernetes, seperti Pivotal Container Service (PKS) , sangat menyadari masalah penyewaan ini dan menggunakan model yang serupa, memberikan Kubernetes yang sama sebagai layanan yang dapat diperoleh dari cloud publik, tetapi di pusat data Anda sendiri.

Hal ini menyebabkan munculnya model "banyak cluster", bukan "satu cluster umum besar". Seringkali, pelanggan GKE dari Google memiliki lusinan kluster Kubernet yang digunakan untuk beberapa tim. Seringkali setiap pengembang mendapatkan cluster mereka sendiri. Perilaku ini menghasilkan sejumlah instance (Kubesprawl) yang mengejutkan.

Atau, operator menaikkan cluster Kubernet mereka sendiri di pusat data mereka sendiri untuk mengambil pekerjaan tambahan untuk mengelola beberapa cluster, atau setuju untuk menyewa satu atau dua cluster besar.

Biasanya, cluster terkecil adalah empat mesin (atau mesin virtual). Satu (atau tiga untuk HA) untuk Master Kubernetes, tiga untuk Pekerja Kubernetes. Banyak uang dihabiskan untuk sistem yang sebagian besar tidak digunakan.

Karena itu, Anda perlu memindahkan Kubernetes ke arah multi-tenancy yang kaku. Komunitas Kubernetes sangat menyadari kebutuhan ini. Kelompok kerja multi-sewa telah dibentuk. Dia bekerja keras dalam masalah ini, dan mereka memiliki beberapa model dan saran tentang cara bekerja dengan masing-masing model.

Jesse Frazel menulis posting blog tentang topik ini, dan itu bagus karena dia jauh lebih pintar dari saya, jadi saya bisa merujuk padanya dan menyelamatkan diri dari studi intensif selama sepuluh tahun, mencoba mencapai levelnya. Jika Anda belum membaca posting itu, baca sekarang.

Hanya VM yang sangat kecil yang dioptimalkan untuk kecepatan ...

Kata Containers adalah proyek sumber terbuka dan komunitas yang bekerja untuk menciptakan implementasi standar mesin virtual ringan yang terlihat dan berfungsi seperti wadah tetapi memberikan isolasi beban kerja dan manfaat keamanan VM.

Jesse menyarankan menggunakan teknologi wadah VM, seperti wadah Kata . Mereka menawarkan isolasi level VM, tetapi bekerja seperti wadah. Ini memungkinkan Kubernetes untuk memberikan masing-masing "penyewa" (kami mengasumsikan penyewa di namespace) set sendiri layanan sistem Kubernetes berjalan dalam wadah VM bersarang (wadah VM di dalam mesin virtual yang menyediakan infrastruktur IaaS menyediakan).


Gambar Jesse Frasel: hard multi-tenancy di Kubernetes

Ini adalah solusi multi-rental Kubernetes yang elegan. Usulannya bahkan lebih jauh bagi Kubernetes untuk menggunakan wadah VM bersarang untuk beban kerja (Pods) yang berjalan di Kubernetes, yang memberikan peningkatan signifikan dalam pemanfaatan sumber daya.

Kami memiliki setidaknya satu optimisasi tersisa. Buat hypervisor yang tepat untuk penyedia infrastruktur dasar atau penyedia cloud. Jika wadah VM adalah abstraksi tingkat pertama yang disediakan oleh IaaS, maka kami akan lebih meningkatkan pemanfaatan sumber daya. Jumlah minimum VM untuk memulai kluster Kubernet dikurangi menjadi satu mesin (atau tiga untuk HA) untuk meng-host sistem manajemen Kubernet, yang tersedia untuk "superuser".

Multi-tenancy yang dioptimalkan sumber daya (biaya)

Penyebaran Kubernetes dengan dua ruang nama dan beberapa aplikasi yang berjalan akan terlihat seperti ini:

Catatan: ada beban lain pada infrastruktur IaaS yang sama. Karena ini adalah wadah VM, mereka memiliki tingkat isolasi yang sama dengan cloud VM konvensional. Karena itu, mereka dapat bekerja pada hypervisor yang sama dengan risiko minimal.

Awalnya, tidak ada infrastruktur yang digunakan di cloud, jadi untuk pengguna super biayanya nol.

Pengguna super meminta kluster Kubernetes dari cloud. Penyedia layanan cloud menciptakan mesin virtual dengan satu wadah (atau tiga untuk HA) yang menjalankan API Kubernetes inti dan layanan sistem. Superuser dapat menggunakan modul di namespace sistem atau membuat ruang baru untuk mendelegasikan akses ke pengguna lain.

Superuser membuat dua ruang nama foo dan bar . Kubernetes meminta dua wadah VM dari cloud untuk setiap tingkat manajemen namespace (Kubernetes API dan Layanan Sistem). Superuser mendelegasikan akses ke ruang nama ini ke beberapa pengguna, masing-masing dari mereka meluncurkan beberapa beban kerja (modul), dan wadah VM meminta wadah ini untuk beban kerja ini.

Pada semua tahap, superuser hanya membayar untuk sumber daya yang benar-benar dikonsumsi. Penyedia layanan cloud mengontrol sumber daya ini dan tersedia untuk setiap pengguna cloud.

Saya tidak benar-benar mengatakan sesuatu yang baru ...

Penyedia layanan cloud sudah bekerja ke arah ini. Anda dapat memverifikasi ini dengan menonton acara komunitas (Amazon mungkin sudah diam-diam melakukan ini dengan Fargate).

Tip pertama adalah Virtual Kubelet , alat open source yang dirancang untuk menyamar sebagai kubelet. Ini menghubungkan Kubernetes ke API lain, yang memungkinkan Kubernetes untuk meminta kontainer VM dari penjadwal standar di cloud.

Petunjuk lainnya adalah sejumlah besar teknologi baru untuk kontainerisasi VM, seperti wadah Kata yang telah disebutkan, serta Firecracker Amazon dan pelindung Google.

Kesimpulan

Jika Anda benar menerapkan peningkatan dalam model sewa keras, Anda akan menemukan Holy Grail dari virtualisasi Kubernetes. Isolasi penuh beban kerja dan tanpa biaya tambahan.

Jika Anda tidak menggunakan cloud publik, Anda masih mendapatkan manfaat dari pemanfaatan sumber daya yang lebih tinggi, yang terbayar dengan persyaratan perangkat keras yang lebih rendah.

Mari berharap VMware dan OpenStack memperhatikan dan melepaskan hypervisor berdasarkan wadah VM ringan dan implementasi Virtual Kubelet yang sesuai.