നിർമ്മാണത്തിൽ ഇസ്തിയോയും കുബർനെറ്റസും. ഭാഗം 2. ട്രേസിംഗ്

അവസാനത്തിൽ ലേഖനം ഞങ്ങൾ സർവീസ് മെഷ് ഇസ്തിയോയുടെ അടിസ്ഥാന ഘടകങ്ങൾ നോക്കി, സിസ്റ്റവുമായി പരിചയപ്പെടുകയും ഇസ്റ്റിയോയുമായി പ്രവർത്തിക്കാൻ തുടങ്ങുമ്പോൾ സാധാരണയായി ഉണ്ടാകുന്ന പ്രധാന ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുകയും ചെയ്തു. ഒരു നെറ്റ്‌വർക്കിലൂടെ ട്രെയ്‌സിംഗ് വിവരങ്ങളുടെ ശേഖരണം എങ്ങനെ സംഘടിപ്പിക്കാമെന്ന് ഈ ഭാഗത്ത് ഞങ്ങൾ നോക്കും.

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

ഒന്നാം നമ്പർ തെറ്റിദ്ധാരണ: ഞങ്ങൾക്ക് സൗജന്യമായി ഓൺലൈൻ ഹൈക്കിംഗ് ഡാറ്റ ലഭിക്കും.

വാസ്തവത്തിൽ, താരതമ്യേന സൗജന്യമായി, ഞങ്ങളുടെ സിസ്റ്റത്തിന്റെ നോഡുകൾ അമ്പടയാളങ്ങളും സേവനങ്ങൾക്കിടയിൽ കടന്നുപോകുന്ന ഡാറ്റാ നിരക്കും ഉപയോഗിച്ച് മാത്രമേ കണക്റ്റുചെയ്യാനാകൂ (വാസ്തവത്തിൽ, ഒരു യൂണിറ്റ് സമയത്തിനുള്ള ബൈറ്റുകളുടെ എണ്ണം മാത്രം). എന്നിരുന്നാലും, മിക്ക കേസുകളിലും, ഞങ്ങളുടെ സേവനങ്ങൾ HTTP, gRPC, Redis മുതലായവ പോലുള്ള ഏതെങ്കിലും തരത്തിലുള്ള ആപ്ലിക്കേഷൻ ലെയർ പ്രോട്ടോക്കോൾ വഴി ആശയവിനിമയം നടത്തുന്നു. കൂടാതെ, തീർച്ചയായും, ഈ പ്രോട്ടോക്കോളുകൾക്കായി പ്രത്യേകമായി ട്രെയ്‌സിംഗ് വിവരങ്ങൾ കാണാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു; ഡാറ്റാ നിരക്കല്ല, അഭ്യർത്ഥന നിരക്ക് കാണാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഞങ്ങളുടെ പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് അഭ്യർത്ഥനകളുടെ കാലതാമസം മനസ്സിലാക്കാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. അവസാനമായി, ഒരു അഭ്യർത്ഥന ഞങ്ങളുടെ സിസ്റ്റത്തിലേക്ക് ലോഗിൻ ചെയ്യുന്നത് മുതൽ ഉപയോക്താവിൽ നിന്ന് പ്രതികരണം സ്വീകരിക്കുന്നത് വരെയുള്ള മുഴുവൻ പാതയും കാണാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നു. ഈ പ്രശ്നം ഇനി പരിഹരിക്കാൻ അത്ര എളുപ്പമല്ല.

