ഇസ്തിയോയ്‌ക്കൊപ്പം മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക. ഭാഗം 2

കുറിപ്പ്. വിവർത്തനം.: ആദ്യ ഭാഗം ഈ സീരീസ് ഇസ്തിയോ കഴിവുകൾ അവതരിപ്പിക്കുന്നതിനും അവ പ്രവർത്തനത്തിൽ പ്രകടിപ്പിക്കുന്നതിനുമായി സമർപ്പിച്ചിരിക്കുന്നു. ഈ സേവന മെഷിൻ്റെ കോൺഫിഗറേഷൻ്റെയും ഉപയോഗത്തിൻ്റെയും കൂടുതൽ സങ്കീർണ്ണമായ വശങ്ങളെക്കുറിച്ചും പ്രത്യേകിച്ച്, നന്നായി ട്യൂൺ ചെയ്ത റൂട്ടിംഗിനെയും നെറ്റ്‌വർക്ക് ട്രാഫിക് മാനേജുമെൻ്റിനെയും കുറിച്ച് ഞങ്ങൾ ഇപ്പോൾ സംസാരിക്കും.

ലേഖനം ശേഖരണത്തിൽ നിന്നുള്ള കോൺഫിഗറേഷനുകൾ (കുബർനെറ്റസിനും ഇസ്തിയോയ്ക്കും മാനിഫെസ്റ്റുകൾ) ഉപയോഗിക്കുന്നുണ്ടെന്നും ഞങ്ങൾ നിങ്ങളെ ഓർമ്മിപ്പിക്കുന്നു. istio-mastery.

ട്രാഫിക് മാനേജ്മെന്റ്

Istio ഉപയോഗിച്ച്, ക്ലസ്റ്ററിൽ പുതിയ കഴിവുകൾ ദൃശ്യമാകും:

• ഡൈനാമിക് അഭ്യർത്ഥന റൂട്ടിംഗ്: കാനറി റോൾഔട്ടുകൾ, എ/ബി ടെസ്റ്റിംഗ്;
• ലോഡ് ബാലൻസിങ്: ലളിതവും സ്ഥിരതയുള്ളതും, ഹാഷുകളെ അടിസ്ഥാനമാക്കിയുള്ളതും;
• വീഴ്ചയ്ക്ക് ശേഷം വീണ്ടെടുക്കൽ: കാലഹരണപ്പെടൽ, വീണ്ടും ശ്രമിക്കൽ, സർക്യൂട്ട് ബ്രേക്കറുകൾ;
• പിഴവുകൾ ചേർക്കുന്നു: കാലതാമസം, ഉപേക്ഷിച്ച അഭ്യർത്ഥനകൾ മുതലായവ.

ലേഖനം തുടരുമ്പോൾ, തിരഞ്ഞെടുത്ത ആപ്ലിക്കേഷൻ ഒരു ഉദാഹരണമായി ഉപയോഗിച്ച് ഈ കഴിവുകൾ ചിത്രീകരിക്കുകയും പുതിയ ആശയങ്ങൾ വഴിയിൽ അവതരിപ്പിക്കുകയും ചെയ്യും. അത്തരമൊരു ആശയം ആദ്യമായിരിക്കും DestinationRules (അതായത് ട്രാഫിക്/അഭ്യർത്ഥനകൾ സ്വീകർത്താവിനെക്കുറിച്ചുള്ള നിയമങ്ങൾ - ഏകദേശം. വിവർത്തനം.), അതിൻ്റെ സഹായത്തോടെ ഞങ്ങൾ A/B ടെസ്റ്റിംഗ് സജീവമാക്കുന്നു.

എ/ബി ടെസ്റ്റിംഗ്: ഡെസ്റ്റിനേഷൻ റൂൾസ് പ്രയോഗത്തിലാണ്

ഒരു ആപ്ലിക്കേഷൻ്റെ രണ്ട് പതിപ്പുകൾ ഉള്ള സന്ദർഭങ്ങളിൽ A/B ടെസ്റ്റിംഗ് ഉപയോഗിക്കുന്നു (സാധാരണയായി അവ ദൃശ്യപരമായി വ്യത്യസ്തമാണ്) കൂടാതെ ഏതാണ് ഉപയോക്തൃ അനുഭവം മെച്ചപ്പെടുത്തുമെന്ന് ഞങ്ങൾക്ക് 100% ഉറപ്പില്ല. അതിനാൽ, ഞങ്ങൾ രണ്ട് പതിപ്പുകളും ഒരേസമയം പ്രവർത്തിപ്പിക്കുകയും അളവുകൾ ശേഖരിക്കുകയും ചെയ്യുന്നു.

