కుబేర్‌నెట్స్‌కు టిండెర్ తరలింపు

రచన: క్రిస్ ఓబ్రెయిన్, ఇంజనీరింగ్ మేనేజర్ | క్రిస్ థామస్, ఇంజనీరింగ్ మేనేజర్ | జిన్యాంగ్ లీ, సీనియర్ సాఫ్ట్‌వేర్ ఇంజనీర్ | ఎడిట్ చేసినవారు: కూపర్ జాక్సన్, సాఫ్ట్‌వేర్ ఇంజనీర్

ఎందుకు

దాదాపు రెండేళ్ల క్రితం టిండెర్ తన ప్లాట్‌ఫామ్‌ను కుబెర్నెట్స్‌కు తరలించాలని నిర్ణయించుకుంది. మార్పులేని విస్తరణ ద్వారా టిండెర్ ఇంజనీరింగ్‌ను కంటైనరైజేషన్ మరియు తక్కువ-టచ్ ఆపరేషన్ వైపు నడిపించే అవకాశాన్ని కుబెర్నెటెస్ మాకు కల్పించింది. అప్లికేషన్ నిర్మాణం, విస్తరణ మరియు మౌలిక సదుపాయాలు కోడ్‌గా నిర్వచించబడతాయి.

మేము స్కేల్ మరియు స్థిరత్వం యొక్క సవాళ్లను పరిష్కరించడానికి కూడా చూస్తున్నాము. స్కేలింగ్ క్లిష్టమైనప్పుడు, క్రొత్త EC2 ఉదంతాలు ఆన్‌లైన్‌లోకి రావడానికి చాలా నిమిషాల నిరీక్షణతో మేము తరచుగా బాధపడ్డాము. కంటైనర్ల షెడ్యూల్ మరియు నిమిషాల వ్యవధిలో ట్రాఫిక్‌ను అందించడం అనే ఆలోచన మాకు ఆకర్షణీయంగా ఉంది.

ఇది అంత సులభం కాదు. 2019 ప్రారంభంలో మా వలస సమయంలో, మేము మా కుబెర్నెట్ క్లస్టర్‌లో క్లిష్టమైన ద్రవ్యరాశిని చేరుకున్నాము మరియు ట్రాఫిక్ వాల్యూమ్, క్లస్టర్ పరిమాణం మరియు DNS కారణంగా వివిధ సవాళ్లను ఎదుర్కొన్నాము. మేము 200 సేవలను మార్చడానికి ఆసక్తికరంగా ఉన్న సవాళ్లను పరిష్కరించాము మరియు కుబెర్నెట్స్ క్లస్టర్‌ను మొత్తం 1,000 నోడ్లు, 15,000 పాడ్‌లు మరియు 48,000 రన్నింగ్ కంటైనర్‌లను అమలు చేస్తున్నాము.

ఎలా

జనవరి 2018 నుండి, మేము వలస ప్రయత్నం యొక్క వివిధ దశల ద్వారా పనిచేశాము. మేము మా సేవలను కంటైనరైజ్ చేయడం ద్వారా ప్రారంభించాము మరియు వాటిని కుబెర్నెట్స్ హోస్ట్ చేసిన స్టేజింగ్ ఎన్విరాన్మెంట్ల శ్రేణికి అమర్చడం ద్వారా ప్రారంభించాము. అక్టోబర్ నుండి, మేము మా లెగసీ సేవలను క్రమపద్ధతిలో కుబెర్నెట్స్‌కు తరలించడం ప్రారంభించాము. మరుసటి సంవత్సరం మార్చి నాటికి, మేము మా వలసలను ఖరారు చేసాము మరియు టిండెర్ ప్లాట్‌ఫాం ఇప్పుడు ప్రత్యేకంగా కుబర్‌నెట్స్‌లో నడుస్తుంది.

కుబెర్నెట్స్ కోసం చిత్రాలను నిర్మించడం

కుబెర్నెట్ క్లస్టర్‌లో నడుస్తున్న మైక్రోసర్వీస్‌ల కోసం 30 కి పైగా సోర్స్ కోడ్ రిపోజిటరీలు ఉన్నాయి. ఈ రిపోజిటరీలలోని కోడ్ ఒకే భాష కోసం బహుళ రన్‌టైమ్ పరిసరాలతో వివిధ భాషలలో (ఉదా., నోడ్.జెస్, జావా, స్కాలా, గో) వ్రాయబడింది.

