Kembali ke layanan microser dengan Istio. Bagian 1



Catatan perev. : Sambungan layanan jelas menjadi solusi yang relevan dalam infrastruktur modern untuk aplikasi yang mengikuti arsitektur layanan mikro. Meskipun Istio mungkin didengar oleh banyak insinyur DevOps, itu adalah produk yang cukup baru, yang, karena komprehensif dalam hal fitur yang disediakan, mungkin memerlukan waktu yang cukup lama untuk saling mengenal satu sama lain. Insinyur Jerman Rinor Maloku, yang bertanggung jawab untuk komputasi awan untuk pelanggan besar di perusahaan telekomunikasi Orange Networks, telah menulis serangkaian materi yang luar biasa yang memungkinkan Anda untuk dengan cepat dan mendalam menyelami Istio. Dia memulai ceritanya dengan apa yang bisa dilakukan Istio dan bagaimana Anda bisa dengan cepat melihatnya dengan mata kepala sendiri.

Istio adalah proyek Open Source yang dikembangkan bersama dengan tim dari Google, IBM dan Lyft. Ini memecahkan kesulitan yang muncul dalam aplikasi berbasis pada layanan microser, misalnya, seperti:

  • Manajemen lalu lintas : timeout, retries, load balancing;
  • Keamanan : otentikasi dan otorisasi pengguna akhir;
  • Observabilitas : jejak, pemantauan, penebangan.

Semuanya dapat diselesaikan pada tingkat aplikasi, tetapi setelah itu layanan Anda akan berhenti menjadi "mikro". Semua upaya tambahan untuk memecahkan masalah ini adalah pemborosan sumber daya perusahaan yang dapat digunakan secara langsung untuk nilai-nilai bisnis. Pertimbangkan sebuah contoh:
Manajer Proyek: Berapa lama untuk menambahkan umpan balik?
Pengembang: Dua sprint.

MP: Apa? .. Itu hanya CRUD!
R: Membuat CRUD adalah bagian sederhana dari tugas, tetapi kita masih perlu mengautentikasi dan mengotorisasi pengguna dan layanan. Karena jaringan tidak dapat diandalkan, Anda perlu menerapkan permintaan berulang, serta pola pemutus sirkuit di klien. Namun, untuk memastikan bahwa keseluruhan sistem tidak jatuh, Anda akan membutuhkan batas waktu dan bulkhead (untuk rincian lebih lanjut tentang kedua pola yang disebutkan, lihat lebih lanjut dalam artikel - kira-kira. Terjemahan) , Dan untuk mendeteksi masalah, pemantauan, pelacakan, [...]

MP: Oh, kalau begitu mari kita masukkan fitur ini ke dalam Layanan produk.
Saya pikir idenya jelas: volume langkah dan upaya yang diperlukan untuk menambahkan satu layanan sangat besar. Pada artikel ini, kita akan melihat bagaimana Istio menghilangkan semua kesulitan yang disebutkan di atas (yang tidak ditargetkan untuk logika bisnis) dari layanan.



Catatan : Artikel ini mengasumsikan bahwa Anda memiliki pengetahuan praktis tentang Kubernet. Kalau tidak, saya sarankan membaca pengantar saya untuk Kubernetes dan hanya setelah itu lanjutkan membaca materi ini.

Ide Istio


Di dunia tanpa Istio, satu layanan membuat permintaan langsung ke yang lain, dan jika terjadi kegagalan, layanan harus memprosesnya sendiri: membuat upaya baru, memberikan batas waktu, membuka pemutus sirkuit, dll.


Lalu Lintas Jaringan di Kubernetes

