Liburan telah berakhir dan kami kembali dengan pos kedua kami di seri Istio Service Mesh.
Topik hari ini adalah Circuit Breaker, yang, yang diterjemahkan ke dalam bahasa Rusia sebagai electrotechnical, berarti "circuit breaker", bahasa sehari-hari - "circuit breaker". Hanya di Istio mesin ini tidak memutus sirkuit yang korsleting atau kelebihan beban, tetapi kontainer yang rusak.
Bagaimana cara kerjanya idealnya
Ketika layanan microsoft dikelola oleh Kubernetes, misalnya, sebagai bagian dari platform OpenShift, mereka secara otomatis naik turun tergantung pada beban. Karena layanan microser berfungsi dalam pod, mungkin ada beberapa layanan microser kemas di satu titik akhir, dan Kubernetes akan merutekan permintaan dan menyeimbangkan beban di antara mereka. Dan - idealnya - semua ini harus bekerja dengan sempurna.
Kami ingat bahwa layanan microser kecil dan fana. Ephemerality, yang di sini berarti kesederhanaan dari kemunculan dan penghilangan, sering diremehkan. Kelahiran dan kematian instance microservice berikutnya dalam pod cukup diharapkan, OpenShift dan Kubernetes melakukannya dengan baik, dan semuanya bekerja dengan baik - tetapi sekali lagi secara teori.
Bagaimana cara kerjanya?
Sekarang bayangkan bahwa contoh khusus dari layanan-mikro, yaitu wadah, telah menjadi tidak dapat digunakan: ia tidak merespons (kesalahan 503) atau, yang lebih tidak menyenangkan, bereaksi, tetapi terlalu lambat. Dengan kata lain, ini membisukan atau tidak menanggapi permintaan, tetapi tidak secara otomatis menghapusnya dari kumpulan. Apa yang harus dilakukan dalam kasus ini? Coba lagi? Hapus dari skema perutean? Dan apa artinya "terlalu lambat" - berapa jumlahnya, dan siapa yang menentukannya? Mungkin hanya memberinya istirahat dan coba lagi nanti? Jika demikian, berapa lama kemudian?
Apa itu Pool Ejection di Istio
Dan di sini Istio datang untuk menyelamatkan dengan pemutus sirkuit Pemutus Sirkuitnya, yang untuk sementara menghapus wadah yang rusak dari kumpulan sumber daya perutean dan penyeimbangan muatan, menerapkan prosedur Ejeksi Pool.
Menggunakan strategi deteksi outlier, Istio mendeteksi kurva pod yang terlempar dari baris umum dan menghapusnya dari kumpulan sumber daya untuk waktu tertentu, yang disebut "jendela tidur".
Untuk menunjukkan bagaimana ini bekerja di Kubernetes pada platform OpenShift, kita mulai dengan tangkapan layar dari layanan microser yang biasanya berfungsi dari contoh di repositori
Red Hat Developer Demos . Di sini kita memiliki dua pod, v1 dan v2, di mana masing-masing satu wadah berfungsi. Ketika aturan perutean Istio tidak digunakan, Kubernetes secara default menerapkan perutean round-robin yang seimbang:
Bersiap untuk kecelakaan
Sebelum melakukan Pool Ejection, Anda harus membuat aturan perutean Istio. Misalkan kita ingin mendistribusikan permintaan antar pod sehubungan dengan 50/50. Selain itu, kami akan menambah jumlah wadah v2 dari satu menjadi dua, seperti ini:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Sekarang kami menetapkan aturan perutean sehingga lalu lintas didistribusikan di antara pod dalam rasio 50/50.
Dan ini adalah hasil dari aturan ini:
Mungkin mengeluh bahwa pada layar ini bukan 50/50, tetapi 14: 9, tetapi seiring waktu situasinya akan membaik.
Kami mengatur kegagalan
Dan sekarang kita akan menonaktifkan salah satu dari dua wadah v2 sehingga kita memiliki satu wadah sehat v1, satu wadah sehat v2 dan satu wadah gagal v2:
Perbaiki kecelakaan itu
Jadi, kami memiliki wadah yang salah, dan sekarang saatnya untuk Pool Ejection. Menggunakan konfigurasi yang sangat sederhana, kami akan mengecualikan wadah yang gagal ini dari skema perutean apa pun selama 15 detik dengan harapan akan kembali ke kondisi sehat (apakah akan memulai ulang, atau akan mengembalikan kinerja). Inilah konfigurasi ini dan hasil dari kerjanya:
Seperti yang Anda lihat, wadah yang gagal v2 tidak lagi digunakan saat merutekan permintaan, karena telah dihapus dari kumpulan. Tetapi setelah 15 detik itu akan secara otomatis kembali ke kolam. Sebenarnya, kami hanya menunjukkan cara kerja Pool Ejection.
Mulai membangun arsitektur
Pool Ejection, dikombinasikan dengan kemampuan pemantauan Istio, memungkinkan Anda untuk mulai membangun kerangka kerja untuk mengganti wadah yang rusak secara otomatis untuk mengurangi, atau bahkan menghilangkan downtime dan crash.
NASA memiliki satu moto profil tinggi - Kegagalan Bukan Opsi, yang ditulis oleh direktur penerbangan
Gene Krantz . Ini dapat diterjemahkan ke dalam bahasa Rusia sebagai "Kekalahan bukanlah suatu pilihan", dan intinya di sini adalah bahwa semuanya dapat dibuat untuk bekerja dengan kemauan yang cukup. Namun, dalam kehidupan nyata, kegagalan tidak hanya terjadi, mereka tidak bisa dihindari, di mana-mana dan dalam segala hal. Dan bagaimana cara mengatasinya dalam kasus layanan mikro? Menurut pendapat kami, lebih baik untuk tidak mengandalkan tekad, tetapi pada kemampuan kontainer,
Kubernetes ,
Red Hat OpenShift , dan
Istio .
Istio, seperti yang kami tulis di atas, mengimplementasikan konsep pemutus sirkuit, yang telah membuktikan dirinya di dunia fisik. Dan seperti halnya mesin otomatis memutuskan bagian masalah dari suatu rangkaian, perangkat lunak Circuit Breaker di Istio memutus koneksi antara aliran permintaan dan wadah masalah ketika ada sesuatu yang salah dengan titik akhir, misalnya, ketika server crash atau mulai melambat.
Selain itu, dalam kasus kedua hanya ada lebih banyak masalah, karena rem satu kontainer tidak hanya menyebabkan kaskade keterlambatan dalam layanan mengaksesnya dan, sebagai hasilnya, mengurangi kinerja sistem secara keseluruhan, tetapi juga menghasilkan permintaan berulang untuk layanan yang sudah berjalan lambat, yang hanya memperburuk situasi .
Pemutus sirkuit secara teori
Circuit Breaker adalah proksi yang mengontrol aliran permintaan ke titik akhir. Ketika titik ini berhenti bekerja atau, tergantung pada pengaturannya, ia mulai melambat, proxy terputus dari wadah. Lalu lintas dialihkan ke kontainer lain, well, hanya karena penyeimbangan muatan. Sambungan tetap terbuka (terbuka) untuk jendela tidur yang diberikan, katakanlah, dua menit, dan kemudian dianggap setengah terbuka (setengah terbuka). Mencoba mengirim permintaan berikutnya menentukan keadaan komunikasi selanjutnya. Jika semuanya baik-baik saja dengan layanan, koneksi kembali ke keadaan operasional dan kembali menjadi tertutup. Jika masih ada yang salah dengan layanan, koneksi terbuka dan jendela tidur diaktifkan kembali. Berikut tampilan diagram keadaan Pemutus Sirkuit yang disederhanakan:
Penting untuk dicatat di sini bahwa semua ini terjadi pada tingkat arsitektur sistem. Oleh karena itu, pada titik tertentu Anda harus mengajarkan aplikasi Anda untuk bekerja dengan Circuit Breaker, misalnya, memberikan nilai default sebagai respons atau, jika mungkin, mengabaikan keberadaan layanan. Pola sekat digunakan untuk ini, tetapi di luar cakupan artikel ini.
Circuit Breaker dalam praktek
Sebagai contoh, kami akan meluncurkan pada OpenShift dua versi dari microservice rekomendasi kami. Versi 1 akan berfungsi dengan baik, tetapi dalam v2 kita akan membangun penundaan untuk mensimulasikan rem di server. Untuk melihat hasilnya, gunakan alat
pengepungan :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Segalanya tampak bekerja, tetapi berapa biayanya? Sekilas, kami memiliki ketersediaan 100%, tetapi perhatikan lebih dekat - durasi transaksi maksimum adalah 12 detik. Ini jelas merupakan hambatan dan perlu disulam.
Untuk melakukan ini, kami akan menggunakan Istio untuk menghilangkan akses ke wadah lambat. Inilah yang terlihat seperti konfigurasi yang sesuai dengan menggunakan Circuit Breaker:
Baris terakhir dengan parameter httpMaxRequestsPerConnection memberi sinyal bahwa koneksi harus terbuka ketika mencoba membuat satu lagi - koneksi kedua - selain yang sudah ada. Karena wadah kami meniru layanan pengereman, situasi seperti itu akan terjadi secara berkala, dan kemudian Istio akan mengembalikan kesalahan 503, dan inilah yang akan ditampilkan pengepungan:
OK, kita punya Circuit Breaker, apa selanjutnya?
Jadi, kami menerapkan shutdown otomatis, tanpa menyentuh kode sumber layanan itu sendiri. Menggunakan prosedur Circuit Breaker dan Pool Ejection yang dijelaskan di atas, kita dapat menghapus wadah rem dari sumber daya sampai mereka kembali normal, dan memeriksa statusnya pada frekuensi yang diberikan - dalam contoh kita, ini adalah dua menit (parameter sleepWindow).
Harap dicatat bahwa kemampuan aplikasi untuk merespons kesalahan 503 masih ditetapkan pada level kode sumbernya. Ada banyak strategi untuk bekerja dengan Circuit Breaker, yang diterapkan tergantung pada situasinya.
Dalam posting selanjutnya: kita akan berbicara tentang penelusuran dan pemantauan, yang sudah ada atau ditambahkan dengan mudah ke Istio, serta cara memasukkan kesalahan ke dalam sistem dengan sengaja.