Penerapan Canary di Kubernetes #3: Istio

Menggunakan Istio+Kiali untuk meluncurkan dan memvisualisasikan penerapan Canary

Artikel dalam seri ini

1. Penerapan Canary di Kubernetes #1: Gitlab CI
2. Penerapan Canary di Kubernetes #2: Peluncuran Argo
3. (Artikel ini)
4. Penerapan Canary menggunakan Jenkins-X Istio Flagger

Penyebaran Canary

Kami harap Anda membaca bagian pertama, di mana kami menjelaskan secara singkat apa itu penerapan Canary dan menunjukkan cara mengimplementasikannya menggunakan sumber daya standar Kubernetes.

Istio

Dan kami berasumsi dengan membaca artikel ini Anda sudah mengetahui apa itu Istio. Jika belum, Anda bisa membacanya di sini.

Aplikasi untuk tes

Setiap pod berisi dua kontainer: aplikasi kita dan istio-proxy.

Kami akan menggunakan aplikasi pengujian sederhana dengan pod python frontend-nginx dan backend. Pod nginx hanya akan mengalihkan setiap permintaan ke pod backend dan berfungsi sebagai proxy. Detailnya dapat ditemukan di yaml berikut:

• frontend.yaml
• backend.yaml
• istio.yaml

Menjalankan aplikasi pengujian sendiri

Jika Anda ingin mengikuti contoh saya dan menggunakan sendiri aplikasi pengujian ini, lihat proyek baca saya.

Penerapan Awal

Saat kami meluncurkan Deployment pertama, kami melihat bahwa pod aplikasi kami hanya memiliki 2 container, yaitu sidecar Istio baru saja diimplementasikan:

Dan kami juga melihat Istio Gateway Loadbalancer di namespace istio-system:

Generasi lalu lintas

Kami akan menggunakan IP berikut untuk menghasilkan lalu lintas yang akan diterima oleh pod frontend dan diteruskan ke pod backend:

while true; do curl -s --resolve 'frontend.istio-test:80:35.242.202.152' frontend.istio-test; sleep 0.1; done

Kami juga akan menambahkan frontend.istio-test ke file host kami.

Lihat Mesh melalui Kiali

Kami menginstal aplikasi pengujian dan Istio bersama dengan Tracing, Grafana, Prometheus dan Kiali (lihat detail di bawah). proyek baca saya). Oleh karena itu kita dapat menggunakan Kiali melalui:

istioctl dashboard kiali # admin:admin

Kiali memvisualisasikan lalu lintas saat ini melalui Mesh

Seperti yang bisa kita lihat, 100% lalu lintas menuju ke layanan frontend, lalu ke pod frontend dengan label v1, karena kita menggunakan proxy nginx sederhana yang mengalihkan permintaan ke layanan backend, yang pada gilirannya mengarahkan mereka ke pod backend dengan label v1.

Kiali bekerja sangat baik dengan Istio dan menyediakan solusi rendering Mesh dalam kotak. Bagus sekali.

Penyebaran Canary

Backend kami sudah memiliki dua penerapan k8, satu untuk v1 dan satu lagi untuk v2. Sekarang kita hanya perlu memberitahu Istio untuk meneruskan persentase permintaan tertentu ke v2.

Langkah 1: 10%

Dan yang perlu kita lakukan hanyalah menyesuaikan bobot VirtualService di dalamnya istio.yaml:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Kami melihat bahwa 10% permintaan dialihkan ke v2.

Langkah 2: 50%

Dan sekarang cukup ditingkatkan menjadi 50% saja:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
...
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 50
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 50

Langkah 3: 100%

Sekarang penerapan Canary dapat dianggap selesai dan semua lalu lintas dialihkan ke v2:

Menguji Canary secara manual

Katakanlah sekarang kita mengirim 2% dari semua permintaan ke backend v10. Bagaimana jika kita ingin menguji v2 secara manual untuk memastikan semuanya berfungsi sesuai harapan?

Kita dapat menambahkan aturan pencocokan khusus berdasarkan header HTTP:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
  - match:
    - headers:
        canary:
          exact: "canary-tester"
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100
  - match:
    - {}
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v1
        port:
          number: 80
      weight: 90
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 10

Sekarang menggunakan curl kita dapat memaksakan permintaan v2 dengan mengirimkan header:

Permintaan tanpa header akan tetap didorong oleh rasio 1/10:

Canary untuk dua versi dependen

Sekarang kita akan mempertimbangkan opsi di mana kita memiliki versi v2 untuk frontend dan backend. Untuk keduanya, kami menetapkan bahwa 10% lalu lintas harus menuju ke v2:

Kita melihat bahwa frontend v1 dan v2 keduanya meneruskan lalu lintas dengan rasio 1/10 ke backend v1 dan v2.

Bagaimana jika kita perlu meneruskan lalu lintas dari frontend-v2 saja ke backend-v2 karena tidak kompatibel dengan v1? Untuk melakukan ini, kami akan menetapkan rasio 1/10 untuk frontend, yang mengontrol lalu lintas apa yang sampai ke backend-v2 menggunakan negosiasi sourceLabels :

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: backend
  namespace: default
spec:
  gateways: []
  hosts:
  - "backend.default.svc.cluster.local"
  http:
...
  - match:
    - sourceLabels:
        app: frontend
        version: v2
    route:
    - destination:
        host: backend.default.svc.cluster.local
        subset: v2
        port:
          number: 80
      weight: 100

Hasilnya, kami mendapatkan apa yang kami butuhkan:

Perbedaan dari pendekatan manual Canary

В bagian pertama Kami melakukan penerapan Canary secara manual, juga menggunakan dua penerapan k8. Di sana kami mengontrol rasio permintaan dengan mengubah jumlah replika. Pendekatan ini berhasil, namun memiliki kelemahan serius.

Istio memungkinkan untuk menentukan rasio permintaan terlepas dari jumlah replika. Artinya, misalnya kita dapat menggunakan HPA (Horizontal Pod Autoscaler) dan tidak perlu dikonfigurasi sesuai dengan status penerapan Canary saat ini.

Total

Istio berfungsi dengan baik dan menggunakannya bersama Kiali menghasilkan kombinasi yang sangat kuat. Berikutnya dalam daftar minat saya adalah menggabungkan Spinnaker dengan Istio untuk otomatisasi dan analitik Canary.

Sumber: www.habr.com