Istio dan Kubernetes dalam pengeluaran. Bahagian 2. Mengesan

Pada masa lalu artikel Kami melihat komponen asas Service Mesh Istio, berkenalan dengan sistem dan menjawab soalan utama yang biasanya timbul apabila mula bekerja dengan Istio. Dalam bahagian ini kita akan melihat bagaimana untuk mengatur pengumpulan maklumat pengesanan melalui rangkaian.

Perkara pertama yang terlintas di fikiran kebanyakan pembangun dan pentadbir sistem apabila mereka mendengar perkataan Service Mesh sedang mengesan. Sesungguhnya, kami menambah pelayan proksi khas pada setiap nod rangkaian yang melaluinya semua trafik TCP. Nampaknya kini boleh menghantar maklumat dengan mudah tentang semua interaksi rangkaian pada rangkaian. Malangnya, pada hakikatnya terdapat banyak nuansa yang perlu diambil kira. Mari lihat mereka.

Salah tanggapan nombor satu: kita boleh mendapatkan data mendaki dalam talian secara percuma.

Malah, secara relatifnya percuma, kami hanya boleh mendapatkan nod sistem kami yang disambungkan dengan anak panah dan kadar data yang melalui antara perkhidmatan (sebenarnya, hanya bilangan bait seunit masa). Walau bagaimanapun, dalam kebanyakan kes, perkhidmatan kami berkomunikasi melalui beberapa jenis protokol lapisan aplikasi, seperti HTTP, gRPC, Redis dan sebagainya. Dan, sudah tentu, kami ingin melihat maklumat pengesanan khusus untuk protokol ini; kami mahu melihat kadar permintaan, bukan kadar data. Kami ingin memahami kependaman permintaan menggunakan protokol kami. Akhir sekali, kami ingin melihat laluan penuh yang diambil oleh permintaan daripada log masuk ke sistem kami untuk menerima respons daripada pengguna. Masalah ini tidak lagi begitu mudah untuk diselesaikan.

Mula-mula, mari kita lihat rupa jarak pengesanan penghantaran dari sudut pandangan seni bina di Istio. Seperti yang kita ingat dari bahagian pertama, Istio mempunyai komponen berasingan yang dipanggil Mixer untuk mengumpul telemetri. Walau bagaimanapun, dalam versi semasa 1.0.*, penghantaran dilakukan terus daripada pelayan proksi, iaitu daripada proksi utusan. Proksi utusan menyokong penghantaran rentang pengesanan menggunakan protokol zipkin keluar dari kotak. Ia adalah mungkin untuk menyambungkan protokol lain, tetapi hanya melalui pemalam. Dengan Istio kami segera mendapat proksi utusan yang dipasang dan dikonfigurasikan, yang hanya menyokong protokol zipkin. Jika kita ingin menggunakan, sebagai contoh, protokol Jaeger dan menghantar rentang penjejakan melalui UDP, maka kita perlu membina imej istio-proksi kita sendiri. Terdapat sokongan untuk pemalam tersuai untuk istio-proxy, tetapi ia masih dalam versi alfa. Oleh itu, jika kita ingin melakukannya tanpa sebilangan besar tetapan tersuai, julat teknologi yang digunakan untuk menyimpan dan menerima rentang pengesanan dikurangkan. Daripada sistem utama, sebenarnya, kini anda boleh menggunakan Zipkin sendiri, atau Jaeger, tetapi menghantar segala-galanya ke sana menggunakan protokol serasi zipkin (yang jauh lebih cekap). Protokol zipkin itu sendiri melibatkan penghantaran semua maklumat pengesanan kepada pengumpul melalui protokol HTTP, yang agak mahal.

Seperti yang telah saya katakan, kami ingin menjejaki protokol peringkat aplikasi. Ini bermakna pelayan proksi yang berdiri di sebelah setiap perkhidmatan mesti memahami jenis interaksi yang berlaku sekarang. Secara lalai, Istio mengkonfigurasi semua port menjadi TCP biasa, yang bermaksud tiada jejak akan dihantar. Agar jejak dihantar, anda mesti, pertama sekali, mendayakan pilihan ini dalam konfigurasi mesh utama dan, yang paling penting, menamakan semua port entiti perkhidmatan kubernetes mengikut protokol yang digunakan dalam perkhidmatan. Iaitu, sebagai contoh, seperti ini:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

Anda juga boleh menggunakan nama kompaun seperti http-magic (Istio akan melihat http dan mengenali port itu sebagai titik akhir http). Formatnya ialah: proto-extra.