బిల్డ్ సిస్టమ్ ప్రతి మైక్రోసర్వీస్ కోసం పూర్తిగా అనుకూలీకరించదగిన “బిల్డ్ కాంటెక్స్ట్” పై పనిచేసేలా రూపొందించబడింది, ఇది సాధారణంగా డాకర్‌ఫైల్ మరియు షెల్ ఆదేశాల శ్రేణిని కలిగి ఉంటుంది. వాటి విషయాలు పూర్తిగా అనుకూలీకరించదగినవి అయితే, ఈ నిర్మాణ సందర్భాలు అన్నీ ప్రామాణిక ఆకృతిని అనుసరించడం ద్వారా వ్రాయబడతాయి. బిల్డ్ సందర్భాల యొక్క ప్రామాణీకరణ అన్ని మైక్రోసర్వీస్‌లను నిర్వహించడానికి ఒకే బిల్డ్ సిస్టమ్‌ను అనుమతిస్తుంది.

మూర్తి 1–1 బిల్డర్ కంటైనర్ ద్వారా ప్రామాణిక నిర్మాణ ప్రక్రియ

రన్‌టైమ్ పరిసరాల మధ్య గరిష్ట అనుగుణ్యతను సాధించడానికి, అభివృద్ధి మరియు పరీక్ష దశలో ఒకే నిర్మాణ ప్రక్రియ ఉపయోగించబడుతోంది. ప్లాట్‌ఫారమ్‌లో స్థిరమైన నిర్మాణ వాతావరణానికి హామీ ఇవ్వడానికి మేము ఒక మార్గాన్ని రూపొందించాల్సిన అవసరం వచ్చినప్పుడు ఇది ఒక ప్రత్యేకమైన సవాలును విధించింది. ఫలితంగా, అన్ని నిర్మాణ ప్రక్రియలు ప్రత్యేక “బిల్డర్” కంటైనర్‌లో అమలు చేయబడతాయి.

బిల్డర్ కంటైనర్ అమలుకు అనేక అధునాతన డాకర్ పద్ధతులు అవసరం. ఈ బిల్డర్ కంటైనర్ టిండర్ ప్రైవేట్ రిపోజిటరీలను యాక్సెస్ చేయడానికి అవసరమైన స్థానిక వినియోగదారు ID మరియు రహస్యాలను (ఉదా., SSH కీ, AWS ఆధారాలు మొదలైనవి) వారసత్వంగా పొందుతుంది. నిర్మాణ కళాఖండాలను నిల్వ చేయడానికి సహజమైన మార్గాన్ని కలిగి ఉండటానికి ఇది సోర్స్ కోడ్ కలిగి ఉన్న స్థానిక డైరెక్టరీలను మౌంట్ చేస్తుంది. ఈ విధానం పనితీరును మెరుగుపరుస్తుంది, ఎందుకంటే ఇది బిల్డర్ కంటైనర్ మరియు హోస్ట్ మెషీన్ మధ్య నిర్మించిన కళాఖండాలను కాపీ చేయడాన్ని తొలగిస్తుంది. మరింత ఆకృతీకరణ లేకుండా నిల్వ చేసిన నిర్మాణ కళాఖండాలు తదుపరిసారి తిరిగి ఉపయోగించబడతాయి.

కొన్ని సేవల కోసం, రన్-టైమ్ ఎన్విరాన్‌మెంట్‌తో కంపైల్-టైమ్ ఎన్విరాన్‌మెంట్‌తో సరిపోలడానికి మేము బిల్డర్‌లో మరొక కంటైనర్‌ను సృష్టించాల్సిన అవసరం ఉంది (ఉదా., Node.js bcrypt లైబ్రరీని ఇన్‌స్టాల్ చేయడం ప్లాట్‌ఫాం-నిర్దిష్ట బైనరీ కళాకృతులను ఉత్పత్తి చేస్తుంది). కంపైల్-టైమ్ అవసరాలు సేవల్లో విభిన్నంగా ఉండవచ్చు మరియు చివరి డాకర్‌ఫైల్ ఫ్లైలో కూర్చబడుతుంది.

కుబర్నెట్స్ క్లస్టర్ ఆర్కిటెక్చర్ మరియు మైగ్రేషన్

క్లస్టర్ సైజింగ్

అమెజాన్ ఇసి 2 సందర్భాల్లో ఆటోమేటెడ్ క్లస్టర్ ప్రొవిజనింగ్ కోసం కుబ్-ఆవ్స్ ఉపయోగించాలని మేము నిర్ణయించుకున్నాము. ప్రారంభంలో, మేము ఒక సాధారణ నోడ్ పూల్‌లో ప్రతిదీ నడుపుతున్నాము. వనరులను బాగా ఉపయోగించుకోవటానికి, పనిభారాన్ని వేర్వేరు పరిమాణాలు మరియు సందర్భాలలో వేరు చేయవలసిన అవసరాన్ని మేము త్వరగా గుర్తించాము. తార్కికం ఏమిటంటే, భారీగా థ్రెడ్ చేసిన పాడ్‌లను కలిసి నడపడం వల్ల ఎక్కువ సంఖ్యలో ఒకే-థ్రెడ్ పాడ్‌లతో కలిసి జీవించనివ్వడం కంటే ఎక్కువ performance హించదగిన పనితీరు ఫలితాలను ఇచ్చింది.

