గతం లో మేము సర్వీస్ మెష్ ఇస్టియో యొక్క ప్రాథమిక భాగాలను చూశాము, సిస్టమ్‌తో పరిచయం పొందాము మరియు ఇస్టియోతో పని చేయడం ప్రారంభించినప్పుడు సాధారణంగా తలెత్తే ప్రధాన ప్రశ్నలకు సమాధానమిచ్చాము. ఈ భాగంలో మేము నెట్‌వర్క్ ద్వారా ట్రేసింగ్ సమాచార సేకరణను ఎలా నిర్వహించాలో చూద్దాం.
సర్వీస్ మెష్ ఈజ్ ట్రేసింగ్ అనే పదాలు విన్నప్పుడు చాలా మంది డెవలపర్‌లు మరియు సిస్టమ్ అడ్మినిస్ట్రేటర్‌లకు ముందుగా గుర్తుకు వచ్చేది. నిజానికి, మేము ప్రతి నెట్‌వర్క్ నోడ్‌కు ప్రత్యేక ప్రాక్సీ సర్వర్‌ని జోడిస్తాము, దీని ద్వారా అన్ని TCP ట్రాఫిక్ పాస్ అవుతుంది. నెట్‌వర్క్‌లోని అన్ని నెట్‌వర్క్ పరస్పర చర్యల గురించి సమాచారాన్ని సులభంగా పంపడం ఇప్పుడు సాధ్యమేనని తెలుస్తోంది. దురదృష్టవశాత్తు, వాస్తవానికి పరిగణనలోకి తీసుకోవలసిన అనేక సూక్ష్మ నైపుణ్యాలు ఉన్నాయి. వాటిని చూద్దాం.
అపోహ నంబర్ వన్: మేము ఆన్‌లైన్ హైకింగ్ డేటాను ఉచితంగా పొందవచ్చు.
వాస్తవానికి, సాపేక్షంగా ఉచితంగా, మేము మా సిస్టమ్ యొక్క నోడ్‌లను బాణాలు మరియు సేవల మధ్య పాస్ చేసే డేటా రేట్ ద్వారా మాత్రమే కనెక్ట్ చేయగలము (వాస్తవానికి, యూనిట్ సమయానికి బైట్‌ల సంఖ్య మాత్రమే). అయినప్పటికీ, చాలా సందర్భాలలో, మా సేవలు HTTP, gRPC, Redis మొదలైన కొన్ని రకాల అప్లికేషన్ లేయర్ ప్రోటోకాల్ ద్వారా కమ్యూనికేట్ చేస్తాయి. మరియు, వాస్తవానికి, మేము ఈ ప్రోటోకాల్‌ల కోసం ప్రత్యేకంగా ట్రేసింగ్ సమాచారాన్ని చూడాలనుకుంటున్నాము; మేము అభ్యర్థన రేటును చూడాలనుకుంటున్నాము, డేటా రేట్ కాదు. మేము మా ప్రోటోకాల్‌ను ఉపయోగించి అభ్యర్థనల జాప్యాన్ని అర్థం చేసుకోవాలనుకుంటున్నాము. చివరగా, ఒక అభ్యర్థన మా సిస్టమ్‌లోకి లాగిన్ చేయడం నుండి వినియోగదారు నుండి ప్రతిస్పందనను స్వీకరించే వరకు పూర్తి మార్గాన్ని చూడాలనుకుంటున్నాము. ఇకపై ఈ సమస్యను పరిష్కరించడం అంత సులభం కాదు.
ముందుగా, ఇస్టియోలో ఆర్కిటెక్చరల్ పాయింట్ ఆఫ్ వ్యూ నుండి ట్రేసింగ్ స్పాన్‌లను పంపడం ఎలా ఉంటుందో చూద్దాం. మొదటి భాగం నుండి మనకు గుర్తున్నట్లుగా, టెలిమెట్రీని సేకరించడానికి ఇస్టియో మిక్సర్ అనే ప్రత్యేక భాగాన్ని కలిగి ఉంది. అయితే, ప్రస్తుత వెర్షన్ 1.0.*లో, పంపడం అనేది నేరుగా ప్రాక్సీ సర్వర్‌ల నుండి, అంటే ఎన్వోయ్ ప్రాక్సీ నుండి జరుగుతుంది. ఎన్వాయ్ ప్రాక్సీ జిప్కిన్ ప్రోటోకాల్‌ను ఉపయోగించి ట్రేసింగ్ స్పాన్‌లను బాక్స్ వెలుపల పంపడానికి మద్దతు ఇస్తుంది. ఇతర ప్రోటోకాల్‌లను కనెక్ట్ చేయడం సాధ్యపడుతుంది, కానీ ప్లగ్ఇన్ ద్వారా మాత్రమే. ఇస్టియోతో మేము వెంటనే అసెంబుల్ చేయబడిన మరియు కాన్ఫిగర్ చేసిన ఎన్వోయ్ ప్రాక్సీని పొందుతాము, ఇది జిప్కిన్ ప్రోటోకాల్‌కు మాత్రమే మద్దతు ఇస్తుంది. మేము ఉదాహరణకు, జైగర్ ప్రోటోకాల్‌ను ఉపయోగించాలనుకుంటే మరియు UDP ద్వారా ట్రేసింగ్ స్పాన్‌లను పంపాలనుకుంటే, మేము మా స్వంత istio-proxy చిత్రాన్ని రూపొందించాలి. istio-proxy కోసం అనుకూల ప్లగిన్‌లకు మద్దతు ఉంది, అయితే ఇది ఇప్పటికీ ఆల్ఫా వెర్షన్‌లో ఉంది. అందువల్ల, మేము పెద్ద సంఖ్యలో అనుకూల సెట్టింగ్‌లు లేకుండా చేయాలనుకుంటే, ట్రేసింగ్ స్పాన్‌లను నిల్వ చేయడానికి మరియు స్వీకరించడానికి ఉపయోగించే సాంకేతికతల పరిధి తగ్గించబడుతుంది. ప్రధాన సిస్టమ్‌లలో, వాస్తవానికి, ఇప్పుడు మీరు జిప్‌కిన్‌ను లేదా జేగర్‌ని ఉపయోగించవచ్చు, కానీ జిప్కిన్ అనుకూల ప్రోటోకాల్ (ఇది చాలా తక్కువ సమర్థవంతమైనది) ఉపయోగించి ప్రతిదానిని అక్కడకు పంపవచ్చు. జిప్కిన్ ప్రోటోకాల్ అనేది HTTP ప్రోటోకాల్ ద్వారా సేకరించేవారికి అన్ని ట్రేసింగ్ సమాచారాన్ని పంపుతుంది, ఇది చాలా ఖరీదైనది.
నేను ఇప్పటికే చెప్పినట్లుగా, మేము అప్లికేషన్-స్థాయి ప్రోటోకాల్‌లను కనుగొనాలనుకుంటున్నాము. అంటే ప్రతి సేవకు పక్కన ఉన్న ప్రాక్సీ సర్వర్‌లు ఇప్పుడు ఎలాంటి పరస్పర చర్య జరుగుతుందో అర్థం చేసుకోవాలి. డిఫాల్ట్‌గా, Istio అన్ని పోర్ట్‌లను సాదా TCPగా కాన్ఫిగర్ చేస్తుంది, అంటే ఎలాంటి జాడలు పంపబడవు. ట్రేస్‌లు పంపబడాలంటే, మీరు ముందుగా, మెయిన్ మెష్ కాన్ఫిగర్‌లో ఈ ఎంపికను ప్రారంభించాలి మరియు చాలా ముఖ్యమైనది ఏమిటంటే, సేవలో ఉపయోగించే ప్రోటోకాల్‌కు అనుగుణంగా కుబెర్నెట్స్ సర్వీస్ ఎంటిటీల యొక్క అన్ని పోర్ట్‌లకు పేరు పెట్టాలి. అంటే, ఉదాహరణకు, ఇలా:
apiVersion: v1
kind: Service
metadata:
name: nginx
spec:
ports:
- port: 80
targetPort: 80
name: http
selector:
app: nginxమీరు http-magic వంటి సమ్మేళన పేర్లను కూడా ఉపయోగించవచ్చు (ఇస్టియో httpని చూస్తుంది మరియు ఆ పోర్ట్‌ను http ముగింపు బిందువుగా గుర్తిస్తుంది). ఫార్మాట్: ప్రోటో-ఎక్స్‌ట్రా.
ప్రోటోకాల్‌ను నిర్ణయించడానికి భారీ సంఖ్యలో కాన్ఫిగరేషన్‌లను ప్యాచ్ చేయకుండా ఉండటానికి, మీరు డర్టీ వర్క్‌అరౌండ్‌ను ఉపయోగించవచ్చు: పైలట్ కాంపోనెంట్‌ను ప్యాచ్ చేయండి. . చివరికి, ఈ లాజిక్‌ను స్టాండర్డ్‌గా మార్చడం మరియు అన్ని పోర్ట్‌ల కోసం నామకరణ సమావేశానికి మారడం అవసరం.
ప్రోటోకాల్ నిజంగా సరిగ్గా నిర్వచించబడిందో లేదో అర్థం చేసుకోవడానికి, మీరు ఎన్వోయ్ ప్రాక్సీతో ఏదైనా సైడ్‌కార్ కంటైనర్‌లలోకి వెళ్లి, స్థానం /config_dumpతో ఎన్వోయ్ ఇంటర్‌ఫేస్ యొక్క అడ్మిన్ పోర్ట్‌కు అభ్యర్థన చేయాలి. ఫలిత కాన్ఫిగరేషన్‌లో, మీరు కోరుకున్న సేవ యొక్క ఆపరేషన్ ఫీల్డ్‌ను చూడాలి. ఇది అభ్యర్థన చేసిన ప్రదేశానికి ఐడెంటిఫైయర్‌గా ఇస్టియోలో ఉపయోగించబడుతుంది. ఇస్టియోలో ఈ పరామితి యొక్క విలువను అనుకూలీకరించడానికి (మేము దానిని మా ట్రేసింగ్ సిస్టమ్‌లో చూస్తాము), సైడ్‌కార్ కంటైనర్‌ను ప్రారంభించే దశలో సర్వీస్‌క్లస్టర్ ఫ్లాగ్‌ను పేర్కొనడం అవసరం. ఉదాహరణకు, డౌన్‌వర్డ్ కుబెర్నెట్స్ API నుండి పొందిన వేరియబుల్స్ నుండి దీనిని ఇలా లెక్కించవచ్చు:
--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')
రాయబారిలో ట్రేసింగ్ ఎలా పని చేస్తుందో అర్థం చేసుకోవడానికి మంచి ఉదాహరణ .
ట్రేసింగ్ స్పాన్‌లను పంపడానికి ఎండ్‌పాయింట్ తప్పనిసరిగా ఎన్వోయ్ ప్రాక్సీ లాంచ్ ఫ్లాగ్‌లలో కూడా పేర్కొనబడాలి, ఉదాహరణకు: --zipkinAddress tracing-collector.tracing:9411
అపోహ సంఖ్య రెండు: మేము చౌకగా రిక్వెస్ట్‌ల పూర్తి ట్రేస్‌లను సిస్టమ్‌లో అవుట్ ఆఫ్ ది బాక్స్ ద్వారా పొందవచ్చు
దురదృష్టవశాత్తు, అది కాదు. మీరు ఇప్పటికే సేవల పరస్పర చర్యను ఎలా అమలు చేసారు అనేదానిపై అమలు సంక్లిష్టత ఆధారపడి ఉంటుంది. అది ఎందుకు?
వాస్తవం ఏమిటంటే, ఇస్టియో-ప్రాక్సీ అదే సేవను విడిచిపెట్టిన వారితో ఒక సేవకు ఇన్‌కమింగ్ అభ్యర్థనల యొక్క అనురూప్యాన్ని అర్థం చేసుకోవడానికి, మొత్తం ట్రాఫిక్‌ను అడ్డగించడం సరిపోదు. మీరు ఒక రకమైన కమ్యూనికేషన్ ఐడెంటిఫైయర్‌ని కలిగి ఉండాలి. HTTP ఎన్వోయ్ ప్రాక్సీ ప్రత్యేక శీర్షికలను ఉపయోగిస్తుంది, దీని ద్వారా సేవకు ఏ నిర్దిష్ట అభ్యర్థన ఇతర సేవలకు నిర్దిష్ట అభ్యర్థనలను ఉత్పత్తి చేస్తుందో అర్థం చేసుకుంటుంది. అటువంటి శీర్షికల జాబితా:
- x-అభ్యర్థన-id,
- x-b3-ట్రేసిడ్,
- x-b3-స్పానిడ్,
- x-b3-పేరెంట్స్పానిడ్,
- x-b3-నమూనా,
- x-b3-జెండాలు,
- x-ot-span-context.
మీకు ఒకే పాయింట్ ఉంటే, ఉదాహరణకు, ఒక ప్రాథమిక క్లయింట్, దీనిలో మీరు అటువంటి లాజిక్‌ను జోడించవచ్చు, అప్పుడు ప్రతిదీ బాగానే ఉంది, ఈ లైబ్రరీ అన్ని క్లయింట్‌ల కోసం నవీకరించబడే వరకు మీరు వేచి ఉండాలి. కానీ మీరు చాలా భిన్నమైన వ్యవస్థను కలిగి ఉంటే మరియు నెట్‌వర్క్ ద్వారా సేవ నుండి సేవకు వెళ్లడంలో ఏకీకరణ లేకపోతే, ఇది చాలా పెద్ద సమస్యగా ఉంటుంది. అటువంటి తర్కాన్ని జోడించకుండా, అన్ని ట్రేసింగ్ సమాచారం "సింగిల్-లెవల్" మాత్రమే అవుతుంది. అంటే, మేము అన్ని ఇంటర్-సర్వీస్ ఇంటరాక్షన్‌లను స్వీకరిస్తాము, కానీ అవి నెట్‌వర్క్ ద్వారా ఒకే చైన్‌లలోకి అతుక్కోవు.
తీర్మానం
నెట్‌వర్క్ ద్వారా ట్రేసింగ్ సమాచారాన్ని సేకరించడానికి ఇస్టియో అనుకూలమైన సాధనాన్ని అందిస్తుంది, అయితే అమలు కోసం మీరు మీ సిస్టమ్‌ను స్వీకరించి, ఇస్టియో అమలు యొక్క లక్షణాలను పరిగణనలోకి తీసుకోవాలని మీరు అర్థం చేసుకోవాలి. ఫలితంగా, రెండు ప్రధాన అంశాలను పరిష్కరించాల్సిన అవసరం ఉంది: అప్లికేషన్ స్థాయి ప్రోటోకాల్‌ను నిర్వచించడం (దీనికి రాయబారి ప్రాక్సీ తప్పనిసరిగా మద్దతు ఇవ్వాలి) మరియు సేవ నుండి అభ్యర్థనల నుండి సేవకు అభ్యర్థనల కనెక్షన్ గురించి సమాచారాన్ని ఫార్వార్డ్ చేయడం (హెడర్‌లను ఉపయోగించడం) , HTTP ప్రోటోకాల్ విషయంలో). ఈ సమస్యలు పరిష్కరించబడినప్పుడు, అనేక విభిన్న భాషలు మరియు ఫ్రేమ్‌వర్క్‌లలో వ్రాయబడిన చాలా భిన్నమైన సిస్టమ్‌లలో కూడా నెట్‌వర్క్ నుండి సమాచారాన్ని పారదర్శకంగా సేకరించడానికి మమ్మల్ని అనుమతించే శక్తివంతమైన సాధనం మా వద్ద ఉంది.
సర్వీస్ మెష్ గురించి తదుపరి కథనంలో, మేము ఇస్టియోతో ఉన్న అతిపెద్ద సమస్యలలో ఒకదానిని పరిశీలిస్తాము - ప్రతి సైడ్‌కార్ ప్రాక్సీ కంటైనర్ ద్వారా RAM యొక్క పెద్ద వినియోగం మరియు మీరు దానిని ఎలా ఎదుర్కోవాలో చర్చిస్తాము.
మూలం: www.habr.com