Alibaba Cloud Service Mesh:Konfigurasikan routing fallback di ASM

Perbedaan fallback dengan retries dan circuit breaker

ASM menyediakan beberapa mekanisme ketahanan. Pilih yang tepat berdasarkan jenis kegagalan yang perlu ditangani:

Fallback beroperasi pada level routing: proxy sidecar memeriksa apakah subset target memiliki endpoint yang sehat sebelum meneruskan permintaan. Jika tidak ada endpoint sehat, permintaan dialihkan ke target fallback.

Prasyarat

Versi layanan reviews Bookinfo

Layanan reviews Bookinfo memiliki tiga versi, masing-masing dapat diidentifikasi berdasarkan peringkat bintangnya di halaman produk:

Layanan productpage memanggil reviews. Sebuah VirtualService mengarahkan seluruh traffic ke reviews-v3. Ketika v3 tidak tersedia, aturan fallback mengalihkan permintaan ke reviews-v2 alih-alih mengembalikan error 503.

Unduh file konfigurasi yang digunakan dalam topik ini.

Langkah 1: Buat destination rule untuk layanan reviews

Definisikan DestinationRule dengan subset untuk setiap versi layanan reviews.

1. Buat file bernama reviews.yaml dengan konten berikut:

      apiVersion: networking.istio.io/v1alpha3
      kind: DestinationRule
      metadata:
        name: reviews
      spec:
        host: reviews
        subsets:
        - name: v1
          labels:
            version: v1
        - name: v2
          labels:
            version: v2
        - name: v3
          labels:
            version: v3

2. Sambungkan ke instans ASM menggunakan kubectl dan file KubeConfig, lalu terapkan aturan tersebut:

      kubectl apply -f reviews.yaml

3. Dapatkan alamat IP gerbang masuk dengan salah satu metode berikut:

   • Jalankan perintah berikut:

     kubectl get svc -n istio-system istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}'

   • Temukan alamat IP pada halaman Ingress Gateway di Konsol ASM. Lihat Mencari alamat IP gerbang masuk instans ASM.

4. Buka http://<gateway-ip>/productpage di browser. Bidang Reviews served by dan peringkat bintang mengidentifikasi versi yang melayani setiap permintaan. Refresh halaman beberapa kali — permintaan didistribusikan ke v1, v2, dan v3. Misalnya, reviews-v2 menampilkan bintang hitam:

   

Langkah 2: Konfigurasikan aturan fallback dasar

Arahkan seluruh traffic ke reviews-v3 dan tetapkan reviews-v2 sebagai target fallback.

1. Buat file bernama reviews-route-fallback-sample1.yaml: Field fallback.target memberi tahu proxy sidecar untuk meneruskan permintaan ke reviews-v2 ketika reviews-v3 tidak dapat dijangkau.

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: reviews-route
        namespace: default
      spec:
        hosts:
          - reviews
        http:
          - route:
              - destination:
                  host: reviews
                  subset: v3
                fallback:
                  target:
                    host: reviews
                    subset: v2

2. Terapkan VirtualService:

      kubectl apply -f reviews-route-fallback-sample1.yaml

3. Buka http://<gateway-ip>/productpage dan refresh. Semua permintaan sekarang diarahkan ke v3 (bintang merah).

   

4. Simulasikan kegagalan v3 dengan mengatur jumlah replika deployment-nya menjadi nol:

      kubectl scale deployment reviews-v3 --replicas=0

5. Refresh halaman. Permintaan sekarang dialihkan ke v2 (bintang hitam).

Verifikasi fallback melalui log akses

Tambahkan field terkait fallback ke format log akses kustom untuk memastikan fallback telah dipicu. Lihat Customize access log fields untuk instruksi penyiapan.