ആദ്യം, ഇസ്തിയോയിലെ ഒരു വാസ്തുവിദ്യാ വീക്ഷണകോണിൽ നിന്ന് അയയ്‌ക്കുന്ന ട്രെയ്‌സിംഗ് സ്പാനുകൾ എങ്ങനെയുണ്ടെന്ന് നോക്കാം. ആദ്യ ഭാഗത്തിൽ നിന്ന് നമ്മൾ ഓർക്കുന്നത് പോലെ, ടെലിമെട്രി ശേഖരിക്കുന്നതിന് ഇസ്തിയോയ്ക്ക് മിക്സർ എന്ന പ്രത്യേക ഘടകം ഉണ്ട്. എന്നിരുന്നാലും, നിലവിലെ പതിപ്പ് 1.0.*-ൽ, അയയ്‌ക്കുന്നത് പ്രോക്‌സി സെർവറുകളിൽ നിന്നാണ്, അതായത് എൻവോയ് പ്രോക്‌സിയിൽ നിന്ന്. സിപ്‌കിൻ പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് ബോക്‌സിന് പുറത്ത് ട്രെയ്‌സിംഗ് സ്പാനുകൾ അയയ്‌ക്കുന്നതിനെ എൻവോയ് പ്രോക്‌സി പിന്തുണയ്‌ക്കുന്നു. മറ്റ് പ്രോട്ടോക്കോളുകൾ ബന്ധിപ്പിക്കുന്നത് സാധ്യമാണ്, പക്ഷേ ഒരു പ്ലഗിൻ വഴി മാത്രം. ഇസ്റ്റിയോ ഉപയോഗിച്ച്, നമുക്ക് ഉടനടി അസംബിൾ ചെയ്തതും കോൺഫിഗർ ചെയ്തതുമായ ഒരു എൻവോയ് പ്രോക്സി ലഭിക്കും, അത് zipkin പ്രോട്ടോക്കോൾ മാത്രം പിന്തുണയ്ക്കുന്നു. ഉദാഹരണത്തിന്, ജെയ്ഗർ പ്രോട്ടോക്കോൾ ഉപയോഗിക്കാനും UDP വഴി ട്രെയ്‌സിംഗ് സ്പാനുകൾ അയയ്‌ക്കാനും ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഞങ്ങൾ ഞങ്ങളുടെ സ്വന്തം istio-proxy ഇമേജ് നിർമ്മിക്കേണ്ടതുണ്ട്. istio-proxy-യ്‌ക്കുള്ള ഇഷ്‌ടാനുസൃത പ്ലഗിന്നുകൾക്ക് പിന്തുണയുണ്ട്, പക്ഷേ അത് ഇപ്പോഴും ആൽഫ പതിപ്പിലാണ്. അതിനാൽ, ഒരു വലിയ എണ്ണം ഇഷ്‌ടാനുസൃത ക്രമീകരണങ്ങൾ ഇല്ലാതെ ചെയ്യാൻ ഞങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ട്രെയ്‌സിംഗ് സ്പാനുകൾ സംഭരിക്കുന്നതിനും സ്വീകരിക്കുന്നതിനും ഉപയോഗിക്കുന്ന സാങ്കേതികവിദ്യകളുടെ ശ്രേണി കുറയുന്നു. പ്രധാന സിസ്റ്റങ്ങളിൽ, വാസ്തവത്തിൽ, ഇപ്പോൾ നിങ്ങൾക്ക് Zipkin തന്നെ അല്ലെങ്കിൽ ജെയ്ഗർ ഉപയോഗിക്കാം, എന്നാൽ zipkin അനുയോജ്യമായ പ്രോട്ടോക്കോൾ ഉപയോഗിച്ച് എല്ലാം അയയ്‌ക്കുക (ഇത് കാര്യക്ഷമത കുറവാണ്). എച്ച്ടിടിപി പ്രോട്ടോക്കോൾ വഴി എല്ലാ ട്രേസിംഗ് വിവരങ്ങളും ശേഖരിക്കുന്നവർക്ക് അയയ്ക്കുന്നത് zipkin പ്രോട്ടോക്കോളിൽ തന്നെ ഉൾപ്പെടുന്നു, അത് വളരെ ചെലവേറിയതാണ്.

