Cuti telah berakhir, dan kami kembali dengan siaran kedua kami dalam siri Istio Service Mesh.
Topik hari ini ialah Pemutus Litar, yang dalam bahasa Rusia bermaksud "suis automatik" atau, dalam bahasa sehari-hari, "pemutus litar." Walau bagaimanapun, di Istio, pemutus litar ini memutuskan sambungan bekas yang rosak dan bukannya litar terpintas atau terlampau beban.
Bagaimana ia sepatutnya berfungsi dengan ideal
Apabila perkhidmatan mikro diurus oleh Kubernetes, sebagai contoh, dalam platform OpenShift, ia secara automatik naik dan turun bergantung pada beban. Oleh kerana perkhidmatan mikro dijalankan dalam pod, berbilang contoh perkhidmatan mikro kontena boleh dijalankan 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 merujuk kepada kemudahan kemunculan dan kehilangan, sering dipandang remeh. Kelahiran dan kematian satu lagi contoh perkhidmatan mikro dalam pod adalah dijangka sepenuhnya; OpenShift dan Kubernetes mengendalikan perkara ini dengan baik, dan semuanya berfungsi dengan baik—tetapi sekali lagi, itu hanya dalam teori.
Bagaimana ia sebenarnya berfungsi
Sekarang bayangkan bahawa contoh perkhidmatan mikro tertentu, atau bekas, telah menjadi tidak boleh digunakan: sama ada ia tidak bertindak balas (ralat 503) atau, lebih teruk, ia bertindak balas tetapi terlalu perlahan. Dalam erti kata lain, ia bermasalah atau tidak bertindak balas, tetapi ia tidak dialih keluar secara automatik daripada kolam. Apa yang perlu anda lakukan dalam kes ini? Cuba lagi? Alih keluarnya daripada penghalaan? Dan apakah maksud "terlalu perlahan"? Berapa banyak itu, dan siapa yang menentukannya? Mungkin anda perlu berhenti dan cuba lagi kemudian? Jika ya, berapa lama?
Apakah Pool Ejection di Istio?
Di sinilah Istio hadir dengan mekanisme perlindungan Pemutus Litarnya, yang mengalihkan sementara bekas yang rosak daripada kumpulan sumber penghalaan dan pengimbangan beban dengan melaksanakan prosedur Pool Ejection.
Menggunakan strategi pengesanan terpencil, Istio mengesan pod yang tidak segerak dan mengalih keluarnya daripada kumpulan sumber untuk masa tertentu, dipanggil tetingkap tidur.
Untuk menunjukkan cara ini berfungsi dalam Kubernetes pada platform OpenShift, mari kita mulakan dengan tangkapan skrin perkhidmatan mikro yang biasa dijalankan daripada repositori contoh. 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 kegagalan
Sebelum melakukan Pool Ejection, kita perlu mencipta peraturan penghalaan Istio. Katakan kita mahu mengedarkan permintaan antara pod 50/50. Kami juga akan menambah bilangan bekas v2 daripada satu kepada dua, seperti ini:
oc scale deployment recommendation-v2 --replicas=2 -n tutorial
Kini kami menyediakan peraturan penghalaan supaya trafik diedarkan antara pod dalam nisbah 50/50.
Dan inilah keputusan peraturan ini:
Seseorang mungkin mencari kesalahan dengan fakta bahawa skrin ini bukan 50/50, tetapi 14:9, tetapi keadaan akan bertambah baik dari semasa ke semasa.
Kami menyebabkan gangguan
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:
Kami sedang membetulkan masalah
Jadi, kami mempunyai bekas yang gagal, dan sudah tiba masanya untuk Pool Ejection. Menggunakan konfigurasi yang sangat mudah, kami akan mengecualikan bekas yang gagal ini daripada semua penghalaan selama 15 saat, dengan harapan ia akan pulih dengan sendirinya (sama ada dengan memulakan semula atau memulihkan prestasi). Inilah rupa konfigurasi ini dan hasilnya:
Seperti yang anda lihat, bekas v2 yang rosak tidak lagi digunakan untuk penghalaan permintaan kerana ia telah dialih keluar daripada kolam. Walau bagaimanapun, selepas 15 saat, ia akan kembali ke kolam secara automatik. Sebenarnya, kami baru sahaja 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 gagal 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 ideanya ialah apa-apa sahaja boleh dibuat untuk berfungsi dengan kemahuan yang mencukupi. Walau bagaimanapun, dalam kehidupan sebenar, kegagalan tidak berlaku begitu sahaja; mereka tidak dapat dielakkan, di mana-mana dan dalam segala-galanya. Jadi bagaimana anda berurusan dengan mereka dalam kes perkhidmatan mikro? Pada pendapat kami, lebih baik untuk tidak bergantung pada kemahuan, tetapi pada keupayaan kontena. , dan .
Istio, seperti yang telah kami nyatakan, melaksanakan konsep pemutus litar yang mantap dalam dunia fizikal. Sama seperti pemutus litar elektrik memutuskan sambungan bahagian litar yang bermasalah, Pemutus Litar berasaskan perisian Istio memutuskan sambungan antara aliran permintaan dan bekas bermasalah apabila berlaku masalah dengan titik akhir, seperti pelayan ranap atau menjadi perlahan.
Selain itu, dalam kes kedua, masalah hanya meningkat, kerana kelembapan satu kontena bukan sahaja menyebabkan lata kelewatan dalam perkhidmatan yang mengaksesnya dan, akibatnya, mengurangkan prestasi sistem secara keseluruhan, tetapi juga menjana permintaan berulang kepada perkhidmatan yang sudah perlahan, yang hanya memburukkan keadaan.
Pemutus Litar dalam Teori
Pemutus Litar ialah proksi yang mengawal aliran permintaan ke titik akhir. Apabila titik akhir ini berhenti berfungsi atau, bergantung pada tetapan yang dikonfigurasikan, mula perlahan, proksi memutuskan sambungan ke bekas. Trafik kemudiannya diubah hala ke bekas lain, semata-mata untuk tujuan 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 seterusnya. Jika perkhidmatan OK, sambungan kembali ke keadaan berfungsi dan ditutup semula. Jika perkhidmatan masih gagal, sambungan diputuskan dan tetingkap tidur didayakan semula. Berikut ialah rajah ringkas peralihan keadaan Pemutus Litar:
Adalah penting untuk ambil perhatian bahawa semua ini berlaku pada peringkat seni bina sistem, boleh dikatakan. Oleh itu, pada satu ketika, anda perlu mengajar aplikasi anda untuk berfungsi dengan Pemutus Litar, contohnya, dengan memberikan nilai lalai sebagai tindak balas atau, jika boleh, mengabaikan kewujudan perkhidmatan. Ini dicapai menggunakan corak sekat, tetapi ia di luar skop artikel ini.
Pemutus Litar dalam Amalan
Untuk contoh ini, kami akan menjalankan dua versi perkhidmatan mikro cadangan kami pada OpenShift. Versi 1 akan berjalan seperti biasa, tetapi dalam v2 kami akan menambah kelewatan untuk mensimulasikan ketinggalan 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 100% ketersediaan, tetapi lihat dengan lebih dekat – tempoh transaksi maksimum ialah 12 saat. Ini jelas merupakan halangan, dan ia perlu ditangani.
Untuk melakukan ini, kami akan menggunakan Istio untuk menghalang panggilan untuk memperlahankan bekas. Inilah rupa konfigurasi yang sepadan menggunakan Pemutus Litar:
Baris terakhir dengan parameter httpMaxRequestsPerConnection menunjukkan bahawa sambungan harus ditutup apabila cuba membuat sambungan kedua sebagai tambahan kepada sambungan yang sedia ada. Memandangkan bekas kami mensimulasikan perkhidmatan yang perlahan, situasi sedemikian akan berlaku secara berkala, dan kemudian Istio akan mengembalikan ralat 503, dan inilah yang akan ditunjukkan oleh Siege:
OK, kita ada Pemutus Litar, apa yang seterusnya?
Jadi, kami telah melaksanakan penutupan automatik tanpa menyentuh kod sumber perkhidmatan itu sendiri. Menggunakan Pemutus Litar dan prosedur Pool Ejection yang diterangkan di atas, kami boleh mengalih keluar bekas perlahan daripada kolam sumber sehingga ia kembali normal dan menyemak statusnya pada selang waktu tertentu—dalam contoh kami, setiap dua minit (parameter sleepWindow).
Sila ambil perhatian bahawa keupayaan aplikasi untuk bertindak balas kepada ralat 503 masih ditakrifkan pada tahap kod sumber. Terdapat pelbagai strategi untuk menangani Pemutus Litar, bergantung kepada keadaan.
Dalam jawatan seterusnya: Kami akan merangkumi pengesanan dan pemantauan, yang terbina dalam Istio atau mudah ditambah, serta cara sengaja memasukkan ralat ke dalam sistem.
Sumber: www.habr.com
