Sebuah cerita pendek tentang kelebihan dan kekurangan dari layanan-layanan microser, konsep Service Mesh dan alat-alat Google yang memungkinkan Anda untuk menjalankan aplikasi-aplikasi layanan-mikro tanpa menyumbat kepala Anda dengan pengaturan kebijakan, akses dan sertifikat yang tak ada habisnya dan dengan cepat menemukan kesalahan yang bersembunyi bukan dalam kode, tetapi dalam logika microservice.
Artikel ini didasarkan pada
laporan Craig Box pada konferensi DevOops tahun lalu tahun 2017 kami. Video dan terjemahan dari laporan tersebut sedang terpotong.
Craig Box (Craig Box,
Twitter ) - DevRel Google yang bertanggung jawab atas layanan microservices dan Kubernetes dan Istio. Kisahnya saat ini adalah tentang mengelola layanan microser pada platform ini.
Mari kita mulai dengan konsep yang relatif baru yang disebut Service Mesh. Istilah ini digunakan untuk menggambarkan jaringan Microsoft yang berinteraksi yang membentuk aplikasi.
Pada level tinggi, kita melihat jaringan sebagai pipa yang hanya memindahkan bit. Kami tidak ingin khawatir tentang mereka atau, misalnya, tentang alamat MAC dalam aplikasi, tetapi kami berusaha untuk memikirkan tentang layanan dan koneksi yang mereka butuhkan. Jika Anda melihat dari sudut pandang
OSI , maka kami memiliki jaringan tingkat ketiga (dengan fungsi untuk menentukan rute dan pengalamatan logis), tetapi kami ingin berpikir tentang ketujuh (dengan fungsi akses ke layanan jaringan).
Seperti apakah seharusnya jaringan tingkat tujuh yang sesungguhnya? Mungkin kita ingin melihat sesuatu seperti jejak lalu lintas di sekitar layanan bermasalah. Sehingga Anda dapat terhubung ke layanan, dan pada saat yang sama tingkat model dinaikkan dari tingkat ketiga. Kami ingin mendapatkan ide tentang apa yang terjadi di cluster, menemukan dependensi yang tidak diinginkan, mencari tahu akar penyebab kegagalan. Kita juga perlu menghindari overhead yang tidak perlu, misalnya, menghubungkan dengan latensi tinggi atau menghubungkan ke server dengan cache yang dingin atau tidak sepenuhnya menghangat.
Kita harus yakin bahwa lalu lintas antar layanan dilindungi dari serangan sepele. Diperlukan otentikasi mutual TLS, tetapi tanpa menyematkan modul yang sesuai di setiap aplikasi yang kami tulis. Penting untuk dapat mengontrol apa yang mengelilingi aplikasi kita tidak hanya pada tingkat koneksi, tetapi juga pada tingkat yang lebih tinggi.
Service Mesh adalah lapisan yang memungkinkan kita untuk memecahkan masalah di atas dalam lingkungan layanan mikro.
Monolith dan microservices: pro dan kontra
Tetapi pertama-tama kita bertanya pada diri sendiri, mengapa kita harus menyelesaikan masalah ini sama sekali? Bagaimana kami melakukan pengembangan perangkat lunak sebelumnya? Kami memiliki aplikasi yang terlihat seperti ini - seperti monolit.
Sangat bagus: semua kode dalam tampilan penuh. Mengapa tidak terus menggunakan pendekatan ini?
Ya, karena monolit memiliki masalah sendiri. Kesulitan utama adalah bahwa jika kita ingin membangun kembali aplikasi ini, kita harus menggunakan kembali setiap modul, bahkan jika tidak ada yang berubah. Kami dipaksa untuk membuat aplikasi dalam bahasa yang sama atau dalam bahasa yang kompatibel, bahkan jika tim yang berbeda mengerjakannya. Bahkan, bagian-bagian individual tidak dapat diuji secara independen satu sama lain. Saatnya untuk mengubahnya, saatnya untuk layanan microser.
Jadi, kami membagi monolit menjadi beberapa bagian. Anda mungkin memperhatikan bahwa dalam contoh ini kami menghapus beberapa dependensi yang tidak perlu dan berhenti menggunakan metode internal yang dipanggil dari modul lain. Kami menciptakan layanan dari model yang digunakan sebelumnya, menciptakan abstraksi dalam kasus di mana kami perlu mempertahankan keadaan. Misalnya, setiap layanan harus memiliki status independen sehingga ketika Anda mengaksesnya, Anda tidak perlu khawatir tentang apa yang terjadi di seluruh lingkungan kami.
Apa hasilnya?
Kami meninggalkan dunia aplikasi raksasa untuk mendapatkan apa yang benar-benar tampak hebat. Kami mempercepat pengembangan, berhenti menggunakan metode internal, menciptakan layanan, dan sekarang kami dapat menskalakannya secara mandiri, menjadikan layanan lebih besar tanpa harus menggabungkan semua yang lain. Tetapi berapa harga perubahan yang telah kita hilangkan?
Kami memiliki panggilan yang andal di dalam aplikasi karena Anda cukup memanggil fungsi atau modul. Kami mengganti panggilan tepercaya di dalam modul dengan panggilan prosedur jarak jauh yang tidak dapat diandalkan. Tetapi layanan di sisi lain tidak selalu tersedia.
Kami aman, menggunakan proses yang sama di dalam mesin yang sama. Sekarang kami terhubung ke layanan yang mungkin ada pada mesin yang berbeda dan pada jaringan yang tidak terpercaya.
Dalam pendekatan baru pada jaringan, keberadaan pengguna lain yang mencoba untuk terhubung ke layanan dimungkinkan. Penundaan meningkat, dan pada saat yang sama, kemampuan pengukurannya menurun. Sekarang kita memiliki koneksi selangkah demi selangkah di semua layanan yang membuat satu panggilan modul, dan kita tidak bisa lagi hanya melihat aplikasi di debugger dan mencari tahu apa yang sebenarnya menyebabkan kegagalan. Dan masalah ini perlu dipecahkan. Jelas, kita membutuhkan seperangkat alat baru.
Apa yang bisa dilakukan?
Ada beberapa opsi. Kita dapat mengambil aplikasi kita dan mengatakan bahwa jika
RPC tidak berfungsi pertama kali, maka Anda harus mencoba lagi, dan kemudian lagi dan lagi. Tunggu sebentar dan coba lagi atau tambahkan Jitter. Kami juga dapat menambahkan jejak entri - keluar untuk mengatakan bahwa panggilan dimulai dan berakhir, yang bagi saya setara dengan debugging. Anda dapat menambahkan infrastruktur untuk menyediakan otentikasi koneksi dan mengajarkan semua aplikasi kami cara bekerja dengan enkripsi TLS. Kami harus menanggung beban isi masing-masing tim dan terus-menerus mengingat berbagai masalah yang mungkin muncul di perpustakaan SSL.
Mempertahankan konsistensi di berbagai platform adalah tugas yang tidak berterima kasih. Saya ingin ruang antara aplikasi menjadi masuk akal, sehingga ada kemungkinan pelacakan. Kita juga memerlukan kemampuan untuk mengubah konfigurasi saat runtime agar tidak mengkompilasi ulang atau memulai kembali aplikasi untuk migrasi. Wishlist ini dan mengimplementasikan Service Mesh.
Isstio
Bicara tentang
Istio .
Istio adalah kerangka kerja lengkap untuk menghubungkan, mengelola dan memantau arsitektur layanan mikro. Istio dirancang untuk bekerja di atas Kubernetes. Dia sendiri tidak menyebarkan perangkat lunak dan tidak peduli untuk membuatnya tersedia di mesin yang kami gunakan untuk tujuan ini dengan wadah di Kubernetes.
Pada gambar, kita melihat tiga bagian berbeda dari mesin dan blok yang membentuk layanan microser kami. Kami memiliki cara untuk mengelompokkan mereka menggunakan mekanisme yang disediakan oleh Kubernetes. Kami dapat menargetkan dan mengatakan bahwa grup tertentu, yang mungkin memiliki penskalaan otomatis, dilampirkan ke layanan web atau mungkin memiliki metode penyebaran lainnya, akan berisi layanan web kami. Dalam hal ini, kita tidak perlu memikirkan mesin, kita beroperasi dalam hal tingkat akses ke layanan jaringan.
Situasi ini dapat direpresentasikan dalam bentuk diagram. Pertimbangkan contoh ketika kita memiliki mekanisme yang melakukan pemrosesan gambar. Pengguna di sebelah kiri adalah lalu lintas dari mana datang kepada kami di microservice.
Untuk menerima pembayaran dari pengguna, kami memiliki layanan pembayaran mikro terpisah yang memanggil API eksternal yang terletak di luar cluster.
Untuk memproses login pengguna, kami menyediakan microservice otentikasi, dan telah menyatakan disimpan lagi di luar cluster kami di
database Cloud SQL .
Apa yang dilakukan Istio? Istio meningkatkan Kubernetes. Anda menginstalnya menggunakan fungsi alfa di Kubernet yang disebut Initializer. Saat Anda menggunakan perangkat lunak, kubernetes akan melihatnya dan bertanya apakah kami ingin mengubah dan menambahkan wadah lain di dalam masing-masing kubernet. Wadah ini akan menangani jalur dan perutean, menyadari semua perubahan aplikasi.
Beginilah tampilan sirkuit dengan Istio.
Kami memiliki mesin eksternal yang menyediakan proksi masuk dan keluar untuk lalu lintas di layanan tertentu. Kita dapat membongkar fungsi yang sudah kita bicarakan. Kita tidak perlu mengajarkan aplikasi bagaimana melakukan telemetri atau melacak menggunakan TLS. Tetapi kita dapat menambahkan hal-hal lain di dalamnya: gangguan otomatis, batas kecepatan,
pelepasan kenari .
Semua lalu lintas sekarang akan melalui server proxy pada mesin eksternal, dan tidak langsung ke layanan. Kubernetes melakukan semuanya pada alamat IP yang sama. Kami akan dapat mencegat lalu lintas yang akan pergi ke depan atau mengakhiri layanan.
Proksi eksternal yang digunakan Istio disebut
Utusan .
Utusan sebenarnya lebih tua dari Istio, dikembangkan di Lyft. Telah bekerja dalam produksi selama lebih dari setahun, meluncurkan seluruh infrastruktur layanan-mikro. Kami memilih Utusan untuk proyek Istio bekerja sama dengan komunitas. Jadi, Google, IBM dan LYFT adalah tiga perusahaan yang masih mengerjakannya.
Utusan ditulis dalam C ++ 11. Ini telah diproduksi selama lebih dari 18 bulan sebelum menjadi proyek open source. Tidak akan membutuhkan banyak sumber daya saat Anda menghubungkannya ke layanan Anda.
Berikut adalah beberapa hal yang dapat dilakukan Utusan. Ini adalah pembuatan server proxy untuk HTTP, termasuk HTTP / 2 dan protokol yang didasarkan padanya, seperti gRPC. Itu juga dapat meneruskan ke protokol lain di tingkat biner. Utusan mengontrol zona infrastruktur Anda sehingga Anda dapat membuat bagian Anda otonom. Itu dapat menangani sejumlah besar koneksi jaringan dengan coba lagi dan tunggu. Anda dapat mengatur sejumlah upaya untuk menyambung ke server sebelum menghentikan panggilan dan mengirimkan informasi ke server Anda bahwa layanan ini tidak merespons.
Tidak perlu khawatir memuat ulang aplikasi untuk menambahkan konfigurasi ke dalamnya. Anda cukup menghubungkannya menggunakan API yang sangat mirip dengan kubernetes dan mengubah konfigurasi saat runtime.
Tim Istio telah memberikan kontribusi besar pada Platform Utusan UpStream. Misalnya, peringatan kesalahan injeksi. Kami memungkinkan untuk melihat bagaimana aplikasi berperilaku jika melebihi jumlah permintaan untuk objek yang gagal. Dan juga menerapkan fungsi tampilan grafis dan pemisahan lalu lintas untuk menangani kasus ketika penyebaran kenari digunakan.
Gambar tersebut menunjukkan seperti apa arsitektur sistem Istio. Kami hanya akan mengambil dua layanan microser yang disebutkan sebelumnya. Pada akhirnya, dalam diagram, semuanya sangat mirip dengan jaringan yang ditentukan perangkat lunak. Dari server proxy Utusan, yang kami gunakan dengan aplikasi, lalu lintas ditransfer menggunakan tabel IP di namespace. Panel kontrol bertanggung jawab untuk mengelola konsol, tetapi tidak memproses lalu lintas itu sendiri.
Kami memiliki tiga komponen. Pilot, yang membuat konfigurasi, melihat aturan yang dapat diubah menggunakan API untuk panel kontrol Istio, dan kemudian memperbarui Utusan sehingga berperilaku seperti layanan penemuan cluster. Istio-Auth berfungsi sebagai otoritas sertifikasi dan mengirimkan sertifikat TLS ke proksi. Aplikasi tidak memerlukan SSL, mereka dapat terhubung melalui HTTP, dan proksi akan menangani semua ini untuk Anda.
Mixer memproses permintaan untuk memastikan bahwa Anda mematuhi kebijakan keamanan, dan kemudian mengirimkan informasi telemetri. Tanpa membuat perubahan apa pun pada aplikasi, kita bisa melihat semua yang terjadi di dalam kluster kita.
Manfaat Istio
Jadi, mari kita bicara lebih detail tentang lima hal yang akan kita dapatkan dari Istio. Pertama-tama, pertimbangkan
manajemen lalu lintas . Kita dapat memisahkan kontrol lalu lintas dari penskalaan infrastruktur, jadi sebelumnya kita bisa melakukan sekitar 20 contoh aplikasi dan 19 di antaranya ada di versi lama, dan satu di versi baru, yaitu, 5% dari lalu lintas akan di versi baru. Dengan Istio, kami dapat menggunakan sejumlah instance yang kami butuhkan, dan pada saat yang sama menunjukkan persentase lalu lintas yang harus dikirim ke versi baru. Aturan pemisahan yang sederhana.
Semuanya dapat diprogram dengan cepat menggunakan aturan. Utusan akan diperbarui secara berkala ketika konfigurasi berubah, dan ini tidak akan menyebabkan pemadaman layanan. Karena kami bekerja di tingkat akses ke layanan jaringan, kami dapat melihat paket-paket, dan dalam hal ini ada peluang untuk masuk ke agen pengguna, yang terletak di tingkat ketiga jaringan.
Misalnya, kita dapat mengatakan bahwa lalu lintas apa pun dari iPhone mengikuti aturan yang berbeda, dan kami akan mengarahkan sebagian kecil lalu lintas ke versi baru, yang ingin kami uji untuk perangkat tertentu. Layanan panggilan internal Microsoft dapat menentukan versi spesifik mana yang perlu disambungkan, dan Anda dapat mentransfernya ke versi lain, misalnya 2.0.
Keuntungan kedua adalah
transparansi . Saat Anda memiliki tampilan di dalam gugus, Anda bisa memahami cara membuatnya. Kita tidak perlu membuat alat untuk metrik dalam proses pengembangan. Metrik sudah ada di setiap komponen.
Beberapa percaya bahwa cukup untuk menyimpan catatan log untuk pemantauan. Tetapi pada kenyataannya, yang kita butuhkan adalah memiliki seperangkat indikator universal yang dapat dimasukkan ke layanan pemantauan.
Beginilah tampilan bilah alat Istio yang dibuat menggunakan layanan Prometheus. Ingatlah untuk menyebarkannya di dalam cluster.
Dalam contoh tersebut, tangkapan layar menunjukkan sejumlah parameter yang dipantau khusus untuk seluruh kluster. Hal-hal yang lebih menarik dapat disimpulkan, misalnya, berapa persen aplikasi memberikan lebih dari 500 kesalahan, yang menyiratkan kegagalan. Waktu respons dikumpulkan dalam semua instance layanan panggilan dan menanggapi dalam cluster, fungsi ini tidak memerlukan pengaturan. Istio tahu apa yang didukung Prometheus, dan dia tahu layanan apa yang tersedia di cluster Anda, sehingga Istio-Mixer dapat mengirim metrik ke Prometheus tanpa pengaturan tambahan.
Mari kita lihat cara kerjanya. Jika Anda memanggil layanan tertentu, layanan proxy mengirimkan informasi tentang panggilan ini ke Mixer, yang menangkap parameter seperti waktu tunggu untuk respons, status kode, dan IP. Ini menormalkan mereka dan mengirimkannya ke server yang Anda konfigurasikan. Khusus untuk menampilkan indikator utama ada layanan Prometheus dan adaptor FLUX DB, tetapi Anda juga dapat menulis adaptor Anda sendiri dan menampilkan data dalam format apa pun untuk aplikasi lain. Dan Anda tidak perlu mengubah apa pun di infrastruktur jika Anda ingin menambahkan metrik baru.
Jika Anda ingin melakukan penelitian lebih mendalam, gunakan
sistem penelusuran terdistribusi
Zipkin . Informasi tentang semua panggilan yang dialihkan melalui Istio-Mixer dapat dikirim ke Zipkin. Di sana Anda akan melihat seluruh rantai panggilan layanan mikro saat merespons pengguna dan dengan mudah menemukan layanan yang memakan waktu.
Pada level aplikasi, tidak perlu khawatir membuat jejak. Utusan itu sendiri meneruskan semua informasi yang diperlukan ke Mixer, yang mengirimkannya ke jejak, misalnya, ke Zipkin,
jejak stackdriver dari Google atau aplikasi pengguna lainnya.
Mari kita bicara tentang
toleransi kesalahan dan efisiensi .
Timeout antara panggilan layanan diperlukan untuk menguji kesehatan, pertama-tama, penyeimbang beban. Kami memperkenalkan kesalahan ke dalam koneksi ini dan melihat apa yang terjadi. Pertimbangkan sebuah contoh. Misalkan ada koneksi antara layanan A dan layanan B. Kami menunggu respons dari layanan video selama 100 milidetik dan hanya memberikan 3 upaya jika hasilnya tidak diterima. Intinya, kita akan mengambilnya selama 300 milidetik sebelum melaporkan upaya koneksi yang gagal.
Lebih jauh, misalnya, layanan film kami harus melihat peringkat film melalui layanan microser lain. Peringkat tersebut memiliki batas waktu 200 milidetik dan dua upaya panggilan diberikan. Memanggil layanan video dapat menyebabkan Anda menunggu 400 milidetik jika peringkat bintangnya di luar jangkauan. Tapi, kita ingat, setelah 300 ms layanan film akan melaporkan bahwa itu idle, dan kita tidak akan pernah tahu penyebab sebenarnya dari kegagalan tersebut. Menggunakan batas waktu dan menguji apa yang terjadi dalam kasus-kasus ini adalah cara yang bagus untuk menemukan semua jenis bug pintar dalam arsitektur layanan mikro Anda.
Mari kita lihat sekarang apa dengan efisiensi. Penyeimbang kubernet sendiri hanya bertindak pada tingkat lapisan keempat. Kami menemukan konstruktor input untuk load balancing dari lapisan kedua ke ketujuh. Istio diimplementasikan sebagai penyeimbang untuk lapisan jaringan dengan akses ke layanan jaringan.
Kami melakukan TLS-offloading, jadi kami menggunakan SSL modern yang didoping dengan baik di Utusan, jadi Anda tidak perlu khawatir tentang kerentanan.
Keuntungan lain dari Istio adalah
keamanan .
Apa saja fitur keamanan dasar di Istio? Layanan Istio-Auth bekerja dalam beberapa arah. Ini menggunakan kerangka kerja publik dan satu set standar otentikasi untuk layanan
SPIFFE . Jika kita berbicara tentang arus lalu lintas, maka kita memiliki otoritas sertifikat Istio yang mengeluarkan sertifikat untuk akun layanan yang kita jalankan di dalam cluster. Sertifikat ini mematuhi standar SPIFFE dan didistribusikan oleh Utusan menggunakan mekanisme keamanan kubernetes. Utusan menggunakan kunci untuk otentikasi TLS dua arah. Dengan demikian, aplikasi backend menerima pengidentifikasi atas dasar yang sudah mungkin untuk mengatur kebijakan.
Istio memiliki sertifikat root sendiri sehingga Anda tidak khawatir tentang pencabutan dan tanggal kedaluwarsa. Sistem akan merespons penskalaan otomatis, jadi dengan memperkenalkan entitas baru, Anda mendapatkan sertifikat baru. Tidak ada pengaturan manual. Anda tidak perlu mengkonfigurasi firewall. Pengguna akan menggunakan kebijakan jaringan dan kubernet untuk menerapkan firewall di antara kontainer.
Akhirnya,
penerapan kebijakan . Mixer adalah titik integrasi dengan backend infrastruktur yang dapat Anda kembangkan dengan Service Mesh. Layanan dapat dengan mudah bergerak dalam sebuah cluster, digunakan di berbagai lingkungan, di cloud atau secara lokal. Semuanya dirancang untuk kontrol operasional panggilan yang masuk melalui Utusan.
Kami dapat mengizinkan dan melarang panggilan tertentu, menetapkan prasyarat untuk panggilan tidak terjawab, membatasi kecepatan dan nomornya. Misalnya, Anda mengizinkan 20 permintaan gratis per hari ke beberapa layanan. Jika pengguna telah membuat 20 permintaan, permintaan selanjutnya tidak diproses.Prasyarat dapat mencakup hal-hal seperti, misalnya, server sedang dikonfirmasi, ICL, dan berada di daftar putih. Manajemen kuota dapat digunakan jika diperlukan bahwa setiap orang yang menggunakan layanan memiliki kecepatan akses yang sama. Akhirnya, Mixer mengumpulkan permintaan dan respons hasil telemetri siap. Ini memungkinkan produsen dan pengguna untuk menonton telemetri ini menggunakan layanan.
Ingat slide pertama dengan aplikasi foto yang dengannya kami mulai belajar Istio? Semua hal di atas disembunyikan di bawah bentuk sederhana. Di tingkat atas, semua yang Anda butuhkan akan dilakukan secara otomatis. Anda akan menggunakan aplikasi dan tidak akan khawatir tentang bagaimana mendefinisikan kebijakan keamanan atau mengkonfigurasi beberapa aturan perutean. Aplikasi akan bekerja persis seperti yang Anda harapkan.Bagaimana cara memulai dengan Istio
Istio mendukung versi kubernet sebelumnya, tetapi fitur penginisialisasi baru yang saya bicarakan adalah dalam versi 1.7 dan lebih tinggi. Ini adalah fungsi alpha di kubernetes. Saya sarankan menggunakan cluster Alpha Container Engine Google. Kami memiliki kelompok yang dapat Anda aktifkan selama beberapa hari dan pada saat yang sama menggunakan semua kemampuan produksi di dalamnya.Pertama-tama, Istio adalah proyek open source di github. Kami baru saja merilis versi 0.2. Di versi 0.1, Anda bisa mengelola objek di dalam namespace kubernet dengan nama yang sama. Sejak versi 0.2, kami mendukung kerja di namespace kami sendiri dan di cluster kubernetes. Kami juga menambahkan akses ke kemampuan untuk mengelola layanan yang berjalan di mesin virtual. Anda dapat menggunakan Utusan di mesin virtual dan mengamankan layanan yang berjalan di atasnya. Di masa depan, Istio akan mendukung platform lain, seperti Cloud Foundry .Panduan instalasi cepat untuk framework ada di sini.. Jika Anda memiliki cluster yang menjalankan Google Container Engine 1.8 dengan fitur alpha diaktifkan, menginstal Istio hanya satu perintah.Jika Anda menyukai ceramah ini, datanglah ke konferensi DevOops 2018 (Peter) pada 14 Oktober : di sana Anda tidak hanya dapat mendengarkan ceramah, tetapi juga mengobrol dengan pembicara mana pun di area diskusi.