കുബെർനെറ്റസിലെ കാനറി വിന്യാസം #3: ഇസ്റ്റിയോ

ഒരു കാനറി വിന്യാസം സമാരംഭിക്കുന്നതിനും ദൃശ്യവൽക്കരിക്കുന്നതിനും Istio+Kiali ഉപയോഗിക്കുന്നു

ഈ പരമ്പരയിലെ ലേഖനങ്ങൾ

1. കുബർനെറ്റസിലെ കാനറി വിന്യാസം #1: Gitlab CI
2. കുബർനെറ്റസിലെ കാനറി വിന്യാസം #2: ആർഗോ റോൾഔട്ടുകൾ
3. (ഈ ലേഖനം)
4. Jenkins-X Istio Flagger ഉപയോഗിച്ചുള്ള കാനറി വിന്യാസം

കാനറി വിന്യാസം

നിങ്ങൾ വായിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു ആദ്യ ഭാഗം, അവിടെ കാനറി വിന്യാസങ്ങൾ എന്താണെന്ന് ഞങ്ങൾ സംക്ഷിപ്തമായി വിശദീകരിക്കുകയും സ്റ്റാൻഡേർഡ് കുബർനെറ്റസ് ഉറവിടങ്ങൾ ഉപയോഗിച്ച് അവ എങ്ങനെ നടപ്പിലാക്കാമെന്ന് കാണിച്ചുതരികയും ചെയ്തു.

ഇസ്തോ

ഈ ലേഖനം വായിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് ഇസ്തിയോ എന്താണെന്ന് ഇതിനകം അറിയാമെന്ന് ഞങ്ങൾ അനുമാനിക്കുന്നു. ഇല്ലെങ്കിൽ, നിങ്ങൾക്ക് അതിനെക്കുറിച്ച് വായിക്കാം ഇവിടെ.

ടെസ്റ്റുകൾക്കുള്ള അപേക്ഷ

ഓരോ പോഡിലും രണ്ട് കണ്ടെയ്നറുകൾ അടങ്ങിയിരിക്കുന്നു: ഞങ്ങളുടെ ആപ്ലിക്കേഷനും istio-proxy.

ഫ്രണ്ട്‌എൻ‌എൻ‌ജി‌എൻ‌എക്സ്, ബാക്ക്‌എൻഡ് പൈത്തൺ പോഡുകൾ എന്നിവയ്‌ക്കൊപ്പം ഞങ്ങൾ ഒരു ലളിതമായ ടെസ്റ്റ് ആപ്ലിക്കേഷൻ ഉപയോഗിക്കും. nginx പോഡ് ഓരോ അഭ്യർത്ഥനയും ബാക്കെൻഡ് പോഡിലേക്ക് റീഡയറക്ട് ചെയ്യുകയും ഒരു പ്രോക്സി ആയി പ്രവർത്തിക്കുകയും ചെയ്യും. വിശദാംശങ്ങൾ ഇനിപ്പറയുന്ന യാമുകളിൽ കാണാം:

• ഫ്രണ്ട്എൻഡ്.യാംഎൽ
• backend.yaml
• istio.yaml

ടെസ്റ്റ് ആപ്ലിക്കേഷൻ സ്വയം പ്രവർത്തിപ്പിക്കുന്നു

നിങ്ങൾക്ക് എന്റെ മാതൃക പിന്തുടരാനും ഈ ടെസ്റ്റ് ആപ്ലിക്കേഷൻ സ്വയം ഉപയോഗിക്കാനും താൽപ്പര്യമുണ്ടെങ്കിൽ, കാണുക പദ്ധതി വായിക്കുക.

പ്രാരംഭ വിന്യാസം

ഞങ്ങൾ ആദ്യ വിന്യാസം സമാരംഭിക്കുമ്പോൾ, ഞങ്ങളുടെ ആപ്ലിക്കേഷന്റെ പോഡുകൾക്ക് 2 കണ്ടെയ്നറുകൾ മാത്രമേയുള്ളൂവെന്ന് ഞങ്ങൾ കാണുന്നു, അതായത്, ഇസ്തിയോ സൈഡ്കാർ ഇപ്പോൾ നടപ്പിലാക്കുന്നു:

നെയിംസ്‌പെയ്‌സിൽ ഇസ്തിയോ ഗേറ്റ്‌വേ ലോഡ്ബാലൻസറും ഞങ്ങൾ കാണുന്നു 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 ഞങ്ങളുടെ ഹോസ്റ്റ് ഫയലിലേക്ക്.

