Istio dan Kubernetes dalam produksi. Bagian 2. Menelusuri

Terakhir Artikel Kami melihat komponen dasar Service Mesh Istio, mengenal sistem dan menjawab pertanyaan utama yang biasanya muncul saat mulai bekerja dengan Istio. Pada bagian ini kita akan melihat bagaimana mengatur pengumpulan informasi penelusuran melalui jaringan.

Hal pertama yang terlintas dalam pikiran banyak pengembang dan administrator sistem ketika mereka mendengar kata Service Mesh adalah penelusuran. Memang, kami menambahkan server proxy khusus ke setiap node jaringan yang dilalui semua lalu lintas TCP. Tampaknya sekarang dimungkinkan untuk dengan mudah mengirim informasi tentang semua interaksi jaringan di jaringan. Sayangnya, pada kenyataannya ada banyak nuansa yang perlu diperhatikan. Mari kita lihat mereka.

Kesalahpahaman nomor satu: kita bisa mendapatkan data pendakian online secara gratis.

Faktanya, secara relatif gratis, kita hanya bisa menghubungkan node-node sistem kita dengan panah dan kecepatan data yang melewati antar layanan (sebenarnya, hanya jumlah byte per unit waktu). Namun, dalam sebagian besar kasus, layanan kami berkomunikasi melalui beberapa jenis protokol lapisan aplikasi, seperti HTTP, gRPC, Redis, dan sebagainya. Dan, tentu saja, kami ingin melihat informasi penelusuran khusus untuk protokol-protokol ini; kami ingin melihat kecepatan permintaan, bukan kecepatan data. Kami ingin memahami latensi permintaan menggunakan protokol kami. Terakhir, kami ingin melihat jalur lengkap yang diambil permintaan mulai dari masuk ke sistem kami hingga menerima respons dari pengguna. Masalah ini tidak lagi mudah untuk diselesaikan.

Pertama, mari kita lihat seperti apa pengiriman tracing span dari sudut pandang arsitektur di Istio. Seperti yang kita ingat dari bagian pertama, Istio memiliki komponen terpisah yang disebut Mixer untuk mengumpulkan telemetri. Namun pada versi 1.0.* saat ini, pengiriman dilakukan langsung dari server proxy yaitu dari proxy utusan. Proksi utusan mendukung pengiriman rentang penelusuran menggunakan protokol zipkin secara langsung. Dimungkinkan untuk menghubungkan protokol lain, tetapi hanya melalui sebuah plugin. Dengan Istio kami segera mendapatkan proxy utusan yang telah dirakit dan dikonfigurasi, yang hanya mendukung protokol zipkin. Jika kita ingin menggunakan, misalnya, protokol Jaeger dan mengirim rentang penelusuran melalui UDP, maka kita perlu membuat image istio-proxy kita sendiri. Ada dukungan untuk plugin khusus untuk istio-proxy, tetapi masih dalam versi alpha. Oleh karena itu, jika kita ingin melakukannya tanpa sejumlah besar pengaturan khusus, jangkauan teknologi yang digunakan untuk menyimpan dan menerima rentang penelusuran akan berkurang. Faktanya, dari sistem utama, sekarang Anda dapat menggunakan Zipkin itu sendiri, atau Jaeger, tetapi mengirim semuanya ke sana menggunakan protokol yang kompatibel dengan zipkin (yang kurang efisien). Protokol zipkin sendiri melibatkan pengiriman semua informasi penelusuran ke kolektor melalui protokol HTTP, yang biayanya cukup mahal.

Seperti yang sudah saya katakan, kami ingin melacak protokol tingkat aplikasi. Artinya server proxy yang berdiri di samping setiap layanan harus memahami interaksi seperti apa yang sedang terjadi saat ini. Secara default, Istio mengonfigurasi semua port menjadi TCP biasa, yang berarti tidak ada jejak yang akan dikirim. Agar jejak dapat terkirim, pertama-tama Anda harus mengaktifkan opsi ini di konfigurasi mesh utama dan, yang sangat penting, memberi nama semua port entitas layanan kubernetes sesuai dengan protokol yang digunakan dalam layanan tersebut. Misalnya saja 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 gabungan seperti http-magic (Istio akan melihat http dan mengenali port tersebut sebagai titik akhir http). Formatnya adalah: proto-ekstra.

