Catatan. terjemahan: Jejaring layanan telah menjadi topik hangat dalam infrastruktur saat ini untuk aplikasi yang mengikuti arsitektur layanan mikro. Meskipun Istio mungkin menarik perhatian banyak insinyur DevOps, ini adalah produk yang cukup baru, meskipun kompleks dalam hal fitur yang disediakannya, namun memerlukan banyak waktu untuk mengenalnya. Insinyur Jerman Rinor Maloku, yang bertanggung jawab atas komputasi awan untuk klien besar di perusahaan telekomunikasi Orange Networks, telah menulis serangkaian materi luar biasa yang memungkinkan Anda menyelami Istio dengan cepat dan mendalam. Dia memulai ceritanya dengan apa yang dapat dilakukan Istio dan bagaimana Anda dapat dengan cepat melihatnya dengan mata kepala sendiri.
Istio β Proyek Sumber Terbuka, dikembangkan bekerja sama dengan tim dari Google, IBM, dan Lyft. Ini memecahkan kompleksitas yang muncul dalam aplikasi berbasis layanan mikro, misalnya seperti:
- manajemen lalu lintas: batas waktu, percobaan ulang, penyeimbangan beban;
- keamanan: otentikasi dan otorisasi pengguna akhir;
- kemampuan observasi: penelusuran, pemantauan, pencatatan.
Semuanya bisa diselesaikan di level aplikasi, namun setelah itu layanan Anda tidak lagi bersifat "mikro". Segala upaya ekstra untuk mengatasi masalah ini merupakan pemborosan sumber daya perusahaan yang sebenarnya dapat digunakan secara langsung untuk nilai bisnis. Perhatikan sebuah contoh:
Manajer Proyek: Berapa lama waktu yang dibutuhkan untuk menambahkan fitur umpan balik?
Pengembang: Dua sprint.MP: Apa?.. Cuma CRUD!
R: Melakukan CRUD adalah bagian tugas yang mudah, namun kita masih perlu mengautentikasi dan mengotorisasi pengguna dan layanan. Karena jaringan tidak dapat diandalkan, Anda juga perlu menerapkan permintaan berulang pada klien. Juga, untuk memastikan bahwa seluruh sistem tidak crash, timeout dan (Untuk informasi lebih lanjut tentang kedua pola yang disebutkan, lihat artikel selanjutnya - kira-kira terjemahan), dan untuk mendeteksi masalah, memantau, menelusuri, [β¦]MP: Oh, kalau begitu, mari kita masukkan fitur ini ke dalam layanan Produk.
Saya pikir idenya jelas: jumlah langkah dan upaya yang diperlukan untuk menambahkan satu layanan sangatlah besar. Pada artikel ini, kita akan melihat bagaimana Istio menghilangkan semua kompleksitas yang disebutkan di atas (tidak ditargetkan oleh logika bisnis) dari layanan.
Catatan: Artikel ini mengasumsikan bahwa Anda memiliki pengetahuan tentang Kubernetes. Jika tidak, saya sarankan membaca dan baru kemudian melanjutkan membaca materi ini.
Ide istio
Di dunia tanpa Istio, satu layanan membuat permintaan langsung ke layanan lain, dan jika terjadi kegagalan, layanan harus menanganinya sendiri: melakukan upaya baru, memberikan waktu tunggu, membuka pemutus sirkuit, dll.
Lalu lintas jaringan di Kubernetes
Istio, di sisi lain, menawarkan solusi khusus yang sepenuhnya terpisah dari layanan dan fungsi dengan mengganggu interaksi jaringan. Dan dengan demikian ia mengimplementasikan:
- toleransi kesalahan: berdasarkan kode status dalam respons, ia memahami jika permintaan gagal dan mengirimkannya kembali.
- Peluncuran Canary: hanya mengalihkan persentase permintaan yang tetap ke versi layanan yang baru.
- Pemantauan dan Metrik: berapa lama waktu yang dibutuhkan hingga layanan merespons?
- Penelusuran dan observasi: Menambahkan header khusus ke setiap permintaan dan melacaknya di seluruh cluster.
- keamanan: Mengambil token JWT, mengautentikasi dan memberi otorisasi kepada pengguna.
Ini hanyalah beberapa kemungkinan (sebenarnya hanya beberapa!) yang membuat Anda penasaran. Sekarang mari selami detail teknisnya!
Arsitektur
Istio mencegat semua lalu lintas jaringan dan menerapkan serangkaian aturan padanya, memasukkan proxy cerdas dalam bentuk wadah sespan ke dalam setiap pod. Proxy yang mengaktifkan semua kemungkinan membentuk a Pesawat Data, dan dapat disesuaikan secara dinamis Kontrol Pesawat.
Pesawat Data
Proxy yang dimasukkan ke dalam pod memungkinkan Istio dengan mudah mencapai persyaratan yang kita butuhkan. Misalnya, mari kita periksa fungsi percobaan ulang dan pemutus sirkuit.
Bagaimana percobaan ulang dan pemutusan sirkuit diterapkan di Envoy
Untuk meringkas:
- Utusan (kita berbicara tentang proxy yang terletak di wadah sespan, yang didistribusikan dan bagaimana caranya - kira-kira. terjemahkan) mengirimkan permintaan ke instance pertama layanan B dan gagal.
- Utusan Sidecar mencoba lagi (mencoba kembali). (1)
- Permintaan yang gagal dikembalikan ke proksi yang memanggilnya.
- Ini membuka Pemutus Sirkuit dan memanggil layanan berikutnya untuk permintaan berikutnya. (2)
Ini berarti Anda tidak perlu menggunakan perpustakaan Retry berikutnya, Anda tidak perlu membuat implementasi Circuit Breaking dan Service Discovery Anda sendiri dalam bahasa pemrograman X, Y atau Z. Semua ini dan lebih banyak lagi tersedia dari kotak di Istio dan tidak memerlukan tidak perubahan kode.
Besar! Sekarang Anda mungkin ingin melakukan perjalanan dengan Istio, tetapi masih ada keraguan, pertanyaan terbuka. Jika ini adalah solusi universal untuk semua kesempatan dalam hidup, maka Anda memiliki kecurigaan yang sah: bagaimanapun juga, semua solusi tersebut sebenarnya tidak cocok untuk kasus apa pun.
Dan akhirnya Anda bertanya: βApakah ini dapat disesuaikan?β
Sekarang Anda siap untuk perjalanan laut - dan mari berkenalan dengan Control Plane.
Kontrol Pesawat
Ini terdiri dari tiga komponen: Pilot, Pengaduk ΠΈ Benteng, yang bersama-sama mengonfigurasi Utusan untuk merutekan lalu lintas, menerapkan kebijakan, dan mengumpulkan data telemetri. Secara skematis, semuanya terlihat seperti ini:
Interaksi Control Plane dengan Data Plane
Utusan (yaitu bidang data) dikonfigurasi dengan (Definisi Sumber Daya Kustom) yang ditentukan oleh Istio dan dirancang khusus untuk tujuan ini. Artinya bagi Anda adalah bahwa mereka hanyalah sumber daya lain di Kubernetes dengan sintaksis yang familier. Setelah dibuat, sumber daya ini akan diambil oleh bidang kendali dan diterapkan ke Utusan.
Hubungan layanan dengan Istio
Kami telah menjelaskan hubungan Istio dengan layanan, namun tidak sebaliknya: bagaimana hubungan layanan dengan Istio?
Jujur saja, pihak jasa mengetahui keberadaan Istio seperti halnya ikan mengetahui tentang air, ketika mereka bertanya pada diri sendiri: βApa itu air?β.
Ilustrasi : Bagaimana kamu menyukai air? - Apa sebenarnya air itu?
Dengan demikian, Anda dapat mengambil cluster yang berfungsi dan setelah menerapkan komponen Istio, layanan di dalamnya akan terus berfungsi, dan setelah menghapus komponen ini, semuanya akan baik-baik saja kembali. Jelas dalam hal ini Anda akan kehilangan peluang yang diberikan oleh Istio.
Cukup teorinya - mari kita praktikkan pengetahuan ini!
Istio dalam praktek
Istio memerlukan cluster Kubernetes dengan setidaknya 4 vCPU dan RAM 8 GB. Untuk meningkatkan cluster dengan cepat dan mengikuti petunjuk dari artikel, saya sarankan menggunakan Google Cloud Platform, yang menawarkan pengguna baru .
Setelah membuat cluster dan mengatur akses ke Kubernetes melalui utilitas konsol, Anda dapat menginstal Istio melalui manajer paket Helm.
Pemasangan Helm
Instal klien Helm di komputer Anda seperti yang dijelaskan di . Kami akan menggunakannya untuk menghasilkan template untuk menginstal Istio di bagian selanjutnya.
Instalasi
Unduh sumber daya Istio dari (tautan penulis asli ke versi 1.0.5 telah diubah ke versi sekarang, yaitu 1.0.6 - kira-kira terjemahan), ekstrak isinya ke satu direktori, yang akan saya sebut sebagai [istio-resources].
Untuk memudahkan identifikasi sumber daya Istio, buat namespace di kluster K8s istio-system:
$ kubectl create namespace istio-system
Selesaikan instalasi dengan menavigasi ke direktori [istio-resources] dan menjalankan 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 kunci Istio ke sebuah file istio.yaml. Kami telah memodifikasi template standar untuk diri kami sendiri dengan menentukan parameter berikut:
-
global.mtls.enableddipasang difalse(yaitu otentikasi mTLS dinonaktifkan - kira-kira terjemahan)untuk menyederhanakan proses kencan kami; -
tracing.enabledmengaktifkan penelusuran permintaan dengan Jaeger; -
kiali.enabledmenginstal Kiali ke dalam cluster untuk memvisualisasikan layanan dan lalu lintas; -
grafana.enabledmenginstal Grafana untuk memvisualisasikan metrik yang dikumpulkan.
Terapkan sumber daya yang dihasilkan dengan perintah:
$ kubectl apply -f istio.yaml
Instalasi Istio di cluster selesai! Tunggu hingga semua pod di namespace istio-system akan dapat Running ΠΈΠ»ΠΈ Completeddengan menjalankan perintah di bawah ini:
$ kubectl get pods -n istio-systemKami sekarang siap untuk melanjutkan ke bagian berikutnya, di mana kami akan menaikkan dan menjalankan aplikasi.
Arsitektur Aplikasi Analisis Sentimen
Mari kita gunakan contoh aplikasi layanan mikro Analisis Sentimen yang digunakan di atas . Ini cukup kompleks untuk menunjukkan kemungkinan Istio dalam praktiknya.
Aplikasi ini terdiri dari empat layanan mikro:
- Layanan SA-Depan, yang melayani aplikasi front-end di Reactjs;
- Layanan Aplikasi Web SA, yang melayani kueri Analisis Sentimen;
- Layanan Logika SAyang melakukan dirinya sendiri ;
- Layanan Umpan Balik SA, yang menerima umpan balik dari pengguna mengenai keakuratan analisis yang dilakukan.
Dalam diagram ini, selain layanan, kita juga melihat Ingress Controller, yang di Kubernetes merutekan permintaan masuk ke layanan terkait. Istio menggunakan konsep serupa sebagai bagian dari Ingress Gateway, rinciannya akan menyusul.
Meluncurkan aplikasi dengan proxy dari Istio
Untuk operasi lebih lanjut yang disebutkan dalam artikel, kloning repositori Anda . Ini berisi aplikasi dan manifes untuk Kubernetes dan Istio.
Memasukkan sespan
Penyisipan dapat dilakukan Π°Π²ΡΠΎΠΌΠ°ΡΠΈΡΠ΅ΡΠΊΠΈ ΠΈΠ»ΠΈ dengan tangan. Untuk menyisipkan kontainer sespan secara otomatis, Anda perlu menyetel label ke namespace istio-injection=enabled, yang dilakukan dengan perintah berikut:
$ kubectl label namespace default istio-injection=enabled
namespace/default labeled
Sekarang setiap pod yang akan di-deploy di namespace default (default) akan mendapatkan wadah sespannya. Untuk memverifikasi ini, mari terapkan aplikasi pengujian dengan masuk ke direktori root repositori [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 men-deploy layanan, periksa apakah pod masing-masing memiliki dua kontainer (dengan layanan itu sendiri dan sespannya) dengan menjalankan perintah kubectl get pods dan memastikannya di bawah kolom READY nilai yang ditentukan 2/2, melambangkan bahwa kedua container sedang 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 12mSecara visual terlihat seperti ini:
Proksi utusan di salah satu pod
Sekarang aplikasi sudah aktif dan berjalan, kita perlu mengizinkan lalu lintas masuk untuk masuk ke aplikasi.
Gerbang Masuk
Praktik terbaik untuk mencapai hal ini (mengizinkan lalu lintas di cluster) adalah melalui Gerbang Masuk di Istio, yang terletak di βtepiβ cluster dan memungkinkan Anda mengaktifkan fitur Istio seperti perutean, penyeimbangan beban, keamanan, dan pemantauan lalu lintas masuk.
Komponen Ingress Gateway dan layanan yang meneruskannya ke luar diinstal pada cluster selama instalasi Istio. Untuk mengetahui alamat IP eksternal suatu layanan, jalankan:
$ 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.120Kami akan terus mengakses aplikasi menggunakan IP ini (saya akan menyebutnya sebagai IP EKSTERNAL), jadi untuk kenyamanan, kami akan menulis nilainya ke 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 mendapatkan kesalahan Layanan Tidak Tersedia, karena secara default Istio memblokir semua lalu lintas masuksampai Gateway ditentukan.
Sumber daya gerbang
Gateway adalah CRD (Custom Resource Definition) di Kubernetes, yang ditentukan setelah menginstal Istio di sebuah cluster dan mengaktifkan kemampuan untuk menentukan port, protokol, dan host yang ingin kita izinkan lalu lintas masuknya.
Dalam kasus kami, kami ingin mengizinkan lalu lintas HTTP pada port 80 untuk semua host. Masalahnya diwujudkan dengan definisi berikut ():
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 pemilihnya istio: ingressgateway. Dengan pemilih ini, kita dapat menentukan Ingress Gateway mana yang akan diterapkan konfigurasinya. 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 createdGateway sekarang mengizinkan akses ke port 80 tetapi tidak tahu ke mana harus merutekan permintaan. Untuk ini, Anda perlu Layanan Virtual.
Sumber daya Layanan Virtual
VirtualService memberi tahu Ingress Gateway cara merutekan permintaan yang diizinkan dalam klaster.
Permintaan ke aplikasi kami yang datang melalui http-gateway harus dikirim ke layanan sa-frontend, sa-web-app, dan sa-feedback:
Rute yang akan dikonfigurasi dengan VirtualServices
Pertimbangkan permintaan yang harus dikirim ke SA-Frontend:
- Pencocokan persis di sepanjang jalan
/harus dikirim ke SA-Frontend untuk mendapatkan index.html; - Jalur dengan awalan
/static/*harus dikirim ke SA-Frontend untuk mendapatkan file statis yang digunakan di frontend, seperti CSS dan JavaScript; - Jalur yang cocok dengan ekspresi reguler
'^.*.(ico|png|jpg)$', harus dikirim ke SA-Frontend, karena Ini adalah gambar-gambar yang ditampilkan di halaman.
Implementasinya dicapai dengan konfigurasi berikut ():
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: 80poin penting:
- Layanan Virtual ini mengacu pada permintaan yang masuk http-gateway;
- Π
destinationmendefinisikan layanan ke mana permintaan dikirim.
Catatan: Konfigurasi di atas disimpan dalam sebuah file sa-virtualservice-external.yaml, yang juga berisi pengaturan untuk perutean ke SA-WebApp dan SA-Feedback, tetapi telah dipersingkat di artikel ini agar lebih singkat.
Terapkan Layanan Virtual dengan menelepon:
$ kubectl apply -f resource-manifests/istio/sa-virtualservice-external.yaml
virtualservice.networking.istio.io/sa-external-services createdCatatan: Saat kami menerapkan sumber daya Istio, Server API Kubernetes memicu peristiwa yang diterima oleh Bidang Kontrol Istio, dan setelah itu, konfigurasi baru diterapkan ke proksi Envoy setiap pod. Dan pengontrol Ingress Gateway tampaknya merupakan Utusan lain yang dikonfigurasi di Control Plane. Semua ini terlihat seperti ini pada diagram:
Konfigurasi Istio-IngressGateway untuk perutean permintaan
Analisis Sentimen kini tersedia di http://{EXTERNAL-IP}/. Jangan khawatir jika Anda mendapatkan status Tidak Ditemukan: terkadang diperlukan waktu lebih lama agar konfigurasi diterapkan dan cache Utusan diperbarui.
Sebelum melanjutkan, mainkan aplikasi sebentar untuk menghasilkan lalu lintas. (kehadirannya diperlukan untuk kejelasan dalam tindakan selanjutnya - kira-kira terjemahan).
Kiali: observabilitas
Untuk masuk ke antarmuka admin 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 terbuka dengan login sebagai admin/admin. Di sini Anda akan menemukan banyak fitur berguna, misalnya, untuk memeriksa konfigurasi komponen Istio, memvisualisasikan layanan dari informasi yang dikumpulkan dengan mencegat permintaan jaringan, mendapatkan jawaban atas pertanyaan βSiapa yang menghubungi siapa?β, βVersi layanan mana yang mengalami kegagalan?β dan seterusnya. Secara umum, jelajahi kemungkinan Kiali sebelum melanjutkan memvisualisasikan metrik dengan Grafana.
Grafana: visualisasi metrik
Metrik yang dikumpulkan di Istio berakhir di Prometheus dan divisualisasikan dengan Grafana. Untuk masuk ke antarmuka admin Grafana, jalankan perintah di bawah ini, lalu buka :
$ kubectl -n istio-system port-forward
$(kubectl -n istio-system get pod -l app=grafana
-o jsonpath={.items[0].metadata.name}) 3000Dengan mengklik menu Beranda kiri atas dan pilih Dasbor Layanan Istio di pojok kiri atas, mulai dengan servis sa-web-appuntuk melihat metrik yang dikumpulkan:
Di sini kita menunggu pertunjukan yang kosong dan benar-benar membosankan - manajemen tidak akan pernah menyetujuinya. Mari buat 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; doneSekarang kami memiliki grafik yang jauh lebih cantik, dan selain itu, alat luar biasa Prometheus untuk pemantauan dan Grafana untuk memvisualisasikan metrik, yang memungkinkan kami mempelajari tentang kinerja, status kesehatan, peningkatan/penurunan layanan dari waktu ke waktu.
Terakhir, mari kita lihat penelusuran permintaan dalam layanan.
Jaeger: menelusuri
Kita perlu melakukan penelusuran, karena semakin banyak layanan yang kita miliki, semakin sulit untuk mengetahui penyebab kegagalannya. Mari kita lihat kasus sederhana dari gambar di bawah ini:
Contoh umum dari permintaan acak yang gagal
Permintaan datang, jatuh - apa alasannya? Layanan pertama? Atau kedua? Ada pengecualian pada keduanya - mari kita lihat log masing-masing. Seberapa sering Anda mendapati diri Anda melakukan hal ini? Pekerjaan kami lebih seperti detektif perangkat lunak daripada pengembangβ¦
Ini adalah masalah yang tersebar luas di layanan mikro dan diselesaikan dengan sistem penelusuran terdistribusi, di mana layanan meneruskan header unik satu sama lain, setelah itu informasi ini dialihkan ke sistem penelusuran, untuk dibandingkan dengan data permintaan. Berikut ilustrasinya:
TraceId digunakan untuk mengidentifikasi permintaan
Istio menggunakan Jaeger Tracer, yang mengimplementasikan kerangka kerja OpenTracing API yang tidak bergantung pada 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}') 16686Sekarang pergi ke dan pilih layanan sa-web-app. Jika layanan tidak ditampilkan di menu tarik-turun, tampilkan/hasilkan aktivitas di halaman dan perbarui antarmuka. Setelah itu klik tombolnya Temukan jejak, yang akan menampilkan jejak terbaru - pilih salah satu - informasi terperinci tentang semua jejak akan muncul:
Jejak ini menunjukkan:
- Permintaan itu masuk istio-ingressgateway (ini adalah interaksi pertama dengan salah satu layanan, dan ID Jejak dibuat untuk permintaan tersebut), setelah itu gateway mengirimkan permintaan ke layanan sa-web-app.
- Dalam pelayanan sa-web-app permintaan diambil oleh sespan Utusan, "anak" dibuat dalam rentang tersebut (itulah sebabnya kita melihatnya di jejak) dan diarahkan ke wadah sa-web-app. ( - unit kerja logis di Jaeger, yang memiliki nama, waktu mulai operasi, dan durasinya. Rentang dapat disarangkan dan dipesan. Grafik bentang asiklik terarah membentuk jejak. - kira-kira. terjemahan.)
- Di sini permintaan diproses dengan metode analisis sentimen. Jejak ini sudah dihasilkan oleh aplikasi, mis. mereka memerlukan perubahan kode.
- Mulai saat ini, permintaan POST dimulai sa-logika. ID Jejak harus diteruskan dari sa-web-app.
- ...
Catatan: Pada langkah 4, aplikasi akan melihat header yang dihasilkan oleh Istio dan meneruskannya ke permintaan berikutnya, seperti yang ditunjukkan pada gambar di bawah:
(A) Penerusan header adalah tanggung jawab Istio; (B) Layanan bertanggung jawab atas header
Istio melakukan sebagian besar pekerjaan karena menghasilkan header untuk permintaan masuk, membuat span baru di setiap sidecare dan meneruskannya. Namun, tanpa bekerja dengan header di dalam layanan, jalur pelacakan permintaan secara lengkap akan hilang.
Header berikut harus diperhatikan (diteruskan):
x-request-id
x-b3-traceid
x-b3-spanid
x-b3-parentspanid
x-b3-sampled
x-b3-flags
x-ot-span-contextIni adalah tugas yang sederhana, tetapi untuk menyederhanakan implementasinya, sudah ada - misalnya, di layanan sa-web-app, klien RestTemplate meneruskan header ini jika Anda cukup menambahkan pustaka Jaeger dan OpenTracing ke .
Perhatikan bahwa aplikasi Analisis Sentimen mendemonstrasikan implementasi di Flask, Spring, dan ASP.NET Core.
Kini setelah jelas apa yang akan kita dapatkan (atau hampir keluar dari kotak), mari kita lihat penyempurnaan perutean, manajemen lalu lintas jaringan, keamanan, dan banyak lagi!
Catatan. terjemahan: baca tentang itu di bagian selanjutnya materi Istio dari Rinor Maloku, yang terjemahannya akan menyusul di blog kami dalam waktu dekat. UPDATE (14 Maret): sudah diterbitkan.
PS dari penerjemah
Baca juga di blog kami:
- "Kembali ke layanan mikro dengan Istio": , ;
- «»;
- «»;
- «»;
- Β«'.
Sumber: www.habr.com