Istio juga menawarkan solusi khusus, sepenuhnya terpisah dari layanan dan berfungsi dengan mengganggu interaksi jaringan. Dan itu mengimplementasikan:

  • Toleransi kesalahan : Berdasarkan kode status dalam respons, ia memahami apakah permintaan gagal, dan menjalankannya lagi.
  • Peluncuran Canary : pengalihan ke versi baru dari layanan hanya persentase tetap dari jumlah permintaan.
  • Pemantauan dan metrik : berapa lama layanan merespons?
  • Penelusuran dan Pengamatan : Menambahkan tajuk khusus untuk setiap permintaan dan melacaknya di gugus.
  • Keamanan : mengekstrak token JWT, mengautentikasi, dan mengotorisasi pengguna.

Ini hanya beberapa kemungkinan (benar-benar hanya beberapa!) Untuk membuat Anda penasaran. Sekarang mari selami rincian teknisnya!

Arsitektur Istio


Istio memotong semua lalu lintas jaringan dan menerapkan seperangkat aturan untuk itu, memasukkan proxy cerdas ke setiap pod dalam bentuk wadah sespan. Proxy yang mengaktifkan semua fitur membentuk Data Plane , dan mereka dapat dikonfigurasi secara dinamis menggunakan Control Plane .

Pesawat data


Proxy yang dimasukkan ke dalam pod memungkinkan Istio dengan mudah memenuhi persyaratan yang kami butuhkan. Misalnya, periksa fungsi coba lagi dan pemutus sirkuit.


Bagaimana retries dan circuit break diimplementasikan dalam Utusan

Untuk meringkas:

  1. Utusan (berbicara tentang proxy dalam wadah sespan yang didistribusikan sebagai produk terpisah - kira-kira. Terjemahan). Mengirim permintaan ke instance pertama layanan B dan terjadi kegagalan.
  2. Utusan Sidecar mencoba lagi . (1)
  3. Permintaan yang gagal dikembalikan ke proksi yang memanggilnya.
  4. Ini membuka Circuit Breaker dan memanggil layanan berikutnya untuk permintaan berikutnya. (2)

Ini berarti bahwa Anda tidak perlu menggunakan pustaka Coba lagi berikutnya, Anda tidak harus melakukan implementasi Circuit Breaking dan Service Discovery Anda sendiri dalam bahasa pemrograman X, Y atau Z. Semua ini dan banyak lagi tersedia di luar kotak di Istio dan tidak memerlukan perubahan pada kode.

Hebat! Sekarang Anda mungkin ingin melakukan perjalanan dengan Istio, tetapi masih ada beberapa keraguan, pertanyaan terbuka. Jika ini adalah solusi universal untuk semua kesempatan dalam hidup, maka Anda memiliki kecurigaan yang sah: setelah semua, semua keputusan seperti itu pada kenyataannya ternyata tidak cocok untuk setiap kesempatan.

Dan akhirnya, Anda bertanya: "Apakah bisa disesuaikan?"

Sekarang Anda siap untuk pelayaran laut - dan mari kita berkenalan dengan Control Plane.

Kontrol pesawat


Ini terdiri dari tiga komponen: Pilot , Mixer, dan Citadel , yang bekerja bersama untuk mengkonfigurasi Utusan untuk merutekan lalu lintas, menerapkan kebijakan, dan mengumpulkan data telemetri. Secara skematis, semuanya terlihat seperti ini:


Kontrol Interaksi Pesawat dengan Pesawat Data

Utusan (yaitu pesawat data) dikonfigurasikan menggunakan Kubernetes CRD (Custom Resource Definition) yang didefinisikan oleh Istio dan dirancang khusus untuk tujuan ini. Bagi Anda, ini berarti bahwa mereka tampaknya menjadi sumber daya berikutnya di Kubernetes dengan sintaksis yang akrab. Setelah dibuat, sumber ini akan diambil oleh pesawat kontrol dan diterapkan ke Utusan.

Rasio layanan untuk Istio


Kami menggambarkan sikap Istio terhadap layanan, tetapi tidak sebaliknya: bagaimana hubungan layanan dengan Istio?