Field	Nilai	Deskripsi
fallback_path	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-path)%	Rantai fallback. A:B berarti A dialihkan ke B. A:B:C berarti A dialihkan ke B, lalu B ke C.
fallback_final_cluster_name	%DYNAMIC_METADATA(com.aliyun.fallback:final-cluster)%	Cluster yang akhirnya menangani permintaan setelah fallback berhasil.
fallback_result	%DYNAMIC_METADATA(com.aliyun.fallback:fallback-result)%	Hasil fallback. Jika fallback gagal, permintaan dialihkan ke cluster rute aslinya.

Periksa log istio-proxy productpage-v1. Fallback yang berhasil dari v3 ke v2 menghasilkan entri log seperti berikut:

{
    "authority": "reviews:9080",
    "authority_for": "reviews:9080",
    "bytes_received": "0",
    "bytes_sent": "442",
    "downstream_local_address": "192.168.255.46:9080",
    "downstream_remote_address": "172.16.0.252:57238",
    "duration": "10",
    "fallback_path": "outbound|9080|v3|reviews.default.svc.cluster.local:outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_final_cluster_name": "outbound|9080|v2|reviews.default.svc.cluster.local",
    "fallback_result": "fallback successful",
    "istio_policy_status": "-",
    "method": "GET",
    "path": "/reviews/0",
    "protocol": "HTTP/1.1",
    "request_id": "15b2dffc-5f3f-4060-b9fa-898eab08****",
    "requested_server_name": "-",
    "response_code": "200",
    "response_flags": "-",
    "route_name": "-",
    "start_time": "2023-05-30T07:02:26.990Z",
    "trace_id": "18b3aed8af41****",
    "upstream_cluster": "outbound|9080|v2|reviews.default.svc.cluster.local",
    "upstream_host": "172.16.0.11:9080",
    "upstream_local_address": "172.16.0.252:44448",
    "upstream_service_time": "9",
    "upstream_transport_failure_reason": "-",
    "user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/113.0.X.X Safari/537.36",
    "x_forwarded_for": "-"
}

Tiga field spesifik fallback berikut mengonfirmasi perilaku tersebut:

• fallback_path menunjukkan rantai: cluster v3 ke cluster v2.

• fallback_final_cluster_name mengidentifikasi v2 sebagai cluster yang melayani permintaan.

• fallback_result bernilai "fallback successful".

Langkah 3: Gabungkan fallback dengan routing berbasis bobot

Aturan fallback bekerja bersamaan dengan routing berbasis bobot. Dalam skenario ini, traffic dibagi 50/50 antara v3 dan v2, dan masing-masing versi memiliki target fallback sendiri.

1. Pulihkan v3:

      kubectl scale deployment reviews-v3 --replicas=1

2. Buat file bernama reviews-route-fallback-sample2.yaml: Dua rantai fallback independen didefinisikan: Retries dinonaktifkan (attempts: 0) untuk mengisolasi perilaku fallback dari retry selama pengujian.

   • Traffic v3 (50%): dialihkan ke v2 jika v3 tidak tersedia

   • Traffic v2 (50%): dialihkan ke v1 jika v2 tidak tersedia

      apiVersion: networking.istio.io/v1beta1
      kind: VirtualService
      metadata:
        name: reviews-route
        namespace: default
      spec:
        hosts:
          - reviews
        http:
          - route:
              - destination:
                  host: reviews
                  subset: v3
                fallback:
                  target:
                    host: reviews
                    subset: v2
                weight: 50
              - destination:
                  host: reviews
                  subset: v2
                fallback:
                  target:
                    host: reviews
                    subset: v1
                weight: 50
            retries:
              attempts: 0

3. Terapkan VirtualService yang diperbarui:

      kubectl apply -f reviews-route-fallback-sample2.yaml

4. Refresh halaman produk. Permintaan didistribusikan merata antara v3 (bintang merah) dan v2 (bintang hitam).

Gunakan fallback di lingkungan produksi

Routing fallback menyembunyikan kegagalan layanan, yang bermanfaat untuk ketersediaan tetapi memerlukan perencanaan cermat di lingkungan produksi.

Topik terkait

• Create an ASM instance

• Customize access logs of clusters on the data plane

• Update an ASM instance