በ Kubernetes ውስጥ የካናሪ ማሰማራት # 3: ኢስቲዮ

Istio+Kialiን በመጠቀም የካናሪ ማሰማራትን ለመጀመር እና ለማየት

በዚህ ተከታታይ ውስጥ ያሉ መጣጥፎች

1. የካናሪ ማሰማራት በኩበርኔትስ # 1: Gitlab CI
2. የካናሪ ማሰማራት በ Kubernetes # 2: Argo Rollouts
3. (ይህ ዓምድ)
4. Jenkins-X Istio Flaggerን በመጠቀም የካናሪ ማሰማራት

የካናሪ ማሰማራት

እንዲያነቡ ተስፋ እናደርጋለን የመጀመሪያ ክፍል, የካናሪ ማሰማራቶች ምን እንደሆኑ በአጭሩ ገለጽን እና መደበኛ የኩበርኔትስ ሀብቶችን በመጠቀም እንዴት እንደሚተገበሩ አሳይተናል.

Istio

እና ይህን ጽሑፍ በማንበብ, ኢስቲዮ ምን እንደሆነ አስቀድመው ያውቃሉ ብለን እንገምታለን. ካልሆነ ስለሱ ማንበብ ይችላሉ. እዚህ.

ለፈተናዎች ማመልከቻ

እያንዳንዱ ፖድ ሁለት ኮንቴይነሮችን ይይዛል፡ መተግበሪያችን እና ኢስቲዮ ፕሮክሲ።

ቀላል የፍተሻ አፕሊኬሽን ከfrontend-nginx እና backend python pods ጋር እንጠቀማለን። የ nginx ፖድ በቀላሉ እያንዳንዱን ጥያቄ ወደ የጀርባ ፖድ ያስተላልፋል እና እንደ ተኪ ይሠራል። ዝርዝሩን በሚከተለው yamls ውስጥ በበለጠ ዝርዝር ማየት ይቻላል፡-

• ግንባር.yaml
• ጀርባ.yaml
• istio.yaml

የሙከራ መተግበሪያን እራስዎ ያሂዱ

የእኔን ምሳሌ ለመከተል እና ይህንን የሙከራ መተግበሪያ እራስዎ ለመጠቀም ከፈለጉ ይመልከቱ የፕሮጀክት ንባብ.

የመጀመሪያ ማሰማራት

የመጀመሪያውን ማሰማራት ስንጀምር የኛ አፕሊኬሽን ፖድፖች እያንዳንዳቸው 2 ኮንቴይነሮች ብቻ እንዳላቸው እናያለን ማለትም የኢስቲዮ የጎን መኪና እየተተገበረ ነው፡

እና ደግሞ Istio Gateway Loadbalancer በስም ቦታ ላይ እናያለን። istio-system:

ትራፊክ ማመንጨት

በግንባር ፖድዶች የሚቀበል እና ወደ ኋለኛው ፓዶች የሚሸጋገር ትራፊክ ለመፍጠር የሚከተለውን አይፒ እንጠቀማለን።

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

እኛ ደግሞ እንጨምራለን frontend.istio-test ወደ እኛ አስተናጋጆች ፋይል.

Mesh በኪያሊ በኩል ይመልከቱ

የሙከራ መተግበሪያን እና ኢስቲዮ ከ Tracing፣ Grafana፣ Prometheus እና Kiali ጋር ጭነናል (ለዝርዝሩ እዚህ ይመልከቱ)። የፕሮጀክት ንባብ). ስለዚህ ኪያሊ በሚከተሉት መንገዶች መጠቀም እንችላለን-

istioctl dashboard kiali # admin:admin

ኪያሊ በሜሽ በኩል ያለውን የአሁኑን ትራፊክ በዓይነ ሕሊናዎ ያሳያል

እንደምናየው፣ 100% የትራፊክ ፍሰት ወደ ፊት ለፊት አገልግሎት፣ ከዚያም ወደ የፊት ክፍል ንዑስ መለያ v1 ይሄዳል፣ ምክንያቱም እኛ ቀላል nginx proxy እየተጠቀምን ስለሆነ ወደ የኋላ አገልግሎት ጥያቄዎችን የሚያዞር ሲሆን ይህም በተራው ወደ የኋላ ፖድስ ይመራቸዋል መለያ v1.

