ఇంటర్నెట్‌లో (సర్వీస్ మెష్), మరియు ఇక్కడ మరొకటి ఉంది. హుర్రే! కానీ ఎందుకు? అప్పుడు, డాకర్ మరియు కుబెర్నెటీస్ వంటి కంటైనర్ ప్లాట్‌ఫారమ్‌లు రాకముందే 10 సంవత్సరాల క్రితం సర్వీస్ మెష్‌లు కనిపిస్తే బాగుంటుందని నా అభిప్రాయాన్ని తెలియజేయాలనుకుంటున్నాను. నా దృక్కోణం ఇతరులకన్నా మెరుగ్గా లేదా అధ్వాన్నంగా ఉందని నేను చెప్పడం లేదు, కానీ సేవా మెష్‌లు చాలా క్లిష్టమైన జంతువులు కాబట్టి, వాటిని బాగా అర్థం చేసుకోవడానికి బహుళ దృక్కోణాలు సహాయపడతాయి.
నేను డాట్‌క్లౌడ్ ప్లాట్‌ఫారమ్ గురించి మాట్లాడతాను, ఇది వందకు పైగా మైక్రోసర్వీస్‌లలో నిర్మించబడింది మరియు వేలాది కంటెయినరైజ్డ్ అప్లికేషన్‌లకు మద్దతు ఇస్తుంది. దీన్ని అభివృద్ధి చేయడంలో మరియు ప్రారంభించడంలో మేము ఎదుర్కొన్న సవాళ్లను మరియు సర్వీస్ మెష్‌లు ఎలా సహాయపడతాయో (లేదా చేయలేనివి) వివరిస్తాను.
డాట్‌క్లౌడ్ చరిత్ర
నేను డాట్‌క్లౌడ్ చరిత్ర మరియు ఈ ప్లాట్‌ఫారమ్ కోసం ఆర్కిటెక్చర్ ఎంపికల గురించి వ్రాసాను, కానీ నేను నెట్‌వర్క్ లేయర్ గురించి పెద్దగా మాట్లాడలేదు. మీరు చదవడానికి డైవ్ చేయకూడదనుకుంటే డాట్‌క్లౌడ్ గురించి, ఇక్కడ సారాంశం క్లుప్తంగా ఉంది: ఇది PaaS ప్లాట్‌ఫారమ్-ఎ-సర్వీస్, ఇది వినియోగదారులను విస్తృత శ్రేణి డేటాకు మద్దతుతో విస్తృత శ్రేణి అప్లికేషన్‌లను (జావా, PHP, పైథాన్...) అమలు చేయడానికి అనుమతిస్తుంది. సేవలు (MongoDB, MySQL, Redis...) మరియు Heroku వంటి వర్క్‌ఫ్లో: మీరు మీ కోడ్‌ని ప్లాట్‌ఫారమ్‌కి అప్‌లోడ్ చేస్తారు, ఇది కంటైనర్ చిత్రాలను రూపొందించి వాటిని అమలు చేస్తుంది.
డాట్‌క్లౌడ్ ప్లాట్‌ఫారమ్‌కు ట్రాఫిక్ ఎలా మళ్లించబడిందో నేను మీకు చెప్తాను. ఇది ప్రత్యేకంగా చల్లగా ఉన్నందున కాదు (సిస్టమ్ దాని సమయానికి బాగా పనిచేసినప్పటికీ!), కానీ ప్రాథమికంగా ఆధునిక సాధనాలతో ఇటువంటి డిజైన్‌ను నిరాడంబరమైన బృందం తక్కువ సమయంలో సులభంగా అమలు చేయగలదు. మైక్రోసర్వీసెస్ లేదా కొన్ని అప్లికేషన్లు. ఈ విధంగా, మీరు ఎంపికలను సరిపోల్చవచ్చు: మీరు అన్నింటినీ మీరే అభివృద్ధి చేస్తే లేదా ఇప్పటికే ఉన్న సర్వీస్ మెష్‌ని ఉపయోగిస్తే ఏమి జరుగుతుంది. దీన్ని మీరే తయారు చేసుకోవడం లేదా కొనుగోలు చేయడం ప్రామాణిక ఎంపిక.
హోస్ట్ చేసిన అప్లికేషన్‌ల కోసం ట్రాఫిక్ రూటింగ్
డాట్‌క్లౌడ్‌లోని అప్లికేషన్లు HTTP మరియు TCP ముగింపు పాయింట్‌లను బహిర్గతం చేయగలవు.
HTTP ముగింపు పాయింట్లు లోడ్ బాలన్సర్ క్లస్టర్ కాన్ఫిగరేషన్‌కు డైనమిక్‌గా జోడించబడింది . ఇది నేడు వనరులు చేసే పనిని పోలి ఉంటుంది కుబెర్నెటెస్‌లో మరియు లోడ్ బ్యాలెన్సర్ వంటిది .
క్లయింట్లు తగిన డొమైన్‌ల ద్వారా HTTP ఎండ్‌పాయింట్‌లకు కనెక్ట్ అవుతారు, డొమైన్ పేరు డాట్‌క్లౌడ్ లోడ్ బ్యాలెన్సర్‌లకు సూచించినట్లయితే. ప్రత్యేకంగా ఏమీ లేదు.
TCP ముగింపు పాయింట్లు పోర్ట్ నంబర్‌తో అనుబంధించబడింది, ఇది ఎన్విరాన్మెంట్ వేరియబుల్స్ ద్వారా ఆ స్టాక్‌లోని అన్ని కంటైనర్‌లకు పంపబడుతుంది.
క్లయింట్లు తగిన హోస్ట్ పేరు (గేట్‌వే-X.dotcloud.com లాంటిది) మరియు పోర్ట్ నంబర్‌ని ఉపయోగించి TCP ఎండ్‌పాయింట్‌లకు కనెక్ట్ చేయవచ్చు.
ఈ హోస్ట్ పేరు “nats” సర్వర్ క్లస్టర్‌కి పరిష్కరిస్తుంది (సంబంధం లేదు ), ఇది ఇన్‌కమింగ్ TCP కనెక్షన్‌లను సరైన కంటైనర్‌కు (లేదా, లోడ్-సమతుల్య సేవల విషయంలో, సరైన కంటైనర్‌లకు) దారి తీస్తుంది.
మీకు కుబెర్నెటెస్ గురించి తెలిసి ఉంటే, ఇది బహుశా మీకు సేవల గురించి గుర్తు చేస్తుంది .
డాట్‌క్లౌడ్ ప్లాట్‌ఫారమ్‌లో సమానమైన సేవలు ఏవీ లేవు : సరళత కోసం, ప్లాట్‌ఫారమ్ లోపల మరియు వెలుపల నుండి సేవలు ఒకే విధంగా యాక్సెస్ చేయబడ్డాయి.
ప్రతిదీ చాలా సరళంగా నిర్వహించబడింది: HTTP మరియు TCP రూటింగ్ నెట్‌వర్క్‌ల యొక్క ప్రారంభ అమలులు బహుశా పైథాన్‌లోని కొన్ని వందల లైన్‌లు మాత్రమే. ప్లాట్‌ఫారమ్ పెరిగేకొద్దీ మరియు అదనపు అవసరాలు కనిపించినప్పుడు శుద్ధి చేయబడిన సాధారణ (నేను అమాయకమైన) అల్గోరిథంలు.
ఇప్పటికే ఉన్న కోడ్ యొక్క విస్తృత రీఫ్యాక్టరింగ్ అవసరం లేదు. ముఖ్యంగా, ఎన్విరాన్మెంట్ వేరియబుల్స్ ద్వారా పొందిన చిరునామాను నేరుగా ఉపయోగించవచ్చు.
ఆధునిక సేవా మెష్ నుండి ఇది ఎలా భిన్నంగా ఉంటుంది?
పరిమితం చేయబడింది దృశ్యమానత. TCP రూటింగ్ మెష్‌కు సంబంధించి మా వద్ద ఎటువంటి కొలమానాలు లేవు. HTTP రూటింగ్ విషయానికి వస్తే, తరువాతి సంస్కరణలు ఎర్రర్ కోడ్‌లు మరియు ప్రతిస్పందన సమయాలతో వివరణాత్మక HTTP మెట్రిక్‌లను ప్రవేశపెట్టాయి, అయితే ఆధునిక సేవా మెష్‌లు మరింత ముందుకు వెళ్తాయి, ఉదాహరణకు ప్రోమేథియస్ వంటి కొలమానాల సేకరణ వ్యవస్థలతో ఏకీకరణను అందిస్తాయి.
కార్యాచరణ దృక్కోణం (సమస్యలను పరిష్కరించడంలో సహాయపడటం) నుండి మాత్రమే కాకుండా, కొత్త ఫీచర్‌లను విడుదల చేసేటప్పుడు కూడా దృశ్యమానత ముఖ్యం. ఇది సురక్షితమైనది и .
రూటింగ్ సామర్థ్యం పరిమితం కూడా. డాట్‌క్లౌడ్ రూటింగ్ మెష్‌లో, ట్రాఫిక్ అంతా డెడికేటెడ్ రూటింగ్ నోడ్‌ల క్లస్టర్ ద్వారా వెళ్లాలి. దీని అర్థం బహుళ AZ (లభ్యత జోన్) సరిహద్దులను దాటడం మరియు జాప్యాన్ని గణనీయంగా పెంచడం. ఒక్కో పేజీకి వందకు పైగా SQL ప్రశ్నలను చేస్తున్న ట్రబుల్షూటింగ్ కోడ్ మరియు ప్రతి ప్రశ్నకు SQL సర్వర్‌కి కొత్త కనెక్షన్‌ను తెరవడం నాకు గుర్తుంది. స్థానికంగా నడుస్తున్నప్పుడు, పేజీ తక్షణమే లోడ్ అవుతుంది, కానీ డాట్‌క్లౌడ్‌లో లోడ్ కావడానికి కొన్ని సెకన్ల సమయం పడుతుంది ఎందుకంటే ప్రతి TCP కనెక్షన్ (మరియు తదుపరి SQL ప్రశ్న) పదుల మిల్లీసెకన్లు పడుతుంది. ఈ ప్రత్యేక సందర్భంలో, నిరంతర కనెక్షన్లు సమస్యను పరిష్కరించాయి.
ఆధునిక సేవా మెష్‌లు అటువంటి సమస్యలను ఎదుర్కోవడంలో మెరుగ్గా ఉంటాయి. అన్నింటిలో మొదటిది, కనెక్షన్లు రూట్ చేయబడి ఉన్నాయని వారు తనిఖీ చేస్తారు మూలంలో. తార్కిక ప్రవాహం ఒకే విధంగా ఉంటుంది: клиент → меш → сервис, కానీ ఇప్పుడు మెష్ స్థానికంగా పనిచేస్తుంది మరియు రిమోట్ నోడ్లలో కాదు, కాబట్టి కనెక్షన్ клиент → меш స్థానికంగా మరియు చాలా వేగంగా ఉంటుంది (మిల్లీసెకన్లకు బదులుగా మైక్రోసెకన్లు).
ఆధునిక సర్వీస్ మెష్‌లు కూడా స్మార్ట్ లోడ్ బ్యాలెన్సింగ్ అల్గారిథమ్‌లను అమలు చేస్తాయి. బ్యాకెండ్‌ల ఆరోగ్యాన్ని పర్యవేక్షించడం ద్వారా, వారు మరింత ట్రాఫిక్‌ను వేగవంతమైన బ్యాకెండ్‌లకు పంపగలరు, ఫలితంగా మొత్తం పనితీరు మెరుగుపడుతుంది.
భద్రత మంచి కూడా. డాట్‌క్లౌడ్ రూటింగ్ మెష్ పూర్తిగా EC2 క్లాసిక్‌లో నడుస్తుంది మరియు ట్రాఫిక్‌ను గుప్తీకరించలేదు (ఎవరైనా EC2 నెట్‌వర్క్ ట్రాఫిక్‌పై స్నిఫర్‌ను ఉంచగలిగితే, మీరు ఇప్పటికే పెద్ద సమస్యలో ఉన్నారనే ఊహ ఆధారంగా). ఆధునిక సేవా మెష్‌లు మా ట్రాఫిక్ మొత్తాన్ని పారదర్శకంగా రక్షిస్తాయి, ఉదాహరణకు, పరస్పర TLS ప్రమాణీకరణ మరియు తదుపరి ఎన్‌క్రిప్షన్‌తో.
ప్లాట్‌ఫారమ్ సేవల కోసం ట్రాఫిక్ రూటింగ్
సరే, మేము అప్లికేషన్‌ల మధ్య ట్రాఫిక్ గురించి చర్చించాము, అయితే డాట్‌క్లౌడ్ ప్లాట్‌ఫారమ్ గురించి ఏమిటి?
ప్లాట్‌ఫారమ్ వివిధ విధులకు బాధ్యత వహించే సుమారు వంద మైక్రోసర్వీస్‌లను కలిగి ఉంది. కొందరు ఇతరుల నుండి అభ్యర్థనలను అంగీకరించారు మరియు కొందరు ఇతర సేవలకు కనెక్ట్ అయిన నేపథ్య కార్మికులు కానీ కనెక్షన్‌లను స్వయంగా అంగీకరించలేదు. ఏదైనా సందర్భంలో, ప్రతి సేవ తప్పనిసరిగా కనెక్ట్ కావాల్సిన చిరునామాల ముగింపు పాయింట్‌లను తెలుసుకోవాలి.
అనేక ఉన్నత-స్థాయి సేవలు పైన వివరించిన రూటింగ్ మెష్‌ని ఉపయోగించవచ్చు. నిజానికి, డాట్‌క్లౌడ్ ప్లాట్‌ఫారమ్‌లోనే అనేక డాట్‌క్లౌడ్ యొక్క వందకు పైగా మైక్రోసర్వీస్‌లు సాధారణ అప్లికేషన్‌లుగా అమలు చేయబడ్డాయి. కానీ తక్కువ సంఖ్యలో తక్కువ-స్థాయి సేవలు (ముఖ్యంగా ఈ రౌటింగ్ మెష్‌ను అమలు చేసేవి) తక్కువ డిపెండెన్సీలతో (అవి పని చేయడానికి తమపై ఆధారపడలేవు కాబట్టి - మంచి పాత కోడి మరియు గుడ్డు సమస్య) సరళమైనవి కావాలి.
ఈ తక్కువ-స్థాయి, మిషన్-క్లిష్టమైన సేవలు కొన్ని కీ నోడ్లలో నేరుగా కంటైనర్‌లను అమలు చేయడం ద్వారా అమలు చేయబడ్డాయి. ఈ సందర్భంలో, ప్రామాణిక ప్లాట్‌ఫారమ్ సేవలు ఉపయోగించబడలేదు: లింకర్, షెడ్యూలర్ మరియు రన్నర్. మీరు ఆధునిక కంటైనర్ ప్లాట్‌ఫారమ్‌లతో పోల్చాలనుకుంటే, అది కంట్రోల్ ప్లేన్‌ను నడుపుతున్నట్లే docker run కుబెర్నెట్‌లకు పనిని అప్పగించే బదులు నేరుగా నోడ్‌లపై. ఇది భావనలో చాలా పోలి ఉంటుంది , ఇది ఉపయోగిస్తుంది లేదా స్వతంత్ర క్లస్టర్‌ను బూట్ చేస్తున్నప్పుడు.
ఈ సేవలు సరళమైన మరియు క్రూడ్ పద్ధతిలో బహిర్గతం చేయబడ్డాయి: YAML ఫైల్ వారి పేర్లు మరియు చిరునామాలను జాబితా చేసింది; మరియు ప్రతి క్లయింట్ విస్తరణ కోసం ఈ YAML ఫైల్ కాపీని తీసుకోవాలి.
ఒక వైపు, ఇది చాలా నమ్మదగినది ఎందుకంటే దీనికి జూకీపర్ వంటి బాహ్య కీ/విలువ స్టోర్ మద్దతు అవసరం లేదు (ఆ సమయంలో etcd లేదా కాన్సుల్ లేరని గుర్తుంచుకోండి). మరోవైపు సర్వీసులను తరలించడం కష్టంగా మారింది. ప్రతిసారి తరలింపు జరిగినప్పుడు, క్లయింట్‌లందరూ నవీకరించబడిన YAML ఫైల్‌ని అందుకుంటారు (మరియు రీబూట్ అయ్యే అవకాశం ఉంది). చాలా సౌకర్యంగా లేదు!
తదనంతరం, మేము ప్రతి క్లయింట్ స్థానిక ప్రాక్సీ సర్వర్‌కు కనెక్ట్ చేయబడిన కొత్త పథకాన్ని అమలు చేయడం ప్రారంభించాము. చిరునామా మరియు పోర్ట్‌కు బదులుగా, ఇది సేవ యొక్క పోర్ట్ నంబర్‌ను మాత్రమే తెలుసుకోవాలి మరియు దాని ద్వారా కనెక్ట్ చేయాలి localhost. స్థానిక ప్రాక్సీ ఈ కనెక్షన్‌ని నిర్వహిస్తుంది మరియు దానిని వాస్తవ సర్వర్‌కు ఫార్వార్డ్ చేస్తుంది. ఇప్పుడు, బ్యాకెండ్‌ను మరొక యంత్రానికి లేదా స్కేలింగ్‌కి తరలించేటప్పుడు, అన్ని క్లయింట్‌లను నవీకరించడానికి బదులుగా, మీరు ఈ స్థానిక ప్రాక్సీలన్నింటినీ మాత్రమే నవీకరించాలి; మరియు ఇకపై రీబూట్ అవసరం లేదు.
(TLS కనెక్షన్‌లలోని ట్రాఫిక్‌ను సంగ్రహించడానికి మరియు స్వీకరించే వైపు మరొక ప్రాక్సీ సర్వర్‌ను ఉంచడానికి కూడా ప్రణాళిక చేయబడింది, అలాగే స్వీకరించే సేవలో పాల్గొనకుండా TLS ధృవీకరణ పత్రాలను ధృవీకరించండి, ఇది కనెక్షన్‌లను మాత్రమే ఆమోదించడానికి కాన్ఫిగర్ చేయబడింది. localhost. దీని గురించి మరింత తరువాత).
ఇది చాలా పోలి ఉంటుంది Airbnb నుండి, కానీ ముఖ్యమైన తేడా ఏమిటంటే SmartStack అమలు చేయబడుతుంది మరియు ఉత్పత్తికి అమలు చేయబడుతుంది, అయితే dotCloud డాకర్ అయినప్పుడు dotCloud యొక్క అంతర్గత రూటింగ్ సిస్టమ్ నిలిపివేయబడింది.
Istio, Linkerd మరియు Consul Connect వంటి సిస్టమ్‌ల పూర్వీకులలో SmartStack ఒకటిగా నేను వ్యక్తిగతంగా భావిస్తున్నాను ఎందుకంటే అవన్నీ ఒకే నమూనాను అనుసరిస్తాయి:
- ప్రతి నోడ్‌లో ప్రాక్సీని అమలు చేయండి.
- క్లయింట్లు ప్రాక్సీకి కనెక్ట్ అవుతారు.
- బ్యాకెండ్‌లు మారినప్పుడు కంట్రోల్ ప్లేన్ ప్రాక్సీ కాన్ఫిగరేషన్‌ను అప్‌డేట్ చేస్తుంది.
- ... లాభం!
సర్వీస్ మెష్ యొక్క ఆధునిక అమలు
ఈరోజు మనం ఇదే విధమైన గ్రిడ్‌ని అమలు చేయవలసి వస్తే, మనం ఇలాంటి సూత్రాలను ఉపయోగించవచ్చు. ఉదాహరణకు, స్పేస్‌లోని చిరునామాలకు సేవా పేర్లను మ్యాపింగ్ చేయడం ద్వారా అంతర్గత DNS జోన్‌ను కాన్ఫిగర్ చేయండి 127.0.0.0/8. ఆపై క్లస్టర్‌లోని ప్రతి నోడ్‌లో HAProxyని అమలు చేయండి, ప్రతి సేవా చిరునామాలో (ఆ సబ్‌నెట్‌లో) కనెక్షన్‌లను ఆమోదించండి 127.0.0.0/8) మరియు లోడ్‌ను తగిన బ్యాకెండ్‌లకు దారి మళ్లించడం/బ్యాలెన్సింగ్ చేయడం. HAProxy కాన్ఫిగరేషన్‌ని నియంత్రించవచ్చు , మీరు etcd లేదా కాన్సుల్‌లో బ్యాకెండ్ సమాచారాన్ని నిల్వ చేయడానికి అనుమతిస్తుంది మరియు అవసరమైనప్పుడు స్వయంచాలకంగా నవీకరించబడిన కాన్ఫిగరేషన్‌ను HAProxyకి పుష్ చేస్తుంది.
ఇది ఇస్టియో ఎలా పని చేస్తుందో చాలా చక్కనిది! కానీ కొన్ని తేడాలతో:
- ఉపయోగాలు HAProxyకి బదులుగా.
- etcd లేదా కాన్సుల్‌కు బదులుగా Kubernetes API ద్వారా బ్యాకెండ్ కాన్ఫిగరేషన్‌ను నిల్వ చేస్తుంది.
- సేవలు 127.0.0.0/8కి బదులుగా అంతర్గత సబ్‌నెట్‌లో (కుబెర్నెట్స్ క్లస్టర్‌ఐపి చిరునామాలు) చిరునామాలు కేటాయించబడ్డాయి.
- క్లయింట్ మరియు సర్వర్‌ల మధ్య పరస్పర TLS ప్రమాణీకరణను జోడించడానికి అదనపు భాగం (సిటాడెల్) ఉంది.
- సర్క్యూట్ బ్రేకింగ్, డిస్ట్రిబ్యూట్ ట్రేసింగ్, కానరీ డిప్లాయ్‌మెంట్ మొదలైన కొత్త ఫీచర్‌లకు మద్దతు ఇస్తుంది.
కొన్ని తేడాలను శీఘ్రంగా పరిశీలిద్దాం.
ఎన్వోయ్ ప్రాక్సీ
ఎన్వాయ్ ప్రాక్సీని లిఫ్ట్ రాశారు [టాక్సీ మార్కెట్‌లో ఉబెర్ యొక్క పోటీదారు - సుమారు. వీధి]. ఇది ఇతర ప్రాక్సీలకు (ఉదా. HAProxy, Nginx, Traefik...) అనేక విధాలుగా సారూప్యంగా ఉంటుంది, అయితే ఇతర ప్రాక్సీలకు లేని ఫీచర్‌లు వారికి అవసరమైనందున Lyft వారిది వ్రాసింది మరియు ఇప్పటికే ఉన్నదాన్ని పొడిగించకుండా కొత్తదాన్ని తయారు చేయడం మరింత తెలివిగా అనిపించింది.
రాయబారిని దాని స్వంతంగా ఉపయోగించవచ్చు. నేను ఇతర సేవలకు కనెక్ట్ చేయవలసిన నిర్దిష్ట సేవను కలిగి ఉంటే, నేను దానిని ఎన్వోయ్‌కి కనెక్ట్ చేయడానికి కాన్ఫిగర్ చేయగలను, ఆపై విజిబిలిటీ వంటి చాలా గొప్ప అదనపు కార్యాచరణను పొందుతున్నప్పుడు ఇతర సేవల స్థానంతో డైనమిక్‌గా కాన్ఫిగర్ చేసి ఎన్వాయ్‌ని మళ్లీ కాన్ఫిగర్ చేయగలను. కస్టమ్ క్లయింట్ లైబ్రరీకి బదులుగా లేదా కోడ్‌లోకి కాల్ ట్రేస్‌లను ఇంజెక్ట్ చేయడానికి, మేము ట్రాఫిక్‌ను ఎన్వోయ్‌కి పంపుతాము మరియు అది మా కోసం కొలమానాలను సేకరిస్తుంది.
కానీ రాయబారి కూడా పని చేయగలడు డేటా విమానం (డేటా ప్లేన్) సర్వీస్ మెష్ కోసం. ఈ సేవా మెష్ కోసం ఇప్పుడు ఎన్వోయ్ కాన్ఫిగర్ చేయబడిందని దీని అర్థం నియంత్రణ విమానం (నియంత్రణ విమానం).
నియంత్రణ విమానం
నియంత్రణ విమానం కోసం, Istio Kubernetes APIపై ఆధారపడుతుంది. ఇది confdని ఉపయోగించడం నుండి చాలా భిన్నంగా లేదు, ఇది డేటా స్టోర్‌లోని కీల సెట్‌ను వీక్షించడానికి etcd లేదా కాన్సుల్‌పై ఆధారపడుతుంది. Kubernetes వనరుల సమితిని వీక్షించడానికి Istio Kubernetes APIని ఉపయోగిస్తుంది.
ఈ మధ్య: నేను వ్యక్తిగతంగా ఇది ఉపయోగకరంగా ఉంది ఇది చదువుతుంది:
కుబెర్నెటెస్ API సర్వర్ అనేది API వనరుల కోసం నిల్వ, సంస్కరణ, ధ్రువీకరణ, నవీకరణ మరియు అర్థశాస్త్రాలను అందించే "మూగ సర్వర్".
ఇస్టియో కుబెర్నెటీస్‌తో కలిసి పనిచేయడానికి రూపొందించబడింది; మరియు మీరు దీన్ని Kubernetes వెలుపల ఉపయోగించాలనుకుంటే, మీరు Kubernetes API సర్వర్ (మరియు etcd సహాయక సేవ) యొక్క ఉదాహరణను అమలు చేయాలి.
సేవా చిరునామాలు
ఇస్టియో కుబెర్నెట్స్ కేటాయించే క్లస్టర్‌ఐపి చిరునామాలపై ఆధారపడుతుంది, కాబట్టి ఇస్టియో సేవలు అంతర్గత చిరునామాను పొందుతాయి (పరిధిలో కాదు 127.0.0.0/8).
Istio లేకుండా Kubernetes క్లస్టర్‌లోని నిర్దిష్ట సేవ కోసం ClusterIP చిరునామాకు ట్రాఫిక్ kube-proxy ద్వారా అడ్డగించబడుతుంది మరియు ఆ ప్రాక్సీ యొక్క బ్యాకెండ్‌కి పంపబడుతుంది. మీకు సాంకేతిక వివరాలపై ఆసక్తి ఉంటే, ClusterIP చిరునామాకు వెళ్లే కనెక్షన్‌ల గమ్యస్థాన IP చిరునామాలను తిరిగి వ్రాయడానికి kube-proxy iptables నియమాలను (లేదా IPVS లోడ్ బ్యాలెన్సర్‌లు, అది ఎలా కాన్ఫిగర్ చేయబడిందో బట్టి) సెట్ చేస్తుంది.
Kubernetes క్లస్టర్‌లో Istio ఇన్‌స్టాల్ చేసిన తర్వాత, ఒక కంటైనర్‌ను పరిచయం చేయడం ద్వారా ఇచ్చిన వినియోగదారుకు లేదా మొత్తం నేమ్‌స్పేస్‌కు కూడా ఇది స్పష్టంగా ప్రారంభించబడే వరకు ఏమీ మారదు sidecar అనుకూల పాడ్‌లలోకి. ఈ కంటైనర్ ఎన్వోయ్ యొక్క ఉదాహరణను స్పిన్ అప్ చేస్తుంది మరియు ఇతర సేవలకు వెళ్లే ట్రాఫిక్‌ను అడ్డుకోవడానికి మరియు ఆ ట్రాఫిక్‌ను ఎన్వోయ్‌కి మళ్లించడానికి iptables నియమాల సమితిని సెటప్ చేస్తుంది.
Kubernetes DNSతో అనుసంధానించబడినప్పుడు, మా కోడ్ సేవ పేరు మరియు "కేవలం పని చేస్తుంది" అనే ప్రతిదాని ద్వారా కనెక్ట్ చేయగలదని దీని అర్థం. మరో మాటలో చెప్పాలంటే, మా కోడ్ వంటి ప్రశ్నలను జారీ చేస్తుంది http://api/v1/users/4242అప్పుడు api కోసం అభ్యర్థనను పరిష్కరించండి 10.97.105.48, iptables నియమాలు 10.97.105.48 నుండి కనెక్షన్‌లను అడ్డగిస్తాయి మరియు వాటిని స్థానిక ఎన్వోయ్ ప్రాక్సీకి ఫార్వార్డ్ చేస్తాయి మరియు ఆ స్థానిక ప్రాక్సీ అభ్యర్థనను వాస్తవ బ్యాకెండ్ APIకి ఫార్వార్డ్ చేస్తుంది. అయ్యో!
అదనపు frills
Istio mTLS (మ్యూచువల్ TLS) ద్వారా ఎండ్-టు-ఎండ్ ఎన్‌క్రిప్షన్ మరియు ప్రామాణీకరణను కూడా అందిస్తుంది. అనే ఒక భాగం సిటాడెల్.
ఒక భాగం కూడా ఉంది మిక్సర్, ఏ రాయబారి అభ్యర్థించవచ్చు ప్రతి హెడర్‌లు, బ్యాకెండ్ లోడ్ మొదలైన వివిధ కారకాలపై ఆధారపడి ఆ అభ్యర్థన గురించి ప్రత్యేక నిర్ణయం తీసుకోమని అభ్యర్థించండి... (చింతించకండి: మిక్సర్‌ని కొనసాగించడానికి అనేక మార్గాలు ఉన్నాయి మరియు అది క్రాష్ అయినప్పటికీ, ఎన్వోయ్ పని చేస్తూనే ఉంటుంది ప్రాక్సీగా మంచిది) .
మరియు, వాస్తవానికి, మేము విజిబిలిటీని పేర్కొన్నాము: పంపిణీ చేయబడిన ట్రేసింగ్‌ను అందించేటప్పుడు ఎన్వాయ్ భారీ మొత్తంలో కొలమానాలను సేకరిస్తుంది. మైక్రోసర్వీస్ ఆర్కిటెక్చర్‌లో, ఒక API అభ్యర్థన తప్పనిసరిగా మైక్రోసర్వీస్ A, B, C మరియు D గుండా వెళితే, లాగిన్ అయిన తర్వాత, పంపిణీ చేయబడిన ట్రేసింగ్ అభ్యర్థనకు ఒక ప్రత్యేక ఐడెంటిఫైయర్‌ని జోడిస్తుంది మరియు ఈ ఐడెంటిఫైయర్‌ని ఈ మైక్రోసర్వీస్‌లన్నింటికీ సబ్‌రిక్వెస్ట్‌ల ద్వారా నిల్వ చేస్తుంది. అన్ని సంబంధిత కాల్‌లను క్యాప్చర్ చేయాలి. ఆలస్యం, మొదలైనవి.
అభివృద్ధి చేయండి లేదా కొనండి
ఇస్టియో సంక్లిష్టంగా ఖ్యాతిని పొందింది. దీనికి విరుద్ధంగా, ఈ పోస్ట్ ప్రారంభంలో నేను వివరించిన రూటింగ్ మెష్‌ను రూపొందించడం ఇప్పటికే ఉన్న సాధనాలను ఉపయోగించడం చాలా సులభం. కాబట్టి, బదులుగా మీ స్వంత సేవా మెష్‌ని సృష్టించడం సమంజసమా?
మనకు నిరాడంబరమైన అవసరాలు ఉంటే (మాకు దృశ్యమానత, సర్క్యూట్ బ్రేకర్ మరియు ఇతర సూక్ష్మబేధాలు అవసరం లేదు), అప్పుడు మన స్వంత సాధనాన్ని అభివృద్ధి చేయడానికి ఆలోచనలు వస్తాయి. కానీ మేము కుబెర్నెట్‌లను ఉపయోగిస్తే, దాని అవసరం కూడా ఉండకపోవచ్చు ఎందుకంటే కుబెర్నెట్స్ ఇప్పటికే సర్వీస్ డిస్కవరీ మరియు లోడ్ బ్యాలెన్సింగ్ కోసం ప్రాథమిక సాధనాలను అందిస్తుంది.
కానీ మనకు అధునాతన అవసరాలు ఉంటే, సేవా మెష్‌ను “కొనుగోలు చేయడం” చాలా మంచి ఎంపికగా కనిపిస్తుంది. (ఇస్టియో ఓపెన్ సోర్స్ అయినందున ఇది ఎల్లప్పుడూ "కొనుగోలు" కాదు, కానీ దానిని అర్థం చేసుకోవడానికి, అమలు చేయడానికి మరియు నిర్వహించడానికి మేము ఇంకా ఇంజనీరింగ్ సమయాన్ని పెట్టుబడి పెట్టాలి.)
నేను Istio, Linkerd లేదా Consul Connect ఎంచుకోవాలా?
ఇప్పటివరకు మేము ఇస్టియో గురించి మాత్రమే మాట్లాడాము, కానీ ఇది మాత్రమే సేవా మెష్ కాదు. ఒక ప్రసిద్ధ ప్రత్యామ్నాయం , మరియు మరింత ఉంది .
ఏమి ఎంచుకోవాలి?
నిజాయితీగా, నాకు తెలియదు. ప్రస్తుతానికి ఈ ప్రశ్నకు సమాధానం చెప్పేంత సమర్థుడని నేను భావించడం లేదు. కొన్ని ఉన్నాయి ఈ సాధనాల పోలికతో మరియు కూడా .
వంటి సాధనాన్ని ఉపయోగించడం ఒక మంచి విధానం . సర్వీస్ మెష్‌ల ద్వారా బహిర్గతమయ్యే APIలను సరళీకృతం చేయడానికి మరియు ఏకీకృతం చేయడానికి ఇది సంగ్రహణ పొరను అమలు చేస్తుంది. విభిన్న సేవా మెష్‌ల యొక్క నిర్దిష్ట (మరియు, నా అభిప్రాయం ప్రకారం, సాపేక్షంగా సంక్లిష్టమైన) APIలను నేర్చుకునే బదులు, మేము SuperGloo యొక్క సరళమైన నిర్మాణాలను ఉపయోగించవచ్చు - మరియు HTTP ఇంటర్‌ఫేస్‌లు మరియు బ్యాకెండ్‌లను వివరించే ఇంటర్మీడియట్ కాన్ఫిగరేషన్ ఆకృతిని కలిగి ఉన్నట్లుగా, మేము ఒకదాని నుండి మరొకదానికి సులభంగా మారవచ్చు. Nginx, HAProxy, Traefik, Apache... కోసం వాస్తవ కాన్ఫిగరేషన్‌ను రూపొందించడం.
నేను ఇస్టియో మరియు సూపర్‌గ్లూతో కొంచెం మాట్లాడాను మరియు తదుపరి కథనంలో నేను సూపర్‌గ్లూని ఉపయోగించి ఇప్పటికే ఉన్న క్లస్టర్‌కి ఇస్టియో లేదా లింకర్డ్‌ని ఎలా జోడించాలో చూపించాలనుకుంటున్నాను మరియు రెండోది పనిని ఎలా పూర్తి చేస్తుంది, అంటే, దీని నుండి మారడానికి మిమ్మల్ని అనుమతిస్తుంది కాన్ఫిగరేషన్‌లను ఓవర్‌రైట్ చేయకుండా మరొక సర్వీస్ మెష్.
మూలం: www.habr.com