Liburan telah usai dan kami kembali dengan postingan kedua kami di seri Istio Service Mesh.
Topik hari ini adalah Pemutus Sirkuit, yang diterjemahkan ke dalam bahasa Rusia teknik kelistrikan berarti “pemutus sirkuit”, dalam bahasa umum – “pemutus sirkuit”. Hanya di Istio mesin ini tidak memutus hubungan pendek atau kelebihan beban, melainkan wadah yang rusak.
Bagaimana hal ini seharusnya berjalan secara ideal
Ketika layanan-layanan mikro dikelola oleh Kubernetes, misalnya dalam platform OpenShift, layanan-layanan tersebut secara otomatis ditingkatkan dan diturunkan skalanya tergantung pada bebannya. Karena layanan-layanan mikro berjalan di dalam pod, mungkin terdapat beberapa contoh layanan mikro yang terkontainer pada satu titik akhir, dan Kubernetes akan merutekan permintaan dan menyeimbangkan beban di antara layanan-layanan tersebut. Dan - idealnya - semua ini harus berjalan dengan sempurna.
Kami ingat bahwa layanan mikro bersifat kecil dan bersifat sementara. Ephemerality, yang di sini berarti mudahnya muncul dan menghilang, seringkali diremehkan. Kelahiran dan kematian contoh lain dari layanan mikro dalam sebuah pod adalah hal yang sangat diharapkan, OpenShift dan Kubernetes menangani hal ini dengan baik, dan semuanya bekerja dengan baik - tetapi sekali lagi secara teori.
Bagaimana cara kerjanya
Sekarang bayangkan contoh spesifik dari layanan mikro, yaitu sebuah wadah, menjadi tidak dapat digunakan: tidak merespons (kesalahan 503), atau, yang lebih tidak menyenangkan, merespons, tetapi terlalu lambat. Dengan kata lain, ia menjadi glitchy atau tidak merespons permintaan, namun tidak secara otomatis dihapus dari kumpulan. Apa yang harus dilakukan dalam kasus ini? Untuk mencoba lagi? Haruskah saya menghapusnya dari skema perutean? Dan apa yang dimaksud dengan “terlalu lambat” – berapa jumlahnya, dan siapa yang menentukannya? Mungkin istirahat saja dan coba lagi nanti? Jika iya, berapa lama lagi?
Apa itu Ejeksi Kolam Renang di Istio
Dan di sini Istio datang untuk menyelamatkan dengan mesin perlindungan Pemutus Sirkuit, yang untuk sementara menghapus kontainer yang rusak dari kumpulan sumber daya perutean dan penyeimbangan beban, dengan menerapkan prosedur Pool Ejection.
Dengan menggunakan strategi deteksi outlier, Istio mendeteksi pod kurva yang tidak sesuai dan menghapusnya dari kumpulan sumber daya selama jangka waktu tertentu, yang disebut jendela tidur.
Untuk menunjukkan cara kerjanya di Kubernetes pada platform OpenShift, mari kita mulai dengan tangkapan layar layanan mikro yang berfungsi normal dari contoh di repositori . Di sini kita memiliki dua pod, v1 dan v2, masing-masing menjalankan satu container. Ketika aturan perutean Istio tidak digunakan, Kubernetes secara default menggunakan perutean round-robin yang seimbang:
Bersiap untuk kecelakaan
Sebelum melakukan Pool Ejection, Anda perlu membuat aturan routing Istio. Katakanlah kita ingin mendistribusikan permintaan antar pod dengan rasio 50/50. Selain itu, kami akan menambah jumlah container 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 antar pod dengan rasio 50/50.
Berikut hasil dari aturan ini:
Anda dapat menemukan kesalahan dengan fakta bahwa layar ini bukan 50/50, tetapi 14:9, tetapi seiring waktu situasinya akan membaik.
Membuat kesalahan
Sekarang mari kita nonaktifkan salah satu dari dua container v2 sehingga kita memiliki satu container v1 yang sehat, satu container v2 yang sehat, dan satu container v2 yang rusak:
Memperbaiki kesalahan
Jadi, kami memiliki wadah yang rusak, dan inilah waktunya untuk Pool Ejection. Dengan menggunakan konfigurasi yang sangat sederhana, kami akan mengecualikan kontainer yang gagal ini dari skema perutean apa pun selama 15 detik dengan harapan kontainer akan kembali ke kondisi sehat (mulai ulang atau pulihkan kinerja). Seperti inilah tampilan config ini dan hasil kerjanya :
Seperti yang Anda lihat, kontainer v2 yang gagal tidak lagi digunakan untuk permintaan perutean karena telah dihapus dari kumpulan. Namun setelah 15 detik secara otomatis akan kembali ke kolam. Sebenarnya kami baru saja menunjukkan cara kerja Pool Ejection.
Mari kita mulai membangun arsitektur
Pool Ejection, dikombinasikan dengan kemampuan pemantauan Istio, memungkinkan Anda mulai membangun kerangka kerja untuk mengganti kontainer yang rusak secara otomatis guna mengurangi, jika tidak menghilangkan, waktu henti dan kegagalan.
NASA memiliki satu moto yang keras - Kegagalan Bukanlah Pilihan, yang penulisnya dianggap sebagai direktur penerbangan . Ini dapat diterjemahkan ke dalam bahasa Rusia sebagai “Kegagalan bukanlah suatu pilihan,” dan maknanya di sini adalah bahwa segala sesuatu dapat dilakukan jika Anda memiliki kemauan yang cukup. Namun, dalam kehidupan nyata, kegagalan tidak terjadi begitu saja, kegagalan tidak bisa dihindari, di mana pun dan dalam segala hal. Dan bagaimana cara mengatasinya dalam kasus layanan mikro? Menurut pendapat kami, lebih baik tidak mengandalkan kemauan, tetapi pada kemampuan kontainer, , Dan .
Istio, seperti yang kami tulis di atas, menerapkan konsep pemutus arus yang telah terbukti baik di dunia fisik. Dan seperti pemutus sirkuit listrik yang mematikan bagian sirkuit yang bermasalah, perangkat lunak Circuit Breaker Istio membuka koneksi antara aliran permintaan dan wadah masalah ketika ada yang salah dengan titik akhir, misalnya, ketika server mogok atau mulai mogok. pelan - pelan.
Selain itu, dalam kasus kedua hanya terdapat lebih banyak masalah, karena rem pada satu kontainer tidak hanya menyebabkan serangkaian penundaan dalam layanan yang mengaksesnya dan, sebagai akibatnya, mengurangi kinerja sistem secara keseluruhan, tetapi juga menghasilkan pengulangan. permintaan ke 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 pengaturan yang ditentukan, mulai melambat, proxy memutus koneksi dengan penampung. Lalu lintas kemudian dialihkan ke kontainer lain, hanya karena penyeimbangan beban. Koneksi tetap terbuka selama jangka waktu tidur tertentu, katakanlah dua menit, dan kemudian dianggap setengah terbuka. Upaya untuk mengirim permintaan berikutnya menentukan status koneksi selanjutnya. Jika semuanya baik-baik saja dengan layanan, koneksi kembali ke kondisi kerja dan ditutup lagi. Jika masih ada yang salah dengan layanan, sambungan terputus dan jendela tidur diaktifkan kembali. Berikut tampilan diagram status Pemutus Sirkuit yang disederhanakan:
Penting untuk dicatat di sini bahwa semua ini terjadi pada tingkat arsitektur sistem. Jadi pada titik tertentu Anda harus mengajarkan aplikasi Anda untuk bekerja dengan Circuit Breaker, seperti memberikan nilai default sebagai respons atau, jika mungkin, mengabaikan keberadaan layanan. Pola sekat digunakan untuk ini, namun hal ini berada di luar cakupan artikel ini.
Pemutus Sirkuit dalam praktiknya
Misalnya, kami akan menjalankan dua versi layanan mikro rekomendasi kami di OpenShift. Versi 1 akan berfungsi dengan baik, tetapi di v2 kami akan membuat penundaan untuk mensimulasikan pelambatan di server. Untuk melihat hasilnya, gunakan alat ini :
siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io
Segalanya tampaknya berhasil, tetapi berapa biayanya? Sekilas, kami memiliki ketersediaan 100%, namun lihat lebih dekat - durasi transaksi maksimum adalah 12 detik. Hal ini jelas merupakan hambatan dan perlu diperluas.
Untuk melakukan ini, kami akan menggunakan Istio untuk menghilangkan panggilan ke container yang lambat. Ini adalah tampilan konfigurasi terkait menggunakan Pemutus Sirkuit:
Baris terakhir dengan parameter httpMaxRequestsPerConnection menandakan bahwa koneksi harus diputuskan ketika mencoba membuat koneksi lain - kedua - selain yang sudah ada. Karena penampung kami mensimulasikan layanan yang lambat, situasi seperti itu akan muncul secara berkala, dan kemudian Istio akan mengembalikan kesalahan 503, tetapi inilah yang akan ditunjukkan oleh pengepungan:
Oke, kita punya Circuit Breaker, apa selanjutnya?
Jadi, kami menerapkan pematian otomatis tanpa menyentuh kode sumber layanan itu sendiri sama sekali. Menggunakan Pemutus Sirkuit dan prosedur Pool Ejection yang dijelaskan di atas, kita dapat menghapus wadah rem dari kumpulan sumber daya hingga kembali normal, dan memeriksa statusnya pada frekuensi tertentu - dalam contoh kita, ini adalah dua menit (parameter sleepWindow).
Perhatikan bahwa kemampuan aplikasi untuk merespons kesalahan 503 masih diatur pada tingkat kode sumber. Ada banyak strategi dalam menggunakan Circuit Breaker, tergantung situasinya.
Di postingan berikutnya: Kami akan membahas tentang penelusuran dan pemantauan yang sudah ada di dalam atau mudah ditambahkan ke Istio, serta cara memasukkan kesalahan ke dalam sistem dengan sengaja.
Sumber: www.habr.com