ഞാൻ ഇതിനകം പറഞ്ഞതുപോലെ, ഞങ്ങൾ ആപ്ലിക്കേഷൻ-ലെവൽ പ്രോട്ടോക്കോളുകൾ കണ്ടെത്താൻ ആഗ്രഹിക്കുന്നു. ഇതിനർത്ഥം ഓരോ സേവനത്തിനും അടുത്തായി നിൽക്കുന്ന പ്രോക്സി സെർവറുകൾ ഇപ്പോൾ എന്ത് തരത്തിലുള്ള ഇടപെടലാണ് നടക്കുന്നതെന്ന് മനസ്സിലാക്കണം. സ്ഥിരസ്ഥിതിയായി, എല്ലാ പോർട്ടുകളും പ്ലെയിൻ TCP ആയി Istio കോൺഫിഗർ ചെയ്യുന്നു, അതായത് ട്രെയ്‌സുകളൊന്നും അയയ്‌ക്കില്ല. ട്രെയ്‌സുകൾ അയയ്‌ക്കുന്നതിന്, നിങ്ങൾ ആദ്യം, പ്രധാന മെഷ് കോൺഫിഗറേഷനിൽ ഈ ഓപ്‌ഷൻ പ്രവർത്തനക്ഷമമാക്കുകയും, വളരെ പ്രധാനപ്പെട്ടത്, സേവനത്തിൽ ഉപയോഗിക്കുന്ന പ്രോട്ടോക്കോൾ അനുസരിച്ച് kubernetes സേവന സ്ഥാപനങ്ങളുടെ എല്ലാ പോർട്ടുകൾക്കും പേര് നൽകുകയും വേണം. അതായത്, ഉദാഹരണത്തിന്, ഇതുപോലെ:

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

നിങ്ങൾക്ക് http-magic പോലുള്ള സംയുക്ത നാമങ്ങളും ഉപയോഗിക്കാം (Istio http കാണുകയും ആ പോർട്ട് ഒരു http എൻഡ് പോയിന്റായി തിരിച്ചറിയുകയും ചെയ്യും). ഫോർമാറ്റ് ഇതാണ്: പ്രോട്ടോ എക്സ്ട്രാ.

പ്രോട്ടോക്കോൾ നിർണ്ണയിക്കാൻ ധാരാളം കോൺഫിഗറേഷനുകൾ പാച്ച് ചെയ്യാതിരിക്കാൻ, നിങ്ങൾക്ക് ഒരു വൃത്തികെട്ട പരിഹാരമാർഗ്ഗം ഉപയോഗിക്കാം: പൈലറ്റ് ഘടകം ഇപ്പോൾ തന്നെ പാച്ച് ചെയ്യുക. പ്രോട്ടോക്കോൾ ഡെഫനിഷൻ ലോജിക് നിർവഹിക്കുന്നു. അവസാനം, തീർച്ചയായും, ഈ ലോജിക് സ്റ്റാൻഡേർഡിലേക്ക് മാറ്റുകയും എല്ലാ പോർട്ടുകൾക്കുമായി ഒരു നാമകരണ കൺവെൻഷനിലേക്ക് മാറുകയും ചെയ്യേണ്ടത് ആവശ്യമാണ്.

പ്രോട്ടോക്കോൾ ശരിക്കും കൃത്യമായി നിർവചിച്ചിട്ടുണ്ടോ എന്ന് മനസിലാക്കാൻ, നിങ്ങൾ എൻവോയ് പ്രോക്സി ഉള്ള ഏതെങ്കിലും സൈഡ്കാർ കണ്ടെയ്നറുകളിലേക്ക് പോയി ലൊക്കേഷൻ /config_dump ഉള്ള എൻവോയ് ഇന്റർഫേസിന്റെ അഡ്മിൻ പോർട്ടിലേക്ക് ഒരു അഭ്യർത്ഥന നടത്തേണ്ടതുണ്ട്. തത്ഫലമായുണ്ടാകുന്ന കോൺഫിഗറേഷനിൽ, നിങ്ങൾ ആവശ്യമുള്ള സേവനത്തിന്റെ പ്രവർത്തന ഫീൽഡ് നോക്കേണ്ടതുണ്ട്. എവിടെയാണ് അഭ്യർത്ഥന നടത്തുന്നത് എന്നതിന്റെ ഐഡന്റിഫയറായി ഇത് ഇസ്തിയോയിൽ ഉപയോഗിക്കുന്നു. ഇസ്റ്റിയോയിലെ ഈ പാരാമീറ്ററിന്റെ മൂല്യം ഇഷ്‌ടാനുസൃതമാക്കുന്നതിന് (ഞങ്ങൾ ഇത് ഞങ്ങളുടെ ട്രേസിംഗ് സിസ്റ്റത്തിൽ കാണും), സൈഡ്‌കാർ കണ്ടെയ്‌നർ സമാരംഭിക്കുന്ന ഘട്ടത്തിൽ സർവീസ് ക്ലസ്റ്റർ ഫ്ലാഗ് വ്യക്തമാക്കേണ്ടത് ആവശ്യമാണ്. ഉദാഹരണത്തിന്, താഴേക്കുള്ള kubernetes API-ൽ നിന്ന് ലഭിച്ച വേരിയബിളുകളിൽ നിന്ന് ഇത് ഇതുപോലെ കണക്കാക്കാം:

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