Untuk tidak menampal sebilangan besar konfigurasi untuk menentukan protokol, anda boleh menggunakan penyelesaian yang kotor: tampal komponen Pilot pada masa itu hanya melaksanakan logik definisi protokol. Pada akhirnya, sudah tentu, adalah perlu untuk menukar logik ini kepada standard dan beralih kepada konvensyen penamaan untuk semua port.

Untuk memahami sama ada protokol benar-benar ditakrifkan dengan betul, anda perlu pergi ke mana-mana bekas kereta sampingan dengan proksi utusan dan membuat permintaan ke port pentadbir antara muka utusan dengan lokasi /config_dump. Dalam konfigurasi yang dihasilkan, anda perlu melihat medan operasi perkhidmatan yang dikehendaki. Ia digunakan dalam Istio sebagai pengecam tempat permintaan dibuat. Untuk menyesuaikan nilai parameter ini dalam Istio (kemudian kami akan melihatnya dalam sistem pengesanan kami), adalah perlu untuk menentukan bendera serviceCluster pada peringkat melancarkan bekas kereta sampingan. Sebagai contoh, ia boleh dikira seperti ini daripada pembolehubah yang diperoleh daripada 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 pengesanan berfungsi dalam utusan di sini.

Titik akhir itu sendiri untuk menghantar rentang pengesanan juga mesti dinyatakan dalam bendera pelancaran proksi utusan, contohnya: --zipkinAddress tracing-collector.tracing:9411

Kesalahpahaman nombor dua: kami boleh mendapatkan jejak permintaan lengkap secara murah melalui sistem di luar kotak

Malangnya, ia tidak. Kerumitan pelaksanaan bergantung pada cara anda telah melaksanakan interaksi perkhidmatan. Kenapa begitu?

Hakikatnya ialah agar proksi istio dapat memahami surat-menyurat permintaan masuk ke perkhidmatan dengan mereka yang meninggalkan perkhidmatan yang sama, tidak cukup untuk memintas semua lalu lintas sahaja. Anda perlu mempunyai beberapa jenis pengecam komunikasi. Proksi utusan HTTP menggunakan pengepala khas, yang mana utusan memahami permintaan khusus kepada perkhidmatan yang menjana permintaan khusus kepada perkhidmatan lain. Senarai tajuk tersebut:

• x-request-id,
• x-b3-traceid,
• x-b3-sepanyol,
• x-b3-parentspanid,
• x-b3-sampel,
• x-b3-bendera,
• x-ot-span-context.

Jika anda mempunyai satu titik, sebagai contoh, pelanggan asas, di mana anda boleh menambah logik sedemikian, maka semuanya baik-baik saja, anda hanya perlu menunggu perpustakaan ini dikemas kini untuk semua pelanggan. Tetapi jika anda mempunyai sistem yang sangat heterogen dan tidak ada penyatuan dalam bergerak dari perkhidmatan ke perkhidmatan melalui rangkaian, maka ini kemungkinan besar akan menjadi masalah besar. Tanpa menambah logik sedemikian, semua maklumat pengesanan hanya akan menjadi "peringkat tunggal". Iaitu, kami akan menerima semua interaksi antara perkhidmatan, tetapi mereka tidak akan dilekatkan pada satu rantai laluan melalui rangkaian.

Kesimpulan

Istio menyediakan alat yang mudah untuk mengumpul maklumat pengesanan melalui rangkaian, tetapi anda mesti memahami bahawa untuk pelaksanaan anda perlu menyesuaikan sistem anda dan mengambil kira ciri-ciri pelaksanaan Istio. Akibatnya, dua perkara utama perlu diselesaikan: menentukan protokol peringkat aplikasi (yang mesti disokong oleh proksi utusan) dan menyediakan pemajuan maklumat mengenai sambungan permintaan kepada perkhidmatan daripada permintaan daripada perkhidmatan (menggunakan pengepala , dalam kes protokol HTTP). Apabila isu ini diselesaikan, kami mempunyai alat berkuasa yang membolehkan kami mengumpul maklumat secara telus daripada rangkaian, walaupun dalam sistem yang sangat heterogen yang ditulis dalam pelbagai bahasa dan rangka kerja yang berbeza.

Dalam artikel seterusnya tentang Service Mesh, kami akan melihat salah satu masalah terbesar dengan Istio - penggunaan RAM yang besar oleh setiap bekas proksi kereta sampingan dan membincangkan cara anda boleh menanganinya.

Sumber: www.habr.com