Penggunaan Canary dalam Kubernetes #3: Istio

Menggunakan Istio+Kiali untuk melancarkan dan menggambarkan penggunaan Canary

Artikel dalam siri ini

1. Penggunaan Canary dalam Kubernetes #1: Gitlab CI
2. Penggunaan Canary dalam Kubernetes #2: Pelancaran Argo
3. (Artikel ini)
4. Penggunaan Canary menggunakan Jenkins-X Istio Flagger

Penggunaan Canary

Kami harap anda membaca bahagian pertama, di mana kami menerangkan secara ringkas tentang penggunaan Canary dan menunjukkan cara melaksanakannya menggunakan sumber Kubernetes standard.

Istio

Dan kami menganggap bahawa dengan membaca artikel ini anda sudah tahu apa itu Istio. Jika tidak, maka anda boleh membacanya di sini.

Permohonan untuk ujian

Setiap pod mengandungi dua bekas: aplikasi kami dan proksi istio.

Kami akan menggunakan aplikasi ujian mudah dengan pod python frontend-nginx dan backend. Pod nginx hanya akan mengubah hala setiap permintaan ke pod belakang dan berfungsi sebagai proksi. Butiran boleh didapati dalam yamls berikut:

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

Menjalankan aplikasi ujian sendiri

Jika anda ingin mengikuti contoh saya dan menggunakan aplikasi ujian ini sendiri, lihat projek readme.

Penggunaan Awal

Apabila kami melancarkan Deployment pertama, kami melihat bahawa pod aplikasi kami hanya mempunyai 2 bekas, iaitu, sidecar Istio baru sahaja dilaksanakan:

Dan kami juga melihat Istio Gateway Loadbalancer dalam ruang nama istio-system:

Penjanaan trafik

Kami akan menggunakan IP berikut untuk menjana trafik yang akan diterima oleh pod hujung hadapan dan dimajukan ke pod hujung belakang:

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

Kami juga akan menambah frontend.istio-test ke fail hos kami.

Lihat Mesh melalui Kiali

Kami memasang aplikasi ujian dan Istio bersama-sama dengan Tracing, Grafana, Prometheus dan Kiali (lihat di bawah untuk butiran). projek readme). Oleh itu kita boleh menggunakan Kiali melalui:

istioctl dashboard kiali # admin:admin

Kiali menggambarkan trafik semasa melalui Mesh

Seperti yang dapat kita lihat, 100% trafik pergi ke perkhidmatan bahagian hadapan, kemudian ke pod hujung hadapan dengan label v1, kerana kami menggunakan proksi nginx mudah yang mengubah hala permintaan ke perkhidmatan hujung belakang, yang seterusnya mengubah halanya ke pod hujung belakang dengan label v1.

Kiali berfungsi hebat dengan Istio dan menyediakan penyelesaian pemaparan Mesh berkotak. Hebat sahaja.

Penggunaan Canary

Bahagian belakang kami sudah mempunyai dua penempatan k8, satu untuk v1 dan satu untuk v2. Sekarang kita hanya perlu memberitahu Istio untuk memajukan peratusan permintaan tertentu kepada v2.

Langkah 1: 10%

Dan apa yang perlu kita lakukan ialah melaraskan berat VirtualService masuk 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 bahawa 10% permintaan diubah hala ke v2.

Langkah 2: 50%

Dan kini sudah cukup untuk meningkatkannya kepada 50%:

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 penempatan Canary boleh dianggap lengkap dan semua trafik diubah hala ke v2:

Menguji Canary secara manual

Katakan kami kini menghantar 2% daripada semua permintaan ke bahagian belakang v10. Bagaimana jika kita mahu menguji v2 secara manual untuk memastikan semuanya berfungsi seperti yang kita harapkan?

Kami boleh menambah peraturan padanan khas berdasarkan pengepala 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 boleh memaksa permintaan v2 dengan menghantar pengepala:

Permintaan tanpa pengepala masih akan didorong oleh nisbah 1/10:

Canary untuk dua versi bergantung

Sekarang kita akan mempertimbangkan pilihan di mana kita mempunyai versi v2 untuk kedua-dua bahagian hadapan dan bahagian belakang. Untuk kedua-duanya, kami menyatakan bahawa 10% daripada trafik harus pergi ke v2:

Kami melihat bahawa bahagian hadapan v1 dan v2 kedua-dua lalu lintas hadapan pada nisbah 1/10 kepada bahagian belakang v1 dan v2.

Bagaimana jika kita perlu memajukan trafik dari frontend-v2 sahaja ke backend-v2 kerana ia tidak serasi dengan v1? Untuk melakukan ini, kami akan menetapkan nisbah 1/10 untuk bahagian hadapan, yang mengawal apa yang trafik sampai ke bahagian belakang-v2 menggunakan rundingan 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 mendapat apa yang kami perlukan:

Perbezaan dari pendekatan Canary manual

В bahagian pertama Kami melakukan penggunaan Canary secara manual, juga menggunakan dua penempatan k8s. Di sana kami mengawal nisbah permintaan dengan menukar bilangan replika. Pendekatan ini berkesan, tetapi mempunyai kelemahan yang serius.

Istio memungkinkan untuk menentukan nisbah permintaan tanpa mengira bilangan replika. Ini bermakna, sebagai contoh, kita boleh menggunakan HPA (Horizontal Pod Autoscalers) dan tidak perlu dikonfigurasikan mengikut keadaan semasa penggunaan Canary.

Jumlah

Istio berfungsi hebat dan menggunakannya bersama-sama dengan Kiali menghasilkan gabungan yang sangat berkuasa. Seterusnya dalam senarai minat saya ialah menggabungkan Spinnaker dengan Istio untuk automasi dan analisis Canary.

Sumber: www.habr.com