ദൂതനിൽ ട്രെയ്‌സിംഗ് എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്ന് മനസിലാക്കാനുള്ള മികച്ച ഉദാഹരണം ഇവിടെ.

ട്രെയ്‌സിംഗ് സ്പാനുകൾ അയയ്‌ക്കുന്നതിനുള്ള അവസാന പോയിന്റ് തന്നെ എൻവോയ് പ്രോക്‌സി ലോഞ്ച് ഫ്ലാഗുകളിലും വ്യക്തമാക്കിയിരിക്കണം, ഉദാഹരണത്തിന്: --zipkinAddress tracing-collector.tracing:9411

തെറ്റിദ്ധാരണ നമ്പർ രണ്ട്: അഭ്യർത്ഥനകളുടെ പൂർണ്ണമായ ട്രെയ്‌സ് സിസ്റ്റം ഔട്ട് ഓഫ് ബോക്‌സിലൂടെ നമുക്ക് ചെലവുകുറഞ്ഞ രീതിയിൽ ലഭിക്കും

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

ഒരേ സേവനം ഉപേക്ഷിക്കുന്നവരുമായി ഒരു സേവനത്തിലേക്കുള്ള ഇൻകമിംഗ് അഭ്യർത്ഥനകളുടെ കത്തിടപാടുകൾ istio-proxy-ക്ക് മനസ്സിലാക്കാൻ കഴിയണമെങ്കിൽ, എല്ലാ ട്രാഫിക്കും തടസ്സപ്പെടുത്തുന്നത് മാത്രം പോരാ എന്നതാണ് വസ്തുത. നിങ്ങൾക്ക് ഏതെങ്കിലും തരത്തിലുള്ള ആശയവിനിമയ ഐഡന്റിഫയർ ഉണ്ടായിരിക്കണം. HTTP എൻവോയ് പ്രോക്സി പ്രത്യേക തലക്കെട്ടുകൾ ഉപയോഗിക്കുന്നു, ഇതിലൂടെ സേവനത്തിലേക്കുള്ള നിർദ്ദിഷ്ട അഭ്യർത്ഥന മറ്റ് സേവനങ്ങളിലേക്ക് നിർദ്ദിഷ്ട അഭ്യർത്ഥനകൾ സൃഷ്ടിക്കുന്നുവെന്ന് ദൂതൻ മനസ്സിലാക്കുന്നു. അത്തരം തലക്കെട്ടുകളുടെ പട്ടിക:

• x-request-id,
• x-b3-traceid,
• x-b3-സ്പാനിഡ്,
• x-b3-parentspanid,
• x-b3-സാമ്പിൾ,
• x-b3-പതാകകൾ,
• x-ot-span-context.