మేము స్థిరపడ్డాము:

  • పర్యవేక్షణ కోసం m5.4xlarge (ప్రోమేతియస్)
  • Node.js పనిభారం కోసం c5.4xlarge (సింగిల్-థ్రెడ్ పనిభారం)
  • జావా మరియు గో కోసం c5.2xlarge (బహుళ-థ్రెడ్ పనిభారం)
  • నియంత్రణ విమానం కోసం c5.4xlarge (3 నోడ్స్)

వలస

మా లెగసీ మౌలిక సదుపాయాల నుండి కుబెర్నెటీస్‌కు వలస వెళ్ళడానికి సన్నాహక దశలలో ఒకటి, ఒక నిర్దిష్ట వర్చువల్ ప్రైవేట్ క్లౌడ్ (VPC) సబ్‌నెట్‌లో సృష్టించబడిన కొత్త సాగే లోడ్ బ్యాలెన్సర్‌లను (ELB లు) సూచించడానికి ఇప్పటికే ఉన్న సేవ నుండి సేవకు సమాచార మార్పిడిని మార్చడం. ఈ సబ్‌నెట్‌ను కుబెర్నెట్స్ VPC కి పీర్ చేశారు. సేవా డిపెండెన్సీల కోసం నిర్దిష్ట ఆర్డరింగ్‌తో సంబంధం లేకుండా మాడ్యూళ్ళను గ్రాన్యులర్‌గా మార్చడానికి ఇది మాకు అనుమతి ఇచ్చింది.

ఈ ఎండ్ పాయింట్స్ ప్రతి కొత్త ELB కి సూచించే CNAME కలిగి ఉన్న బరువున్న DNS రికార్డ్ సెట్లను ఉపయోగించి సృష్టించబడ్డాయి. కటోవర్ కోసం, మేము కొత్త కుబెర్నెటీస్ సేవ ELB ని 0 బరువుతో చూపిస్తూ ఒక క్రొత్త రికార్డును చేర్చుకున్నాము. అప్పుడు మేము టైమ్ టు లైవ్ (టిటిఎల్) ను రికార్డులో 0 గా సెట్ చేసాము. పాత మరియు కొత్త బరువులు నెమ్మదిగా సర్దుబాటు చేయబడ్డాయి చివరికి క్రొత్త సర్వర్‌లో 100% తో ముగుస్తుంది. కటోవర్ పూర్తయిన తరువాత, టిటిఎల్ మరింత సహేతుకమైనదిగా సెట్ చేయబడింది.

మా జావా మాడ్యూల్స్ తక్కువ DNS TTL ని గౌరవించాయి, కాని మా నోడ్ అనువర్తనాలు చేయలేదు. మా ఇంజనీర్లలో ఒకరు కనెక్షన్ పూల్ కోడ్ యొక్క కొంత భాగాన్ని ప్రతి 60 ఏళ్ళకు కొలనులను రిఫ్రెష్ చేసే మేనేజర్‌లో చుట్టడానికి తిరిగి వ్రాశారు. పెర్ఫార్మెన్స్ హిట్ లేకుండా ఇది మాకు బాగా పనిచేసింది.

అవగాహన

నెట్‌వర్క్ ఫాబ్రిక్ పరిమితులు

జనవరి 8, 2019 తెల్లవారుజామున, టిండెర్ యొక్క ప్లాట్‌ఫాం నిరంతర అంతరాయానికి గురైంది. ఆ రోజు ఉదయాన్నే ప్లాట్‌ఫాం జాప్యం యొక్క సంబంధం లేని పెరుగుదలకు ప్రతిస్పందనగా, పాడ్ మరియు నోడ్ గణనలు క్లస్టర్‌పై స్కేల్ చేయబడ్డాయి. ఇది మా అన్ని నోడ్‌లపై ARP కాష్ అలసటకు దారితీసింది.

ARP కాష్‌కు సంబంధించిన మూడు లైనక్స్ విలువలు ఉన్నాయి:

క్రెడిట్

