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

የካናሪ ማሰማራቶችን ለማስኬድ እና ለማየት ኢስቲዮ + ኪያሊን መጠቀም

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

1. የካናሪ ማሰማራት በኩበርኔትስ # 1: Gitlab CI
2. የካናሪ ማሰማራት በ Kubernetes # 2: Argo Rollouts
3. (ይህ ጽሑፍ)
4. የጄንኪንስ-ኤክስ ኢስቲዮ ፍላገርን በመጠቀም የካናሪ ማሰማራት

የካናሪ ማሰማራት

እርስዎ እንደሚያነቡት ተስፋ እናደርጋለን የመጀመሪያ ክፍል, የካናሪ ማሰማራቶች ምን እንደሆኑ በአጭሩ አብራርተናል እና መደበኛ የኩበርኔትስ ሀብቶችን በመጠቀም እንዴት ተግባራዊ ማድረግ እንደሚቻል አሳይተናል።

Istio

ይህንን ጽሑፍ በማንበብ ኢስቲዮ ምን እንደሆነ አስቀድመው እንደሚያውቁ እንገምታለን። ካልሆነ ግን ስለሱ የበለጠ እዚህ ማንበብ ይችላሉ። እዚህ.

የሙከራ መተግበሪያ

እያንዳንዱ ፖድ ሁለት ኮንቴይነሮችን ይይዛል፡ የእኛ አፕሊኬሽን እና ኢስቲዮ-ፕሮክሲ።

የፊት ለፊት-NGINX ፖድ እና የኋላ-መጨረሻ የፓይቶን ፖድ ያለው ቀላል የሙከራ መተግበሪያ እንጠቀማለን። የNGINX ፖድ እያንዳንዱን ጥያቄ ወደ የኋላ-መጨረሻ ፖድ ያስተላልፋል እና እንደ ተኪ ሆኖ ያገለግላል። ዝርዝሮቹ በሚከተሉት የYAML ፋይሎች ውስጥ ይገኛሉ፡

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

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

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

የመጀመሪያ ማሰማራት

የመጀመሪያውን ዲፕሎሜሽን ስናስጀምር፣ የአፕሊኬሽኖቻችን ፖዶች እያንዳንዳቸው ሁለት ኮንቴይነሮች ብቻ እንዳላቸው እናያለን፣ ይህም ማለት የኢስቲዮ የጎን ጋሪ አሁንም እየተተገበረ ነው ማለት ነው፡

እንዲሁም በ namespace ውስጥ ኢስቲዮ ጌትዌይ ሎድባሌጀርን እናያለን። istio-system:

የትራፊክ ማመንጨት

የፊት ለፊት ፖዶች የሚቀበሉትን እና ወደ የኋላ መጨረሻ ፖዶች የሚተላለፉትን ትራፊክ ለመፍጠር የሚከተለውን IP እንጠቀማለን፡

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

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

ሜሽ በኪሊ በኩል መመልከት

የሙከራ ማመልከቻ እና ኢስቲዮ ከትራሲንግ፣ ግራፋና፣ ፕሮሜቴየስ እና ኪያሊ ጋር አዘጋጅተናል (ለዝርዝሮች ከታች ይመልከቱ)። ፕሮጀክት readme) ስለዚህ፣ ኪያሊን በሚከተሉት መንገዶች መጠቀም እንችላለን፡

istioctl dashboard kiali # admin:admin

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

እንደምናየው፣ 100% የሚሆነው የትራፊክ ፍሰት ወደ frontend አገልግሎት ይሄዳል፣ ከዚያም label v1 ወዳለው frontend pod ይሄዳል፣ ምክንያቱም ጥያቄዎችን ወደ backend አገልግሎት የሚያስተላልፍ ቀላል የnginx ፕሮክሲ እንጠቀማለን፣ ይህም በተራው label v1 ወዳለው backend pods ያስተላልፋል።

ኪያሊ ከኢስቲዮ ጋር በጥሩ ሁኔታ ይሰራል እና ለሜሽ ቪዥዋል አብሮ የተሰራ መፍትሄ ይሰጣል። በቀላሉ አስደናቂ ነው።

የካናሪ ማሰማራት

የኋላ ክፍላችን ሁለት የ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 ይዛወራል፡

በእጅ የተሰራ የካናሪ ሙከራ

በአሁኑ ጊዜ 10% የሚሆኑትን ጥያቄዎች ወደ v2 backend እየላክን ነው እንበል። ሁሉም ነገር እንደተጠበቀው እንዲሰራ ለማረጋገጥ 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

አሁን ኩርልን በመጠቀም ራስጌውን በመላክ ለ v2 ጥያቄ ማስገደድ እንችላለን፡

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

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

አሁን ለግንባር እና ለኋላ ገፅ v2 ያለንበትን ሁኔታ እንመልከት። ለሁለቱም፣ 10% የሚሆነው የትራፊክ ፍሰት ወደ v2 መሄድ እንዳለበት ገልጸናል፡

የፊት ለፊት v1 እና v2 ሁለቱም የፊት ለፊት ትራፊክ ከኋላ በኩል v1 እና v2 ጋር በ1/10 ጥምርታ እናያለን።

ከv1 ጋር ተኳሃኝ ስላልሆነ ከfrontend-v2 የሚመጣውን ትራፊክ ወደ backend-v2 ብቻ ማስተላለፍ ቢያስፈልገንስ? ይህንን ለማድረግ፣ ለfrontend 1/10 ጥምርታ እናስቀምጣለን፣ ይህም በማቻቻል በመጠቀም ወደ backend-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 (Horizontal Pod Autoscalers) መጠቀም እንችላለን ማለት ነው።

ውጤቱ

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

ምንጭ: hab.com