നിങ്ങൾക്ക് ഒരൊറ്റ പോയിന്റ് ഉണ്ടെങ്കിൽ, ഉദാഹരണത്തിന്, ഒരു അടിസ്ഥാന ക്ലയന്റ്, അതിൽ നിങ്ങൾക്ക് അത്തരം ലോജിക് ചേർക്കാൻ കഴിയും, എല്ലാം ശരിയാണ്, എല്ലാ ക്ലയന്റുകൾക്കുമായി ഈ ലൈബ്രറി അപ്ഡേറ്റ് ചെയ്യുന്നതിനായി നിങ്ങൾ കാത്തിരിക്കേണ്ടതുണ്ട്. എന്നാൽ നിങ്ങൾക്ക് വളരെ വൈവിധ്യമാർന്ന സംവിധാനമുണ്ടെങ്കിൽ, നെറ്റ്‌വർക്കിലൂടെ സേവനത്തിൽ നിന്ന് സേവനത്തിലേക്ക് മാറുന്നതിൽ ഏകീകരണം ഇല്ലെങ്കിൽ, ഇത് മിക്കവാറും ഒരു വലിയ പ്രശ്നമായിരിക്കും. അത്തരം ലോജിക് ചേർക്കാതെ, എല്ലാ ട്രേസിംഗ് വിവരങ്ങളും "സിംഗിൾ-ലെവൽ" മാത്രമായിരിക്കും. അതായത്, ഞങ്ങൾക്ക് എല്ലാ ഇന്റർ-സർവീസ് ഇടപെടലുകളും ലഭിക്കും, പക്ഷേ അവ നെറ്റ്‌വർക്കിലൂടെ കടന്നുപോകുന്ന ഒറ്റ ശൃംഖലകളിൽ ഒട്ടിക്കില്ല.

തീരുമാനം

ഒരു നെറ്റ്‌വർക്കിലൂടെ ട്രെയ്‌സിംഗ് വിവരങ്ങൾ ശേഖരിക്കുന്നതിന് ഇസ്‌റ്റിയോ സൗകര്യപ്രദമായ ഒരു ഉപകരണം നൽകുന്നു, എന്നാൽ നടപ്പിലാക്കുന്നതിന് നിങ്ങളുടെ സിസ്റ്റം പൊരുത്തപ്പെടുത്തുകയും ഇസ്‌റ്റിയോ നടപ്പിലാക്കലിന്റെ സവിശേഷതകൾ കണക്കിലെടുക്കുകയും ചെയ്യണമെന്ന് നിങ്ങൾ മനസ്സിലാക്കണം. തൽഫലമായി, രണ്ട് പ്രധാന പോയിന്റുകൾ പരിഹരിക്കേണ്ടതുണ്ട്: ആപ്ലിക്കേഷൻ ലെവൽ പ്രോട്ടോക്കോൾ നിർവചിക്കുക (ഇത് എൻവോയ് പ്രോക്സി പിന്തുണയ്ക്കണം) കൂടാതെ സേവനത്തിൽ നിന്നുള്ള അഭ്യർത്ഥനകളിൽ നിന്ന് (തലക്കെട്ടുകൾ ഉപയോഗിച്ച് സേവനത്തിലേക്കുള്ള അഭ്യർത്ഥനകളുടെ കണക്ഷനെക്കുറിച്ചുള്ള വിവരങ്ങൾ കൈമാറൽ സജ്ജീകരിക്കുക) , HTTP പ്രോട്ടോക്കോളിന്റെ കാര്യത്തിൽ). ഈ പ്രശ്‌നങ്ങൾ പരിഹരിക്കപ്പെടുമ്പോൾ, വിവിധ ഭാഷകളിലും ചട്ടക്കൂടുകളിലും എഴുതിയിരിക്കുന്ന വളരെ വൈവിധ്യമാർന്ന സിസ്റ്റങ്ങളിൽ പോലും, നെറ്റ്‌വർക്കിൽ നിന്ന് വിവരങ്ങൾ സുതാര്യമായി ശേഖരിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്ന ശക്തമായ ഒരു ഉപകരണം ഞങ്ങളുടെ പക്കലുണ്ട്.

സർവീസ് മെഷിനെക്കുറിച്ചുള്ള അടുത്ത ലേഖനത്തിൽ, ഇസ്‌റ്റിയോയിലെ ഏറ്റവും വലിയ പ്രശ്‌നങ്ങളിലൊന്ന് ഞങ്ങൾ നോക്കാം - ഓരോ സൈഡ്‌കാർ പ്രോക്‌സി കണ്ടെയ്‌നറിനും റാം-ന്റെ വലിയ ഉപഭോഗം, അത് എങ്ങനെ കൈകാര്യം ചെയ്യാമെന്ന് ചർച്ച ചെയ്യുക.

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