Jujur, Istio tahu tentang keberadaan layanan serta ikan - tentang air, ketika mereka bertanya pada diri sendiri: "Apa itu air pada umumnya?".


Ilustrasi oleh Victoria Dimitrakopoulos : - Bagaimana Anda menyukai air? - Apa itu air pada umumnya?

Dengan demikian, Anda dapat mengambil cluster kerja dan setelah penyebaran komponen Istio, layanan yang berada di dalamnya akan terus bekerja, dan setelah penghapusan komponen ini, semuanya akan baik-baik saja. Jelas bahwa dengan melakukan itu Anda akan kehilangan peluang yang disediakan oleh Istio.

Teori yang cukup - mari kita praktikkan ini!

Istio dalam latihan


Istio membutuhkan kluster Kubernetes di mana setidaknya 4 vCPU dan 8 GB RAM tersedia. Untuk meningkatkan cluster dengan cepat dan mengikuti instruksi dari artikel, saya sarankan menggunakan Google Cloud Platform, yang menawarkan pengguna baru gratis $ 300 .

Setelah Anda membuat sebuah cluster dan mengkonfigurasi akses ke Kubernetes melalui utilitas konsol, Anda dapat menginstal Istio melalui manajer paket Helm.

Pemasangan Helm


Instal klien Helm di komputer Anda, seperti yang mereka katakan dalam dokumentasi resmi . Kami akan menggunakannya untuk membuat templat untuk menginstal Istio di bagian selanjutnya.

Instal Istio


Unduh sumber daya Istio dari rilis terbaru (tautan penulis asli ke versi 1.0.5 diubah ke yang sekarang, yaitu 1.0.6 - kira-kira diterjemahkan.) , Ekstrak konten ke dalam satu direktori, yang akan saya panggil di masa depan [istio-resources] .

Untuk memudahkan mengidentifikasi sumber daya Istio, buat namespace istio-system -istio di kluster K8s:

 $ kubectl create namespace istio-system 

Selesaikan penginstalan dengan masuk ke [istio-resources] dan jalankan perintah:

 $ helm template install/kubernetes/helm/istio \ --set global.mtls.enabled=false \ --set tracing.enabled=true \ --set kiali.enabled=true \ --set grafana.enabled=true \ --namespace istio-system > istio.yaml 

Perintah ini akan menampilkan komponen utama Istio ke file istio.yaml . Kami mengubah templat standar untuk diri kami sendiri, menetapkan parameter berikut:

  • global.mtls.enabled disetel ke false (mis. otentikasi mTLS dinonaktifkan - sekitar terjemahan) untuk menyederhanakan proses kencan kami;
  • tracing.enabled memungkinkan penelusuran kueri menggunakan Jaeger;
  • kiali.enabled menginstal Kiali di cluster untuk memvisualisasikan layanan dan lalu lintas;
  • grafana.enabled mengatur Grafana untuk memvisualisasikan metrik yang dikumpulkan.

Kami menerapkan sumber daya yang dihasilkan dengan perintah:

 $ kubectl apply -f istio.yaml 

Menginstal Istio di cluster sudah selesai! Tunggu hingga semua pod di namespace istio-system Running atau Completed dengan menjalankan perintah di bawah ini:

 $ kubectl get pods -n istio-system 

Sekarang kita siap untuk melanjutkan di bagian selanjutnya, di mana kita akan meningkatkan dan meluncurkan aplikasi.

Arsitektur Aplikasi Sentimen Analisis


Mari kita ambil contoh aplikasi microservice Sentiment Analysis yang digunakan dalam artikel pengantar yang telah disebutkan di Kubernetes . Itu cukup canggih untuk menunjukkan kemampuan Istio dalam praktek.