gc_thresh3 హార్డ్ క్యాప్. మీరు “పొరుగు పట్టిక ఓవర్‌ఫ్లో” లాగ్ ఎంట్రీలను పొందుతుంటే, ARP కాష్ యొక్క సింక్రోనస్ చెత్త సేకరణ (జిసి) తర్వాత కూడా, పొరుగువారి ప్రవేశాన్ని నిల్వ చేయడానికి తగినంత స్థలం లేదని ఇది సూచిస్తుంది. ఈ సందర్భంలో, కెర్నల్ ప్యాకెట్‌ను పూర్తిగా పడిపోతుంది.

మేము కుబెర్నెట్స్‌లో మా నెట్‌వర్క్ ఫాబ్రిక్‌గా ఫ్లాన్నెల్‌ను ఉపయోగిస్తాము. ప్యాకెట్లు VXLAN ద్వారా ఫార్వార్డ్ చేయబడతాయి. VXLAN అనేది లేయర్ 3 నెట్‌వర్క్ ద్వారా లేయర్ 2 ఓవర్లే స్కీమ్. ఇది లేయర్ 2 నెట్‌వర్క్ విభాగాలను విస్తరించడానికి ఒక మార్గాన్ని అందించడానికి MAC అడ్రస్-ఇన్-యూజర్ డేటాగ్రామ్ ప్రోటోకాల్ (MAC-in-UDP) ఎన్‌క్యాప్సులేషన్‌ను ఉపయోగిస్తుంది. భౌతిక డేటా సెంటర్ నెట్‌వర్క్‌లోని రవాణా ప్రోటోకాల్ IP ప్లస్ UDP.

మూర్తి 2–1 ఫ్లాన్నెల్ రేఖాచిత్రం (క్రెడిట్)

మూర్తి 2–2 VXLAN ప్యాకెట్ (క్రెడిట్)

ప్రతి కుబెర్నెట్ వర్కర్ నోడ్ ఒక పెద్ద / 9 బ్లాక్ నుండి దాని స్వంత / 24 వర్చువల్ అడ్రస్ స్థలాన్ని కేటాయిస్తుంది. ప్రతి నోడ్ కోసం, ఇది 1 రూట్ టేబుల్ ఎంట్రీ, 1 ARP టేబుల్ ఎంట్రీ (ఫ్లాన్నెల్ 1 ఇంటర్ఫేస్లో) మరియు 1 ఫార్వార్డింగ్ డేటాబేస్ (FDB) ఎంట్రీకి దారితీస్తుంది. వర్కర్ నోడ్ మొదట ప్రారంభించినప్పుడు లేదా ప్రతి కొత్త నోడ్ కనుగొనబడినప్పుడు ఇవి జోడించబడతాయి.

అదనంగా, నోడ్-టు-పాడ్ (లేదా పాడ్-టు-పాడ్) కమ్యూనికేషన్ చివరికి eth0 ఇంటర్ఫేస్ మీద ప్రవహిస్తుంది (పై ఫ్లాన్నెల్ రేఖాచిత్రంలో చిత్రీకరించబడింది). ఇది ప్రతి సంబంధిత నోడ్ సోర్స్ మరియు నోడ్ గమ్యానికి ARP పట్టికలో అదనపు ఎంట్రీకి దారి తీస్తుంది.

మన వాతావరణంలో, ఈ రకమైన కమ్యూనికేషన్ చాలా సాధారణం. మా కుబెర్నెట్ సేవా వస్తువుల కోసం, ఒక ELB సృష్టించబడుతుంది మరియు కుబెర్నెట్ ప్రతి నోడ్‌ను ELB తో నమోదు చేస్తుంది. ELB పాడ్ అవగాహన లేదు మరియు ఎంచుకున్న నోడ్ ప్యాకెట్ యొక్క చివరి గమ్యం కాకపోవచ్చు. ఎందుకంటే నోడ్ ELB నుండి ప్యాకెట్‌ను స్వీకరించినప్పుడు, ఇది సేవ కోసం దాని ఐప్యాబుల్స్ నియమాలను అంచనా వేస్తుంది మరియు యాదృచ్చికంగా మరొక నోడ్‌లో పాడ్‌ను ఎంచుకుంటుంది.

అంతరాయం సమయంలో, క్లస్టర్‌లో మొత్తం 605 నోడ్‌లు ఉన్నాయి. పైన పేర్కొన్న కారణాల వల్ల, డిఫాల్ట్ gc_thresh3 విలువను గ్రహించటానికి ఇది సరిపోతుంది. ఇది జరిగిన తర్వాత, ప్యాకెట్లను వదిలివేయడమే కాకుండా, మొత్తం ఫ్లాన్నెల్ / 24 లు వర్చువల్ అడ్రస్ స్థలం ARP పట్టిక నుండి లేదు. నోడ్ టు పాడ్ కమ్యూనికేషన్ మరియు DNS శోధనలు విఫలమవుతాయి. (DNS క్లస్టర్‌లో హోస్ట్ చేయబడింది, ఈ కథనంలో తరువాత మరింత వివరంగా వివరించబడుతుంది.)

