Jalur lalu lintas mode longgar bekerja bersama resource routing kustom, seperti virtual services dan destination rules, untuk menyediakan ingress traffic end-to-end terpadu, routing detail halus, dan pemrosesan traffic berbasis plugin.
Pengenalan Fungsi
Jalur lalu lintas mode longgar memungkinkan Anda mengisolasi versi aplikasi. Traffic diarahkan ke jalur yang berbeda berdasarkan header permintaan pass-through dan header permintaan pemandu traffic. Ketika layanan dalam suatu jalur saling memanggil, jika layanan target tidak ada di jalur tersebut, traffic diteruskan ke jalur garis dasar. Pendekatan ini menjamin integritas tautan dan menyederhanakan manajemen traffic.
Sebelum menggunakan jalur lalu lintas mode longgar, pahami konsep-konsep berikut.
Metode untuk meneruskan konteks rantai panggilan
Meneruskan konteks rantai panggilan merupakan prasyarat untuk jalur lalu lintas mode longgar. Dalam satu rantai panggilan, semua permintaan harus memiliki header permintaan yang sama.
Jalur lalu lintas mode longgar mendukung metode umum untuk meneruskan konteks rantai panggilan. Pilih skenario yang sesuai dengan aplikasi Anda.
Skenario 1: Teruskan trace ID
Trace ID adalah header permintaan dengan fitur-fitur berikut:
-
Header permintaan diteruskan sepanjang seluruh rantai panggilan.
-
Header permintaan unik untuk setiap rantai panggilan.
Trace ID secara unik mengidentifikasi satu rantai panggilan lengkap. Nilainya biasanya berupa string acak. Jika aplikasi Anda terintegrasi dengan sistem tracing, kemungkinan besar sudah meneruskan trace ID. Standar tracing umum menggunakan header permintaan unik untuk trace ID, seperti x-b3-trace-id dan x-datadog-trace-id.
Skenario 2: Teruskan header permintaan kustom
Kode aplikasi Anda mungkin sudah meneruskan header permintaan yang memiliki makna bisnis, seperti version atau env. Header-header ini sering kali mengidentifikasi versi dan lingkungan rantai panggilan. Dalam skenario ini, Anda harus menggunakan header permintaan kustom tersebut sebagai header permintaan pemandu traffic.
Skenario 3: Teruskan header permintaan baggage
Baggage adalah mekanisme standar OpenTelemetry yang meneruskan informasi konteks lintas proses dalam rantai panggilan terdistribusi dengan menambahkan bidang Baggage ke Header HTTP. Nilai bidang tersebut berupa kumpulan pasangan kunci-nilai yang dapat membawa data konteks seperti ID penyewa, trace ID, dan kredensial keamanan, sehingga memungkinkan korelasi jejak dan log tanpa perubahan kode. Contohnya:
baggage: userId=alice,serverNode=DF%2028,isProduction=falseBaggage merupakan metode yang direkomendasikan untuk mengonfigurasi jalur lalu lintas mode longgar karena merupakan mekanisme standar OpenTelemetry untuk meneruskan konteks rantai panggilan.
Untuk Skenario 1 dan 3: Jika aplikasi Anda belum terintegrasi dengan sistem tracing atau tidak meneruskan baggage dalam kodenya, Anda dapat menggunakan automatic instrumentation. Anda dapat menggunakan OpenTelemetry Operator untuk menyuntikkan kemampuan automatic instrumentation ke dalam aplikasi Anda. Hal ini memungkinkan penerusan header permintaan trace ID tanpa mengubah kode aplikasi Anda. Untuk menyiapkan automatic instrumentation, ikuti langkah-langkah dalam dokumen komunitas. Anda harus menginstal OpenTelemetry Operator, mengonfigurasi automatic instrumentation, dan menambahkan anotasi ke Pod aplikasi Anda. Automatic instrumentation OpenTelemetry mendukung banyak standar umum untuk meneruskan konteks rantai panggilan terdistribusi, seperti W3C Baggage dan B3. Dokumen komunitas menyediakan contoh untuk meneruskan W3C TraceContext dan W3C Baggage. Untuk informasi lebih lanjut, lihat Automatic Instrumentation.
Header permintaan pemandu traffic
Jalur lalu lintas mode longgar menggunakan header permintaan pemandu traffic untuk memberi tag rantai permintaan. Anda dapat menentukan header permintaan apa pun yang tidak bentrok dengan header terkait bisnis yang sudah ada di aplikasi Anda. Berdasarkan metode penerusan konteks rantai panggilan yang Anda pilih, jalur lalu lintas mode longgar memastikan bahwa header permintaan pemandu traffic disertakan di setiap langkah rantai panggilan. Nilai header tersebut adalah nama jalur lalu lintas. Misalnya, jika Anda menentukan x-asm-prefer-tag sebagai header permintaan pemandu traffic, ketika permintaan dikirim ke layanan dalam jalur bernama s1, permintaan berikutnya dalam rantai panggilan selalu membawa header permintaan x-asm-prefer-tag: s1. Jalur lalu lintas menggunakan tag jalur dalam header permintaan untuk membuat lingkungan terisolasi bagi versi aplikasi yang berbeda.
Jika Anda memilih untuk meneruskan header permintaan kustom, Anda harus menggunakan header yang sama tersebut sebagai header permintaan pemandu traffic.
Ikhtisar skenario
Skenario berikut menunjukkan cara mengarahkan traffic ke jalur menggunakan tiga metode berbeda untuk meneruskan header permintaan, serta cara mengonfigurasi virtual service kustom untuk mengarahkan traffic ke jalur mode longgar.
Referensi
-
Jalur lalu lintas memiliki dua mode: Strict dan Loose. Untuk informasi lebih lanjut tentang mode dan perbedaannya, lihat Ikhtisar jalur lalu lintas.
-
Untuk menggunakan header yang sama baik untuk penerusan maupun pemandu traffic guna mengelola traffic end-to-end, lihat Skenario 2: Teruskan header permintaan kustom dalam rantai.
-
Anda dapat mengimplementasikan jalur lalu lintas menggunakan aturan traffic seperti VirtualService dan DestinationRule. Anda juga dapat mengonfigurasi fallback traffic. Jika aplikasi dengan versi atau fitur tertentu tidak tersedia, traffic dikirim ke versi fallback yang ditentukan. Untuk informasi lebih lanjut, lihat Implementasi jalur lalu lintas dan fallback traffic berdasarkan aturan traffic.
-
Aturan pemandu traffic untuk jalur lalu lintas mencakup aturan yang mencocokkan header permintaan dan URI permintaan. Untuk menerapkan aturan pencocokan yang lebih kompleks atau routing kustom, Anda dapat menggunakan virtual service kustom. Untuk detail konfigurasi, lihat Arahkan traffic ke jalur mode longgar menggunakan virtual service kustom.