Kembali ke perkhidmatan mikro dengan Istio. Bahagian 2

Catatan. terjemah: Bahagian pertama Siri ini didedikasikan untuk memperkenalkan keupayaan Istio dan menunjukkannya dalam tindakan. Sekarang kita akan bercakap tentang aspek yang lebih kompleks dalam konfigurasi dan penggunaan jaringan perkhidmatan ini, dan khususnya, tentang penghalaan yang ditala dengan halus dan pengurusan trafik rangkaian.

Kami juga mengingatkan anda bahawa artikel menggunakan konfigurasi (manifes untuk Kubernetes dan Istio) daripada repositori istio-penguasaan.

Pengurusan Trafik

Dengan Istio, keupayaan baharu muncul dalam kluster untuk menyediakan:

• Penghalaan permintaan dinamik: pelancaran kenari, ujian A/B;
• Pengimbangan beban: mudah dan konsisten, berdasarkan cincang;
• Pemulihan selepas jatuh: tamat masa, percubaan semula, pemutus litar;
• Memasukkan kesalahan: kelewatan, permintaan digugurkan, dsb.

Semasa artikel diteruskan, keupayaan ini akan digambarkan menggunakan aplikasi yang dipilih sebagai contoh dan konsep baharu akan diperkenalkan di sepanjang jalan. Konsep pertama seperti itu ialah DestinationRules (iaitu peraturan tentang penerima trafik/permintaan - lebih kurang transl.), dengan bantuannya kami mengaktifkan ujian A/B.

Ujian A/B: DestinationRules dalam amalan

Ujian A/B digunakan dalam kes di mana terdapat dua versi aplikasi (biasanya ia berbeza secara visual) dan kami tidak 100% pasti yang mana satu akan meningkatkan pengalaman pengguna. Oleh itu, kami menjalankan kedua-dua versi secara serentak dan mengumpul metrik.

Untuk menggunakan versi kedua bahagian hadapan, diperlukan untuk menunjukkan ujian A/B, jalankan arahan berikut:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

Manifes penggunaan untuk versi hijau berbeza di dua tempat:

1. Imej adalah berdasarkan tag yang berbeza - istio-green,
2. Pod mempunyai label version: green.

Memandangkan kedua-dua penempatan mempunyai label app: sa-frontend,permintaan dihalakan oleh perkhidmatan maya sa-external-services untuk perkhidmatan sa-frontend, akan diubah hala ke semua kejadiannya dan beban akan diedarkan melalui algoritma round-robin, yang akan membawa kepada situasi berikut:

Fail yang diminta tidak ditemui

Fail ini tidak ditemui kerana ia dinamakan berbeza dalam versi aplikasi yang berbeza. Mari pastikan ini:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

Maksudnya begitu index.html, meminta satu versi fail statik, boleh dihantar oleh pengimbang beban kepada pod yang mempunyai versi berbeza, di mana, atas sebab yang jelas, fail sedemikian tidak wujud. Oleh itu, agar aplikasi berfungsi, kami perlu menetapkan sekatan: "versi aplikasi yang sama yang menyediakan index.html harus menyediakan permintaan berikutnya'.

Kami akan sampai ke sana dengan pengimbangan beban berasaskan cincang yang konsisten (Pengimbangan Muatan Hash Konsisten). Dalam kes ini permintaan daripada pelanggan yang sama dihantar ke contoh bahagian belakang yang sama, yang mana sifat pratakrif digunakan - contohnya, pengepala HTTP. Dilaksanakan menggunakan DestinationRules.

Peraturan Destinasi

Selepas Perkhidmatan Maya menghantar permintaan kepada perkhidmatan yang dikehendaki, menggunakan DestinationRules kami boleh menentukan dasar yang akan digunakan pada trafik yang ditakdirkan untuk contoh perkhidmatan ini:

Pengurusan trafik dengan sumber Istio

Nota: Kesan sumber Istio pada trafik rangkaian dibentangkan di sini dengan cara yang mudah difahami. Tepatnya, keputusan mengenai contoh untuk menghantar permintaan dibuat oleh Utusan dalam Gerbang Ingress yang dikonfigurasikan dalam CRD.