കിയാലി വഴി മെഷ് കാണുക

ട്രെയ്‌സിംഗ്, ഗ്രാഫാന, പ്രൊമിത്യൂസ്, കിയാലി എന്നിവയ്‌ക്കൊപ്പം ഞങ്ങൾ ടെസ്റ്റ് ആപ്ലിക്കേഷനും ഇസ്തിയോയും ഇൻസ്റ്റാൾ ചെയ്തു (വിശദാംശങ്ങൾക്ക് ചുവടെ കാണുക). പദ്ധതി വായിക്കുക). അതിനാൽ നമുക്ക് കിയാലി ഇതുവഴി ഉപയോഗിക്കാം:

istioctl dashboard kiali # admin:admin

മെഷിലൂടെ നിലവിലെ ട്രാഫിക്കിനെ കിയാലി ദൃശ്യവൽക്കരിക്കുന്നു

ഞങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, ട്രാഫിക്കിന്റെ 100% ഫ്രണ്ട്‌എൻഡ് സേവനത്തിലേക്കും തുടർന്ന് v1 ലേബലുള്ള ഫ്രണ്ട്‌എൻഡ് പോഡുകളിലേക്കും പോകുന്നു, കാരണം ഞങ്ങൾ ഒരു ലളിതമായ nginx പ്രോക്സി ഉപയോഗിക്കുന്നു, അത് ബാക്കെൻഡ് സേവനത്തിലേക്ക് അഭ്യർത്ഥനകൾ റീഡയറക്‌ടുചെയ്യുന്നു, അത് അവയെ ബാക്കെൻഡ് പോഡുകളിലേക്ക് റീഡയറക്‌ടുചെയ്യുന്നു. ലേബലിനൊപ്പം 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-ലേക്ക് റീഡയറക്‌ട് ചെയ്യുന്നു:

കാനറിയെ നേരിട്ട് പരിശോധിക്കുന്നു

ഞങ്ങൾ ഇപ്പോൾ എല്ലാ അഭ്യർത്ഥനകളുടെയും 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 ബാക്കെൻഡ് v1, v2 എന്നീ അനുപാതത്തിൽ ഫോർവേഡ് ട്രാഫിക്കും ഞങ്ങൾ കാണുന്നു.

v2-ന് അനുയോജ്യമല്ലാത്തതിനാൽ ഫ്രണ്ട്‌എൻഡ്-v2-ൽ നിന്ന് ബാക്കെൻഡ്-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 വിന്യാസങ്ങൾ ഉപയോഗിച്ചും ഞങ്ങൾ കാനറി വിന്യാസം സ്വമേധയാ നടത്തി. അവിടെ ഞങ്ങൾ പകർപ്പുകളുടെ എണ്ണം മാറ്റി അഭ്യർത്ഥനകളുടെ അനുപാതം നിയന്ത്രിച്ചു. ഈ സമീപനം പ്രവർത്തിക്കുന്നു, പക്ഷേ ഗുരുതരമായ പോരായ്മകളുണ്ട്.

പകർപ്പുകളുടെ എണ്ണം കണക്കിലെടുക്കാതെ അഭ്യർത്ഥനകളുടെ അനുപാതം നിർണ്ണയിക്കുന്നത് ഇസ്തിയോ സാധ്യമാക്കുന്നു. ഇതിനർത്ഥം, ഉദാഹരണത്തിന്, നമുക്ക് HPA-കൾ (തിരശ്ചീന പോഡ് ഓട്ടോസ്കെയിലറുകൾ) ഉപയോഗിക്കാമെന്നും കാനറി വിന്യാസത്തിന്റെ നിലവിലെ അവസ്ഥയ്ക്ക് അനുസൃതമായി കോൺഫിഗർ ചെയ്യേണ്ടതില്ലെന്നും ആണ്.

ഫലം

ഇസ്റ്റിയോ മികച്ച രീതിയിൽ പ്രവർത്തിക്കുന്നു, കിയാലിക്കൊപ്പം ഇത് ഉപയോഗിക്കുന്നത് വളരെ ശക്തമായ ഒരു കോമ്പിനേഷൻ ഉണ്ടാക്കുന്നു. എന്റെ താൽപ്പര്യങ്ങളുടെ പട്ടികയിൽ അടുത്തത് ഓട്ടോമേഷനും കാനറി അനലിറ്റിക്‌സിനും വേണ്ടി സ്പിന്നക്കറിനെ ഇസ്‌റ്റിയോയുമായി സംയോജിപ്പിക്കുന്നതാണ്.

അവലംബം: www.habr.com