పరిష్కరించడానికి, gc_thresh1, gc_thresh2 మరియు gc_thresh3 విలువలు పెంచబడ్డాయి మరియు తప్పిపోయిన నెట్‌వర్క్‌లను తిరిగి నమోదు చేయడానికి ఫ్లాన్నెల్ పున ar ప్రారంభించాలి.

స్కేలు వద్ద D హించని విధంగా DNS నడుస్తోంది

మా వలసలకు అనుగుణంగా, మా సేవల కోసం ట్రాఫిక్ ఆకృతిని మరియు లెగసీ నుండి కుబెర్నెటీస్‌కు పెరుగుతున్న కటౌవర్‌ను సులభతరం చేయడానికి మేము DNS ను భారీగా ప్రభావితం చేసాము. మేము అనుబంధిత రూట్ 53 రికార్డ్‌సెట్‌లలో తక్కువ టిటిఎల్ విలువలను సెట్ చేసాము. మేము EC2 సందర్భాల్లో మా లెగసీ మౌలిక సదుపాయాలను అమలు చేసినప్పుడు, మా పరిష్కరిణి కాన్ఫిగరేషన్ అమెజాన్ యొక్క DNS కు సూచించింది. మేము దీనిని స్వల్పంగా తీసుకున్నాము మరియు మా సేవలు మరియు అమెజాన్ సేవలకు (ఉదా. డైనమోడిబి) తక్కువ టిటిఎల్ ఖర్చు ఎక్కువగా గుర్తించబడలేదు.

మేము కుబెర్నెట్స్‌కు మరింత ఎక్కువ సేవలను ఆన్‌బోర్డ్ చేస్తున్నప్పుడు, సెకనుకు 250,000 అభ్యర్ధనలకు సమాధానం ఇచ్చే DNS సేవను మేము నడుపుతున్నాము. మేము మా అనువర్తనాల్లో అడపాదడపా మరియు ప్రభావవంతమైన DNS శోధన సమయం ముగిసింది. సంపూర్ణ ట్యూనింగ్ ప్రయత్నం మరియు DNS ప్రొవైడర్ ఒక కోర్డిఎన్ఎస్ విస్తరణకు మారినప్పటికీ ఇది సంభవించింది, ఒక సమయంలో 120 కోర్లను తినే 1,000 పాడ్ల వద్ద గరిష్ట స్థాయికి చేరుకుంది.

ఇతర కారణాలు మరియు పరిష్కారాలను పరిశోధించేటప్పుడు, లైనక్స్ ప్యాకెట్ ఫిల్టరింగ్ ఫ్రేమ్‌వర్క్ నెట్‌ఫిల్టర్‌ను ప్రభావితం చేసే జాతి పరిస్థితిని వివరించే ఒక కథనాన్ని మేము కనుగొన్నాము. మేము చూస్తున్న DNS సమయం ముగిసింది, ఫ్లాన్నెల్ ఇంటర్‌ఫేస్‌లో పెరుగుతున్న చొప్పించు_ విఫలమైన కౌంటర్‌తో పాటు, వ్యాసం యొక్క ఫలితాలతో సమలేఖనం చేయబడింది.

సోర్స్ అండ్ డెస్టినేషన్ నెట్‌వర్క్ అడ్రస్ ట్రాన్స్‌లేషన్ (SNAT మరియు DNAT) మరియు కాంట్రాక్ ట్రాక్‌లో తదుపరి చొప్పించేటప్పుడు ఈ సమస్య సంభవిస్తుంది. అంతర్గతంగా చర్చించబడిన మరియు సంఘం ప్రతిపాదించిన ఒక ప్రత్యామ్నాయం DNS ను వర్కర్ నోడ్‌లోకి తరలించడం. ఈ విషయంలో:

  • SNAT అవసరం లేదు, ఎందుకంటే ట్రాఫిక్ స్థానికంగా నోడ్‌లో ఉంటుంది. ఇది eth0 ఇంటర్ఫేస్ అంతటా ప్రసారం చేయవలసిన అవసరం లేదు.
  • DNAT అవసరం లేదు ఎందుకంటే గమ్యం IP నోడ్‌కు స్థానికంగా ఉంటుంది మరియు iptables నియమాలకు యాదృచ్ఛికంగా ఎంచుకున్న పాడ్ కాదు.