Aplikasi ini terdiri dari empat layanan microser:

  1. Service SA-Frontend , yang melayani aplikasi front-end di Reactjs;
  2. Layanan SA-WebApp yang melayani permintaan Analisis Sentimen;
  3. Layanan SA-Logika , yang melakukan analisis sentimental ;
  4. Layanan SA-Umpan Balik , yang menerima umpan balik dari pengguna tentang keakuratan analisis.



Dalam diagram ini, selain layanan, kami juga melihat Ingress Controller, yang di Kubernetes merutekan permintaan masuk ke layanan yang sesuai. Istio menggunakan konsep serupa di dalam Gateway Ingress, yang detailnya akan mengikuti.

Meluncurkan aplikasi dengan proxy dari Istio


Untuk operasi lebih lanjut yang disebutkan dalam artikel, kloning repositori istio-mastery . Ini berisi aplikasi dan manifes untuk Kubernetes dan Istio.

Masukkan sespan


Penyisipan dapat dilakukan secara otomatis atau manual . Untuk secara otomatis memasukkan wadah sespan, Anda perlu mengatur istio-injection=enabled ke istio-injection=enabled , yang dilakukan dengan perintah berikut:

 $ kubectl label namespace default istio-injection=enabled namespace/default labeled 

Sekarang setiap pod yang akan digunakan dalam namespace default akan menerima wadah sespannya. Untuk memverifikasi ini, mari kita instal aplikasi uji dengan pergi ke direktori root dari [istio-mastery] dan menjalankan perintah berikut:

 $ kubectl apply -f resource-manifests/kube persistentvolumeclaim/sqlite-pvc created deployment.extensions/sa-feedback created service/sa-feedback created deployment.extensions/sa-frontend created service/sa-frontend created deployment.extensions/sa-logic created service/sa-logic created deployment.extensions/sa-web-app created service/sa-web-app created 

Setelah memperluas layanan, kami akan memverifikasi bahwa pod memiliki dua kontainer (dengan layanan itu sendiri dan sespannya), dengan mengeksekusi perintah kubectl get pods dan memastikan bahwa nilai 2/2 ditunjukkan di bawah kolom READY , melambangkan bahwa kedua kontainer berjalan:

 $ kubectl get pods NAME READY STATUS RESTARTS AGE sa-feedback-55f5dc4d9c-c9wfv 2/2 Running 0 12m sa-frontend-558f8986-hhkj9 2/2 Running 0 12m sa-logic-568498cb4d-2sjwj 2/2 Running 0 12m sa-logic-568498cb4d-p4f8c 2/2 Running 0 12m sa-web-app-599cf47c7c-s7cvd 2/2 Running 0 12m 

Secara visual terlihat seperti ini:


Utusan proksi di salah satu pod

Sekarang aplikasi sudah berjalan dan berjalan, kita perlu mengizinkan lalu lintas masuk ke aplikasi.

Ingress gateway


Praktik terbaik untuk mencapai ini (untuk memungkinkan lalu lintas di cluster) adalah melalui Ingress Gateway di Istio, yang terletak di "perbatasan" cluster dan memungkinkan Anda untuk mengaktifkan fitur Istio seperti perutean, penyeimbangan beban, keamanan, dan pemantauan untuk lalu lintas yang masuk.

Komponen Gateway Ingress dan layanan yang meneruskannya di luar diinstal ke dalam cluster selama instalasi Istio. Untuk mengetahui alamat IP eksternal suatu layanan, lakukan:

 $ kubectl get svc -n istio-system -l istio=ingressgateway NAME TYPE CLUSTER-IP EXTERNAL-IP istio-ingressgateway LoadBalancer 10.0.132.127 13.93.30.120 

Kami akan terus mengakses aplikasi melalui IP ini (saya akan menyebutnya sebagai EKSTERNAL-IP), jadi untuk kenyamanan kami akan menulis nilai ke dalam variabel:

 $ EXTERNAL_IP=$(kubectl get svc -n istio-system \ -l app=istio-ingressgateway \ -o jsonpath='{.items[0].status.loadBalancer.ingress[0].ip}') 

