Kanariansaarten käyttöönotto Kubernetesissa #3: Istio

Istio+Kialin käyttö Canaryn käyttöönoton käynnistämiseen ja visualisointiin

Tämän sarjan artikkelit

1. Canaryn käyttöönotto Kubernetesissa #1: Gitlab CI
2. Canaryn käyttöönotto Kubernetesissa #2: Argo Rollouts
3. (Tämä artikkeli)
4. Canary Deployment Jenkins-X Istio Flaggerin avulla

Kanarian käyttöönotto

Toivomme, että luet ensimmäinen osa, jossa selitimme lyhyesti, mitä Canaryn käyttöönotot ovat, ja osoitimme, kuinka ne voidaan ottaa käyttöön Kubernetesin tavallisilla resursseilla.

Sama

Ja oletamme, että lukemalla tämän artikkelin tiedät jo, mikä Istio on. Jos ei, niin voit lukea siitä täällä.

Hakemus testeihin

Jokainen pod sisältää kaksi konttia: sovelluksemme ja istio-välityspalvelimen.

Käytämme yksinkertaista testisovellusta frontend-nginx- ja backend-python-podilla. Nginx pod yksinkertaisesti uudelleenohjaa jokaisen pyynnön backend podiin ja toimii välityspalvelimena. Yksityiskohdat löytyvät seuraavista yamleista:

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

Testisovelluksen suorittaminen itse

Jos haluat seurata esimerkkiäni ja käyttää tätä testisovellusta itse, katso projekti readme.

Ensimmäinen käyttöönotto

Kun käynnistämme ensimmäisen käyttöönoton, näemme, että sovelluksemme podeissa on vain 2 konttia, eli Istio-sivuvaunu on juuri toteutumassa:

Ja näemme myös Istio Gateway Loadbalancerin nimiavaruudessa istio-system:

Liikenteen tuottaminen

Käytämme seuraavaa IP-osoitetta luodaksemme liikennettä, jonka käyttöliittymäpodit vastaanottavat ja välittävät backend-podeihin:

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

Lisäämme myös frontend.istio-test hosts-tiedostoomme.

Katso Meshiä Kialin kautta

Asensimme testisovelluksen ja Istion sekä Tracingin, Grafanan, Prometheuksen ja Kialin (katso tarkemmat tiedot alta). projekti readme). Siksi voimme käyttää Kialia:

istioctl dashboard kiali # admin:admin

Kiali visualisoi nykyisen liikenteen Meshin kautta

Kuten näemme, 100 % liikenteestä menee käyttöliittymäpalveluun ja sitten käyttöliittymän podeihin, joiden tunniste on v1, koska käytämme yksinkertaista nginx-välityspalvelinta, joka uudelleenohjaa pyynnöt taustapalveluun, joka puolestaan ​​ohjaa ne backend-podeihin. tunnisteella v1.

Kiali toimii hyvin Istion kanssa ja tarjoaa laatikollisen Mesh-renderöintiratkaisun. Aivan mahtavaa.

Kanarian käyttöönotto

Taustallamme on jo kaksi k8s-käyttöönottoa, yksi v1:lle ja toinen v2:lle. Nyt täytyy vain käskeä Istio välittämään tietty prosenttiosuus pyynnöistä v2:lle.

Vaihe 1: 10 %

Ja meidän tarvitsee vain säätää VirtualServicen painoa 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

Näemme, että 10 % pyynnöistä ohjataan versioon 2.

Vaihe 2: 50 %

Ja nyt riittää vain nostaa se 50 prosenttiin:

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

Vaihe 3: 100 %

Nyt Canaryn käyttöönottoa voidaan pitää valmiina ja kaikki liikenne ohjataan versioon 2:

Canaryn testaus manuaalisesti

Oletetaan, että lähetämme nyt 2 % kaikista pyynnöistä v10-taustajärjestelmään. Entä jos haluamme testata manuaalisesti v2:ta varmistaaksemme, että kaikki toimii odotetulla tavalla?

Voimme lisätä erityisen vastaavuussäännön HTTP-otsikoiden perusteella:

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

Nyt curlilla voimme pakottaa v2-pyynnön lähettämällä otsikon:

Pyynnöt ilman otsikkoa ohjataan edelleen 1/10-suhteella:

Canary kahdelle riippuvaiselle versiolle

Nyt harkitsemme vaihtoehtoa, jossa meillä on versio v2 sekä käyttöliittymälle että taustajärjestelmälle. Molemmille määritimme, että 10 % liikenteestä tulee mennä v2:een:

Näemme, että käyttöliittymä v1 ja v2 välittävät liikennettä suhteessa 1/10 taustajärjestelmään v1 ja v2.

Entä jos meidän olisi välitettävä liikenne frontend-v2:sta vain backend-v2:een, koska se ei ole yhteensopiva v1:n kanssa? Tätä varten asetamme käyttöliittymälle 1/10-suhteen, joka ohjaa, mitä liikennettä pääsee backend-v2:een neuvottelun avulla. 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

Tuloksena saamme tarvitsemamme:

Erot manuaaliseen Canary-lähestymistapaan

В ensimmäinen osa Teimme Canaryn käyttöönoton manuaalisesti käyttäen myös kahta k8s-käyttöönottoa. Siellä kontrolloimme pyyntöjen suhdetta muuttamalla replikoiden määrää. Tämä lähestymistapa toimii, mutta sillä on vakavia haittoja.

Istio mahdollistaa pyyntöjen suhteen määrittämisen replikoiden lukumäärästä riippumatta. Tämä tarkoittaa esimerkiksi sitä, että voimme käyttää HPA:ita (Horizontal Pod Autoscalers) eikä niitä tarvitse konfiguroida Canaryn käyttöönoton nykyisen tilan mukaan.

Koko

Istio toimii loistavasti ja sen käyttäminen yhdessä Kialin kanssa tekee erittäin tehokkaan yhdistelmän. Seuraavana kiinnostuksen kohteinani on Spinnakerin yhdistäminen Istioon automatisointia ja Canary-analytiikkaa varten.

Lähde: will.com