Mengonfigurasi pengelolaan traffic lanjutan dengan Envoy
Konfigurasi ini didukung untuk pelanggan Pratinjau, tetapi kami tidak merekomendasikannya untuk pengguna Cloud Service Mesh baru. Untuk mengetahui informasi selengkapnya, lihat ringkasan perutean layanan Cloud Service Mesh.
Dokumen ini memberikan informasi tentang cara mengonfigurasi pengelolaan traffic lanjutan untuk deployment Cloud Service Mesh yang menggunakan Envoy.
Sebelum memulai
Sebelum mengonfigurasi pengelolaan traffic lanjutan, ikuti petunjuk di bagian Persiapan untuk menyiapkan Cloud Service Mesh dengan Envoy, termasuk mengonfigurasi Cloud Service Mesh dan host virtual machine (VM) apa pun atau cluster Google Kubernetes Engine (GKE) yang Anda perlukan. Buat resource Google Cloud yang diperlukan.
Ketersediaan fitur pengelolaan traffic lanjutan berbeda-beda tergantung protokol permintaan yang Anda pilih. Protokol ini dikonfigurasi saat Anda mengonfigurasi perutean menggunakan proxy HTTP atau HTTPS target, proxy gRPC target, atau resource proxy TCP target:
- Dengan proxy HTTP target dan proxy HTTPS target, semua fitur yang dijelaskan dalam dokumen ini tersedia.
- Dengan proxy gRPC target, beberapa fitur tersedia.
- Dengan proxy TCP target, fitur pengelolaan traffic lanjutan tidak tersedia.
Untuk mengetahui informasi selengkapnya, lihat fitur Cloud Service Mesh dan Pengelolaan traffic lanjutan. Untuk panduan penyiapan menyeluruh, lihat Mengonfigurasi pengelolaan traffic lanjutan dengan layanan gRPC tanpa proxy.
Siapkan pembagian traffic
Petunjuk ini mengasumsikan hal berikut:
- Deployment Cloud Service Mesh Anda memiliki peta URL yang disebut
review-url-map
. - Peta URL mengirimkan semua traffic ke satu layanan backend yang disebut
review1
, yang berfungsi sebagai layanan backend default. - Anda berencana untuk merutekan 5% traffic ke versi layanan yang baru. Layanan tersebut
berjalan pada VM backend atau endpoint dalam grup endpoint jaringan (NEG)
yang dikaitkan dengan layanan backend
review2
. - Tidak ada aturan host atau pencocok jalur yang digunakan.
Jika Anda membagi traffic ke layanan baru yang belum direferensikan oleh peta URL sebelumnya, tambahkan layanan baru ke weightedBackendServices
terlebih dahulu dan beri bobot 0
. Kemudian, secara bertahap tingkatkan bobot yang ditetapkan ke
layanan tersebut.
Untuk menyiapkan pemisahan traffic, ikuti langkah-langkah berikut:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik Peta aturan pemilihan rute.
Klik
Buat peta aturan pemilihan rute.Di halaman Create a routing rule map, masukkan Name.
Di menu Protocol, pilih HTTP.
Pilih aturan penerusan yang ada.
Di bagian Aturan pemilihan rute, pilih Host, jalur, dan aturan rute lanjutan.
Di bagian Hosts and path matcher, klik
Add hosts and path matcher. Tindakan ini akan menambahkan pencocok jalur baru yang dapat Anda konfigurasi untuk memisahkan traffic.Tambahkan setelan berikut ke kolom Pencocok jalur:
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
Klik Done.
Klik Simpan.
Setelah puas dengan versi yang baru, Anda dapat menyesuaikan bobot kedua layanan tersebut secara bertahap dan pada akhirnya mengirim semua traffic ke review2
.
gcloud
Jalankan perintah
gcloud export
untuk mendapatkan konfigurasi peta URL:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
Tambahkan bagian berikut ke file
review-url-map-config.yaml
:hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - priority: 2 matchRules: - prefixMatch: '' routeAction: weightedBackendServices: - backendService: global/backendServices/review1 weight: 95 - backendService: global/backendServices/review2 weight: 5
Perbarui peta URL:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Setelah puas dengan versi yang baru, Anda dapat menyesuaikan bobot kedua layanan tersebut secara bertahap dan pada akhirnya mengirim semua traffic ke review2
.
Menyiapkan rilis sebagian
Gunakan proses deployment parsial, yang terkadang disebut canarying, untuk merilis versi software baru ke sebagian kecil server sebelum Anda merilis versi baru sampai seimbang di server produksi Anda.
Rilis parsial menggunakan weightedBackendServices
. Untuk mengaktifkan rilis parsial,
tetapkan layanan backend sebagai layanan pengujian, atau canary, dan berikan bobot rendah,
misalnya 2 atau 5. Deploy versi software baru Anda ke server tersebut saja. Setelah Anda puas dengan versi baru ini yang telah terbebas dari masalah, deploy versi tersebut ke seluruh layanan Anda.
- Untuk mengaktifkan rilis parsial, gunakan contoh kode YAML berikut:
pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_PARTIAL_URL weight: 2 - backendService: BACKEND_SERVICE_URL weight: 98
DEFAULT_SERVICE_URL
adalah URL default untuk layanan Anda.BACKEND_SERVICE_PARTIAL_URL
adalah URL untuk layanan backend yang menerima 2% traffic.BACKEND_SERVICE_URL
adalah URL untuk layanan backend yang menerima 98% traffic.
Menyiapkan blue-green deployment
Blue-green deployment adalah model rilis yang mengurangi waktu yang diperlukan untuk mengalihkan traffic produksi ke rilis layanan yang baru, atau ke rollback rilis layanan sebelumnya. Deployment ini mempertahankan kedua versi layanan yang tersedia dalam lingkungan production dan mengalihkan traffic dari satu ke versi lainnya.
Blue-green deployment menggunakan weightedBackendServices
. Dalam contoh YAML
berikutnya, backend ke SERVICE_BLUE_URL
di-deploy sepenuhnya dengan rilis
produksi saat ini dan backend ke SERVICE_GREEN_URL
di-deploy sepenuhnya
dengan rilis baru. Dalam konfigurasi dalam contoh, deployment GREEN
menerima 100% traffic produksi. Jika menemukan masalah, Anda dapat membalikkan bobot untuk kedua deployment tersebut, yang akan secara efektif mengembalikan rilis GREEN
yang rusak dan mengaktifkan kembali rilis BLUE
yang terkenal bagus. Dalam kedua kasus tersebut, traffic dapat dialihkan dengan cepat karena kedua versi tersedia untuk menerima traffic.
- Untuk mengaktifkan blue-green deployment, gunakan contoh kode YAML berikut:
pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_BLUE_URL weight: 0 - backendService: BACKEND_SERVICE_GREEN_URL weight: 100
DEFAULT_SERVICE_URL
adalah URL default untuk layanan Anda.BACKEND_SERVICE_BLUE_URL
adalah URL untuk layanan backend yang tidak menerima traffic Anda.BACKEND_SERVICE_GREEN_URL
adalah URL untuk layanan backend yang menerima 100% traffic Anda.
Menyiapkan pencerminan traffic
Gunakan pencerminan traffic jika Anda ingin traffic diarahkan ke dua layanan backend yang berbeda untuk tujuan proses debug atau pengujian layanan baru.
Pada contoh berikut, semua permintaan dikirim ke SERVICE_URL
dan ke
MIRROR_SERVICE_URL
. Hanya respons dari SERVICE_URL
yang dikirim kembali ke
klien. MIRROR_SERVICE_URL
tidak memiliki dampak kepada klien.
Untuk menyiapkan pencerminan traffic, ikuti langkah-langkah berikut:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik Peta aturan pemilihan rute.
Klik
Buat peta aturan pemilihan rute.Di halaman Create a routing rule map, masukkan Name.
Dalam daftar Protocol, pilih HTTP.
Pilih aturan penerusan yang ada.
Di bagian Aturan pemilihan rute, pilih Host, jalur, dan aturan rute lanjutan.
Di bagian Hosts and path matcher, klik
Add hosts and path matcher. Tindakan ini akan menambahkan pencocok jalur baru yang dapat Anda konfigurasi untuk mencerminkan traffic.Tambahkan setelan berikut ke kolom Pencocok jalur:
- defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URL
DEFAULT_SERVICE_URL
adalah URL default untuk layanan Anda.BACKEND_SERVICE_URL
adalah URL untuk backend yang dicerminkan.BACKEND_SERVICE_MIRROR_URL
adalah URL untuk layanan backend yang Anda cerminkan.
Klik Done.
Klik Simpan.
gcloud
Jalankan perintah
gcloud export
untuk mendapatkan konfigurasi peta URL:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
Tambahkan bagian berikut ke file
review-url-map-config.yaml
:hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: DEFAULT_SERVICE_URL name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: BACKEND_SERVICE_URL weight: 100 requestMirrorPolicy: backendService: BACKEND_SERVICE_MIRROR_URL
DEFAULT_SERVICE_URL
adalah URL default untuk layanan Anda.BACKEND_SERVICE_URL
adalah URL untuk backend yang dicerminkan.BACKEND_SERVICE_MIRROR_URL
adalah URL untuk layanan backend yang Anda cerminkan.
Perbarui peta URL:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Siapkan pemutusan sirkuit
Jeda sirkuit memungkinkan Anda menetapkan nilai minimum kegagalan untuk mencegah permintaan klien membebani backend Anda. Setelah permintaan mencapai batas yang Anda tetapkan, klien berhenti mengizinkan koneksi baru atau mengirim permintaan tambahan, sehingga backend Anda memiliki waktu untuk pulih.
Akibatnya, pemecahan sirkuit mencegah kegagalan beruntun dengan menampilkan error ke klien, bukan membebani backend. Hal ini memungkinkan beberapa traffic disalurkan sekaligus menyediakan waktu untuk mengelola situasi kelebihan beban, seperti menangani lonjakan traffic dengan meningkatkan kapasitas melalui penskalaan otomatis.
Pada contoh berikut, Anda menyetel pemutus arus listrik sebagai berikut:
- Permintaan maksimum per koneksi: 100
- Jumlah koneksi maksimum: 1000
- Maksimum permintaan tertunda: 200
- Permintaan maksimum: 1.000
- Percobaan ulang maksimum: 3
Untuk menyiapkan pemutusan sirkuit, ikuti langkah-langkah ini:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik nama layanan backend yang ingin Anda update.
Klik
Edit.Klik Advanced configurations.
Di bagian Pemutus arus listrik, centang kotak Aktifkan.
Klik
Edit.- Pada Max requests per connection, masukkan
100
. - Di Max connection, masukkan
1000
. - Di bagian Maksimal permintaan yang tertunda, masukkan
200
. - Di Max requests, masukkan
1000
. - Pada Maksimalkan percobaan ulang, masukkan
3
.
- Pada Max requests per connection, masukkan
Klik Simpan, lalu klik Simpan lagi.
gcloud
Jalankan perintah
gcloud export
untuk mengekspor konfigurasi layanan backend. GantiBACKEND_SERVICE_NAME
dengan nama layanan backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Update file
BACKEND_SERVICE_NAME
.yaml sebagai berikut:affinityCookieTtlSec: 0 backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group:https://www.googleapis.com/compute/v1/projects/PROJECT_ID/zones/ZONE/instanceGroups/INSTANCE_GROUP_NAME maxUtilization: 0.8 circuitBreakers: maxConnections: 1000 maxPendingRequests: 200 maxRequests: 1000 maxRequestsPerConnection: 100 maxRetries: 3 connectionDraining: drainingTimeoutSec: 300 healthChecks: - https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks/HEALTH_CHECK_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED localityLbPolicy: ROUND_ROBIN name: BACKEND_SERVICE_NAME port: 80 portName: http protocol: HTTP sessionAffinity: NONE timeoutSec: 30
Perbarui file konfigurasi layanan backend:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Siapkan minat sesi berdasarkan HTTP_COOKIE
Pengelolaan traffic lanjutan memungkinkan Anda mengonfigurasi afinitas sesi berdasarkan cookie yang disediakan.
Untuk menyiapkan afinitas sesi menggunakan HTTP_COOKIE
, ikuti langkah-langkah berikut:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik nama layanan backend yang ingin Anda update.
Klik
Edit.Klik Advanced configurations.
Di bagian Afinitas sesi, pilih Cookie HTTP.
Di bagian Locality Load balancing policy, pilih Ring hash.
- Di kolom HTTP Cookie name, masukkan
http_cookie
. - Di kolom HTTP Cookie path, masukkan
/cookie_path
. - Di kolom HTTP Cookie TTL, masukkan
100
. - Di kolom Ukuran ring minimum, masukkan
10000
.
- Di kolom HTTP Cookie name, masukkan
Klik Simpan.
gcloud
Jalankan perintah
gcloud export
untuk mengekspor konfigurasi layanan backend. GantiBACKEND_SERVICE_NAME
dengan nama layanan backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Update file
YAML
seperti berikut:sessionAffinity: 'HTTP_COOKIE' localityLbPolicy: 'RING_HASH' consistentHash: httpCookie: name: 'http_cookie' path: '/cookie_path' ttl: seconds: 100 nanos: 30 minimumRingSize: 10000
Impor file konfigurasi layanan backend:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Siapkan deteksi pencilan
Deteksi pencilan mengontrol penghapusan host yang tidak responsif dari kumpulan load balancing. Cloud Service Mesh melakukannya dengan menggunakan serangkaian kebijakan yang menentukan kriteria untuk menghapus VM backend atau endpoint yang tidak responsif di NEG, beserta kriteria yang menentukan kapan backend atau endpoint dianggap cukup responsif untuk menerima traffic lagi.
Pada contoh berikut, layanan backend memiliki satu grup instance sebagai
backend-nya. Setelan deteksi pencilan menetapkan bahwa analisis deteksi pencilan dijalankan setiap detik. Jika endpoint menampilkan lima error 5xx
berturut-turut, endpoint akan dikeluarkan dari pertimbangan load balancing selama 30 detik untuk pertama kalinya. Waktu ejeksi yang sebenarnya untuk endpoint yang sama adalah 30 detik dikalikan dengan jumlah endpoint yang dikeluarkan.
Untuk menyiapkan deteksi pencilan pada resource layanan backend, ikuti langkah-langkah berikut:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik nama layanan.
Klik
Edit.Klik Advanced configurations.
Centang kotak Deteksi pencilan.
Klik
Edit.- Setel Error berurutan ke
5
. - Setel Interval ke
1000
milidetik. - Tetapkan Waktu ejeksi dasar ke
30000
milidetik.
- Setel Error berurutan ke
Klik Simpan, lalu klik Simpan lagi.
gcloud
Jalankan perintah
gcloud export
untuk mengekspor konfigurasi layanan backend. GantiBACKEND_SERVICE_NAME
dengan nama layanan backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Perbarui file
YAML
sebagai berikut, dengan mengganti nama layanan backend denganBACKEND_SERVICE_NAME
:name: BACKEND_SERVICE_NAME loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP outlierDetection: consecutiveErrors: 5, interval: seconds: 1, nanos: 0 baseEjectionTime: seconds: 30, nanos: 0
Impor file konfigurasi layanan backend:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Menetapkan kebijakan load balancing lokalitas
Gunakan kebijakan load balancing lokalitas untuk memilih algoritma load balancing berdasarkan bobot lokalitas dan prioritas yang diberikan oleh Cloud Service Mesh. Misalnya, Anda dapat melakukan round robin berbobot di antara endpoint yang responsif atau melakukan hashing yang konsisten.
Pada contoh berikut, layanan backend memiliki satu grup instance sebagai
backend-nya. Kebijakan load balancing lokalitas disetel ke RING_HASH
.
Untuk menetapkan kebijakan load balancing lokalitas, ikuti langkah-langkah berikut:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik nama layanan.
Klik
Edit.Klik Advanced configurations.
Di bagian Kebijakan traffic, pada menu Kebijakan load balancing lokalitas, pilih Hash ring.
Klik Simpan.
gcloud
Jalankan perintah
gcloud export
untuk mengekspor konfigurasi layanan backend. GantiBACKEND_SERVICE_NAME
dengan nama layanan backend.gcloud compute backend-services export BACKEND_SERVICE_NAME \ --destination=BACKEND_SERVICE_NAME-config.yaml --global
Update file
BACKEND_SERVICE_NAME
.yaml sebagai berikut:name: shopping-cart-service loadBalancingScheme: INTERNAL_SELF_MANAGED backends: - balancingMode: UTILIZATION capacityScaler: 1.0 group: $INSTANCE_GROUP_URL healthChecks: - $HEALTH_CHECK_URL port: 80 portName: http protocol: HTTP localityLbPolicy: RING_HASH
Impor file konfigurasi layanan backend:
gcloud compute backend-services import BACKEND_SERVICE_NAME \ --source=BACKEND_SERVICE_NAME-config.yaml --global
Untuk informasi selengkapnya tentang cara kerja kebijakan load balancing lokalitas, lihat dokumentasi untuk resource backendService.
Menyiapkan pengalihan URL
Petunjuk ini mengasumsikan hal berikut:
- Deployment Cloud Service Mesh Anda memiliki peta URL yang disebut
review-url-map
. - Peta URL mengirimkan semua traffic ke satu layanan backend yang disebut
review1
, yang berfungsi sebagai layanan backend default. - Anda ingin mengalihkan lalu lintas dari satu {i>host<i} ke {i>host<i} lainnya.
Untuk menyiapkan pengalihan URL, ikuti langkah-langkah berikut:
Konsol
Di konsol Google Cloud, buka halaman Cloud Service Mesh.
Klik Peta aturan pemilihan rute.
Klik
Buat peta aturan pemilihan rute.Di halaman Create a routing rule map, masukkan Name.
Di menu Protocol, pilih HTTP.
Pilih aturan penerusan yang ada.
Di bagian Aturan pemilihan rute, pilih Host, jalur, dan aturan rute lanjutan.
Di bagian Hosts and path matcher, klik
Add hosts and path matcher. Tindakan ini akan menambahkan pencocok jalur baru yang mengalihkan traffic.Tambahkan setelan berikut ke kolom Pencocok jalur:
- defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True
Klik Done.
Klik Simpan.
gcloud
Jalankan perintah
gcloud export
untuk mendapatkan konfigurasi peta URL:gcloud compute url-maps export review-url-map \ --destination=review-url-map-config.yaml
Tambahkan bagian berikut ke file
review-url-map-config.yaml
:hostRules: - description: '' hosts: - '*' pathMatcher: matcher1 pathMatchers: - defaultService: global/backendServices/review1 name: matcher1 routeRules: - matchRules: - prefixMatch: '' urlRedirect: hostRedirect: '[REDIRECT_HOST]' pathRedirect: '[REDIRECT_URL]' redirectResponseCode: 'FOUND', stripQuery: True
Perbarui peta URL:
gcloud compute url-maps import review-url-map \ --source=review-url-map-config.yaml
Menyiapkan pengarahan traffic dengan penulisan ulang URL
Pengarahan traffic memungkinkan Anda mengarahkan traffic ke berbagai layanan backend berdasarkan atribut permintaan seperti nilai header. Selain itu, Anda dapat mengonfigurasi tindakan seperti menulis ulang URL dalam permintaan sebelum permintaan diarahkan ke layanan backend.
Pada contoh berikut, permintaan diarahkan ke SERVICE_ANDROID_URL
jika jalur permintaan diawali dengan /mobile/
dan User-Agent
permintaan tersebut berisi Android
. Sebelum mengirim permintaan ke layanan backend, awalan URL
dapat diubah menjadi contoh REWRITE_PATH_ANDROID
, /android/
. Namun, jika jalur diawali dengan /mobile/
dan memiliki User-Agent
yang berisi iPhone
, traffic akan diarahkan ke SERVICE_IPHONE_URL
dan awalan URL akan diubah menjadi REWRITE_PATH_IPHONE
. Semua permintaan lain yang diawali dengan /mobile/
dan memiliki User-Agent
dengan nilai selain Android atau iPhone akan diarahkan ke SERVICE_GENERIC_DEVICE_URL
.
pathMatchers: - defaultService: [DEFAULT_SERVICE_URL] name: matcher1 routeRules: - matchRules: - prefixMatch: /mobile/ headerMatches: - headerName: User-Agent regexMatch: .*Android.* service: $[SERVICE_ANDROID_URL] routeAction: urlRewrite: pathPrefixRewrite: [REWRITE_PATH_ANDROID] - matchRules: - prefixMatch: /mobile/ headerMatches: - headerName: User-Agent regexMatch: .*iPhone.* service: [SERVICE_IPHONE_URL] routeAction: urlRewrite: pathPrefixRewrite: [REWRITE_PATH_IPHONE] - matchRules: - prefixMatch: /mobile/ service: [SERVICE_GENERIC_DEVICE_URL]
Menyiapkan injeksi kesalahan
Injeksi kesalahan memungkinkan Anda menginjeksikan salah satu atau kedua penundaan tetap atau penghentian paksa, yang disebut pembatalan, ke rute tertentu untuk menguji ketahanan aplikasi.
Pada contoh berikut, semua permintaan dikirim ke SERVICE_URL
, dengan penundaan tetap 10 detik yang ditambahkan ke 100% permintaan. Klien yang mengirim permintaan melihat bahwa semua respons tertunda selama 10 detik. Selain itu, error
berhenti dengan respons Service Unavailable
503 diterapkan ke 50% permintaan. Klien melihat bahwa 50% permintaan mereka menerima respons 503.
Permintaan ini tidak menjangkau layanan backend sama sekali.
pathMatchers: - defaultService: [DEFAULT_SERVICE_URL] name: matcher1 routeRules: - matchRules: - prefixMatch: '/' routeAction: weightedBackendServices: - backendService: [SERVICE_URL] weight: 100 faultInjectionPolicy: delay: fixedDelay: seconds: 10 nanos: 0 percentage: 100 abort: httpStatus: 503 percentage: 50
Siapkan pemfilteran konfigurasi berdasarkan kecocokan MetadataFilters
MetadataFilters
diaktifkan dengan aturan penerusan dan HttpRouteRuleMatch
.
Gunakan fitur ini untuk mengontrol aturan penerusan atau aturan rute tertentu sehingga bidang kontrol mengirim aturan penerusan atau aturan rute hanya ke proxy yang metadata node-nya cocok dengan setelan filter metadata. Jika Anda tidak menentukan MetadataFilters
, aturan akan dikirim ke semua proxy Envoy.
Fitur ini memudahkan pengoperasian deployment bertahap dari suatu konfigurasi.
Misalnya, buat aturan penerusan bernama forwarding-rule1
, yang hanya ingin Anda kirimkan ke Envoys yang metadata node-nya berisi app: review
dan version: canary
.
Untuk menambahkan MetadataFilters
ke aturan penerusan, ikuti langkah-langkah berikut:
gcloud
Jalankan perintah
gcloud export
untuk mendapatkan konfigurasi aturan penerusan:gcloud compute forwarding-rules export forwarding-rule1 \ --destination=forwarding-rule1-config.yaml \ --global
Hapus aturan penerusan:
gcloud compute forwarding-rules delete forwarding-rule1 \ --global
Perbarui file
forwarding-rule1-config.yaml
.Contoh berikut akan membuat filter metadata
MATCH_ALL
:metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'canary'
Contoh berikut akan membuat filter metadata
MATCH_ANY
:metadataFilters: - filterMatchCriteria: 'MATCH_ANY' filterLabels: - name: 'app' value: 'review' - name: 'version' value: 'production'
Hapus semua kolom khusus output dari file
forwarding-rule1-config.yaml
. Untuk mengetahui informasi selengkapnya, lihat dokumentasi untukgcloud compute forwarding-rules import
.Jalankan perintah
gcloud import
untuk memperbarui fileforwarding-rule1-config.yaml
:gcloud compute forwarding-rules import forwarding-rule1 \ --source=forwarding-rule1-config.yaml \ --global
Gunakan petunjuk ini untuk menambahkan metadata node ke Envoy sebelum memulai Envoy. Hanya nilai string yang didukung.
a. Untuk deployment berbasis VM, di
bootstrap_template.yaml
, tambahkan kode berikut pada bagianmetadata
:app: 'review' version: 'canary'
b. Untuk deployment berbasis Google Kubernetes Engine atau berbasis Kubernetes, di
trafficdirector_istio_sidecar.yaml
, tambahkan kode berikut di bagianenv
:- name: ISTIO_META_app value: 'review' - name: ISTIO_META_version value: 'canary'
Contoh pemfilteran metadata
Gunakan petunjuk berikut untuk skenario saat beberapa project berada di jaringan VPC Bersama yang sama dan Anda ingin setiap resource Cloud Service Mesh project layanan terlihat oleh proxy dalam project yang sama.
Penyiapan VPC Bersama adalah sebagai berikut:
- Nama project host:
vpc-host-project
- Project layanan:
project1
,project2
- Layanan backend dengan backend instance atau endpoint yang menjalankan proxy yang sesuai dengan xDS di
project1
danproject2
Untuk mengonfigurasi Cloud Service Mesh guna mengisolasi project1
, ikuti langkah-langkah berikut:
gcloud
Buat semua aturan penerusan di
project1
dengan filter metadata berikut:metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels - name: 'project_name' value: 'project1' - name: 'version' value: 'production'
Saat Anda mengonfigurasi proxy yang di-deploy ke instance atau endpoint di
project1
, sertakan metadata berikut di bagian metadata node file bootstrap:project_name: 'project1' version: 'production'
Pastikan proxy yang sudah di-deploy di
project2
tidak menerima aturan penerusan yang dibuat pada langkah pertama. Untuk melakukannya, coba akses layanan diproject1
dari sistem yang menjalankan proxy diproject2
. Untuk mengetahui informasi tentang cara memverifikasi bahwa konfigurasi Cloud Service Mesh berfungsi dengan benar, lihat Memverifikasi konfigurasi.
Guna menguji konfigurasi baru pada subset proxy sebelum Anda menyediakannya untuk semua proxy, ikuti langkah-langkah berikut:
gcloud
Mulai proxy yang Anda gunakan untuk pengujian dengan metadata node berikut. Jangan sertakan metadata node ini untuk proxy yang tidak Anda gunakan untuk pengujian.
version: 'test'
Untuk setiap aturan penerusan baru yang ingin Anda uji, sertakan filter metadata berikut:
metadataFilters: - filterMatchCriteria: 'MATCH_ALL' filterLabels: - name: 'version' value: 'test'
Uji konfigurasi baru dengan mengirimkan traffic ke proxy pengujian, dan buat perubahan yang diperlukan. Jika konfigurasi baru berfungsi dengan benar, hanya proxy yang Anda uji yang akan menerima konfigurasi baru. Proxy yang tersisa tidak menerima konfigurasi baru dan tidak dapat menggunakannya.
Setelah Anda mengonfirmasi bahwa konfigurasi baru berfungsi dengan benar, hapus filter metadata yang terkait dengannya. Dengan begitu, semua proxy dapat menerima konfigurasi baru.
Pemecahan masalah
Gunakan informasi ini untuk memecahkan masalah saat lalu lintas tidak dirutekan sesuai dengan aturan rute dan kebijakan lalu lintas yang Anda konfigurasikan.
Gejala:
- Peningkatan traffic ke layanan dalam aturan di atas aturan yang dimaksud.
- Peningkatan yang tidak terduga pada respons HTTP
4xx
dan5xx
untuk aturan rute tertentu.
Solusi: Karena aturan rute ditafsirkan dalam urutan prioritas, tinjau prioritas yang ditetapkan ke setiap aturan.
Saat Anda menentukan aturan rute, pastikan bahwa aturan dengan prioritas lebih tinggi (yaitu, dengan nomor prioritas lebih rendah) tidak merutekan traffic yang seharusnya dirutekan oleh aturan rute berikutnya. Perhatikan contoh berikut:
Aturan rute pertama
- Kecocokan aturan rute pathPrefix =
/shopping/
- Tindakan pengalihan: kirim traffic ke layanan backend
service-1
- Prioritas aturan:
4
- Kecocokan aturan rute pathPrefix =
Aturan rute kedua
- Kecocokan aturan rute regexMatch =
/shopping/cart/ordering/.*
- Tindakan pengalihan: kirim traffic ke layanan backend
service-2
- Prioritas aturan:
8
- Kecocokan aturan rute regexMatch =
Dalam hal ini, permintaan dengan jalur /shopping/cart/ordering/cart.html
dirutekan ke service-1
. Meskipun aturan kedua akan cocok, aturan tersebut
diabaikan karena aturan pertama memiliki prioritas.
Memblokir traffic antarlayanan
Jika Anda ingin memblokir traffic antara Layanan A dan Layanan B, dan deployment Anda dilakukan di GKE, siapkan keamanan layanan dan gunakan kebijakan otorisasi untuk memblokir traffic antarlayanan. Untuk mengetahui petunjuk selengkapnya, lihat Keamanan layanan Cloud Service Mesh serta petunjuk penyiapan dengan Envoy dan gRPC tanpa proxy.
Langkah selanjutnya
- Untuk membantu Anda menyelesaikan masalah konfigurasi Cloud Service Mesh, lihat Memecahkan masalah deployment yang menggunakan Envoy.