Kanaria Deplojo en Kubernetes #3: Istio

Uzante Istio+Kiali por lanĉi kaj bildigi Kanarian deplojon

Artikoloj en ĉi tiu serio

1. Kanaria Deplojo en Kubernetes #1: Gitlab CI
2. Kanaria Deplojo en Kubernetes n-ro 2: Argo-Disvolvado
3. (Ĉi tiu artikolo)
4. Kanaria Deplojo uzante Jenkins-X Istio Flagger

Kanaria Deplojo

Ni esperas, ke vi legas unua parto, kie ni mallonge klarigis, kio estas Kanariaj deplojoj kaj montris kiel efektivigi ilin uzante normajn rimedojn de Kubernetes.

Istio

Kaj ni supozas, ke legante ĉi tiun artikolon vi jam scias kio estas Istio. Se ne, tiam vi povas legi pri ĝi tie.

Apliko por provoj

Ĉiu pod enhavas du ujojn: nia aplikaĵo kaj istio-proxy.

Ni uzos simplan testan aplikaĵon kun frontend-nginx kaj backend python pods. La nginx pod simple redirektos ĉiun peton al la malantaŭa pod kaj funkcios kiel prokurilo. Detaloj troveblas en la jenaj iamloj:

• fasado.yaml
• backend.yaml
• istio.yaml

Rulante la testan aplikaĵon mem

Se vi volas sekvi mian ekzemplon kaj uzi ĉi tiun testan aplikaĵon mem, vidu projekto legu min.

Komenca Deplojo

Kiam ni lanĉas la unuan Deplojon, ni vidas, ke la podoj de nia aplikaĵo havas nur 2 ujojn, tio estas, Istio sidecar ĵus efektiviĝas:

Kaj ni ankaŭ vidas Istio Gateway Loadbalancer en la nomspaco istio-system:

Trafika generacio

Ni uzos la sekvan IP por generi trafikon, kiu estos ricevita de la faskaj kapsuloj kaj plusendita al la backend pods:

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

Ni ankaŭ aldonos frontend.istio-test al nia dosiero gastigas.

Rigardu Mesh per Kiali

Ni instalis la testan apon kaj Istio kune kun Tracing, Grafana, Prometheus kaj Kiali (vidu sube por detaloj). projekto legu min). Tial ni povas uzi Kiali per:

istioctl dashboard kiali # admin:admin

Kiali bildigas aktualan trafikon per Mesh

Kiel ni povas vidi, 100% de la trafiko iras al la fasadservo, tiam al la fasadkapsuloj kun etikedo v1, ĉar ni uzas simplan nginx-prokurilon, kiu alidirektas petojn al la backend-servo, kiu siavice redirektas ilin al la backend pods. kun etikedo v1.

Kiali funkcias bonege kun Istio kaj provizas skatolan Mesh-bildigan solvon. Nur bonega.

Kanaria Deplojo

Nia backend jam havas du k8s-deplojojn, unu por v1 kaj unu por v2. Nun ni nur devas diri al Istio plusendi certan procenton de petoj al v2.

Paŝo 1: 10%

Kaj ĉio, kion ni devas fari, estas alĝustigi la pezon de la VirtualService en 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

Ni vidas, ke 10% de petoj estas redirektitaj al v2.

Paŝo 2: 50%

Kaj nun sufiĉas nur pliigi ĝin al 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

Paŝo 3: 100%

Nun Kanaria deplojo povas esti konsiderita kompleta kaj la tuta trafiko estas redirektita al v2:

Testante Kanarion permane

Ni diru, ke ni nun sendas 2% de ĉiuj petoj al la backend v10. Kio se ni volas mane testi v2 por certigi, ke ĉio funkcias kiel ni atendas?

Ni povas aldoni specialan kongruan regulon bazitan sur HTTP-kapoj:

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

Nun uzante buklon ni povas devigi v2-peton sendante la kaplinion:

Petoj sen kaplinio ankoraŭ estos pelataj de la proporcio 1/10:

Kanario por du dependaj versioj

Nun ni konsideros la opcion kie ni havas version v2 por ambaŭ fasado kaj backend. Por ambaŭ, ni specifis, ke 10% de la trafiko devus iri al v2:

Ni vidas, ke fasado v1 kaj v2 ambaŭ antaŭen trafiko kun proporcio de 1/10 al backend v1 kaj v2.

Kio se ni bezonus plusendi trafikon de frontend-v2 nur al backend-v2 ĉar ĝi ne kongruas kun v1? Por fari tion, ni starigos 1/10-proporcion por la fasado, kiu kontrolas kian trafikon atingas la backend-v2 uzante intertraktadon. 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

Kiel rezulto, ni ricevas tion, kion ni bezonas:

Diferencoj de la mana Kanaria aliro

В la unua parto Ni faris Kanarian deplojon permane, ankaŭ uzante du k8s-deplojojn. Tie ni kontrolis la rilatumon de petoj ŝanĝante la nombron da kopioj. Ĉi tiu aliro funkcias, sed havas gravajn malavantaĝojn.

Istio ebligas determini la rilatumon de petoj sendepende de la nombro da kopioj. Ĉi tio signifas, ekzemple, ke ni povas uzi HPA-ojn (Horizontal Pod Autoscalers) kaj ne bezonas esti agordita laŭ la nuna stato de la Kanaria deplojo.

La rezulto

Istio funkcias bonege kaj uzi ĝin kune kun Kiali faras tre potencan kombinaĵon. La sekva en mia listo de interesoj estas kombini Spinnaker kun Istio por aŭtomatigo kaj Kanaria analizo.

fonto: www.habr.com