మేము ఈ విధానంతో ముందుకు సాగాలని నిర్ణయించుకున్నాము. కోబర్‌డిఎన్‌ఎస్‌ను కుబెర్నెట్స్‌లో డెమోన్‌సెట్‌గా నియమించారు మరియు మేము కుబేలెట్ - క్లస్టర్-డిఎన్ఎస్ కమాండ్ ఫ్లాగ్‌ను కాన్ఫిగర్ చేయడం ద్వారా నోడ్ యొక్క స్థానిక డిఎన్ఎస్ సర్వర్‌ను ప్రతి పాడ్ యొక్క రిసల్వ్.కాన్ఫ్‌లోకి ప్రవేశపెట్టాము. DNS సమయం ముగిసే సమయానికి ప్రత్యామ్నాయం ప్రభావవంతంగా ఉంది.

అయినప్పటికీ, పడిపోయిన ప్యాకెట్లు మరియు ఫ్లాన్నెల్ ఇంటర్ఫేస్ యొక్క insert_failed కౌంటర్ ఇంక్రిమెంట్ మేము ఇంకా చూస్తాము. పై ప్రత్యామ్నాయం తర్వాత కూడా ఇది కొనసాగుతుంది ఎందుకంటే మేము DNS ట్రాఫిక్ కోసం SNAT మరియు / లేదా DNAT ను మాత్రమే తప్పించాము. ఇతర రకాల ట్రాఫిక్ కోసం రేసు పరిస్థితి ఇప్పటికీ సంభవిస్తుంది. అదృష్టవశాత్తూ, మా ప్యాకెట్లలో ఎక్కువ భాగం TCP మరియు పరిస్థితి ఏర్పడినప్పుడు, ప్యాకెట్లు విజయవంతంగా తిరిగి ప్రసారం చేయబడతాయి. అన్ని రకాల ట్రాఫిక్‌లకు దీర్ఘకాలిక పరిష్కారం అనేది మనం ఇంకా చర్చిస్తున్న విషయం.

మెరుగైన లోడ్ బ్యాలెన్సింగ్ సాధించడానికి రాయబారిని ఉపయోగించడం

మేము మా బ్యాకెండ్ సేవలను కుబెర్నెటీస్‌కు తరలించినప్పుడు, మేము పాడ్‌లలో అసమతుల్య భారంతో బాధపడటం ప్రారంభించాము. HTTP కీపాలివ్ కారణంగా, ELB కనెక్షన్లు ప్రతి రోలింగ్ విస్తరణ యొక్క మొదటి సిద్ధంగా ఉన్న పాడ్‌లకు అతుక్కుపోయాయని మేము కనుగొన్నాము, కాబట్టి చాలా ట్రాఫిక్ అందుబాటులో ఉన్న పాడ్‌లలో కొద్ది శాతం ద్వారా ప్రవహించింది. చెత్త నేరస్థుల కోసం కొత్త మోహరింపులపై 100% మాక్స్ సర్జ్ ఉపయోగించడం మేము ప్రయత్నించిన మొదటి ఉపశమనాలలో ఒకటి. ఇది స్వల్పంగా ప్రభావవంతంగా ఉంది మరియు కొన్ని పెద్ద విస్తరణలతో దీర్ఘకాలికంగా స్థిరంగా లేదు.

క్లిష్టమైన సేవలపై వనరుల అభ్యర్ధనలను కృత్రిమంగా పెంచడం మేము ఉపయోగించిన మరో ఉపశమనం, తద్వారా కొలొకేటెడ్ పాడ్‌లు ఇతర భారీ పాడ్‌లతో పాటు ఎక్కువ హెడ్‌రూమ్‌ను కలిగి ఉంటాయి. వనరుల వ్యర్థాల కారణంగా ఇది దీర్ఘకాలంలో కూడా సాధ్యం కాదు మరియు మా నోడ్ అనువర్తనాలు సింగిల్ థ్రెడ్ చేయబడ్డాయి మరియు తద్వారా 1 కోర్ వద్ద సమర్థవంతంగా కప్పబడి ఉన్నాయి. మెరుగైన లోడ్ బ్యాలెన్సింగ్‌ను ఉపయోగించడం మాత్రమే స్పష్టమైన పరిష్కారం.

మేము అంతర్గతంగా రాయబారిని అంచనా వేయడానికి చూస్తున్నాము. ఇది చాలా పరిమిత పద్ధతిలో అమలు చేయడానికి మరియు తక్షణ ప్రయోజనాలను పొందటానికి మాకు అవకాశం కల్పించింది. ఎన్వాయ్ అనేది ఓపెన్ సోర్స్, అధిక-పనితీరు లేయర్ 7 ప్రాక్సీ, ఇది పెద్ద సేవా-ఆధారిత నిర్మాణాల కోసం రూపొందించబడింది. ఇది ఆటోమేటిక్ రిట్రీస్, సర్క్యూట్ బ్రేకింగ్ మరియు గ్లోబల్ రేట్ లిమిటింగ్‌తో సహా అధునాతన లోడ్ బ్యాలెన్సింగ్ పద్ధతులను అమలు చేయగలదు.