A/B ടെസ്റ്റിംഗ് പ്രദർശിപ്പിക്കുന്നതിന് ആവശ്യമായ ഫ്രണ്ട്എൻഡിൻ്റെ രണ്ടാമത്തെ പതിപ്പ് വിന്യസിക്കാൻ, ഇനിപ്പറയുന്ന കമാൻഡ് പ്രവർത്തിപ്പിക്കുക:

$ kubectl apply -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions/sa-frontend-green created

പച്ച പതിപ്പിനുള്ള വിന്യാസ മാനിഫെസ്റ്റ് രണ്ട് സ്ഥലങ്ങളിൽ വ്യത്യാസപ്പെട്ടിരിക്കുന്നു:

1. ചിത്രം മറ്റൊരു ടാഗിനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ് - istio-green,
2. പോഡുകൾക്ക് ഒരു ലേബൽ ഉണ്ട് version: green.

രണ്ട് വിന്യാസങ്ങൾക്കും ഒരു ലേബൽ ഉള്ളതിനാൽ app: sa-frontend, വെർച്വൽ സേവനം വഴി അഭ്യർത്ഥനകൾ sa-external-services സേവനത്തിനായി sa-frontend, അതിൻ്റെ എല്ലാ സന്ദർഭങ്ങളിലേക്കും റീഡയറക്‌ട് ചെയ്യുകയും ലോഡ് വിതരണം ചെയ്യുകയും ചെയ്യും റൗണ്ട് റോബിൻ അൽഗോരിതം, ഇത് ഇനിപ്പറയുന്ന അവസ്ഥയിലേക്ക് നയിക്കും:

ആവശ്യപ്പെട്ട ഫയലുകൾ കണ്ടെത്തിയില്ല

ആപ്ലിക്കേഷൻ്റെ വ്യത്യസ്ത പതിപ്പുകളിൽ വ്യത്യസ്തമായി പേരിട്ടിരിക്കുന്നതിനാൽ ഈ ഫയലുകൾ കണ്ടെത്തിയില്ല. നമുക്ക് ഇത് ഉറപ്പാക്കാം:

$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.c7071b22.css
/static/js/main.059f8e9c.js
$ curl --silent http://$EXTERNAL_IP/ | tr '"' 'n' | grep main
/static/css/main.f87cd8c9.css
/static/js/main.f7659dbb.js

ഇതിനർത്ഥം index.html, സ്റ്റാറ്റിക് ഫയലുകളുടെ ഒരു പതിപ്പ് അഭ്യർത്ഥിക്കുന്നു, മറ്റൊരു പതിപ്പുള്ള പോഡുകളിലേക്ക് ലോഡ് ബാലൻസറിന് അയയ്ക്കാൻ കഴിയും, അവിടെ, വ്യക്തമായ കാരണങ്ങളാൽ, അത്തരം ഫയലുകൾ നിലവിലില്ല. അതിനാൽ, ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നതിന്, ഞങ്ങൾ ഒരു നിയന്ത്രണം സജ്ജീകരിക്കേണ്ടതുണ്ട്: "index.html നൽകിയ ആപ്ലിക്കേഷൻ്റെ അതേ പതിപ്പ് തുടർന്നുള്ള അഭ്യർത്ഥനകൾ നൽകണം".

സ്ഥിരമായ ഹാഷ് അധിഷ്‌ഠിത ലോഡ് ബാലൻസിംഗ് ഉപയോഗിച്ച് ഞങ്ങൾ അവിടെയെത്തും (സ്ഥിരമായ ഹാഷ് ലോഡ് ബാലൻസിങ്). ഈ സാഹചര്യത്തിൽ ഒരേ ക്ലയൻ്റിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾ അതേ ബാക്കെൻഡ് ഉദാഹരണത്തിലേക്ക് അയയ്ക്കുന്നു, ഇതിനായി ഒരു മുൻനിശ്ചയിച്ച പ്രോപ്പർട്ടി ഉപയോഗിക്കുന്നു - ഉദാഹരണത്തിന്, ഒരു HTTP തലക്കെട്ട്. ഡെസ്റ്റിനേഷൻ റൂൾസ് ഉപയോഗിച്ച് നടപ്പിലാക്കിയത്.

ലക്ഷ്യ നിയമങ്ങൾ

അതിനുശേഷം വെർച്വൽ സേവനം ആവശ്യമുള്ള സേവനത്തിലേക്ക് ഒരു അഭ്യർത്ഥന അയച്ചു, ഡെസ്റ്റിനേഷൻ റൂൾസ് ഉപയോഗിച്ച്, ഈ സേവനത്തിൻ്റെ ഉദാഹരണങ്ങൾക്കായി നിശ്ചയിച്ചിട്ടുള്ള ട്രാഫിക്കിന് ബാധകമാകുന്ന നയങ്ങൾ നമുക്ക് നിർവചിക്കാം:

ഇസ്തിയോ വിഭവങ്ങൾ ഉപയോഗിച്ച് ട്രാഫിക് മാനേജ്മെൻ്റ്

അഭിപായപ്പെടുക: നെറ്റ്‌വർക്ക് ട്രാഫിക്കിൽ ഇസ്തിയോ ഉറവിടങ്ങളുടെ സ്വാധീനം മനസ്സിലാക്കാൻ എളുപ്പമുള്ള രീതിയിൽ ഇവിടെ അവതരിപ്പിച്ചിരിക്കുന്നു. കൃത്യമായി പറഞ്ഞാൽ, സിആർഡിയിൽ കോൺഫിഗർ ചെയ്‌തിരിക്കുന്ന ഇൻഗ്രെസ് ഗേറ്റ്‌വേയിലെ ദൂതനാണ് അഭ്യർത്ഥന അയയ്‌ക്കേണ്ട കാര്യം തീരുമാനിക്കുന്നത്.

ഡെസ്റ്റിനേഷൻ റൂളുകൾ ഉപയോഗിച്ച്, സ്ഥിരമായ ഹാഷുകൾ ഉപയോഗിക്കുന്നതിന് ഞങ്ങൾക്ക് ലോഡ് ബാലൻസിംഗ് കോൺഫിഗർ ചെയ്യാനും അതേ സേവന സംഭവം ഒരേ ഉപയോക്താവിനോട് പ്രതികരിക്കുന്നുവെന്ന് ഉറപ്പാക്കാനും കഴിയും. ഇത് നേടാൻ ഇനിപ്പറയുന്ന കോൺഫിഗറേഷൻ നിങ്ങളെ അനുവദിക്കുന്നു (destinationrule-sa-frontend.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-frontend
spec:
  host: sa-frontend
  trafficPolicy:
    loadBalancer:
      consistentHash:
        httpHeaderName: version   # 1

1 - HTTP തലക്കെട്ടിൻ്റെ ഉള്ളടക്കത്തെ അടിസ്ഥാനമാക്കി ഹാഷ് ജനറേറ്റുചെയ്യും version.

ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച് കോൺഫിഗറേഷൻ പ്രയോഗിക്കുക:

$ kubectl apply -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io/sa-frontend created

ഇപ്പോൾ താഴെയുള്ള കമാൻഡ് പ്രവർത്തിപ്പിക്കുക, നിങ്ങൾ തലക്കെട്ട് വ്യക്തമാക്കുമ്പോൾ നിങ്ങൾക്ക് ശരിയായ ഫയലുകൾ ലഭിക്കുന്നുണ്ടെന്ന് ഉറപ്പാക്കുക version:

$ curl --silent -H "version: yogo" http://$EXTERNAL_IP/ | tr '"' 'n' | grep main

അഭിപായപ്പെടുക: തലക്കെട്ടിൽ വ്യത്യസ്ത മൂല്യങ്ങൾ ചേർക്കാനും ബ്രൗസറിൽ നേരിട്ട് ഫലങ്ങൾ പരിശോധിക്കാനും, നിങ്ങൾക്ക് ഉപയോഗിക്കാം ഈ വിപുലീകരണം Chrome-ലേക്ക് (അല്ലെങ്കിൽ ഇതിനോടൊപ്പം Firefox-ന് - ഏകദേശം. പരിഭാഷ.).

പൊതുവേ, ഡെസ്റ്റിനേഷൻ റൂൾസിന് ലോഡ് ബാലൻസിംഗ് മേഖലയിൽ കൂടുതൽ കഴിവുകളുണ്ട് - വിശദാംശങ്ങൾക്കായി പരിശോധിക്കുക ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ.

വെർച്വൽ സർവീസ് കൂടുതൽ പഠിക്കുന്നതിന് മുമ്പ്, ഇനിപ്പറയുന്ന കമാൻഡുകൾ പ്രവർത്തിപ്പിച്ച് ആപ്ലിക്കേഷൻ്റെ "പച്ച പതിപ്പും" അനുബന്ധ ട്രാഫിക് ദിശാ നിയമവും ഇല്ലാതാക്കാം:

$ kubectl delete -f resource-manifests/kube/ab-testing/sa-frontend-green-deployment.yaml
deployment.extensions “sa-frontend-green” deleted
$ kubectl delete -f resource-manifests/istio/ab-testing/destinationrule-sa-frontend.yaml
destinationrule.networking.istio.io “sa-frontend” deleted

മിററിംഗ്: പ്രാക്ടീസിലുള്ള വെർച്വൽ സേവനങ്ങൾ

നിഴൽ ("കവചം") അല്ലെങ്കിൽ മിററിംഗ് ("മിററിംഗ്") അന്തിമ ഉപയോക്താക്കളെ ബാധിക്കാതെ ഉൽപ്പാദനത്തിലെ മാറ്റം പരിശോധിക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്ന സന്ദർഭങ്ങളിൽ ഉപയോഗിക്കുന്നു: ഇത് ചെയ്യുന്നതിന്, ആവശ്യമുള്ള മാറ്റങ്ങൾ വരുത്തിയ രണ്ടാമത്തെ സംഭവത്തിലേക്ക് ഞങ്ങൾ (“മിറർ”) അഭ്യർത്ഥനകൾ ഡ്യൂപ്ലിക്കേറ്റ് ചെയ്യുകയും അനന്തരഫലങ്ങൾ നോക്കുകയും ചെയ്യുന്നു. ലളിതമായി പറഞ്ഞാൽ, നിങ്ങളുടെ സഹപ്രവർത്തകൻ ഏറ്റവും നിർണായകമായ പ്രശ്നം തിരഞ്ഞെടുത്ത് ആർക്കും അത് അവലോകനം ചെയ്യാൻ കഴിയാത്തത്ര വലിയ അഴുക്കിൻ്റെ രൂപത്തിൽ ഒരു പിൻവലിക്കൽ അഭ്യർത്ഥന നടത്തുമ്പോഴാണ്.

ഈ സാഹചര്യം പ്രവർത്തനത്തിൽ പരിശോധിക്കുന്നതിന്, ബഗുകൾ ഉപയോഗിച്ച് SA-Logic-ൻ്റെ രണ്ടാമത്തെ ഉദാഹരണം സൃഷ്ടിക്കാം (buggy) ഇനിപ്പറയുന്ന കമാൻഡ് പ്രവർത്തിപ്പിക്കുന്നതിലൂടെ:

$ kubectl apply -f resource-manifests/kube/shadowing/sa-logic-service-buggy.yaml
deployment.extensions/sa-logic-buggy created

ഇപ്പോൾ എല്ലാ സംഭവങ്ങളും ഉണ്ടെന്ന് ഉറപ്പാക്കാൻ കമാൻഡ് പ്രവർത്തിപ്പിക്കാം app=sa-logic അവയ്ക്ക് അനുബന്ധ പതിപ്പുകളുള്ള ലേബലുകളും ഉണ്ട്:

$ kubectl get pods -l app=sa-logic --show-labels
NAME                              READY   LABELS
sa-logic-568498cb4d-2sjwj         2/2     app=sa-logic,version=v1
sa-logic-568498cb4d-p4f8c         2/2     app=sa-logic,version=v1
sa-logic-buggy-76dff55847-2fl66   2/2     app=sa-logic,version=v2
sa-logic-buggy-76dff55847-kx8zz   2/2     app=sa-logic,version=v2

സേവനം sa-logic ഒരു ലേബൽ ഉപയോഗിച്ച് പോഡുകൾ ലക്ഷ്യമിടുന്നു app=sa-logic, അതിനാൽ എല്ലാ അഭ്യർത്ഥനകളും എല്ലാ സന്ദർഭങ്ങളിലും വിതരണം ചെയ്യും:

... എന്നാൽ അഭ്യർത്ഥനകൾ v1 സംഭവങ്ങളിലേക്ക് അയയ്‌ക്കാനും v2 സന്ദർഭങ്ങളിലേക്ക് മിറർ ചെയ്യാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നു:

DestinationRule-മായി സംയോജിപ്പിച്ച് VirtualService-ലൂടെ ഞങ്ങൾ ഇത് നേടും, അവിടെ നിയമങ്ങൾ VirtualService-ൻ്റെ ഉപസെറ്റുകളും റൂട്ടുകളും ഒരു നിർദ്ദിഷ്‌ട ഉപസെറ്റിലേക്ക് നിർണ്ണയിക്കും.

ഡെസ്റ്റിനേഷൻ റൂളുകളിൽ ഉപസെറ്റുകൾ നിർവചിക്കുന്നു

ഉപവിഭാഗങ്ങൾ (ഉപഗണങ്ങൾ) ഇനിപ്പറയുന്ന കോൺഫിഗറേഷനാൽ നിർണ്ണയിക്കപ്പെടുന്നു (sa-logic-subsets-destinationrule.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: sa-logic
spec:
  host: sa-logic    # 1
  subsets:
  - name: v1        # 2
    labels:
      version: v1   # 3
  - name: v2
    labels:
      version: v2

1. ഹോസ്റ്റ് (host) റൂട്ട് സേവനത്തിലേക്ക് പോകുമ്പോൾ മാത്രമേ ഈ നിയമം ബാധകമാകൂ എന്ന് നിർവചിക്കുന്നു sa-logic;
2. ശീർഷകങ്ങൾ (name) ഉപസെറ്റ് സംഭവങ്ങളിലേക്ക് റൂട്ട് ചെയ്യുമ്പോൾ ഉപസെറ്റുകൾ ഉപയോഗിക്കുന്നു;
3. ലേബൽ (label) ഉപസെറ്റിൻ്റെ ഭാഗമാകാൻ സന്ദർഭങ്ങൾ പൊരുത്തപ്പെടേണ്ട കീ-വാല്യൂ ജോഡികൾ നിർവചിക്കുന്നു.

ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച് കോൺഫിഗറേഷൻ പ്രയോഗിക്കുക:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-destinationrule.yaml
destinationrule.networking.istio.io/sa-logic created

ഇപ്പോൾ ഉപസെറ്റുകൾ നിർവചിക്കപ്പെട്ടിരിക്കുന്നു, സാ-ലോജിക്കിലേക്കുള്ള അഭ്യർത്ഥനകൾക്ക് നിയമങ്ങൾ പ്രയോഗിക്കുന്നതിന് വിർച്ച്വൽ സർവീസ് കോൺഫിഗർ ചെയ്യാനും നമുക്ക് മുന്നോട്ട് പോകാനും കഴിയും.

1. ഒരു ഉപവിഭാഗത്തിലേക്ക് വഴിതിരിച്ചുവിട്ടു v1,
2. ഒരു ഉപവിഭാഗത്തിലേക്ക് മിറർ ചെയ്തു v2.

നിങ്ങളുടെ പദ്ധതികൾ സാക്ഷാത്കരിക്കാൻ ഇനിപ്പറയുന്ന മാനിഫെസ്റ്റോ നിങ്ങളെ അനുവദിക്കുന്നു (sa-logic-subsets-shadowing-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic          
  http:
  - route:
    - destination:
        host: sa-logic  
        subset: v1      
    mirror:             
      host: sa-logic     
      subset: v2

ഇവിടെ വിശദീകരണമൊന്നും ആവശ്യമില്ല, അതിനാൽ നമുക്ക് അത് പ്രവർത്തനത്തിൽ നോക്കാം:

$ kubectl apply -f resource-manifests/istio/shadowing/sa-logic-subsets-shadowing-vs.yaml
virtualservice.networking.istio.io/sa-logic created

ഇനിപ്പറയുന്ന കമാൻഡ് വിളിച്ച് നമുക്ക് ലോഡ് ചേർക്കാം:

$ while true; do curl -v http://$EXTERNAL_IP/sentiment 
    -H "Content-type: application/json" 
    -d '{"sentence": "I love yogobella"}'; 
    sleep .8; done

ഗ്രാഫാനയിലെ ഫലങ്ങൾ നോക്കാം, അവിടെ നിങ്ങൾക്ക് ബഗുകളുള്ള പതിപ്പ് കാണാൻ കഴിയും (buggy) ~60% അഭ്യർത്ഥനകൾക്ക് പരാജയം സംഭവിക്കുന്നു, എന്നാൽ ഈ പരാജയങ്ങളൊന്നും അന്തിമ ഉപയോക്താക്കളെ ബാധിക്കില്ല, കാരണം അവർ ഒരു റൺ ചെയ്യുന്ന സേവനത്തിലൂടെ പ്രതികരിക്കുന്നു.

sa-logic സേവനത്തിൻ്റെ വ്യത്യസ്ത പതിപ്പുകളുടെ വിജയകരമായ പ്രതികരണങ്ങൾ

ഞങ്ങളുടെ സേവനങ്ങളുടെ ദൂതന്മാർക്ക് വെർച്വൽ സർവീസ് എങ്ങനെ പ്രയോഗിക്കുന്നുവെന്ന് ഞങ്ങൾ ആദ്യം ഇവിടെ കണ്ടു: എപ്പോൾ sa-web-app ഒരു അഭ്യർത്ഥന നടത്തുന്നു sa-logic, ഇത് സൈഡ്കാർ എൻവോയ് വഴി കടന്നുപോകുന്നു, അത് - VirtualService വഴി - v1 ഉപസെറ്റിലേക്ക് അഭ്യർത്ഥന റൂട്ട് ചെയ്യുന്നതിനും സേവനത്തിൻ്റെ v2 ഉപസെറ്റിലേക്ക് അഭ്യർത്ഥന പ്രതിഫലിപ്പിക്കുന്നതിനും ക്രമീകരിച്ചിരിക്കുന്നു. sa-logic.

എനിക്കറിയാം, വെർച്വൽ സേവനങ്ങൾ ലളിതമാണെന്ന് നിങ്ങൾ ഇതിനകം ചിന്തിച്ചേക്കാം. അടുത്ത വിഭാഗത്തിൽ, അവരും മികച്ചവരാണെന്ന് പറഞ്ഞുകൊണ്ട് ഞങ്ങൾ അത് വിപുലീകരിക്കും.

കാനറി റോൾഔട്ടുകൾ

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

കാനറി റോൾഔട്ടുകൾ പ്രദർശിപ്പിക്കുന്നതിന്, ഞങ്ങൾ ഒരു ഉപവിഭാഗവുമായി പ്രവർത്തിക്കുന്നത് തുടരും buggy у sa-logic.

നിസ്സാരകാര്യങ്ങളിൽ സമയം പാഴാക്കരുത്, 20% ഉപയോക്താക്കളെ ബഗുകളുള്ള പതിപ്പിലേക്ക് ഉടൻ അയയ്ക്കുക (ഇത് ഞങ്ങളുടെ കാനറി റോൾഔട്ടിനെ പ്രതിനിധീകരിക്കും), ശേഷിക്കുന്ന 80% സാധാരണ സേവനത്തിലേക്ക്. ഇത് ചെയ്യുന്നതിന്, ഇനിപ്പറയുന്ന വിർച്ച്വൽ സേവനം ഉപയോഗിക്കുക (sa-logic-subsets-canary-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic    
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 80         # 1
    - destination: 
        host: sa-logic
        subset: v2
      weight: 20 # 1

1 ആണ് ഭാരം (weight), ഇത് ഒരു സ്വീകർത്താവിലേക്കോ സ്വീകർത്താവിൻ്റെ ഒരു ഉപവിഭാഗത്തിലേക്കോ അയയ്ക്കുന്ന അഭ്യർത്ഥനകളുടെ ശതമാനം വ്യക്തമാക്കുന്നു.

മുമ്പത്തെ വിർച്ച്വൽ സർവീസ് കോൺഫിഗറേഷൻ അപ്ഡേറ്റ് ചെയ്യാം sa-logic ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച്:

$ kubectl apply -f resource-manifests/istio/canary/sa-logic-subsets-canary-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

... ചില അഭ്യർത്ഥനകൾ പരാജയത്തിലേക്ക് നയിക്കുന്നതായി ഞങ്ങൾ ഉടൻ കാണും:

$ while true; do 
   curl -i http://$EXTERNAL_IP/sentiment 
   -H "Content-type: application/json" 
   -d '{"sentence": "I love yogobella"}' 
   --silent -w "Time: %{time_total}s t Status: %{http_code}n" 
   -o /dev/null; sleep .1; done
Time: 0.153075s Status: 200
Time: 0.137581s Status: 200
Time: 0.139345s Status: 200
Time: 30.291806s Status: 500

വെർച്വൽ സർവീസുകൾ കാനറി റോൾഔട്ടുകൾ പ്രാപ്തമാക്കുന്നു: ഈ സാഹചര്യത്തിൽ, പ്രശ്നങ്ങളുടെ സാധ്യതയുള്ള ആഘാതം ഞങ്ങൾ ഉപയോക്തൃ അടിത്തറയുടെ 20% ആയി ചുരുക്കിയിരിക്കുന്നു. അത്ഭുതം! ഇപ്പോൾ, നമ്മുടെ കോഡ് (മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ - എപ്പോഴും...) ഉറപ്പില്ലാത്ത എല്ലാ സന്ദർഭങ്ങളിലും, നമുക്ക് മിററിംഗ്, കാനറി റോൾഔട്ടുകൾ എന്നിവ ഉപയോഗിക്കാം.

സമയപരിധിയും വീണ്ടും ശ്രമങ്ങളും

എന്നാൽ ബഗുകൾ എല്ലായ്പ്പോഴും കോഡിൽ അവസാനിക്കുന്നില്ല. " എന്നതിൽ നിന്നുള്ള പട്ടികയിൽ8 ഡിസ്ട്രിബ്യൂട്ടഡ് കമ്പ്യൂട്ടിംഗിനെ കുറിച്ചുള്ള തെറ്റിദ്ധാരണകൾ"ശൃംഖല വിശ്വസനീയമാണ്" എന്ന തെറ്റായ വിശ്വാസമാണ് ഒന്നാമത്തേത്. വാസ്തവത്തിൽ നെറ്റ്വർക്ക് അല്ല വിശ്വസനീയമാണ്, ഇക്കാരണത്താൽ ഞങ്ങൾക്ക് സമയപരിധി ആവശ്യമാണ് (കാലഹരണപ്പെടലുകൾ) വീണ്ടും ശ്രമിക്കുന്നു (വീണ്ടും ശ്രമിക്കുന്നു).

പ്രകടനത്തിനായി ഞങ്ങൾ അതേ പ്രശ്ന പതിപ്പ് ഉപയോഗിക്കുന്നത് തുടരും sa-logic (buggy), കൂടാതെ ഞങ്ങൾ ക്രമരഹിതമായ പരാജയങ്ങൾ ഉപയോഗിച്ച് നെറ്റ്‌വർക്കിൻ്റെ വിശ്വാസ്യതയെ അനുകരിക്കും.

ബഗുകളുള്ള ഞങ്ങളുടെ സേവനത്തിന് പ്രതികരിക്കാൻ കൂടുതൽ സമയമെടുക്കാനുള്ള 1/3 അവസരവും ആന്തരിക സെർവർ പിശകിൽ അവസാനിക്കാനുള്ള 1/3 സാധ്യതയും പേജ് വിജയകരമായി തിരികെ നൽകാനുള്ള 1/3 അവസരവും അനുവദിക്കുക.

അത്തരം പ്രശ്‌നങ്ങളുടെ ആഘാതം ലഘൂകരിക്കാനും ഉപയോക്താക്കൾക്ക് ജീവിതം മികച്ചതാക്കാനും, ഞങ്ങൾക്ക് ഇവ ചെയ്യാനാകും:

1. സേവനം പ്രതികരിക്കാൻ 8 സെക്കൻഡിൽ കൂടുതൽ സമയമെടുക്കുകയാണെങ്കിൽ, ഒരു സമയപരിധി ചേർക്കുക,
2. അഭ്യർത്ഥന പരാജയപ്പെട്ടാൽ വീണ്ടും ശ്രമിക്കുക.

നടപ്പിലാക്കുന്നതിനായി, ഞങ്ങൾ ഇനിപ്പറയുന്ന ഉറവിട നിർവ്വചനം ഉപയോഗിക്കും (sa-logic-retriries-timeouts-vs.yaml):

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: sa-logic
spec:
  hosts:
    - sa-logic
  http:
  - route: 
    - destination: 
        host: sa-logic
        subset: v1
      weight: 50
    - destination: 
        host: sa-logic
        subset: v2
      weight: 50
    timeout: 8s           # 1
    retries:
      attempts: 3         # 2
      perTryTimeout: 3s # 3

1. അഭ്യർത്ഥനയുടെ സമയപരിധി 8 സെക്കൻഡായി സജ്ജീകരിച്ചിരിക്കുന്നു;
2. അഭ്യർത്ഥനകൾ 3 തവണ വീണ്ടും ശ്രമിച്ചു;
3. പ്രതികരണ സമയം 3 സെക്കൻഡിൽ കൂടുതലാണെങ്കിൽ ഓരോ ശ്രമവും പരാജയപ്പെട്ടതായി കണക്കാക്കുന്നു.

ഇത് ഒരു ഒപ്റ്റിമൈസേഷനാണ്, കാരണം ഉപയോക്താവിന് 8 സെക്കൻഡിൽ കൂടുതൽ കാത്തിരിക്കേണ്ടി വരില്ല, പരാജയങ്ങളുടെ കാര്യത്തിൽ പ്രതികരണം ലഭിക്കാൻ ഞങ്ങൾ മൂന്ന് പുതിയ ശ്രമങ്ങൾ നടത്തും, വിജയകരമായ പ്രതികരണത്തിനുള്ള സാധ്യത വർദ്ധിപ്പിക്കും.

ഇനിപ്പറയുന്ന കമാൻഡ് ഉപയോഗിച്ച് അപ്‌ഡേറ്റ് ചെയ്ത കോൺഫിഗറേഷൻ പ്രയോഗിക്കുക:

$ kubectl apply -f resource-manifests/istio/retries/sa-logic-retries-timeouts-vs.yaml
virtualservice.networking.istio.io/sa-logic configured

വിജയകരമായ പ്രതികരണങ്ങളുടെ എണ്ണം മുകളിൽ വർദ്ധിച്ചിട്ടുണ്ടോ എന്ന് ഗ്രാഫാന ഗ്രാഫുകളിൽ പരിശോധിക്കുക:

ടൈംഔട്ടുകളും ആവർത്തനങ്ങളും ചേർത്തതിന് ശേഷം വിജയകരമായ പ്രതികരണ സ്ഥിതിവിവരക്കണക്കുകളിലെ മെച്ചപ്പെടുത്തലുകൾ

അടുത്ത വിഭാഗത്തിലേക്ക് പോകുന്നതിന് മുമ്പ് (അല്ലെങ്കിൽ, ലേഖനത്തിൻ്റെ അടുത്ത ഭാഗത്തേക്ക്, കാരണം ഇതിൽ കൂടുതൽ പ്രായോഗിക പരീക്ഷണങ്ങൾ ഉണ്ടാകില്ല - ഏകദേശം വിവർത്തനം.), ഇല്ലാതാക്കുക sa-logic-buggy ഇനിപ്പറയുന്ന കമാൻഡുകൾ പ്രവർത്തിപ്പിച്ച് VirtualService ഉം:

$ kubectl delete deployment sa-logic-buggy
deployment.extensions “sa-logic-buggy” deleted
$ kubectl delete virtualservice sa-logic
virtualservice.networking.istio.io “sa-logic” deleted

സർക്യൂട്ട് ബ്രേക്കറും ബൾക്ക്ഹെഡ് പാറ്റേണുകളും

സ്വയം വീണ്ടെടുക്കൽ നേടാൻ നിങ്ങളെ അനുവദിക്കുന്ന മൈക്രോ സർവീസ് ആർക്കിടെക്ചറിലെ രണ്ട് പ്രധാന പാറ്റേണുകളെക്കുറിച്ചാണ് ഞങ്ങൾ സംസാരിക്കുന്നത് (സ്വയം സുഖപ്പെടുത്തൽ) സേവനങ്ങള്.

സർക്യൂട്ട് ബ്രേക്കർ ("സർക്യൂട്ട് ബ്രേക്കർ") അനാരോഗ്യകരമെന്ന് കരുതുന്ന ഒരു സേവനത്തിൻ്റെ സന്ദർഭത്തിലേക്ക് വരുന്ന അഭ്യർത്ഥനകൾ അവസാനിപ്പിക്കാനും ക്ലയൻ്റ് അഭ്യർത്ഥനകൾ ആ സേവനത്തിൻ്റെ ആരോഗ്യകരമായ സന്ദർഭങ്ങളിലേക്ക് റീഡയറക്‌ട് ചെയ്യപ്പെടുമ്പോൾ അത് പുനഃസ്ഥാപിക്കാനും ഉപയോഗിക്കുന്നു (ഇത് വിജയകരമായ പ്രതികരണങ്ങളുടെ ശതമാനം വർദ്ധിപ്പിക്കുന്നു). (ശ്രദ്ധിക്കുക: പാറ്റേണിൻ്റെ കൂടുതൽ വിശദമായ വിവരണം കണ്ടെത്താം, ഉദാഹരണത്തിന്, ഇവിടെ.)

ബൾക്ക്ഹെഡ് ("വിഭജനം") മുഴുവൻ സിസ്റ്റത്തെയും ബാധിക്കുന്നതിൽ നിന്ന് സേവന പരാജയങ്ങളെ ഒറ്റപ്പെടുത്തുന്നു. ഉദാഹരണത്തിന്, സർവീസ് ബി തകരാറിലായി, മറ്റൊരു സേവനം (സർവീസ് ബിയുടെ ക്ലയൻ്റ്) സർവീസ് ബി-ലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തുന്നു, ഇത് അതിൻ്റെ ത്രെഡ് പൂൾ തീർന്നുപോകുകയും മറ്റ് അഭ്യർത്ഥനകൾക്ക് സേവനം നൽകാതിരിക്കുകയും ചെയ്യുന്നു (അവർ സർവീസ് ബിയിൽ നിന്നുള്ളതല്ലെങ്കിൽ പോലും). (ശ്രദ്ധിക്കുക: പാറ്റേണിൻ്റെ കൂടുതൽ വിശദമായ വിവരണം കണ്ടെത്താം, ഉദാഹരണത്തിന്, ഇവിടെ.)

ഈ പാറ്റേണുകളുടെ നടപ്പാക്കൽ വിശദാംശങ്ങൾ ഞാൻ ഒഴിവാക്കും, കാരണം അവ കണ്ടെത്താൻ എളുപ്പമാണ് ഔദ്യോഗിക ഡോക്യുമെന്റേഷൻ, കൂടാതെ ആധികാരികതയും അംഗീകാരവും കാണിക്കാൻ ഞാൻ ശരിക്കും ആഗ്രഹിക്കുന്നു, അത് ലേഖനത്തിൻ്റെ അടുത്ത ഭാഗത്ത് ചർച്ച ചെയ്യും.

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• "ഇസ്റ്റിയോ ഉപയോഗിച്ച് മൈക്രോസർവീസുകളിലേക്ക് മടങ്ങുക": ഭാഗം 1 (പ്രധാന സവിശേഷതകളിലേക്കുള്ള ആമുഖം), ഭാഗം 3 (ആധികാരികതയും അംഗീകാരവും);
• «ചാലകം - കുബെർനെറ്റസിനുള്ള ലൈറ്റ്വെയ്റ്റ് സർവീസ് മെഷ്";
• «എന്താണ് ഒരു സർവീസ് മെഷ്, എന്തുകൊണ്ട് എനിക്ക് ഇത് ആവശ്യമാണ് [മൈക്രോ സർവീസുകളുള്ള ഒരു ക്ലൗഡ് ആപ്ലിക്കേഷന്]?".

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