Pada
artikel terakhir
, kami memeriksa komponen dasar Service Mesh Istio, berkenalan dengan sistem dan menjawab pertanyaan dasar yang biasanya muncul pada awal bekerja dengan Istio. Pada bagian ini, kita akan melihat bagaimana mengatur pengumpulan informasi penelusuran melalui jaringan.
Hal pertama yang ditemukan oleh banyak pengembang dan administrator sistem ketika mereka mendengar kata-kata Service Mesh sedang ditelusuri. Memang, kami menambahkan server proxy khusus untuk setiap node jaringan yang dilaluinya semua lalu lintas TCP. Tampaknya sekarang Anda dapat dengan mudah mengirim informasi tentang semua interaksi jaringan di jaringan. Sayangnya, pada kenyataannya ada banyak nuansa yang perlu diperhitungkan. Mari lihat mereka.
Kesalahpahaman nomor satu: kita bisa mendapatkan data perjalanan melalui jaringan secara gratis
Bahkan, relatif gratis, kita hanya bisa mendapatkan node dari sistem kita terhubung dengan panah dan data rate yang melewati antar layanan (pada kenyataannya, hanya jumlah byte per unit waktu). Namun, dalam kebanyakan kasus, layanan kami berkomunikasi menggunakan beberapa jenis protokol tingkat aplikasi, seperti HTTP, gRPC, Redis, dan sebagainya. Dan, tentu saja, kami ingin melihat penelusuran informasi secara tepat berdasarkan protokol-protokol ini, kami ingin melihat laju permintaan, dan bukan laju data. Kami ingin memahami latensi permintaan oleh protokol kami. Terakhir, kami ingin melihat jalur lengkap dari permintaan yang masuk dari memasuki sistem kami hingga menerima respons dari pengguna. Masalah ini tidak mudah dipecahkan.
Untuk memulai, mari kita lihat bagaimana cara mengirim tracing span dari sudut pandang arsitektur di Istio. Seperti yang kita ingat dari bagian pertama, Istio memiliki komponen terpisah untuk mengumpulkan telemetri, yang disebut Mixer. Namun, dalam versi 1.0 saat ini. * Mengirim dilakukan langsung dari server proxy, yaitu, dengan proxy utusan. Utusan proksi mendukung pengiriman rentang penelusuran melalui protokol zipkin di luar kotak. Protokol lain dapat dihubungkan, tetapi hanya melalui plugin. Dengan Istio, kami segera mendapatkan proxy utusan yang dirangkai dan dikonfigurasi, yang hanya mendukung protokol zipkin. Jika kita ingin menggunakan, misalnya, protokol Jaeger dan mengirim tracing span melalui UDP, maka kita perlu merakit image istio-proxy kita. Ada dukungan untuk plugin khusus untuk istio-proxy, namun masih dalam versi alpha. Oleh karena itu, jika kita ingin melakukannya tanpa banyak pengaturan khusus, rentang teknologi yang digunakan untuk menyimpan dan menerima tracing span berkurang. Dari sistem utama, pada kenyataannya, sekarang Anda dapat menggunakan Zipkin sendiri, atau Jaeger, tetapi mengirim semuanya ke sana menggunakan protokol yang kompatibel dengan zipkin (yang jauh lebih efisien). Protokol zipkin sendiri melibatkan pengiriman semua informasi penelusuran ke kolektor menggunakan protokol HTTP, yang cukup mahal.
Seperti yang saya katakan, kami ingin melacak protokol tingkat aplikasi. Dan ini berarti bahwa server proxy yang ada di sebelah setiap layanan harus memahami jenis interaksi apa yang terjadi sekarang. Secara default, Istio menetapkan tipe untuk semua port TCP biasa, yang berarti tidak ada jejak yang akan dikirim. Agar jejak dapat dikirim, Anda harus terlebih dahulu mengaktifkan opsi ini di konfigurasi jala utama dan, yang sangat penting, ganti nama semua port entitas layanan kubernet sesuai dengan protokol yang digunakan dalam layanan. Misalnya, seperti ini:
apiVersion: v1 kind: Service metadata: name: nginx spec: ports: - port: 80 targetPort: 80 name: http selector: app: nginx
Anda juga dapat menggunakan nama majemuk, seperti http-magic (Istio melihat http dan mengenali port ini sebagai titik akhir http). Formatnya adalah: proto-extra.
Agar tidak menambal sejumlah besar konfigurasi untuk mendefinisikan protokol, Anda dapat menggunakan solusi kotor: untuk menambal komponen Pilot pada saat itu hanya
mengeksekusi logika definisi protokol . Pada akhirnya, tentu saja, Anda perlu mengubah logika ini menjadi standar dan pergi ke konvensi penamaan untuk semua port.
Untuk memahami apakah protokol benar-benar didefinisikan dengan benar, Anda harus masuk ke salah satu wadah sespan dengan proxy utusan dan membuat permintaan ke port admin antarmuka utusan dengan lokasi / config_dump. Dalam konfigurasi yang dihasilkan, Anda perlu melihat operasi bidang layanan yang diinginkan. Ini digunakan dalam Istio sebagai pengidentifikasi ke mana tujuan permintaan. Untuk menyesuaikan nilai parameter ini di Istio (kita akan melihatnya di sistem penelusuran kami), Anda harus menentukan flag serviceCluster pada tahap peluncuran wadah sespan. Misalnya, dapat dihitung seperti ini dari variabel yang diperoleh dari kubernet API ke bawah:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')Contoh yang bagus untuk memahami bagaimana penelusuran berfungsi dalam utusan ada di
sini .
Titik akhir itu sendiri untuk mengirim tracing span juga harus ditentukan dalam flag awal proxy utusan, misalnya:
--zipkinAddress tracing-collector.tracing:9411Kesalahpahaman nomor dua: kita bisa mendapatkan jalan setapak yang lengkap dari permintaan untuk sistem di luar kotak
Sayangnya, ini tidak benar. Kompleksitas implementasi tergantung pada bagaimana Anda telah menerapkan interaksi layanan. Kenapa begitu
Faktanya adalah agar istio-proxy dapat memahami korespondensi permintaan masuk ke layanan dengan mereka yang berasal dari layanan yang sama, tidak cukup hanya dengan mencegat semua lalu lintas. Anda harus memiliki semacam pengenal tautan. HTTP proxy utusan menggunakan header khusus, dimana utusan memahami permintaan layanan tertentu yang menghasilkan permintaan spesifik ke layanan lain. Daftar tajuk tersebut:
- x-request-id,
- x-b3-traceid,
- x-b3-spanid,
- x-b3-parentspanid,
- sampel x-b3,
- bendera x-b3,
- x-ot-span-context.
Jika Anda memiliki satu titik, misalnya, klien basis di mana Anda dapat menambahkan logika seperti itu, maka semuanya baik-baik saja, Anda hanya perlu menunggu semua klien untuk memperbarui perpustakaan ini. Tetapi jika Anda memiliki sistem yang sangat heterogen dan tidak ada penyatuan dalam kampanye dari layanan ke layanan melalui jaringan, maka ini kemungkinan besar akan menjadi masalah besar. Tanpa penambahan logika seperti itu, semua informasi penelusuran hanya akan menjadi "saudara". Yaitu, kita mendapatkan semua interaksi antar-layanan, tetapi mereka tidak akan dilem menjadi satu rantai lintasan melalui jaringan.
Kesimpulan
Istio menyediakan alat yang mudah untuk mengumpulkan informasi penelusuran melalui jaringan, namun, Anda harus memahami bahwa untuk implementasinya Anda perlu menyesuaikan sistem Anda dan mempertimbangkan fitur-fitur implementasi Istio. Akibatnya, Anda perlu menyelesaikan dua poin utama: menentukan protokol lapisan aplikasi (yang harus didukung oleh utusan utusan) dan menyiapkan penerusan informasi tentang konektivitas permintaan ke layanan dari permintaan dari layanan (menggunakan header, dalam kasus protokol HTTP). Ketika masalah ini diselesaikan, kami mendapatkan alat yang ampuh yang memungkinkan Anda mengumpulkan informasi dari jaringan secara transparan, bahkan dalam sistem yang sangat heterogen yang ditulis dalam berbagai bahasa dan kerangka kerja.
Pada artikel selanjutnya tentang Service Mesh, kami akan mempertimbangkan salah satu masalah terbesar Istio - konsumsi memori yang besar dari setiap wadah proxy sespan dan membahas bagaimana cara menanganinya.