స్థానిక కంటైనర్ పోర్టును కొట్టడానికి ఒక మార్గం మరియు క్లస్టర్ ఉన్న ప్రతి పాడ్‌తో పాటు ఎన్‌వాయ్ సైడ్‌కార్ కలిగి ఉండటమే మేము ముందుకు వచ్చిన కాన్ఫిగరేషన్. సంభావ్య క్యాస్కేడింగ్‌ను తగ్గించడానికి మరియు ఒక చిన్న పేలుడు వ్యాసార్థాన్ని ఉంచడానికి, మేము ఫ్రంట్-ప్రాక్సీ ఎన్‌వాయ్ పాడ్‌ల సముదాయాన్ని ఉపయోగించాము, ప్రతి సేవకు ప్రతి లభ్యత జోన్ (AZ) లో ఒక విస్తరణ. ఇవి మా ఇంజనీర్లలో ఒకరు కలిసి ఒక చిన్న సేవా ఆవిష్కరణ యంత్రాంగాన్ని కొట్టాయి, అది ఇచ్చిన సేవ కోసం ప్రతి AZ లోని పాడ్ల జాబితాను తిరిగి ఇచ్చింది.

సర్వీస్ ఫ్రంట్-ఎన్వాయ్స్ ఈ సేవా ఆవిష్కరణ విధానాన్ని ఒక అప్‌స్ట్రీమ్ క్లస్టర్ మరియు మార్గంతో ఉపయోగించుకున్నారు. మేము సహేతుకమైన సమయం ముగిసింది, అన్ని సర్క్యూట్ బ్రేకర్ సెట్టింగులను పెంచాము, ఆపై అశాశ్వతమైన వైఫల్యాలు మరియు సున్నితమైన విస్తరణలకు సహాయపడటానికి కనీస పున ry ప్రయత్న కాన్ఫిగరేషన్‌లో ఉంచాము. మేము ఈ ఫ్రంట్ ఎన్వాయ్ సేవలను TCP ELB తో ముందంజలో ఉంచాము. మా ప్రధాన ఫ్రంట్ ప్రాక్సీ లేయర్ నుండి కీపాలివ్ కొన్ని ఎన్వాయ్ పాడ్స్‌పై పిన్ చేయబడినా, అవి లోడ్‌ను బాగా నిర్వహించగలిగాయి మరియు బ్యాకెండ్‌కు కనీసం_అవసరం ద్వారా బ్యాలెన్స్ చేయడానికి కాన్ఫిగర్ చేయబడ్డాయి.

విస్తరణల కోసం, మేము అప్లికేషన్ మరియు సైడ్‌కార్ పాడ్ రెండింటిలో ప్రీస్టాప్ హుక్‌ని ఉపయోగించాము. సైడ్‌కార్ హెల్త్ చెక్ ఫెయిల్ అడ్మిన్ ఎండ్‌పాయింట్ అని పిలువబడే ఈ హుక్, చిన్న నిద్రతో పాటు, ఇన్‌ఫ్లైట్ కనెక్షన్‌లను పూర్తి చేయడానికి మరియు హరించడానికి అనుమతించడానికి కొంత సమయం ఇస్తుంది.

మేము మా సాధారణ ప్రోమేతియస్ సెటప్‌తో సులభంగా ఏకీకృతం చేయగలిగిన గొప్ప కొలమానాల కారణంగా మేము ఇంత త్వరగా తరలించగలిగాము. ఇది కాన్ఫిగరేషన్ సెట్టింగులపై మళ్ళి, ట్రాఫిక్‌ను తగ్గించేటప్పుడు ఏమి జరుగుతుందో చూడటానికి ఇది మాకు వీలు కల్పించింది.

ఫలితాలు వెంటనే మరియు స్పష్టంగా ఉన్నాయి. మేము చాలా అసమతుల్య సేవలతో ప్రారంభించాము మరియు ఈ సమయంలో ఇది మా క్లస్టర్‌లోని పన్నెండు ముఖ్యమైన సేవల ముందు నడుస్తోంది. ఈ సంవత్సరం మేము మరింత అధునాతన సేవా ఆవిష్కరణ, సర్క్యూట్ బ్రేకింగ్, lier ట్‌లియర్ డిటెక్షన్, రేట్ లిమిటింగ్ మరియు ట్రేసింగ్‌తో పూర్తి-సేవ మెష్‌కు వెళ్లాలని ప్లాన్ చేస్తున్నాము.