Jika Anda mencoba mengakses IP ini melalui browser sekarang, Anda akan menerima kesalahan Layanan Tidak Tersedia, karena Secara default, Istio memblokir semua lalu lintas masuk sampai Gateway ditentukan.

Sumber Daya Gateway


Gateway adalah CRD (Custom Resource Definition) di Kubernetes, didefinisikan setelah menginstal Istio dalam sebuah cluster dan mengaktifkan kemampuan untuk menentukan port, protokol, dan host yang kami inginkan untuk mengizinkan lalu lintas masuk.

Dalam kasus kami, kami ingin mengizinkan lalu lintas HTTP ke port 80 untuk semua host. Tugas diimplementasikan oleh definisi berikut ( http-gateway.yaml ) :

 apiVersion: networking.istio.io/v1alpha3 kind: Gateway metadata: name: http-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: - "*" 

Konfigurasi ini tidak memerlukan penjelasan kecuali untuk istio: ingressgateway . Dengan pemilih ini, kami dapat menunjukkan ke Ingress Gateway mana konfigurasi diterapkan. Dalam kasus kami, ini adalah pengontrol Ingress Gateway, yang diinstal secara default di Istio.

Konfigurasi diterapkan dengan memanggil perintah berikut:

 $ kubectl apply -f resource-manifests/istio/http-gateway.yaml gateway.networking.istio.io/http-gateway created 

Sekarang gateway memungkinkan akses ke port 80, tetapi tidak tahu ke mana harus merutekan permintaan. Ini akan membutuhkan Layanan Virtual .

Sumber Daya Layanan Virtual


VirtualService memberi tahu Ingress Gateway cara merutekan permintaan yang diizinkan di dalam kluster.

Permintaan ke aplikasi kami yang datang melalui http-gateway harus dikirim ke layanan sa-frontend, sa-web-app dan sa-umpan balik:


Rute untuk Mengkonfigurasi dengan VirtualServices

