గమనిక. అనువాదం.: ప్రపంచ ప్రఖ్యాత టిండెర్ సర్వీస్ ఉద్యోగులు ఇటీవల కుబెర్నెట్‌లకు తమ మౌలిక సదుపాయాలను తరలించడానికి సంబంధించిన కొన్ని సాంకేతిక వివరాలను పంచుకున్నారు. ఈ ప్రక్రియ దాదాపు రెండు సంవత్సరాలు పట్టింది మరియు 8 వేల కంటైనర్‌లలో హోస్ట్ చేయబడిన 200 సేవలతో కూడిన K48 లలో చాలా పెద్ద-స్థాయి ప్లాట్‌ఫారమ్ ప్రారంభించబడింది. టిండెర్ ఇంజనీర్లు ఎలాంటి ఆసక్తికరమైన సమస్యలను ఎదుర్కొన్నారు మరియు వారు ఎలాంటి ఫలితాలను సాధించారు?ఈ అనువాదం చదవండి.
ఎందుకు?
దాదాపు రెండు సంవత్సరాల క్రితం, టిండర్ తన ప్లాట్‌ఫారమ్‌ను కుబెర్నెటెస్‌కు తరలించాలని నిర్ణయించుకుంది. కుబెర్నెటెస్ టిండెర్ బృందాన్ని కంటెయినరైజ్ చేయడానికి మరియు మార్పులేని విస్తరణ ద్వారా తక్కువ ప్రయత్నంతో ఉత్పత్తికి వెళ్లడానికి అనుమతిస్తుంది. (మార్పులేని విస్తరణ). ఈ సందర్భంలో, అప్లికేషన్‌ల అసెంబ్లీ, వాటి విస్తరణ మరియు మౌలిక సదుపాయాలు కూడా కోడ్ ద్వారా ప్రత్యేకంగా నిర్వచించబడతాయి.
మేము స్కేలబిలిటీ మరియు స్థిరత్వం సమస్యకు పరిష్కారం కోసం కూడా చూస్తున్నాము. స్కేలింగ్ క్లిష్టంగా మారినప్పుడు, కొత్త EC2 ఉదంతాలు స్పిన్ అప్ చేయడానికి మేము తరచుగా చాలా నిమిషాలు వేచి ఉండాల్సి ఉంటుంది. కంటైనర్‌లను ప్రారంభించడం మరియు నిమిషాలకు బదులుగా సెకన్లలో ట్రాఫిక్‌ను అందించడం ప్రారంభించాలనే ఆలోచన మాకు చాలా ఆకర్షణీయంగా మారింది.
ప్రక్రియ కష్టంగా మారింది. 2019 ప్రారంభంలో మా వలసల సమయంలో, కుబెర్నెట్స్ క్లస్టర్ క్లిష్ట స్థాయికి చేరుకుంది మరియు ట్రాఫిక్ వాల్యూమ్, క్లస్టర్ పరిమాణం మరియు DNS కారణంగా మేము వివిధ సమస్యలను ఎదుర్కోవడం ప్రారంభించాము. అలాగే, మేము 200 సేవలను తరలించడానికి మరియు 1000 నోడ్‌లు, 15000 పాడ్‌లు మరియు 48000 రన్నింగ్ కంటైనర్‌లతో కూడిన కుబెర్నెట్స్ క్లస్టర్‌ను నిర్వహించడానికి సంబంధించిన చాలా ఆసక్తికరమైన సమస్యలను పరిష్కరించాము.
ఎలా?
జనవరి 2018 నుండి, మేము వలస యొక్క వివిధ దశల గుండా వెళ్ళాము. మేము మా సేవలన్నింటినీ కంటెయినరైజ్ చేయడం ద్వారా మరియు వాటిని కుబెర్నెట్స్ టెస్ట్ క్లౌడ్ ఎన్విరాన్‌మెంట్‌లకు అమలు చేయడం ద్వారా ప్రారంభించాము. అక్టోబరు నుండి, మేము ప్రస్తుతం ఉన్న అన్ని సేవలను కుబెర్నెట్‌లకు పద్దతిగా తరలించడం ప్రారంభించాము. తరువాతి సంవత్సరం మార్చి నాటికి, మేము వలసలను పూర్తి చేసాము మరియు ఇప్పుడు టిండర్ ప్లాట్‌ఫారమ్ ప్రత్యేకంగా కుబెర్నెట్స్‌లో నడుస్తుంది.
కుబెర్నెట్స్ కోసం బిల్డింగ్ ఇమేజ్‌లు
మేము Kubernetes క్లస్టర్‌లో నడుస్తున్న మైక్రోసర్వీస్‌ల కోసం 30కి పైగా సోర్స్ కోడ్ రిపోజిటరీలను కలిగి ఉన్నాము. ఈ రిపోజిటరీలలోని కోడ్ ఒకే భాష కోసం బహుళ రన్‌టైమ్ పరిసరాలతో వివిధ భాషలలో (ఉదాహరణకు, Node.js, Java, Scala, Go) వ్రాయబడింది.
ప్రతి మైక్రోసర్వీస్ కోసం పూర్తిగా అనుకూలీకరించదగిన “బిల్డ్ కాంటెక్స్ట్” అందించడానికి బిల్డ్ సిస్టమ్ రూపొందించబడింది. ఇది సాధారణంగా డాకర్‌ఫైల్ మరియు షెల్ ఆదేశాల జాబితాను కలిగి ఉంటుంది. వాటి కంటెంట్ పూర్తిగా అనుకూలీకరించదగినది మరియు అదే సమయంలో, ఈ బిల్డ్ సందర్భాలన్నీ ప్రామాణిక ఆకృతి ప్రకారం వ్రాయబడ్డాయి. బిల్డ్ కాంటెక్స్ట్‌లను ప్రామాణీకరించడం ఒక సింగిల్ బిల్డ్ సిస్టమ్‌ను అన్ని మైక్రోసర్వీస్‌లను నిర్వహించడానికి అనుమతిస్తుంది.
మూర్తి 1-1. బిల్డర్ కంటైనర్ ద్వారా ప్రామాణిక నిర్మాణ ప్రక్రియ
రన్‌టైమ్‌ల మధ్య గరిష్ట స్థిరత్వాన్ని సాధించడానికి (రన్‌టైమ్ పరిసరాలు) అభివృద్ధి మరియు పరీక్ష సమయంలో అదే నిర్మాణ ప్రక్రియ ఉపయోగించబడుతుంది. మేము చాలా ఆసక్తికరమైన సవాలును ఎదుర్కొన్నాము: మొత్తం ప్లాట్‌ఫారమ్‌లో నిర్మాణ వాతావరణం యొక్క స్థిరత్వాన్ని నిర్ధారించడానికి మేము ఒక మార్గాన్ని అభివృద్ధి చేయాలి. దీనిని సాధించడానికి, అన్ని అసెంబ్లీ ప్రక్రియలు ప్రత్యేక కంటైనర్ లోపల నిర్వహించబడతాయి. బిల్డర్.
అతని కంటైనర్ అమలుకు అధునాతన డాకర్ పద్ధతులు అవసరం. ప్రైవేట్ టిండెర్ రిపోజిటరీలను యాక్సెస్ చేయడానికి అవసరమైన స్థానిక వినియోగదారు ID మరియు రహస్యాలు (SSH కీ, AWS ఆధారాలు మొదలైనవి) బిల్డర్ వారసత్వంగా పొందుతుంది. ఇది సహజంగా నిర్మాణ కళాఖండాలను నిల్వ చేయడానికి మూలాలను కలిగి ఉన్న స్థానిక డైరెక్టరీలను మౌంట్ చేస్తుంది. ఈ విధానం పనితీరును మెరుగుపరుస్తుంది ఎందుకంటే ఇది బిల్డర్ కంటైనర్ మరియు హోస్ట్ మధ్య నిర్మాణ కళాఖండాలను కాపీ చేయవలసిన అవసరాన్ని తొలగిస్తుంది. నిల్వ చేయబడిన నిర్మాణ కళాఖండాలు అదనపు కాన్ఫిగరేషన్ లేకుండా తిరిగి ఉపయోగించబడతాయి.
కొన్ని సేవల కోసం, కంపైలేషన్ ఎన్విరాన్మెంట్‌ను రన్‌టైమ్ ఎన్విరాన్‌మెంట్‌కు మ్యాప్ చేయడానికి మేము మరొక కంటైనర్‌ను సృష్టించాలి (ఉదాహరణకు, ఇన్‌స్టాలేషన్ సమయంలో Node.js bcrypt లైబ్రరీ ప్లాట్‌ఫారమ్-నిర్దిష్ట బైనరీ కళాఖండాలను ఉత్పత్తి చేస్తుంది). సంకలన ప్రక్రియలో, సేవల మధ్య అవసరాలు మారవచ్చు మరియు చివరి డాకర్‌ఫైల్ ఫ్లైలో కంపైల్ చేయబడుతుంది.
కుబెర్నెటెస్ క్లస్టర్ ఆర్కిటెక్చర్ మరియు మైగ్రేషన్
క్లస్టర్ పరిమాణం నిర్వహణ
మేము ఉపయోగించాలని నిర్ణయించుకున్నాము kube-aws Amazon EC2 సందర్భాల్లో ఆటోమేటెడ్ క్లస్టర్ విస్తరణ కోసం. చాలా ప్రారంభంలో, ప్రతిదీ నోడ్‌ల యొక్క ఒక సాధారణ పూల్‌లో పనిచేసింది. వనరులను మరింత సమర్థవంతంగా ఉపయోగించుకోవడానికి పనిభారాన్ని పరిమాణం మరియు ఉదాహరణ రకం ద్వారా వేరు చేయవలసిన అవసరాన్ని మేము త్వరగా గ్రహించాము. తర్కం ఏమిటంటే, అనేక లోడ్ చేయబడిన బహుళ-థ్రెడ్ పాడ్‌లు పెద్ద సంఖ్యలో సింగిల్-థ్రెడ్ పాడ్‌లతో సహజీవనం చేయడం కంటే పనితీరు పరంగా మరింత ఊహించదగినవిగా మారాయి.
చివరికి మేము స్థిరపడ్డాము:
- m5.4x పెద్దది - పర్యవేక్షణ కోసం (ప్రోమేతియస్);
- c5.4x పెద్దది - Node.js వర్క్‌లోడ్ (సింగిల్-థ్రెడ్ వర్క్‌లోడ్) కోసం;
- c5.2x పెద్దది - జావా మరియు గో కోసం (మల్టీథ్రెడ్ వర్క్‌లోడ్);
- c5.4x పెద్దది - నియంత్రణ ప్యానెల్ కోసం (3 నోడ్స్).
వలస
పాత ఇన్‌ఫ్రాస్ట్రక్చర్ నుండి కుబెర్నెట్‌స్‌కి మారడానికి సన్నాహక దశల్లో ఒకటి, సేవల మధ్య ఉన్న డైరెక్ట్ కమ్యూనికేషన్‌ను కొత్త లోడ్ బ్యాలెన్సర్‌లకు (ఎలాస్టిక్ లోడ్ బ్యాలెన్సర్‌లు (ELB) మళ్లించడం. అవి వర్చువల్ ప్రైవేట్ క్లౌడ్ (VPC) యొక్క నిర్దిష్ట సబ్‌నెట్‌లో సృష్టించబడ్డాయి. ఈ సబ్‌నెట్ Kubernetes VPCకి కనెక్ట్ చేయబడింది. ఇది సేవా డిపెండెన్సీల నిర్దిష్ట క్రమాన్ని పరిగణనలోకి తీసుకోకుండా మాడ్యూల్‌లను క్రమంగా తరలించడానికి మాకు అనుమతి ఇచ్చింది.
ప్రతి కొత్త ELBకి సూచించే CNAMEలను కలిగి ఉన్న DNS రికార్డ్‌ల బరువున్న సెట్‌లను ఉపయోగించి ఈ ముగింపు పాయింట్‌లు సృష్టించబడ్డాయి. మారడానికి, మేము 0 బరువుతో Kubernetes సేవ యొక్క కొత్త ELBకి సూచించే కొత్త ఎంట్రీని జోడించాము. ఆపై మేము ఎంట్రీ యొక్క టైమ్ టు లైవ్ (TTL)ని 0కి సెట్ చేసాము. దీని తర్వాత, పాత మరియు కొత్త బరువులు నెమ్మదిగా సర్దుబాటు చేయబడింది మరియు చివరికి 100% లోడ్ కొత్త సర్వర్‌కు పంపబడింది. మారడం పూర్తయిన తర్వాత, TTL విలువ మరింత తగిన స్థాయికి తిరిగి వచ్చింది.
మా వద్ద ఉన్న జావా మాడ్యూల్‌లు తక్కువ TTL DNSని తట్టుకోగలవు, కానీ నోడ్ అప్లికేషన్‌లు చేయలేవు. ఇంజనీర్‌లలో ఒకరు కనెక్షన్ పూల్ కోడ్‌లో కొంత భాగాన్ని తిరిగి వ్రాసి, ప్రతి 60 సెకన్లకు పూల్‌లను అప్‌డేట్ చేసే మేనేజర్‌లో చుట్టారు. ఎంచుకున్న విధానం చాలా బాగా పనిచేసింది మరియు ఎటువంటి గుర్తించదగిన పనితీరు క్షీణత లేకుండా.
పాఠాలు
నెట్‌వర్క్ ఫాబ్రిక్ యొక్క పరిమితులు
జనవరి 8, 2019 తెల్లవారుజామున టిండెర్ ప్లాట్‌ఫారమ్ అనుకోకుండా క్రాష్ అయింది. ఆ రోజు ఉదయం ప్లాట్‌ఫారమ్ జాప్యంలో సంబంధం లేని పెరుగుదలకు ప్రతిస్పందనగా, క్లస్టర్‌లోని పాడ్‌లు మరియు నోడ్‌ల సంఖ్య పెరిగింది. దీని వలన మా నోడ్‌లన్నింటిలో ARP కాష్ అయిపోయింది.
ARP కాష్‌కి సంబంధించి మూడు Linux ఎంపికలు ఉన్నాయి:
()
gc_thresh3 - ఇది కఠినమైన పరిమితి. లాగ్‌లో “నైబర్ టేబుల్ ఓవర్‌ఫ్లో” ఎంట్రీలు కనిపించడం అంటే సింక్రోనస్ గార్బేజ్ కలెక్షన్ (GC) తర్వాత కూడా పొరుగున ఉన్న ఎంట్రీని నిల్వ చేయడానికి ARP కాష్‌లో తగినంత స్థలం లేదు. ఈ సందర్భంలో, కెర్నల్ ప్యాకెట్‌ను పూర్తిగా విస్మరించింది.
మేము ఉపయోగిస్తాము కుబెర్నెట్స్‌లో నెట్‌వర్క్ ఫాబ్రిక్‌గా. ప్యాకెట్లు VXLAN ద్వారా ప్రసారం చేయబడతాయి. VXLAN అనేది L2 నెట్‌వర్క్ పైన ఉన్న L3 సొరంగం. సాంకేతికత MAC-in-UDP (MAC అడ్రస్-ఇన్-యూజర్ డేటాగ్రామ్ ప్రోటోకాల్) ఎన్‌క్యాప్సులేషన్‌ను ఉపయోగిస్తుంది మరియు లేయర్ 2 నెట్‌వర్క్ విభాగాల విస్తరణను అనుమతిస్తుంది. భౌతిక డేటా సెంటర్ నెట్‌వర్క్‌లోని రవాణా ప్రోటోకాల్ IP ప్లస్ UDP.
మూర్తి 2-1. ఫ్లాన్నెల్ రేఖాచిత్రం ()
మూర్తి 2-2. VXLAN ప్యాకేజీ ()
ప్రతి కుబెర్నెట్స్ వర్కర్ నోడ్ ఒక పెద్ద /24 బ్లాక్ నుండి /9 మాస్క్‌తో వర్చువల్ అడ్రస్ స్పేస్‌ను కేటాయిస్తుంది. ప్రతి నోడ్ కోసం ఇది రూటింగ్ టేబుల్‌లో ఒక ఎంట్రీ, ARP పట్టికలో ఒక ఎంట్రీ (ఫ్లాన్నెల్.1 ఇంటర్‌ఫేస్‌లో), మరియు స్విచింగ్ టేబుల్‌లో ఒక ఎంట్రీ (FDB). వర్కర్ నోడ్‌ను ప్రారంభించినప్పుడు లేదా ప్రతిసారి కొత్త నోడ్ కనుగొనబడినప్పుడు అవి జోడించబడతాయి.
అదనంగా, నోడ్-పాడ్ (లేదా పాడ్-పాడ్) కమ్యూనికేషన్ అంతిమంగా ఇంటర్ఫేస్ ద్వారా వెళుతుంది eth0 (పైన ఫ్లాన్నెల్ రేఖాచిత్రంలో చూపిన విధంగా). ఇది ప్రతి సంబంధిత సోర్స్ మరియు డెస్టినేషన్ హోస్ట్ కోసం ARP పట్టికలో అదనపు నమోదుకు దారి తీస్తుంది.
మన వాతావరణంలో, ఈ రకమైన కమ్యూనికేషన్ చాలా సాధారణం. కుబెర్నెటీస్‌లోని సర్వీస్ ఆబ్జెక్ట్‌ల కోసం, ఒక ELB సృష్టించబడుతుంది మరియు Kubernetes ప్రతి నోడ్‌ను ELBతో నమోదు చేస్తుంది. ELBకి పాడ్‌ల గురించి ఏమీ తెలియదు మరియు ఎంచుకున్న నోడ్ ప్యాకెట్ యొక్క చివరి గమ్యస్థానం కాకపోవచ్చు. విషయం ఏమిటంటే, నోడ్ ELB నుండి ప్యాకెట్‌ను స్వీకరించినప్పుడు, అది నిబంధనలను పరిగణనలోకి తీసుకుంటుంది. iptables ఒక నిర్దిష్ట సేవ కోసం మరియు యాదృచ్ఛికంగా మరొక నోడ్‌లో పాడ్‌ను ఎంచుకుంటుంది.
వైఫల్యం సమయంలో, క్లస్టర్‌లో 605 నోడ్‌లు ఉన్నాయి. పైన పేర్కొన్న కారణాల వల్ల, ప్రాముఖ్యతను అధిగమించడానికి ఇది సరిపోతుంది gc_thresh3, ఇది డిఫాల్ట్. ఇది జరిగినప్పుడు, ప్యాకెట్లు వదలబడటం మాత్రమే కాకుండా, /24 మాస్క్‌తో ఉన్న మొత్తం ఫ్లాన్నెల్ వర్చువల్ అడ్రస్ స్పేస్ ARP పట్టిక నుండి అదృశ్యమవుతుంది. నోడ్-పాడ్ కమ్యూనికేషన్ మరియు DNS ప్రశ్నలకు అంతరాయం ఏర్పడింది (DNS క్లస్టర్‌లో హోస్ట్ చేయబడింది; వివరాల కోసం ఈ కథనంలో తర్వాత చదవండి).
ఈ సమస్యను పరిష్కరించడానికి, మీరు విలువలను పెంచాలి gc_thresh1, gc_thresh2 и gc_thresh3 మరియు తప్పిపోయిన నెట్‌వర్క్‌లను మళ్లీ నమోదు చేయడానికి ఫ్లాన్నెల్‌ని పునఃప్రారంభించండి.
ఊహించని DNS స్కేలింగ్
మైగ్రేషన్ ప్రక్రియలో, ట్రాఫిక్‌ని నిర్వహించడానికి మరియు పాత మౌలిక సదుపాయాల నుండి కుబెర్నెట్‌లకు సేవలను క్రమంగా బదిలీ చేయడానికి మేము DNSని చురుకుగా ఉపయోగించాము. మేము Route53లో అనుబంధిత రికార్డ్‌సెట్‌ల కోసం తక్కువ TTL విలువలను సెట్ చేసాము. పాత ఇన్‌ఫ్రాస్ట్రక్చర్ EC2 ఇన్‌స్టాన్స్‌లలో రన్ అవుతున్నప్పుడు, మా రిసల్వర్ కాన్ఫిగరేషన్ Amazon DNSకి సూచించబడింది. మేము దీనిని తేలికగా తీసుకున్నాము మరియు మా సేవలు మరియు Amazon సేవలపై (DynamoDB వంటివి) తక్కువ TTL ప్రభావం పెద్దగా గుర్తించబడలేదు.
మేము సేవలను కుబెర్నెటెస్‌కు తరలించినప్పుడు, DNS సెకనుకు 250 వేల అభ్యర్థనలను ప్రాసెస్ చేస్తున్నట్లు మేము కనుగొన్నాము. ఫలితంగా, అప్లికేషన్‌లు DNS ప్రశ్నల కోసం స్థిరమైన మరియు తీవ్రమైన గడువులను అనుభవించడం ప్రారంభించాయి. DNS ప్రొవైడర్‌ను CoreDNSకి ఆప్టిమైజ్ చేయడానికి మరియు మార్చడానికి నమ్మశక్యం కాని ప్రయత్నాలు చేసినప్పటికీ ఇది జరిగింది (ఇది గరిష్ట లోడ్‌లో 1000 కోర్లలో నడుస్తున్న 120 పాడ్‌లకు చేరుకుంది).
ఇతర కారణాలు మరియు పరిష్కారాలను పరిశోధిస్తున్నప్పుడు, మేము కనుగొన్నాము , ప్యాకెట్ ఫిల్టరింగ్ ఫ్రేమ్‌వర్క్‌ను ప్రభావితం చేసే రేసు పరిస్థితులను వివరిస్తుంది netfilter Linux లో. పెరుగుతున్న కౌంటర్‌తో పాటు మేము గమనించిన గడువులు ఇన్సర్ట్_విఫలమైంది ఫ్లాన్నెల్ ఇంటర్‌ఫేస్‌లో వ్యాసం యొక్క అన్వేషణలకు అనుగుణంగా ఉన్నాయి.
సమస్య సోర్స్ మరియు డెస్టినేషన్ నెట్‌వర్క్ అడ్రస్ ట్రాన్స్‌లేషన్ (SNAT మరియు DNAT) దశలో సంభవిస్తుంది మరియు పట్టికలోకి తదుపరి ప్రవేశం కాంట్రాక్. అంతర్గతంగా చర్చించబడిన మరియు సంఘం సూచించిన పరిష్కారాలలో ఒకటి DNSని వర్కర్ నోడ్‌కు తరలించడం. ఈ విషయంలో:
- నోడ్ లోపల ట్రాఫిక్ ఉంటుంది కాబట్టి SNAT అవసరం లేదు. ఇది ఇంటర్ఫేస్ ద్వారా రూట్ చేయవలసిన అవసరం లేదు eth0.
- గమ్యం IP నోడ్‌కు స్థానికంగా ఉంటుంది మరియు నిబంధనల ప్రకారం యాదృచ్ఛికంగా ఎంపిక చేయబడిన పాడ్ కాదు కాబట్టి DNAT అవసరం లేదు iptables.
మేము ఈ విధానానికి కట్టుబడి ఉండాలని నిర్ణయించుకున్నాము. CoreDNS Kubernetesలో డెమోన్‌సెట్‌గా అమలు చేయబడింది మరియు మేము లోకల్ నోడ్ DNS సర్వర్‌ని అమలు చేసాము resolutionv.conf జెండాను అమర్చడం ద్వారా ప్రతి పాడ్ --క్లస్టర్-dns ఆదేశాలు క్యూబ్లెట్ . ఈ పరిష్కారం DNS గడువు ముగిసే సమయానికి ప్రభావవంతంగా ఉంటుంది.
అయినప్పటికీ, మేము ఇప్పటికీ ప్యాకెట్ నష్టాన్ని మరియు కౌంటర్లో పెరుగుదలను చూశాము ఇన్సర్ట్_విఫలమైంది ఫ్లాన్నెల్ ఇంటర్‌ఫేస్‌లో. మేము DNS ట్రాఫిక్ కోసం మాత్రమే SNAT మరియు/లేదా DNATని తొలగించగలిగాము కాబట్టి ప్రత్యామ్నాయం అమలు చేయబడిన తర్వాత ఇది కొనసాగింది. ఇతర రకాల ట్రాఫిక్ కోసం జాతి పరిస్థితులు భద్రపరచబడ్డాయి. అదృష్టవశాత్తూ, మా ప్యాకెట్లలో చాలా వరకు TCP ఉన్నాయి మరియు సమస్య ఏర్పడితే అవి మళ్లీ ప్రసారం చేయబడతాయి. మేము ఇప్పటికీ అన్ని రకాల ట్రాఫిక్‌కు తగిన పరిష్కారాన్ని కనుగొనడానికి ప్రయత్నిస్తున్నాము.
మెరుగైన లోడ్ బ్యాలెన్సింగ్ కోసం రాయబారిని ఉపయోగించడం
మేము కుబెర్నెట్‌లకు బ్యాకెండ్ సేవలను తరలించినందున, మేము పాడ్‌ల మధ్య అసమతుల్య లోడ్‌తో బాధపడటం ప్రారంభించాము. HTTP Keepalive ELB కనెక్షన్‌లను రూపొందించిన ప్రతి డిప్లాయ్‌మెంట్‌లోని మొదటి సిద్ధంగా ఉన్న పాడ్‌లపై వేలాడదీయడానికి కారణమని మేము కనుగొన్నాము. అందువల్ల, ట్రాఫిక్‌లో ఎక్కువ భాగం అందుబాటులో ఉన్న పాడ్‌లలో తక్కువ శాతం ద్వారా వెళ్ళింది. మేము పరీక్షించిన మొదటి పరిష్కారం చెత్త దృష్టాంతాల కోసం కొత్త విస్తరణలపై MaxSurgeని 100%కి సెట్ చేయడం. పెద్ద విస్తరణల పరంగా ప్రభావం చాలా తక్కువగా మరియు రాజీపడనిదిగా మారింది.
మేము ఉపయోగించిన మరొక పరిష్కారం క్లిష్టమైన సేవల కోసం వనరుల అభ్యర్థనలను కృత్రిమంగా పెంచడం. ఈ సందర్భంలో, ఇతర బరువైన పాడ్‌లతో పోలిస్తే సమీపంలో ఉంచిన పాడ్‌లు యుక్తికి ఎక్కువ స్థలాన్ని కలిగి ఉంటాయి. ఇది దీర్ఘకాలంలో పనిచేయదు ఎందుకంటే ఇది వనరులను వృధా చేస్తుంది. అదనంగా, మా నోడ్ అప్లికేషన్‌లు సింగిల్-థ్రెడ్‌గా ఉంటాయి మరియు తదనుగుణంగా, ఒక కోర్ మాత్రమే ఉపయోగించగలవు. మెరుగైన లోడ్ బ్యాలెన్సింగ్‌ను ఉపయోగించడం మాత్రమే నిజమైన పరిష్కారం.
మేము పూర్తిగా అభినందించాలని చాలా కాలంగా కోరుకుంటున్నాము . ప్రస్తుత పరిస్థితి చాలా పరిమితమైన రీతిలో అమలు చేయడానికి మరియు తక్షణ ఫలితాలను పొందడానికి మాకు అనుమతినిచ్చింది. ఎన్వాయ్ అనేది పెద్ద SOA అప్లికేషన్‌ల కోసం రూపొందించబడిన అధిక-పనితీరు, ఓపెన్ సోర్స్, లేయర్-XNUMX ప్రాక్సీ. ఇది ఆటోమేటిక్ రీట్రీలు, సర్క్యూట్ బ్రేకర్లు మరియు గ్లోబల్ రేట్ లిమిటింగ్‌తో సహా అధునాతన లోడ్ బ్యాలెన్సింగ్ టెక్నిక్‌లను అమలు చేయగలదు. (గమనిక. అనువాదం.: మీరు దీని గురించి మరింత చదవగలరు ఇస్టియో గురించి, ఇది రాయబారిపై ఆధారపడి ఉంటుంది.)
మేము ఈ క్రింది కాన్ఫిగరేషన్‌తో ముందుకు వచ్చాము: ప్రతి పాడ్ మరియు ఒకే రూట్‌కి ఒక ఎన్వాయ్ సైడ్‌కార్‌ని కలిగి ఉండండి మరియు క్లస్టర్‌ను స్థానికంగా పోర్ట్ ద్వారా కంటైనర్‌కు కనెక్ట్ చేయండి. సంభావ్య క్యాస్కేడింగ్‌ను తగ్గించడానికి మరియు ఒక చిన్న హిట్ రేడియస్‌ని నిర్వహించడానికి, మేము ప్రతి సేవ కోసం ఒక అవైలబిలిటీ జోన్‌కు (AZ) ఎన్వోయ్ ఫ్రంట్-ప్రాక్సీ పాడ్‌ల సముదాయాన్ని ఉపయోగించాము. వారు మా ఇంజనీర్‌లలో ఒకరు వ్రాసిన సాధారణ సర్వీస్ డిస్కవరీ ఇంజిన్‌పై ఆధారపడ్డారు, అది ఇచ్చిన సేవ కోసం ప్రతి AZలోని పాడ్‌ల జాబితాను అందించింది.
సర్వీస్ ఫ్రంట్-ఎన్వాయ్‌లు ఈ సర్వీస్ డిస్కవరీ మెకానిజంను ఒక అప్‌స్ట్రీమ్ క్లస్టర్ మరియు రూట్‌తో ఉపయోగించారు. మేము తగిన సమయములను సెట్ చేసాము, అన్ని సర్క్యూట్ బ్రేకర్ సెట్టింగులను పెంచాము మరియు ఒకే వైఫల్యాలతో సహాయం చేయడానికి మరియు సజావుగా అమలు చేయబడేలా చేయడానికి కనీస పునఃప్రయత్న కాన్ఫిగరేషన్‌ను జోడించాము. మేము ఈ సర్వీస్ ఫ్రంట్-ఎన్వోయ్‌ల ప్రతి ముందు TCP ELBని ఉంచాము. మా ప్రధాన ప్రాక్సీ లేయర్‌లోని కీపలైవ్ కొన్ని ఎన్వోయ్ పాడ్‌లపై నిలిచిపోయినప్పటికీ, వారు లోడ్‌ను మరింత మెరుగ్గా నిర్వహించగలుగుతున్నారు మరియు బ్యాకెండ్‌లో కనీసం_రిక్వెస్ట్ ద్వారా బ్యాలెన్స్ చేయడానికి కాన్ఫిగర్ చేయబడ్డాయి.
విస్తరణ కోసం, మేము అప్లికేషన్ పాడ్‌లు మరియు సైడ్‌కార్ పాడ్‌లు రెండింటిలోనూ ప్రీస్టాప్ హుక్‌ని ఉపయోగించాము. సైడ్‌కార్ కంటైనర్‌పై ఉన్న అడ్మిన్ ఎండ్‌పాయింట్ స్థితిని తనిఖీ చేయడంలో హుక్ ఎర్రర్ ఏర్పడింది మరియు యాక్టివ్ కనెక్షన్‌లను ముగించడానికి అనుమతించడానికి కాసేపు నిద్రపోయింది.
మేము ఒక సాధారణ ప్రోమేతియస్ ఇన్‌స్టాలేషన్‌లో సులభంగా ఇంటిగ్రేట్ చేయగలిగే వివరణాత్మక కొలమానాల కారణంగా మేము చాలా త్వరగా తరలించడానికి ఒక కారణం. మేము కాన్ఫిగరేషన్ పారామితులను సర్దుబాటు చేస్తున్నప్పుడు మరియు ట్రాఫిక్‌ని పునఃపంపిణీ చేస్తున్నప్పుడు సరిగ్గా ఏమి జరుగుతుందో చూడటానికి ఇది మమ్మల్ని అనుమతించింది.
ఫలితాలు వెంటనే మరియు స్పష్టంగా ఉన్నాయి. మేము అత్యంత అసమతుల్య సేవలతో ప్రారంభించాము మరియు ప్రస్తుతం ఇది క్లస్టర్‌లోని 12 అత్యంత ముఖ్యమైన సేవల ముందు పనిచేస్తుంది. ఈ సంవత్సరం మేము మరింత అధునాతన సర్వీస్ డిస్కవరీ, సర్క్యూట్ బ్రేకింగ్, అవుట్‌లియర్ డిటెక్షన్, రేట్ లిమిటింగ్ మరియు ట్రేసింగ్‌తో పూర్తి సర్వీస్ మెష్‌కి మారాలని ప్లాన్ చేస్తున్నాము.
మూర్తి 3–1. ఎన్వోయ్‌గా మారే సమయంలో ఒక సేవ యొక్క CPU కన్వర్జెన్స్
తుది ఫలితం
ఈ అనుభవం మరియు అదనపు పరిశోధన ద్వారా, మేము పెద్ద కుబెర్నెట్స్ క్లస్టర్‌లను రూపొందించడం, అమలు చేయడం మరియు నిర్వహించడంలో బలమైన నైపుణ్యాలతో బలమైన మౌలిక సదుపాయాల బృందాన్ని రూపొందించాము. అన్ని టిండెర్ ఇంజనీర్లు ఇప్పుడు కంటైనర్‌లను ప్యాకేజీ చేయడానికి మరియు కుబెర్నెట్‌లకు అప్లికేషన్‌లను అమలు చేయడానికి జ్ఞానం మరియు అనుభవాన్ని కలిగి ఉన్నారు.
పాత ఇన్‌ఫ్రాస్ట్రక్చర్‌పై అదనపు సామర్థ్యం అవసరం ఏర్పడినప్పుడు, కొత్త EC2 ఉదంతాల కోసం మేము చాలా నిమిషాలు వేచి ఉండాల్సి వచ్చింది. ఇప్పుడు కంటైనర్‌లు రన్ చేయడం ప్రారంభించి, నిమిషాల్లో కాకుండా సెకన్లలో ట్రాఫిక్‌ను ప్రాసెస్ చేయడం ప్రారంభిస్తాయి. ఒకే EC2 ఉదాహరణపై బహుళ కంటైనర్‌లను షెడ్యూల్ చేయడం కూడా మెరుగైన క్షితిజ సమాంతర ఏకాగ్రతను అందిస్తుంది. ఫలితంగా, గత సంవత్సరంతో పోలిస్తే 2019లో EC2 ఖర్చులు గణనీయంగా తగ్గుతాయని మేము అంచనా వేస్తున్నాము.
వలస దాదాపు రెండు సంవత్సరాలు పట్టింది, కానీ మేము దానిని మార్చి 2019లో పూర్తి చేసాము. ప్రస్తుతం, టిండర్ ప్లాట్‌ఫారమ్ ప్రత్యేకంగా 200 సేవలు, 1000 నోడ్‌లు, 15 పాడ్‌లు మరియు 000 రన్నింగ్ కంటైనర్‌లతో కూడిన కుబెర్నెటీస్ క్లస్టర్‌పై నడుస్తుంది. ఇన్‌ఫ్రాస్ట్రక్చర్ అనేది ఇకపై ఆపరేషన్స్ టీమ్‌ల ఏకైక డొమైన్ కాదు. మా ఇంజనీర్‌లందరూ ఈ బాధ్యతను పంచుకుంటారు మరియు కోడ్‌ని ఉపయోగించి వారి అప్లికేషన్‌లను రూపొందించే మరియు అమలు చేసే ప్రక్రియను నియంత్రిస్తారు.
అనువాదకుని నుండి PS
మా బ్లాగ్‌లోని కథనాల శ్రేణిని కూడా చదవండి:
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
- «".
మూలం: www.habr.com