Cuti telah berakhir dan kami kembali dengan siaran kedua kami dalam siri Istio Service Mesh.
Topik hari ini ialah Pemutus Litar, yang diterjemahkan ke dalam kejuruteraan elektrik Rusia bermaksud "pemutus litar", dalam bahasa biasa - "pemutus litar". Hanya di Istio mesin ini tidak memutuskan sambungan litar yang terputus atau terbeban, tetapi bekas yang rosak.
Bagaimana ini harus berfungsi dengan ideal
Apabila perkhidmatan mikro diurus oleh Kubernetes, contohnya dalam platform OpenShift, ia secara automatik naik dan turun bergantung pada beban. Oleh kerana perkhidmatan mikro dijalankan dalam pod, mungkin terdapat berbilang contoh perkhidmatan mikro kontena pada satu titik akhir dan Kubernetes akan menghalakan permintaan dan mengimbangi beban antara mereka. Dan - idealnya - semua ini harus berfungsi dengan sempurna.
Kami ingat bahawa perkhidmatan mikro adalah kecil dan tidak lama. Ephemerality, yang di sini bermaksud kemudahan muncul dan hilang, sering dipandang remeh. Kelahiran dan kematian satu lagi contoh perkhidmatan mikro dalam pod adalah perkara yang agak dijangka, OpenShift dan Kubernetes mengendalikannya dengan baik, dan semuanya berfungsi dengan baik - tetapi sekali lagi dalam teori.
Bagaimana ia benar-benar berfungsi
Sekarang bayangkan bahawa contoh khusus perkhidmatan mikro, iaitu, bekas, telah menjadi tidak boleh digunakan: sama ada ia tidak bertindak balas (ralat 503), atau, yang lebih tidak menyenangkan, ia bertindak balas, tetapi terlalu perlahan. Dalam erti kata lain, ia menjadi terganggu atau tidak bertindak balas kepada permintaan, tetapi ia tidak dialih keluar secara automatik daripada kolam. Apa yang perlu dilakukan dalam kes ini? Untuk mencuba semula? Patutkah saya mengalih keluarnya daripada skim penghalaan? Dan apakah yang dimaksudkan dengan "terlalu perlahan" - berapa bilangannya, dan siapa yang menentukannya? Mungkin hanya berehat dan cuba lagi kemudian? Jika ya, berapa lama kemudian?
Apakah Pool Ejection di Istio
Dan di sini Istio datang untuk menyelamatkan dengan mesin perlindungan Pemutus Litarnya, yang mengalihkan sementara bekas yang rosak daripada kumpulan sumber penghalaan dan pengimbangan beban, melaksanakan prosedur Pool Ejection.
Menggunakan strategi pengesanan terpencil, Istio mengesan pod lengkung yang berada di luar baris dan mengalih keluarnya daripada kumpulan sumber untuk tempoh masa tertentu, dipanggil tetingkap tidur.
Untuk menunjukkan cara ini berfungsi dalam Kubernetes pada platform OpenShift, mari mulakan dengan tangkapan skrin perkhidmatan mikro yang biasanya berfungsi daripada contoh dalam repositori . Di sini kita mempunyai dua pod, v1 dan v2, masing-masing menjalankan satu bekas. Apabila peraturan penghalaan Istio tidak digunakan, Kubernetes lalai kepada penghalaan round-robin seimbang sekata:
Bersedia untuk kemalangan
Sebelum melakukan Pool Ejection, anda perlu membuat peraturan penghalaan Istio. Katakan kita mahu mengedarkan permintaan antara pod dalam nisbah 50/50. Selain itu, kami akan menambah bilangan bekas v2 daripada satu kepada dua, seperti ini:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Kini kami menetapkan peraturan penghalaan supaya trafik diedarkan antara pod dalam nisbah 50/50.
Begini rupa keputusan peraturan ini:
Anda boleh mencari kesalahan dengan fakta bahawa skrin ini bukan 50/50, tetapi 14:9, tetapi dari masa ke masa keadaan akan bertambah baik.
Membuat kesilapan
Sekarang mari kita lumpuhkan salah satu daripada dua bekas v2 supaya kita mempunyai satu bekas v1 yang sihat, satu bekas v2 yang sihat dan satu bekas v2 yang rosak:
Membetulkan gangguan
Jadi, kami mempunyai bekas yang rosak, dan sudah tiba masanya untuk Pool Ejection. Menggunakan konfigurasi yang sangat mudah, kami akan mengecualikan bekas yang gagal ini daripada mana-mana skim penghalaan selama 15 saat dengan harapan ia akan kembali kepada keadaan yang sihat (sama ada mulakan semula atau pulihkan prestasi). Inilah rupa konfigurasi ini dan hasil kerjanya:
Seperti yang anda lihat, bekas v2 yang gagal tidak lagi digunakan untuk permintaan penghalaan kerana ia telah dialih keluar daripada kumpulan. Tetapi selepas 15 saat ia akan kembali ke kolam secara automatik. Sebenarnya, kami baru menunjukkan cara Pool Ejection berfungsi.
Mari kita mula membina seni bina
Pool Ejection, digabungkan dengan keupayaan pemantauan Istio, membolehkan anda mula membina rangka kerja untuk menggantikan bekas yang rosak secara automatik untuk mengurangkan, jika tidak menghapuskan, masa henti dan kegagalan.
β
NASA mempunyai satu moto yang kuat - Kegagalan Bukan Pilihan, yang pengarangnya dianggap sebagai pengarah penerbangan . Ia boleh diterjemahkan ke dalam bahasa Rusia sebagai "Kegagalan bukan pilihan," dan maksudnya di sini ialah segala-galanya boleh dibuat untuk berfungsi jika anda mempunyai kemahuan yang mencukupi. Walau bagaimanapun, dalam kehidupan sebenar, kegagalan tidak berlaku begitu sahaja, ia tidak dapat dielakkan, di mana-mana dan dalam segala-galanya. Dan bagaimana untuk menanganinya dalam kes perkhidmatan mikro? Pada pendapat kami, adalah lebih baik untuk tidak bergantung pada kemahuan, tetapi pada keupayaan bekas, , dan .
Istio, seperti yang kami tulis di atas, melaksanakan konsep pemutus litar, yang telah membuktikan dirinya dengan baik dalam dunia fizikal. Dan sama seperti pemutus litar elektrik mematikan bahagian litar yang bermasalah, Perisian Istio's Circuit Breaker membuka sambungan antara aliran permintaan dan bekas masalah apabila ada masalah dengan titik akhir, contohnya, apabila pelayan ranap atau mula perlahankan.
Lebih-lebih lagi, dalam kes kedua hanya terdapat lebih banyak masalah, kerana brek satu bekas bukan sahaja menyebabkan kelewatan dalam perkhidmatan yang mengaksesnya dan, akibatnya, mengurangkan prestasi sistem secara keseluruhan, tetapi juga menjana berulang. permintaan kepada perkhidmatan yang sudah berjalan perlahan, yang hanya memburukkan keadaan .
Pemutus Litar secara teori
Pemutus Litar ialah proksi yang mengawal aliran permintaan ke titik akhir. Apabila titik ini berhenti berfungsi atau, bergantung pada tetapan yang ditentukan, mula perlahan, proksi memutuskan sambungan dengan bekas. Lalu lintas kemudiannya diubah hala ke bekas lain, hanya disebabkan pengimbangan beban. Sambungan kekal terbuka untuk tetingkap tidur tertentu, katakan dua minit, dan kemudian dianggap separuh terbuka. Percubaan untuk menghantar permintaan seterusnya menentukan keadaan sambungan selanjutnya. Jika semuanya OK dengan perkhidmatan, sambungan kembali ke keadaan berfungsi dan sekali lagi menjadi tertutup. Jika masih terdapat masalah dengan perkhidmatan, sambungan diputuskan dan tetingkap tidur didayakan semula. Inilah rupa gambarajah keadaan Pemutus Litar yang dipermudahkan:
Adalah penting untuk diperhatikan di sini bahawa semua ini berlaku pada tahap, boleh dikatakan, seni bina sistem. Jadi pada satu ketika anda perlu mengajar aplikasi anda untuk berfungsi dengan Pemutus Litar, seperti memberikan nilai lalai sebagai tindak balas atau, jika boleh, mengabaikan kewujudan perkhidmatan. Corak sekat digunakan untuk ini, tetapi ia di luar skop artikel ini.
Pemutus Litar dalam amalan
Sebagai contoh, kami akan menjalankan dua versi perkhidmatan mikro cadangan kami pada OpenShift. Versi 1 akan berfungsi dengan baik, tetapi dalam v2 kami akan membuat kelewatan untuk mensimulasikan kelembapan pada pelayan. Untuk melihat keputusan, gunakan alat :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Segala-galanya nampaknya berfungsi, tetapi pada kos berapa? Pada pandangan pertama, kami mempunyai ketersediaan 100%, tetapi lihat dengan lebih dekat - tempoh transaksi maksimum ialah sebanyak 12 saat. Ini jelas merupakan halangan dan perlu diperluaskan.
Untuk melakukan ini, kami akan menggunakan Istio untuk menghapuskan panggilan untuk memperlahankan bekas. Inilah rupa konfigurasi yang sepadan menggunakan Pemutus Litar:
Baris terakhir dengan parameter httpMaxRequestsPerConnection memberi isyarat bahawa sambungan dengannya harus diputuskan apabila cuba mencipta satu lagi - satu kedua - sambungan sebagai tambahan kepada yang sedia ada. Memandangkan kontena kami mensimulasikan perkhidmatan yang perlahan, situasi sedemikian akan timbul secara berkala, dan kemudian Istio akan mengembalikan ralat 503, tetapi inilah yang akan ditunjukkan oleh pengepungan:
OK, kita ada Pemutus Litar, apa yang seterusnya?
Jadi, kami melaksanakan penutupan automatik tanpa menyentuh kod sumber perkhidmatan itu sendiri sama sekali. Menggunakan Pemutus Litar dan prosedur Pool Ejection yang diterangkan di atas, kami boleh mengalih keluar bekas brek daripada kolam sumber sehingga ia kembali normal, dan menyemak statusnya pada frekuensi tertentu - dalam contoh kami, ini adalah dua minit (parameter sleepWindow).
Ambil perhatian bahawa keupayaan aplikasi untuk bertindak balas kepada ralat 503 masih ditetapkan pada tahap kod sumber. Terdapat banyak strategi untuk menggunakan Pemutus Litar, bergantung pada keadaan.
Dalam jawatan seterusnya: Kami akan bercakap tentang pengesanan dan pemantauan yang sudah terbina dalam atau mudah ditambahkan pada Istio, serta cara memasukkan ralat secara sengaja ke dalam sistem.
Sumber: www.habr.com