ኪያሊ ከኢስቲዮ ጋር በጥሩ ሁኔታ ይሰራል እና በቦክስ የተሰራ የሜሽ አቀራረብ መፍትሄን ይሰጣል። በጣም ጥሩ።

የካናሪ ማሰማራት

የእኛ የኋለኛ ክፍል አስቀድሞ ሁለት k8s ማሰማራቶች አሉት ፣ አንድ ለv1 እና አንድ ለv2። አሁን ኢስቲዮ የተወሰኑ የጥያቄዎችን መቶኛ ወደ v2 እንዲያዞር ልንነግረው ብቻ ነው።

ደረጃ 1፡ 10%

እና እኛ የሚያስፈልገን የቨርቹዋል ሰርቪሱን ክብደት ማስተካከል ብቻ ነው። 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

10% ጥያቄዎች ወደ v2 እንደተዘዋወሩ እናያለን።

ደረጃ 2፡ 50%

እና አሁን ወደ 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፡ 100%

አሁን የካናሪ ዝርጋታ እንደተጠናቀቀ ሊቆጠር ይችላል እና ሁሉም ትራፊክ ወደ v2 ተዘዋውሯል፡

Canaryን በእጅ መሞከር

አሁን ከሁሉም ጥያቄዎች 2% ወደ v10 የኋላ ክፍል እየላክን ነው እንበል። ሁሉም ነገር እንደተጠበቀው መስራቱን ለማረጋገጥ v2ን በእጅ መሞከር ከፈለግንስ?

በ 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

አሁን curlን በመጠቀም ራስጌ በመላክ የv2 ጥያቄን ማስገደድ እንችላለን፡-

ራስጌ የሌላቸው ጥያቄዎች አሁንም በ1/10 ጥምርታ ይተዳደራሉ፡

ካናሪ ለሁለት ጥገኛ ስሪቶች

አሁን ለግንባር እና ለኋላ ለሁለቱም v2 ስሪት ያለንበትን አማራጭ እንመለከታለን። ለሁለቱም 10% የትራፊክ ፍሰት ወደ v2 መሄድ እንዳለበት ገልፀናል፡-

የፊት ገፅ v1 እና v2 ሁለቱም በ1/10 ወደ backend v1 እና v2 ጥምርታ የሚያስተላልፉ ትራፊክ መሆናቸውን ማየት እንችላለን።

ነገር ግን ከ v2 ጋር ተኳሃኝ ስላልሆነ ትራፊክን ከፊት-v2 ወደ backend-v1 ብቻ ማስተላለፍ ካስፈለገን ምን ማድረግ አለብን? ይህንን ለማድረግ ለግንባር 1/10 ሬሾን እናስቀምጣለን፣ እሱም ድርድርን በመጠቀም ትራፊክ ወደ ኋላ-v2 ምን እንደሚደርስ ይቆጣጠራል። 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

በውጤቱም, እኛ የምንፈልገውን እናገኛለን:

ከመመሪያው የካናሪ አቀራረብ ልዩነቶች

В የመጀመሪያው ክፍል። ሁለት k8s ማሰማራቶችን በመጠቀም የካናሪ ማሰማራትን በእጅ ሰርተናል። እዚያ የተባዙትን ብዛት በመቀየር የጥያቄዎችን ጥምርታ ተቆጣጠርን። ይህ አቀራረብ ይሰራል, ግን ከባድ ድክመቶች አሉት.

ኢስቲዮ የቅጂዎች ብዛት ምንም ይሁን ምን የጥያቄዎችን ጥምርታ ለመወሰን ያስችላል። ይህ ማለት, ለምሳሌ, HPAs ን መጠቀም እንችላለን (አግድም ፖድ አውቶማቲክስ - አግድም ስኬል ኦፍ ፖድ) እና አሁን ባለው የካናሪ ማሰማራት ሁኔታ መሰረት ማዋቀር አያስፈልግም.

ውጤቱ

ኢስቲዮ በጣም ጥሩ ይሰራል እና ከኪያሊ ጋር ሲጣመር በጣም ኃይለኛ ጥምር እናገኛለን። ቀጥሎ በፍላጎቴ ዝርዝር ውስጥ የSpinnaker ከኢስቲዮ ለአውቶሜሽን እና ለካናሪ ትንታኔዎች ጥምረት ነው።

ምንጭ: hab.com