మూర్తి 3–1 రాయబారానికి కటోవర్ సమయంలో ఒక సేవ యొక్క CPU కన్వర్జెన్స్

ముగింపు ఫలితం

ఈ అభ్యాసాలు మరియు అదనపు పరిశోధనల ద్వారా, పెద్ద కుబెర్నెట్ సమూహాలను ఎలా రూపొందించాలి, అమలు చేయాలి మరియు ఆపరేట్ చేయాలనే దానిపై గొప్ప పరిచయంతో బలమైన అంతర్గత మౌలిక సదుపాయాల బృందాన్ని మేము అభివృద్ధి చేసాము. టిండెర్ యొక్క మొత్తం ఇంజనీరింగ్ సంస్థకు ఇప్పుడు కుబెర్నెట్స్‌లో వారి అనువర్తనాలను ఎలా కంటైనరైజ్ చేయాలి మరియు అమలు చేయాలి అనే దానిపై జ్ఞానం మరియు అనుభవం ఉంది.

మా లెగసీ మౌలిక సదుపాయాలపై, అదనపు స్కేల్ అవసరమైనప్పుడు, కొత్త EC2 ఉదంతాలు ఆన్‌లైన్‌లోకి రావడానికి మేము చాలా నిమిషాలు వేచి ఉన్నాము. కంటైనర్లు ఇప్పుడు నిమిషాలకు విరుద్ధంగా సెకన్లలో ట్రాఫిక్‌ను షెడ్యూల్ చేస్తాయి మరియు అందిస్తాయి. ఒకే EC2 ఉదాహరణలో బహుళ కంటైనర్లను షెడ్యూల్ చేయడం కూడా మెరుగైన క్షితిజ సమాంతర సాంద్రతను అందిస్తుంది. ఫలితంగా, మునుపటి సంవత్సరంతో పోల్చితే 2019 లో EC2 పై గణనీయమైన వ్యయ పొదుపులను మేము అంచనా వేస్తున్నాము.

దీనికి దాదాపు రెండు సంవత్సరాలు పట్టింది, కాని మేము మార్చి 2019 లో మా వలసలను ఖరారు చేసాము. టిండెర్ ప్లాట్‌ఫాం ప్రత్యేకంగా కుబెర్నెట్స్ క్లస్టర్‌లో 200 సేవలు, 1,000 నోడ్‌లు, 15,000 పాడ్‌లు మరియు 48,000 రన్నింగ్ కంటైనర్‌లను కలిగి ఉంది. మౌలిక సదుపాయాలు ఇకపై మా కార్యకలాపాల బృందాలకు కేటాయించబడిన పని కాదు. బదులుగా, సంస్థ అంతటా ఉన్న ఇంజనీర్లు ఈ బాధ్యతను పంచుకుంటారు మరియు వారి అనువర్తనాలు ఎలా నిర్మించబడతాయనే దానిపై నియంత్రణ కలిగి ఉంటారు మరియు ప్రతిదానికీ కోడ్ వలె అమలు చేస్తారు.

ఇది కూడ చూడు

వాట్సాప్ ఎక్కువగా టీనేజ్, లేదా వృద్ధులచే ఉపయోగించబడుతుందా?స్నాప్‌చాట్ పోటీదారులు ఎవరు?టిండర్‌పై ఎవరికైనా మంచి అనుభవం ఉందా, లేదా అది హుక్-అప్‌ల కోసమా?మీ ఫోన్ గ్యాలరీకి వాట్సాప్ మీడియాను సేవ్ చేయడం ఎలా ఆపాలి?నేను ఒక నెల పాత వీడియోను నా ఇన్‌స్టాగ్రామ్ కథగా పోస్ట్ చేయవచ్చా?ఇన్‌స్టాగ్రామ్ విక్రేత మోసాన్ని నేను ఎలా నివేదించగలను? నేను ఇన్‌స్టాగ్రామ్‌లో మొబైల్ అమ్మకందారుని మోసం చేశాను. డబ్బు వచ్చిన తరువాత నన్ను అడ్డుకున్నాడు.నా ఇన్‌స్టాగ్రామ్ ఖాతాలో నా తప్పు ఇమెయిల్ ఉంది మరియు ధృవీకరణ కోడ్‌ను అభ్యర్థిస్తోంది. నేను ఏమి చెయ్యగలను?వాట్సాప్ మరియు అసమ్మతి మధ్య తేడా ఏమిటి? ఏది ఎక్కువ ప్రాచుర్యం పొందింది మరియు ఎక్కడ?