Kanāriju izvietošana Kubernetes #3: Istio

Izmantojot Istio+Kiali, lai palaistu un vizualizētu Kanāriju izvietošanu

Raksti šajā sērijā

1. Kanāriju salu izvietošana Kubernetes #1: Gitlab CI
2. Kanāriju izvietošana Kubernetes #2: Argo Rollouts
3. (Šis raksts)
4. Kanāriju izvietošana, izmantojot Jenkins-X Istio Flagger

Kanāriju izvietošana

Mēs ceram, ka jūs izlasīsit pirmā daļa, kur mēs īsi paskaidrojām, kas ir Kanāriju izvietojumi, un parādījām, kā tos ieviest, izmantojot standarta Kubernetes resursus.

Istio

Un mēs pieņemam, ka, izlasot šo rakstu, jūs jau zināt, kas ir Istio. Ja nē, tad varat par to lasīt šeit.

Pieteikšanās testiem

Katrā podā ir divi konteineri: mūsu lietojumprogramma un istio-starpniekserveris.

Mēs izmantosim vienkāršu testa lietojumprogrammu ar frontend-nginx un backend python podiem. Nginx pods vienkārši novirzīs katru pieprasījumu uz aizmugursistēmas podziņu un darbosies kā starpniekserveris. Sīkāku informāciju var atrast šādos yamlos:

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

Testa lietojumprogrammas palaišana pats

Ja vēlaties sekot manam piemēram un pats izmantot šo testa lietojumprogrammu, skatiet projekts readme.

Sākotnējā izvietošana

Kad mēs palaižam pirmo izvietošanu, mēs redzam, ka mūsu lietojumprogrammas podiem ir tikai 2 konteineri, tas ir, Istio blakusvāģis tikko tiek ieviests:

Un mēs redzam arī Istio Gateway Loadbalancer nosaukumu telpā istio-system:

Satiksmes ģenerēšana

Mēs izmantosim šādu IP, lai ģenerētu datplūsmu, ko saņems priekšgala aplikācijas un pārsūtīs uz aizmugursistēmas podiem:

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

Mēs arī pievienosim frontend.istio-test uz mūsu saimnieku failu.

Skatīt Mesh caur Kiali

Mēs instalējām testa lietojumprogrammu un Istio kopā ar Tracing, Grafana, Prometheus un Kiali (sīkāku informāciju skatiet tālāk). projekts readme). Tāpēc mēs varam izmantot Kiali, izmantojot:

istioctl dashboard kiali # admin:admin

Kiali vizualizē pašreizējo satiksmi caur Mesh

Kā redzam, 100% datplūsmas tiek novirzītas uz priekšgala pakalpojumu, pēc tam uz priekšgala podiem ar etiķeti v1, jo mēs izmantojam vienkāršu nginx starpniekserveri, kas novirza pieprasījumus uz aizmugursistēmas pakalpojumu, kas savukārt novirza tos uz aizmugursistēmas podiem. ar etiķeti v1.

Kiali lieliski darbojas ar Istio un nodrošina iesaiņotu tīkla renderēšanas risinājumu. Vienkārši lieliski.

Kanāriju izvietošana

Mūsu aizmugursistēmai jau ir divi k8s izvietojumi, viens v1 un viens v2. Tagad mums vienkārši jāpasaka Istio, lai tas pārsūtītu noteiktu pieprasījumu procentuālo daļu uz v2.

1. darbība: 10%

Un viss, kas mums jādara, ir jāpielāgo VirtualService svars 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

Mēs redzam, ka 10% pieprasījumu tiek novirzīti uz v2.

2. darbība: 50%

Un tagad pietiek tikai palielināt to līdz 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

3. darbība: 100%

Tagad Canary izvietošanu var uzskatīt par pabeigtu, un visa trafika tiek novirzīta uz v2:

Kanāriju testēšana manuāli

Pieņemsim, ka tagad mēs nosūtām 2% no visiem pieprasījumiem v10 aizmugursistēmai. Ko darīt, ja mēs vēlamies manuāli pārbaudīt v2, lai pārliecinātos, ka viss darbojas, kā mēs ceram?

Mēs varam pievienot īpašu atbilstības noteikumu, pamatojoties uz HTTP galvenēm:

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

Tagad, izmantojot curl, mēs varam piespiest v2 pieprasījumu, nosūtot galveni:

Pieprasījumi bez galvenes joprojām tiks vadīti pēc attiecības 1/10:

Canary divām atkarīgām versijām

Tagad mēs apsvērsim iespēju, kurā mums ir versija v2 gan priekšgalam, gan aizmugursistēmai. Abos gadījumos mēs norādījām, ka 10% datplūsmas jānovirza uz v2:

Mēs redzam, ka gan priekšgala v1, gan v2 pārsūta trafiku proporcijā 1/10 ar aizmugursistēmas v1 un v2.

Ko darīt, ja mums būtu jāpārsūta datplūsma no frontend-v2 tikai uz backend-v2, jo tā nav saderīga ar v1? Lai to izdarītu, mēs iestatīsim attiecību 1/10 priekšgalam, kas kontrolē to, kāda trafika nonāk backend-v2, izmantojot sarunas. 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

Rezultātā mēs iegūstam to, kas mums nepieciešams:

Atšķirības no manuālās Kanāriju pieejas

В pirmā daļa Mēs veicām Kanāriju izvietošanu manuāli, izmantojot arī divus k8s izvietojumus. Tur mēs kontrolējām pieprasījumu attiecību, mainot kopiju skaitu. Šī pieeja darbojas, taču tai ir nopietni trūkumi.

Istio ļauj noteikt pieprasījumu attiecību neatkarīgi no kopiju skaita. Tas nozīmē, piemēram, ka mēs varam izmantot HPA (Horizontal Pod Autoscalers), un tie nav jākonfigurē atbilstoši pašreizējam Kanāriju izvietošanas stāvoklim.

Kopsavilkums

Istio darbojas lieliski, un, izmantojot to kopā ar Kiali, tiek iegūta ļoti spēcīga kombinācija. Nākamais manā interešu sarakstā ir Spinnaker apvienošana ar Istio automatizācijai un Kanāriju analītikai.

Avots: www.habr.com