Dengan Peraturan Destinasi, kami boleh mengkonfigurasi pengimbangan beban untuk menggunakan cincang yang konsisten dan memastikan bahawa contoh perkhidmatan yang sama bertindak balas kepada pengguna yang sama. Konfigurasi berikut membolehkan anda mencapai ini (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - cincang akan dijana berdasarkan kandungan pengepala HTTP version.

Gunakan konfigurasi dengan arahan berikut:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

Sekarang jalankan arahan di bawah dan pastikan anda mendapat fail yang betul apabila anda menentukan pengepala version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

Nota: Untuk menambah nilai yang berbeza dalam pengepala dan menguji hasilnya secara langsung dalam penyemak imbas, anda boleh gunakan sambungan ini kepada Chrome (Atau dengan ini untuk Firefox - lebih kurang. terjemah.).

Secara umum, DestinationRules mempunyai lebih banyak keupayaan dalam bidang pengimbangan beban - semak untuk mendapatkan butiran dokumentasi rasmi.

Sebelum mengkaji Perkhidmatan Maya dengan lebih lanjut, mari padamkan "versi hijau" aplikasi dan peraturan arah trafik yang sepadan dengan menjalankan arahan berikut:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

Mencerminkan: Perkhidmatan Maya dalam Amalan

Membayangi (“pelindung”) atau Mencerminkan (“mencerminkan”) digunakan dalam kes di mana kami ingin menguji perubahan dalam pengeluaran tanpa menjejaskan pengguna akhir: untuk melakukan ini, kami menduplikasi permintaan (“cermin”) kepada contoh kedua apabila perubahan yang diingini telah dibuat dan melihat akibatnya. Ringkasnya, ini adalah apabila rakan sekerja anda memilih isu yang paling kritikal dan membuat permintaan tarik dalam bentuk ketulan kotoran yang sangat besar yang tidak boleh disemak oleh sesiapa pun.

Untuk menguji senario ini dalam tindakan, mari buat contoh kedua SA-Logic dengan pepijat (buggy) dengan menjalankan arahan berikut:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

Dan sekarang mari jalankan arahan untuk memastikan bahawa semua kejadian dengan app=sa-logic Mereka juga mempunyai label dengan versi yang sepadan:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

Perkhidmatan sa-logic menyasarkan pod dengan label app=sa-logic, jadi semua permintaan akan diedarkan antara semua keadaan:

... tetapi kami mahu permintaan dihantar ke contoh v1 dan dicerminkan kepada kejadian v2:

Kami akan mencapai ini melalui VirtualService dalam kombinasi dengan DestinationRule, di mana peraturan akan menentukan subset dan laluan VirtualService ke subset tertentu.

Menentukan Subset dalam Peraturan Destinasi

Subset (subset) ditentukan oleh konfigurasi berikut (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. hos (host) mentakrifkan bahawa peraturan ini hanya digunakan untuk kes apabila laluan menuju ke perkhidmatan sa-logic;
2. Tajuk (name) subset digunakan apabila menghala ke contoh subset;
3. Label (label) mentakrifkan pasangan nilai kunci yang keadaan mesti dipadankan untuk menjadi sebahagian daripada subset.

Gunakan konfigurasi dengan arahan berikut:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

Sekarang bahawa subset ditakrifkan, kita boleh meneruskan dan mengkonfigurasi Perkhidmatan Maya untuk menggunakan peraturan pada permintaan kepada sa-logik supaya mereka:

1. Dihalakan ke subset v1,
2. Dicerminkan kepada subset v2.

Manifesto berikut membolehkan anda mencapai rancangan anda (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

Tiada penjelasan diperlukan di sini, jadi mari kita lihat ia dalam tindakan:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

Mari tambah beban dengan memanggil arahan berikut:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

Mari lihat hasil dalam Grafana, di mana anda boleh melihat bahawa versi dengan pepijat (buggy) mengakibatkan kegagalan untuk ~60% permintaan, tetapi tiada satu pun daripada kegagalan ini mempengaruhi pengguna akhir kerana mereka dijawab oleh perkhidmatan yang sedang berjalan.

Respons yang berjaya bagi versi berbeza perkhidmatan sa-logic

Di sini kami mula-mula melihat bagaimana Perkhidmatan Maya digunakan pada Utusan perkhidmatan kami: bila sa-web-app membuat permintaan untuk sa-logic, ia melalui Envoy kereta sampingan, yang - melalui VirtualService - dikonfigurasikan untuk mengarahkan permintaan ke subset v1 dan mencerminkan permintaan ke subset v2 perkhidmatan sa-logic.

Saya tahu, anda mungkin sudah berfikir bahawa Perkhidmatan Maya adalah mudah. Dalam bahagian seterusnya, kami akan mengembangkannya dengan mengatakan bahawa mereka juga benar-benar hebat.

Pelancaran kenari

Canary Deployment ialah proses melancarkan versi baharu aplikasi kepada sebilangan kecil pengguna. Ia digunakan untuk memastikan tiada masalah dalam keluaran dan hanya selepas itu, sudah yakin dengan kualitinya (keluaran), mengedarkannya kepada pengguna lain.оpenonton yang lebih besar.

Untuk menunjukkan pelancaran kenari, kami akan terus bekerja dengan subset buggy у sa-logic.

Jangan buang masa untuk perkara remeh dan segera hantar 20% pengguna ke versi dengan pepijat (ini akan mewakili pelancaran kenari kami), dan baki 80% kepada perkhidmatan biasa. Untuk melakukan ini, gunakan Perkhidmatan Maya berikut (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 ialah berat (weight), yang menentukan peratusan permintaan yang akan ditujukan kepada penerima atau subset penerima.

Mari kemas kini konfigurasi VirtualService sebelumnya untuk sa-logic dengan arahan berikut:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... dan kami akan segera melihat bahawa beberapa permintaan membawa kepada kegagalan:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

VirtualServices mendayakan pelancaran kenari: Dalam kes ini, kami telah mengecilkan potensi kesan isu kepada 20% daripada pangkalan pengguna. Hebat! Sekarang, dalam setiap kes apabila kami tidak pasti tentang kod kami (dengan kata lain - sentiasa...), kami boleh menggunakan pencerminan dan pelancaran kenari.

Tamat masa dan cuba semula

Tetapi pepijat tidak selalu berakhir dalam kod. Dalam senarai daripada "8 Salah tanggapan tentang Pengkomputeran Teragih"Di tempat pertama ialah kepercayaan yang salah bahawa "rangkaian itu boleh dipercayai." Pada hakikatnya rangkaian tiada boleh dipercayai, dan atas sebab ini kami memerlukan tamat masa (masa tamat) dan cuba semula (cuba semula).

Untuk demonstrasi kami akan terus menggunakan versi masalah yang sama sa-logic (buggy), dan kami akan mensimulasikan ketidakbolehpercayaan rangkaian dengan kegagalan rawak.

Biarkan perkhidmatan kami dengan pepijat mempunyai 1/3 peluang untuk mengambil masa terlalu lama untuk bertindak balas, 1/3 peluang untuk berakhir dengan Ralat Pelayan Dalaman dan 1/3 peluang untuk berjaya mengembalikan halaman tersebut.

Untuk mengurangkan kesan masalah sedemikian dan menjadikan kehidupan lebih baik untuk pengguna, kami boleh:

1. tambahkan tamat masa jika perkhidmatan mengambil masa lebih lama daripada 8 saat untuk bertindak balas,
2. cuba semula jika permintaan gagal.

Untuk pelaksanaan, kami akan menggunakan definisi sumber berikut (sa-logic-retry-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. Tamat masa untuk permintaan ditetapkan kepada 8 saat;
2. Permintaan dicuba semula 3 kali;
3. Dan setiap percubaan dianggap tidak berjaya jika masa tindak balas melebihi 3 saat.

Ini adalah pengoptimuman kerana pengguna tidak perlu menunggu lebih daripada 8 saat dan kami akan membuat tiga percubaan baharu untuk mendapatkan respons sekiranya berlaku kegagalan, meningkatkan peluang respons yang berjaya.

Gunakan konfigurasi yang dikemas kini dengan arahan berikut:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

Dan semak dalam graf Grafana bahawa bilangan respons yang berjaya telah meningkat di atas:

Penambahbaikan dalam statistik respons yang berjaya selepas menambah tamat masa dan cuba semula

Sebelum beralih ke bahagian seterusnya (atau lebih tepat, ke bahagian seterusnya artikel, kerana dalam ini tidak akan ada lagi eksperimen praktikal - lebih kurang transl.), padam sa-logic-buggy dan VirtualService dengan menjalankan arahan berikut:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

Corak Pemutus Litar dan Bulkhead

Kami bercakap tentang dua corak penting dalam seni bina perkhidmatan mikro yang membolehkan anda mencapai pemulihan diri (penyembuhan diri) perkhidmatan.

Circuit Breaker ("pemutus litar") digunakan untuk menamatkan permintaan yang datang kepada contoh perkhidmatan yang dianggap tidak sihat dan memulihkannya sementara permintaan pelanggan dialihkan kepada contoh yang sihat bagi perkhidmatan tersebut (yang meningkatkan peratusan respons yang berjaya). (Nota: Penerangan yang lebih terperinci tentang corak boleh didapati, contohnya, di sini.)

Bulkhead ("partition") mengasingkan kegagalan perkhidmatan daripada menjejaskan keseluruhan sistem. Sebagai contoh, Perkhidmatan B rosak dan perkhidmatan lain (pelanggan Perkhidmatan B) membuat permintaan kepada Perkhidmatan B, menyebabkan ia kehabisan kumpulan benangnya dan tidak dapat menyediakan permintaan lain (walaupun ia bukan daripada Perkhidmatan B). (Nota: Penerangan yang lebih terperinci tentang corak boleh didapati, contohnya, di sini.)

Saya akan meninggalkan butiran pelaksanaan corak ini kerana ia mudah dicari dokumentasi rasmi, dan saya juga sangat ingin menunjukkan pengesahan dan kebenaran, yang akan dibincangkan dalam bahagian seterusnya artikel.

PS daripada penterjemah

Baca juga di blog kami:

• "Kembali ke perkhidmatan mikro dengan Istio": bahagian 1 (pengenalan kepada ciri utama), bahagian 3 (pengesahan dan kebenaran);
• «Konduit - jaringan perkhidmatan ringan untuk Kubernetes»;
• «Apakah mesh perkhidmatan dan mengapa saya memerlukannya [untuk aplikasi awan dengan perkhidmatan mikro]?'.

Sumber: www.habr.com