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:

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:

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:

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:

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:

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:

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:

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:

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 dan project2

Untuk mengonfigurasi Cloud Service Mesh guna mengisolasi project1, ikuti langkah-langkah berikut:

Guna menguji konfigurasi baru pada subset proxy sebelum Anda menyediakannya untuk semua proxy, ikuti langkah-langkah berikut:

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 dan 5xx 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

• Aturan rute kedua

  • Kecocokan aturan rute regexMatch = /shopping/cart/ordering/.*
  • Tindakan pengalihan: kirim traffic ke layanan backend service-2
  • Prioritas aturan: 8

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.