Pertimbangkan permintaan yang harus dikirim ke SA-Frontend:

  • Pencocokan persis pada jalur / harus dikirim ke SA-Frontend untuk mendapatkan index.html;
  • Path yang diawali dengan /static/* harus dikirim ke SA-Frontend untuk menerima file statis yang digunakan di frontend, seperti CSS dan JavaScript;
  • Jalur yang termasuk dalam ekspresi reguler '^.*\.(ico|png|jpg)$' harus dikirim ke SA-Frontend, karena Ini adalah gambar yang ditampilkan pada halaman.

Implementasi dicapai dengan konfigurasi berikut ( sa-virtualservice-external.yaml ):

 kind: VirtualService metadata: name: sa-external-services spec: hosts: - "*" gateways: - http-gateway # 1 http: - match: - uri: exact: / - uri: exact: /callback - uri: prefix: /static - uri: regex: '^.*\.(ico|png|jpg)$' route: - destination: host: sa-frontend # 2 port: number: 80 

Poin-poin penting:

  1. Layanan Virtual ini mengacu pada permintaan yang datang melalui http-gateway ;
  2. destination menentukan layanan tempat permintaan dikirimkan.

Catatan : Konfigurasi di atas disimpan dalam file sa-virtualservice-external.yaml , yang juga berisi pengaturan untuk perutean di SA-WebApp dan SA-Umpan Balik, tetapi disingkat di sini dalam artikel untuk singkatnya.

Terapkan VirtualService dengan menelepon:

 $ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml virtualservice.networking.istio.io/sa-external-services created 

Catatan : Saat kami menggunakan sumber daya Istio, Server API Kubernetes memunculkan peristiwa yang menerima Pesawat Kontrol Istio, dan setelah itu konfigurasi baru diterapkan ke proksi Utusan masing-masing pod. Dan kontroler Gateway Ingress tampaknya Utusan berikutnya yang dikonfigurasi di Control Plane. Semua ini pada diagram terlihat seperti ini:


Konfigurasi Istio-IngressGateway untuk perutean kueri

Analisis Sentimen telah tersedia di http://{EXTERNAL-IP}/ . Jangan khawatir jika Anda mendapatkan status Tidak Ditemukan: kadang-kadang butuh sedikit lebih lama untuk konfigurasi untuk berlaku dan Utusan cache untuk diperbarui .

Sebelum melanjutkan, bekerjalah sedikit dengan aplikasi untuk menghasilkan lalu lintas (keberadaannya diperlukan untuk kejelasan dalam langkah selanjutnya - kira-kira. Terjemahan.) .

Kiali: Observabilitas


Untuk sampai ke antarmuka administrasi Kiali, jalankan perintah berikut:

 $ kubectl port-forward \ $(kubectl get pod -n istio-system -l app=kiali \ -o jsonpath='{.items[0].metadata.name}') \ -n istio-system 20001 

... dan buka http: // localhost: 20001 / , masuk sebagai admin / admin. Di sini Anda akan menemukan banyak fitur yang berguna, misalnya, untuk memeriksa konfigurasi komponen Istio, memvisualisasikan layanan berdasarkan informasi yang dikumpulkan saat mencegat permintaan jaringan, menerima jawaban atas pertanyaan "Siapa yang menghubungi siapa?", "Versi layanan mana yang lumpuh?" dll. Secara umum, jelajahi kemungkinan Kiali sebelum beralih ke memvisualisasikan metrik dengan Grafana.



Grafana: visualisasi metrik


Metrik yang dikumpulkan di Istio masuk ke Prometheus dan divisualisasikan dengan Grafana. Untuk masuk ke antarmuka admin Grafana, jalankan perintah di bawah ini, lalu buka http: // localhost: 3000 / :

 $ kubectl -n istio-system port-forward \ $(kubectl -n istio-system get pod -l app=grafana \ -o jsonpath={.items[0].metadata.name}) 3000 

Dengan mengklik menu Beranda di kiri atas dan memilih Dasbor Layanan Istio di sudut kiri atas, mulailah dengan layanan aplikasi-sa-web untuk melihat metrik yang dikumpulkan:



Di sini kami menunggu kinerja yang kosong dan benar-benar membosankan - manajemen tidak akan pernah menyetujui ini. Mari kita membuat beban kecil dengan perintah berikut:

 $ while true; do \ curl -i http://$EXTERNAL_IP/sentiment \ -H "Content-type: application/json" \ -d '{"sentence": "I love yogobella"}'; \ sleep .8; done 

Sekarang kami memiliki grafik yang jauh lebih bagus, dan selain itu, alat Prometheus yang luar biasa untuk pemantauan dan Grafana untuk memvisualisasikan metrik, yang akan memungkinkan kami untuk belajar tentang kinerja, status kesehatan, peningkatan / penurunan layanan dari waktu ke waktu.

Akhirnya, mari kita lihat jejak permintaan dalam layanan.

Jaeger: jejak


Kita perlu melacak, karena semakin banyak layanan yang kita miliki, semakin sulit untuk sampai pada penyebab kegagalan. Mari kita lihat contoh sederhana dari gambar di bawah ini:


Contoh khas permintaan gagal acak

Permintaan datang, jatuh - apa alasannya? Layanan pertama? Atau yang kedua? Ada pengecualian di keduanya - mari kita lihat log masing-masing. Seberapa sering Anda menemukan diri Anda melakukan ini? Pekerjaan kami lebih seperti detektif perangkat lunak daripada pengembang ...

Ini adalah masalah yang tersebar luas di layanan microser dan diselesaikan dengan sistem jejak terdistribusi di mana layanan saling melewati header yang unik, setelah itu informasi ini dialihkan ke sistem jejak, di mana ia dipetakan ke data permintaan. Berikut ini ilustrasi:


TraceId digunakan untuk mengidentifikasi permintaan.

Istio menggunakan Jaeger Tracer, yang mengimplementasikan kerangka kerja OpenTracing API yang independen-vendor. Anda dapat mengakses antarmuka pengguna Jaeger dengan perintah berikut:

 $ kubectl port-forward -n istio-system \ $(kubectl get pod -n istio-system -l app=jaeger \ -o jsonpath='{.items[0].metadata.name}') 16686 

Sekarang buka http: // localhost: 16686 / dan pilih layanan sa-web-app . Jika layanan tidak ditampilkan dalam menu tarik-turun, tampilkan / hasilkan aktivitas pada halaman dan perbarui antarmuka. Setelah itu, klik tombol Cari Jejak , yang akan menampilkan jejak terbaru - pilih apa saja - informasi terperinci tentang semua jejak akan muncul:



Jejak ini menunjukkan:

  1. Permintaan datang ke istio-ingressgateway (ini adalah interaksi pertama dengan salah satu layanan, dan ID Jejak dihasilkan untuk permintaan), setelah itu gateway mengirimkan permintaan ke layanan aplikasi-sa-web .
  2. Dalam layanan sa-web-app, permintaan dijemput oleh sespan Utusan, "anak" dibuat dalam rentang (oleh karena itu kita melihatnya di jejak) dan dialihkan ke wadah sa-web-app . ( Rentang adalah unit kerja logis di Jaeger yang memiliki nama, waktu operasi dimulai dan durasinya. Rentang dapat disarangkan dan dipesan. Grafik asiklik yang diarahkan dari bentang membentuk jejak. - sekitar Terjemahan.)
  3. Di sini, permintaan diproses oleh metode sentimentAnalysis . Jejak-jejak ini sudah dihasilkan oleh aplikasi, mis. mereka membutuhkan perubahan pada kode.
  4. Dari saat ini, permintaan POST untuk s-logika dimulai. Trace ID harus diteruskan dari sa-web-app .
  5. ...

Catatan : Pada langkah 4, aplikasi akan melihat header yang dihasilkan oleh Istio dan meneruskannya ke permintaan berikutnya, seperti yang ditunjukkan pada gambar di bawah ini:


(A) Istio bertanggung jawab untuk meneruskan header; (B) Layanan bertanggung jawab atas tajuk.

Istio melakukan sebagian besar pekerjaan, seperti menghasilkan tajuk untuk permintaan masuk, membuat bentang baru di setiap sespan dan meneruskannya. Namun, tanpa bekerja dengan header di dalam layanan, jalur jejak penuh permintaan akan hilang.

Judul berikut harus dipertimbangkan (diteruskan):

 x-request-id x-b3-traceid x-b3-spanid x-b3-parentspanid x-b3-sampled x-b3-flags x-ot-span-context 

Ini adalah tugas sederhana, namun, untuk menyederhanakan implementasinya, banyak perpustakaan sudah ada - misalnya, dalam layanan sa-web-app, klien RestTemplate meneruskan tajuk ini jika Anda hanya menambahkan pustaka Jaeger dan OpenTracing tergantung padanya .

Perhatikan bahwa aplikasi Analisis Sentimen menunjukkan implementasi pada Flask, Spring, dan ASP.NET Core.

Sekarang sudah menjadi jelas apa yang kita dapatkan di luar kotak (atau hampir "di luar kotak"), pertimbangkan masalah perutean yang diatur secara halus, manajemen lalu lintas jaringan, keamanan, dll!

Catatan perev. : Baca tentang ini dalam angsuran Rinor Maloku Istio berikutnya, yang akan tersedia di blog kami dalam waktu dekat. PEMBARUAN (14 Maret): Bagian kedua telah diterbitkan.

PS dari penerjemah


Baca juga di blog kami:

Source: https://habr.com/ru/post/id438426/


All Articles