Agar tidak menambal sejumlah besar konfigurasi untuk menentukan protokol, Anda dapat menggunakan solusi kotor: menambal komponen Pilot pada saat baru saja melakukan logika definisi protokol. Pada akhirnya, tentu saja, logika ini perlu diubah ke standar dan beralih ke konvensi penamaan untuk semua port.

Untuk memahami apakah protokol benar-benar didefinisikan dengan benar, Anda perlu masuk ke salah satu kontainer sidecar dengan proxy utusan dan membuat permintaan ke port admin antarmuka utusan dengan lokasi /config_dump. Dalam konfigurasi yang dihasilkan, Anda perlu melihat bidang operasi layanan yang diinginkan. Ini digunakan di Istio sebagai pengidentifikasi tempat permintaan dibuat. Untuk menyesuaikan nilai parameter ini di Istio (kita kemudian akan melihatnya di sistem penelusuran kami), perlu untuk menentukan tanda serviceCluster pada tahap peluncuran wadah sespan. Misalnya, dapat dihitung seperti ini dari variabel yang diperoleh dari API kubernetes ke bawah:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

Contoh yang baik untuk memahami cara kerja penelusuran di utusan adalah di sini.

Titik akhir itu sendiri untuk mengirimkan rentang penelusuran juga harus ditentukan dalam tanda peluncuran proksi utusan, misalnya: --zipkinAddress tracing-collector.tracing:9411

Kesalahpahaman nomor dua: kita bisa mendapatkan jejak lengkap permintaan dengan biaya murah melalui sistem yang siap pakai

Sayangnya, tidak demikian. Kompleksitas implementasi bergantung pada bagaimana Anda mengimplementasikan interaksi layanan. Mengapa demikian?

Faktanya adalah agar istio-proxy dapat memahami korespondensi permintaan masuk ke layanan dengan permintaan yang keluar dari layanan yang sama, tidak cukup hanya dengan mencegat semua lalu lintas. Anda perlu memiliki semacam pengenal komunikasi. Proksi utusan HTTP menggunakan header khusus, yang dengannya utusan memahami permintaan spesifik ke layanan mana yang menghasilkan permintaan spesifik ke layanan lain. Daftar header tersebut:

• x-permintaan-id,
• x-b3-traceid,
• x-b3-spanyol,
• x-b3-orangtuapanid,
• x-b3-sampel,
• bendera x-b3,
• konteks-x-ot-span.

Jika Anda memiliki satu titik, misalnya klien dasar, di mana Anda dapat menambahkan logika seperti itu, maka semuanya baik-baik saja, Anda hanya perlu menunggu perpustakaan ini diperbarui untuk semua klien. Namun jika Anda memiliki sistem yang sangat heterogen dan tidak ada kesatuan dalam berpindah dari satu layanan ke layanan lainnya melalui jaringan, kemungkinan besar hal ini akan menjadi masalah besar. Tanpa menambahkan logika seperti itu, semua informasi penelusuran hanya akan bersifat “satu tingkat”. Artinya, kita akan menerima semua interaksi antar layanan, tetapi interaksi tersebut tidak akan terpaku pada satu rantai perjalanan melalui jaringan.

Kesimpulan

Istio menyediakan alat yang mudah digunakan untuk mengumpulkan informasi penelusuran melalui jaringan, namun Anda harus memahami bahwa untuk implementasi Anda perlu menyesuaikan sistem Anda dan mempertimbangkan fitur implementasi Istio. Akibatnya, dua poin utama perlu diselesaikan: mendefinisikan protokol tingkat aplikasi (yang harus didukung oleh proxy utusan) dan mengatur penerusan informasi tentang koneksi permintaan ke layanan dari permintaan dari layanan (menggunakan header , dalam kasus protokol HTTP). Ketika masalah ini teratasi, kami memiliki alat canggih yang memungkinkan kami mengumpulkan informasi dari jaringan secara transparan, bahkan dalam sistem yang sangat heterogen yang ditulis dalam berbagai bahasa dan kerangka kerja.

Pada artikel berikutnya tentang Service Mesh, kita akan melihat salah satu masalah terbesar dengan Istio – konsumsi RAM yang besar oleh setiap wadah proxy sidecar dan membahas bagaimana Anda dapat mengatasinya.

Sumber: www.habr.com