గమనిక. అనువాదం.: GitLab వద్ద కుబెర్నెట్స్ స్వీకరించడం కంపెనీ వృద్ధికి దోహదపడే రెండు ప్రధాన కారకాల్లో ఒకటిగా పరిగణించబడుతుంది. అయినప్పటికీ, ఇటీవలి వరకు, GitLab.com ఆన్‌లైన్ సేవ యొక్క అవస్థాపన వర్చువల్ మెషీన్‌లపై నిర్మించబడింది మరియు కేవలం ఒక సంవత్సరం క్రితం K8 లకు దాని వలస ప్రారంభమైంది, ఇది ఇప్పటికీ పూర్తి కాలేదు. ఇది ఎలా జరుగుతుంది మరియు ప్రాజెక్ట్‌లో పాల్గొనే ఇంజనీర్లు ఎలాంటి తీర్మానాలు చేస్తారు అనే దాని గురించి GitLab SRE ఇంజనీర్ ఇటీవలి కథనం యొక్క అనువాదాన్ని అందించడానికి మేము సంతోషిస్తున్నాము.
సుమారు ఒక సంవత్సరం నుండి, మా మౌలిక సదుపాయాల విభాగం GitLab.comలో నడుస్తున్న అన్ని సేవలను Kubernetesకి మారుస్తోంది. ఈ సమయంలో, మేము కుబెర్నెట్‌లకు సేవలను తరలించడమే కాకుండా, పరివర్తన సమయంలో హైబ్రిడ్ విస్తరణను నిర్వహించడానికి కూడా సవాళ్లను ఎదుర్కొన్నాము. మనం నేర్చుకున్న విలువైన పాఠాలు ఈ ఆర్టికల్‌లో చర్చించబడతాయి.
GitLab.com ప్రారంభం నుండి, దాని సర్వర్లు వర్చువల్ మెషీన్‌లలో క్లౌడ్‌లో నడిచాయి. ఈ వర్చువల్ మిషన్లు చెఫ్ ద్వారా నిర్వహించబడతాయి మరియు మా ఉపయోగించి ఇన్‌స్టాల్ చేయబడతాయి . అప్లికేషన్‌ను అప్‌డేట్ చేయాల్సిన అవసరం ఉన్నట్లయితే, CI పైప్‌లైన్‌ని ఉపయోగించి సర్వర్ ఫ్లీట్‌ను సమన్వయంతో, సీక్వెన్షియల్ పద్ధతిలో అప్‌డేట్ చేయడం మాత్రమే ఉంటుంది. ఈ పద్ధతి - నెమ్మదిగా మరియు కొద్దిగా అయినప్పటికీ - GitLab.com ఆఫ్‌లైన్ వినియోగదారుల వలె అదే ఇన్‌స్టాలేషన్ మరియు కాన్ఫిగరేషన్ పద్ధతులను ఉపయోగిస్తుందని నిర్ధారిస్తుంది (స్వీయ నిర్వహణ) దీని కోసం మా Linux ప్యాకేజీలను ఉపయోగించి GitLab ఇన్‌స్టాలేషన్‌లు.
మేము ఈ పద్ధతిని ఉపయోగిస్తాము ఎందుకంటే GitLab యొక్క వారి కాపీలను ఇన్‌స్టాల్ చేసేటప్పుడు మరియు కాన్ఫిగర్ చేసేటప్పుడు సంఘంలోని సాధారణ సభ్యులు అనుభవించే అన్ని బాధలు మరియు ఆనందాలను అనుభవించడం చాలా ముఖ్యం. ఈ విధానం కొంత కాలం పాటు బాగా పనిచేసింది, కానీ GitLabలో ప్రాజెక్ట్‌ల సంఖ్య 10 మిలియన్‌లకు మించి ఉన్నప్పుడు, అది స్కేలింగ్ మరియు విస్తరణ కోసం మా అవసరాలను తీర్చలేదని మేము గ్రహించాము.
కుబెర్నెట్స్ మరియు క్లౌడ్-నేటివ్ GitLabకి మొదటి అడుగులు
ప్రాజెక్ట్ 2017 లో సృష్టించబడింది క్లౌడ్ విస్తరణ కోసం GitLabని సిద్ధం చేయడానికి మరియు Kubernetes క్లస్టర్‌లలో GitLabని ఇన్‌స్టాల్ చేయడానికి వినియోగదారులను ఎనేబుల్ చేయడానికి. GitLabని Kubernetesకి తరలించడం వలన SaaS ప్లాట్‌ఫారమ్ యొక్క స్కేలబిలిటీ పెరుగుతుంది, విస్తరణలను సులభతరం చేస్తుంది మరియు కంప్యూటింగ్ వనరుల సామర్థ్యాన్ని మెరుగుపరుస్తుందని మాకు అప్పుడు తెలుసు. అదే సమయంలో, మా అప్లికేషన్ యొక్క అనేక విధులు మౌంటెడ్ NFS విభజనలపై ఆధారపడి ఉంటాయి, ఇది వర్చువల్ మిషన్ల నుండి పరివర్తనను నెమ్మదిస్తుంది.
క్లౌడ్ నేటివ్ మరియు కుబెర్నెట్‌ల వైపు పుష్ మా ఇంజనీర్‌లను క్రమంగా పరివర్తనను ప్లాన్ చేయడానికి అనుమతించింది, ఈ సమయంలో మేము కొత్త ఫీచర్‌లను అభివృద్ధి చేయడం కొనసాగించేటప్పుడు నెట్‌వర్క్ నిల్వపై అప్లికేషన్ యొక్క కొన్ని డిపెండెన్సీలను వదిలివేసాము. మేము 2019 వేసవిలో వలసలను ప్లాన్ చేయడం ప్రారంభించినప్పటి నుండి, ఈ పరిమితులు చాలా వరకు పరిష్కరించబడ్డాయి మరియు GitLab.comని Kubernetesకి తరలించే ప్రక్రియ ఇప్పుడు బాగా జరుగుతోంది!
Kubernetes లో GitLab.com యొక్క లక్షణాలు
GitLab.com కోసం, మేము అన్ని అప్లికేషన్ ట్రాఫిక్‌ను నిర్వహించే ఒకే ప్రాంతీయ GKE క్లస్టర్‌ని ఉపయోగిస్తాము. (ఇప్పటికే గమ్మత్తైన) మైగ్రేషన్ యొక్క సంక్లిష్టతను తగ్గించడానికి, మేము స్థానిక నిల్వ లేదా NFSపై ఆధారపడని సేవలపై దృష్టి పెడతాము. GitLab.com ప్రధానంగా మోనోలిథిక్ రైల్స్ కోడ్‌బేస్‌ను ఉపయోగిస్తుంది మరియు మేము వర్క్‌లోడ్ లక్షణాల ఆధారంగా ట్రాఫిక్‌ని వారి స్వంత నోడ్ పూల్స్‌లో వేరుచేయబడిన వివిధ ఎండ్ పాయింట్‌లకు దారి తీస్తాము.
ఫ్రంటెండ్ విషయంలో, ఈ రకాలు వెబ్, API, Git SSH/HTTPS మరియు రిజిస్ట్రీకి అభ్యర్థనలుగా విభజించబడ్డాయి. బ్యాకెండ్ విషయంలో, మేము క్యూలో ఉన్న ఉద్యోగాలను బట్టి వివిధ లక్షణాల ప్రకారం విభజించాము , వివిధ వర్క్‌లోడ్‌ల కోసం సేవా-స్థాయి లక్ష్యాలను (SLOలు) సెట్ చేయడానికి ఇది మమ్మల్ని అనుమతిస్తుంది.
ఈ GitLab.com సేవలు అన్నీ సవరించబడని GitLab హెల్మ్ చార్ట్‌ని ఉపయోగించి కాన్ఫిగర్ చేయబడ్డాయి. కాన్ఫిగరేషన్ సబ్‌చార్ట్‌లలో నిర్వహించబడుతుంది, మేము సేవలను క్రమంగా క్లస్టర్‌కి తరలించేటప్పుడు ఎంపిక చేసి ప్రారంభించవచ్చు. మేము Redis, Postgres, GitLab పేజీలు మరియు Gitaly వంటి మా స్టేట్‌ఫుల్ సర్వీస్‌లలో కొన్నింటిని మైగ్రేషన్‌లో చేర్చకూడదని నిర్ణయించుకున్నప్పటికీ, Kubernetesని ఉపయోగించడం ద్వారా Chef ప్రస్తుతం నిర్వహిస్తున్న VMల సంఖ్యను సమూలంగా తగ్గించవచ్చు.
కుబెర్నెట్స్ కాన్ఫిగరేషన్ విజిబిలిటీ మరియు మేనేజ్‌మెంట్
అన్ని సెట్టింగ్‌లు GitLab ద్వారానే నిర్వహించబడతాయి. దీని కోసం, టెర్రాఫార్మ్ మరియు హెల్మ్ ఆధారంగా మూడు కాన్ఫిగరేషన్ ప్రాజెక్ట్‌లు ఉపయోగించబడతాయి. మేము GitLabని అమలు చేయడానికి సాధ్యమైనప్పుడల్లా GitLabని ఉపయోగించేందుకు ప్రయత్నిస్తాము, కానీ కార్యాచరణ పనుల కోసం మాకు ప్రత్యేక GitLab ఇన్‌స్టాలేషన్ ఉంది. GitLab.com విస్తరణలు మరియు అప్‌డేట్‌లను నిర్వహిస్తున్నప్పుడు మీరు GitLab.com లభ్యతపై ఆధారపడలేదని నిర్ధారించుకోవడానికి ఇది అవసరం.
Kubernetes క్లస్టర్ కోసం మా పైప్‌లైన్‌లు ప్రత్యేక GitLab ఇన్‌స్టాలేషన్‌లో నడుస్తున్నప్పటికీ, ఈ క్రింది చిరునామాలలో పబ్లిక్‌గా అందుబాటులో ఉండే కోడ్ రిపోజిటరీల అద్దాలు ఉన్నాయి:
- — GitLab హెల్మ్ చార్ట్ కోసం GitLab.com కాన్ఫిగరేషన్ ఫ్రేమ్‌వర్క్;
- - GitLab అప్లికేషన్‌తో నేరుగా అనుబంధించబడని సేవల కోసం కాన్ఫిగరేషన్‌లను కలిగి ఉంటుంది. వీటిలో లాగింగ్ మరియు క్లస్టర్ మానిటరింగ్ కోసం కాన్ఫిగరేషన్‌లు, అలాగే PlantUML వంటి ఇంటిగ్రేటెడ్ టూల్స్ ఉన్నాయి;
- — కుబెర్నెట్స్ మరియు లెగసీ VM ఇన్‌ఫ్రాస్ట్రక్చర్ కోసం టెర్రాఫార్మ్ కాన్ఫిగరేషన్. క్లస్టర్, నోడ్ పూల్స్, సర్వీస్ ఖాతాలు మరియు IP చిరునామా రిజర్వేషన్‌లతో సహా క్లస్టర్‌ను అమలు చేయడానికి అవసరమైన అన్ని వనరులను ఇక్కడ మీరు కాన్ఫిగర్ చేస్తారు.
మార్పులు చేసినప్పుడు పబ్లిక్ వీక్షణ చూపబడుతుంది. క్లస్టర్‌కు మార్పులు చేసే ముందు SRE విశ్లేషించే వివరణాత్మక తేడాకి లింక్‌తో.
SRE కోసం, లింక్ GitLab ఇన్‌స్టాలేషన్‌లో వివరణాత్మక వ్యత్యాసానికి దారి తీస్తుంది, ఇది ఉత్పత్తి కోసం ఉపయోగించబడుతుంది మరియు యాక్సెస్ పరిమితం. ఇది ప్రతిపాదిత కాన్ఫిగరేషన్ మార్పులను వీక్షించడానికి ఆపరేషనల్ ప్రాజెక్ట్‌కు (ఇది SREలకు మాత్రమే తెరవబడుతుంది) యాక్సెస్ లేకుండా ఉద్యోగులు మరియు కమ్యూనిటీని అనుమతిస్తుంది. CI పైప్‌లైన్‌ల కోసం ప్రైవేట్ ఉదాహరణతో కోడ్ కోసం పబ్లిక్ GitLab ఉదాహరణని కలపడం ద్వారా, కాన్ఫిగరేషన్ అప్‌డేట్‌ల కోసం GitLab.com నుండి స్వతంత్రతను నిర్ధారించేటప్పుడు మేము ఒకే వర్క్‌ఫ్లోను నిర్వహిస్తాము.
వలస సమయంలో మేము కనుగొన్నది
తరలింపు సమయంలో, మేము కుబెర్నెట్స్‌లో కొత్త వలసలు మరియు విస్తరణలకు వర్తింపజేస్తామని అనుభవం పొందింది.
1. లభ్యత జోన్ల మధ్య ట్రాఫిక్ కారణంగా పెరిగిన ఖర్చులు
GitLab.comలో Git రిపోజిటరీ ఫ్లీట్ కోసం రోజువారీ ఎగ్రెస్ గణాంకాలు (రోజుకు బైట్లు)
Google తన నెట్‌వర్క్‌ను ప్రాంతాలుగా విభజిస్తుంది. అవి, యాక్సెసిబిలిటీ జోన్‌లుగా (AZ) విభజించబడ్డాయి. Git హోస్టింగ్ పెద్ద మొత్తంలో డేటాతో అనుబంధించబడింది, కాబట్టి నెట్‌వర్క్ ఎగ్రెస్‌ని నియంత్రించడం మాకు చాలా ముఖ్యం. అంతర్గత ట్రాఫిక్ కోసం, అదే లభ్యత జోన్‌లో ఉంటే మాత్రమే ఎగ్రెస్ ఉచితం. ఈ వ్రాత ప్రకారం, మేము సాధారణ పనిదినంలో (మరియు అది కేవలం Git రిపోజిటరీల కోసం) సుమారు 100 TB డేటాను అందజేస్తున్నాము. మా పాత VM-ఆధారిత టోపోలాజీలో అదే వర్చువల్ మెషీన్‌లలో ఉండే సేవలు ఇప్పుడు వేర్వేరు కుబెర్నెట్స్ పాడ్‌లలో అమలవుతున్నాయి. దీనర్థం VMకి మునుపు స్థానికంగా ఉన్న కొంత ట్రాఫిక్ లభ్యత జోన్ల వెలుపల ప్రయాణించగలదని అర్థం.
ప్రాంతీయ GKE క్లస్టర్‌లు రిడెండెన్సీ కోసం బహుళ లభ్యత జోన్‌లను విస్తరించడానికి మిమ్మల్ని అనుమతిస్తాయి. మేము అవకాశాన్ని పరిశీలిస్తున్నాము పెద్ద మొత్తంలో ట్రాఫిక్‌ను ఉత్పత్తి చేసే సేవల కోసం. ఇది క్లస్టర్-స్థాయి రిడెండెన్సీని కొనసాగిస్తూ ఎగ్రెస్ ఖర్చులను తగ్గిస్తుంది.
2. పరిమితులు, వనరుల అభ్యర్థనలు మరియు స్కేలింగ్
registry.gitlab.comలో ఉత్పత్తి ట్రాఫిక్‌ని ప్రాసెస్ చేసే ప్రతిరూపాల సంఖ్య. ~15:00 UTC వద్ద ట్రాఫిక్ పీక్స్.
మా మైగ్రేషన్ స్టోరీ ఆగస్ట్ 2019లో మొదలైంది, మేము మా మొదటి సర్వీస్ అయిన GitLab కంటైనర్ రిజిస్ట్రీని Kubernetesకి తరలించినప్పుడు. ఈ మిషన్-క్రిటికల్, హై-ట్రాఫిక్ సర్వీస్ మొదటి మైగ్రేషన్‌కు మంచి ఎంపిక ఎందుకంటే ఇది కొన్ని బాహ్య డిపెండెన్సీలతో కూడిన స్థితిలేని అప్లికేషన్. మేము ఎదుర్కొన్న మొదటి సమస్య నోడ్స్‌లో మెమరీ లేకపోవడం వల్ల పెద్ద సంఖ్యలో తొలగించబడిన పాడ్‌లు. దీని కారణంగా, మేము అభ్యర్థనలు మరియు పరిమితులను మార్చవలసి వచ్చింది.
కాలక్రమేణా మెమరీ వినియోగం పెరిగే అప్లికేషన్ విషయంలో, అభ్యర్థనల కోసం తక్కువ విలువలు (ప్రతి పాడ్‌కు మెమరీని రిజర్వ్ చేయడం) వినియోగంపై “ఉదారమైన” కఠినమైన పరిమితితో కలిపి సంతృప్తతకు దారితీస్తుందని కనుగొనబడింది. (సంతృప్తత) నోడ్స్ మరియు అధిక స్థాయి తొలగింపులు. ఈ సమస్యను పరిష్కరించడానికి, ఇది జరిగింది . ఇది నోడ్‌ల నుండి ఒత్తిడిని తీసివేసి, నోడ్‌పై ఎక్కువ ఒత్తిడిని కలిగించని జీవితచక్రాన్ని పాడ్స్ కలిగి ఉండేలా చూసింది. ఇప్పుడు మేము ఉదారమైన (మరియు దాదాపు ఒకేలాంటి) అభ్యర్థనతో వలసలను ప్రారంభిస్తాము మరియు విలువలను పరిమితం చేస్తాము, వాటిని అవసరమైన విధంగా సర్దుబాటు చేస్తాము.
3. కొలమానాలు మరియు లాగ్‌లు
ఇన్‌ఫ్రాస్ట్రక్చర్ విభాగం ఇన్‌స్టాల్ చేయబడిన జాప్యం, ఎర్రర్ రేట్లు మరియు సంతృప్తతపై దృష్టి పెడుతుంది (SLO)కి లింక్ చేయబడింది .
గత సంవత్సరంలో, మౌలిక సదుపాయాల విభాగంలో కీలకమైన సంఘటనలలో ఒకటి SLOల పర్యవేక్షణ మరియు పనిలో మెరుగుదలలు. వలసల సమయంలో మేము నిశితంగా పర్యవేక్షించే వ్యక్తిగత సేవల కోసం లక్ష్యాలను నిర్దేశించడానికి SLOలు మమ్మల్ని అనుమతించాయి. కానీ ఈ మెరుగైన పరిశీలనతో కూడా, కొలమానాలు మరియు హెచ్చరికలను ఉపయోగించి సమస్యలను వెంటనే చూడటం ఎల్లప్పుడూ సాధ్యం కాదు. ఉదాహరణకు, జాప్యం మరియు ఎర్రర్ రేట్లపై దృష్టి సారించడం ద్వారా, మేము మైగ్రేషన్‌లో ఉన్న సేవ కోసం అన్ని వినియోగ కేసులను పూర్తిగా కవర్ చేయము.
క్లస్టర్‌కి కొంత పనిభారాన్ని తరలించిన వెంటనే ఈ సమస్య కనుగొనబడింది. అభ్యర్థనల సంఖ్య తక్కువగా ఉన్న, కానీ చాలా నిర్దిష్ట కాన్ఫిగరేషన్ డిపెండెన్సీలను కలిగి ఉన్న ఫంక్షన్‌లను మేము తనిఖీ చేయవలసి వచ్చినప్పుడు ఇది చాలా తీవ్రంగా మారింది. పర్యవేక్షిస్తున్నప్పుడు కొలమానాలను మాత్రమే కాకుండా లాగ్‌లు మరియు “పొడవైన తోక”ను కూడా పరిగణనలోకి తీసుకోవడం వలసల నుండి కీలకమైన పాఠాలలో ఒకటి. (ఇది గురించి చార్టులో - సుమారు. అనువాదం.) లోపాలు. ఇప్పుడు ప్రతి మైగ్రేషన్ కోసం మేము లాగ్ ప్రశ్నల యొక్క వివరణాత్మక జాబితాను చేర్చుతాము (లాగ్ ప్రశ్నలు) మరియు సమస్యలు తలెత్తితే ఒక షిఫ్ట్ నుండి మరొక షిఫ్ట్‌కి బదిలీ చేయగల స్పష్టమైన రోల్‌బ్యాక్ విధానాలను ప్లాన్ చేయండి.
పాత VM ఇన్‌ఫ్రాస్ట్రక్చర్ మరియు కొత్త కుబెర్నెట్స్ ఆధారిత ఇన్‌ఫ్రాస్ట్రక్చర్‌పై సమాంతరంగా అదే అభ్యర్థనలను అందించడం ఒక ప్రత్యేకమైన సవాలును అందించింది. లిఫ్ట్ అండ్ షిఫ్ట్ మైగ్రేషన్ కాకుండా (కొత్త ఇన్‌ఫ్రాస్ట్రక్చర్‌కి అప్లికేషన్‌లను “ఉన్నట్లే” త్వరగా బదిలీ చేయడం; మరిన్ని వివరాలను చదవవచ్చు, ఉదాహరణకు, - సుమారు అనువాదం.), "పాత" VMలు మరియు కుబెర్నెట్‌లపై సమాంతర పని చేయడానికి పర్యవేక్షణ సాధనాలు రెండు వాతావరణాలకు అనుకూలంగా ఉండాలి మరియు కొలమానాలను ఒకే వీక్షణలో కలపగలగాలి. పరివర్తన వ్యవధిలో స్థిరమైన పరిశీలనను సాధించడానికి మేము అదే డాష్‌బోర్డ్‌లు మరియు లాగ్ ప్రశ్నలను ఉపయోగించడం ముఖ్యం.
4. ట్రాఫిక్‌ని కొత్త క్లస్టర్‌కి మార్చడం
GitLab.com కోసం, సర్వర్‌లలో కొంత భాగం అంకితం చేయబడింది . కానరీ పార్క్ మా అంతర్గత ప్రాజెక్ట్‌లకు కూడా సేవలు అందిస్తుంది . కానీ ఇది ప్రాథమికంగా మౌలిక సదుపాయాలు మరియు అప్లికేషన్‌లో చేసిన మార్పులను పరీక్షించడానికి రూపొందించబడింది. పరిమిత మొత్తంలో అంతర్గత ట్రాఫిక్‌ని అంగీకరించడం ద్వారా మొదటి మైగ్రేట్ సేవ ప్రారంభించబడింది మరియు క్లస్టర్‌కి మొత్తం ట్రాఫిక్‌ను పంపే ముందు SLOలు కలుసుకున్నాయని నిర్ధారించుకోవడానికి మేము ఈ పద్ధతిని ఉపయోగిస్తూనే ఉన్నాము.
మైగ్రేషన్ విషయంలో, అంతర్గత ప్రాజెక్ట్‌లకు అభ్యర్థనలు ముందుగా కుబెర్నెట్‌లకు పంపబడతాయని దీని అర్థం, ఆపై మేము HAProxy ద్వారా బ్యాకెండ్ బరువును మార్చడం ద్వారా క్రమంగా మిగిలిన ట్రాఫిక్‌ను క్లస్టర్‌కి మారుస్తాము. VM నుండి కుబెర్నెటెస్‌కు వలస వచ్చినప్పుడు, పాత మరియు కొత్త మౌలిక సదుపాయాల మధ్య ట్రాఫిక్‌ను దారి మళ్లించడానికి సులభమైన మార్గాన్ని కలిగి ఉండటం చాలా ప్రయోజనకరంగా ఉందని మరియు తదనుగుణంగా, వలస తర్వాత మొదటి కొన్ని రోజుల్లో పాత మౌలిక సదుపాయాలను వెనక్కి తీసుకోవడానికి సిద్ధంగా ఉంచుకోవడం చాలా ప్రయోజనకరమని స్పష్టమైంది.
5. పాడ్‌ల రిజర్వ్ సామర్థ్యాలు మరియు వాటి ఉపయోగం
దాదాపు వెంటనే కింది సమస్య గుర్తించబడింది: రిజిస్ట్రీ సేవ కోసం పాడ్‌లు త్వరగా ప్రారంభమయ్యాయి, అయితే సైడ్‌కిక్ కోసం పాడ్‌లను ప్రారంభించడం చాలా వరకు పట్టింది . ఉద్యోగాలను త్వరగా ప్రాసెస్ చేయడానికి మరియు త్వరగా స్కేల్ చేయడానికి అవసరమైన కార్మికుల కోసం మేము పనిభారాన్ని కుబెర్నెట్‌లకు తరలించడం ప్రారంభించినప్పుడు Sidekiq పాడ్‌ల కోసం సుదీర్ఘ ప్రారంభ సమయం సమస్యగా మారింది.
ఈ సందర్భంలో, పాఠం ఏమిటంటే, కుబెర్నెటెస్ యొక్క క్షితిజసమాంతర పాడ్ ఆటోస్కేలర్ (HPA) ట్రాఫిక్ పెరుగుదలను బాగా నిర్వహిస్తుంది, పనిభారం యొక్క లక్షణాలను పరిగణనలోకి తీసుకోవడం మరియు పాడ్‌లకు విడి సామర్థ్యాన్ని కేటాయించడం చాలా ముఖ్యం (ముఖ్యంగా డిమాండ్ అసమానంగా పంపిణీ చేయబడినప్పుడు). మా విషయంలో, ఉద్యోగాలలో అకస్మాత్తుగా పెరుగుదల ఉంది, ఇది వేగవంతమైన స్కేలింగ్‌కు దారితీసింది, ఇది మేము నోడ్ పూల్‌ను స్కేల్ చేయడానికి సమయానికి ముందే CPU వనరులను సంతృప్తపరచడానికి దారితీసింది.
క్లస్టర్ నుండి వీలైనంత వరకు దూరిపోవాలనే టెంప్టేషన్ ఎల్లప్పుడూ ఉంటుంది, అయితే, మొదట్లో పనితీరు సమస్యలను ఎదుర్కొన్నందున, మేము ఇప్పుడు ఉదారమైన పాడ్ బడ్జెట్‌తో ప్రారంభించి, SLOలను నిశితంగా గమనిస్తూ తర్వాత తగ్గిస్తున్నాము. Sidekiq సేవ కోసం పాడ్‌లను ప్రారంభించడం గణనీయంగా వేగవంతం చేయబడింది మరియు ఇప్పుడు సగటున 40 సెకన్లు పడుతుంది. GitLab.com మరియు అధికారిక GitLab హెల్మ్ చార్ట్‌తో పనిచేసే స్వీయ-నిర్వహించబడిన ఇన్‌స్టాలేషన్‌ల యొక్క మా వినియోగదారులు రెండింటినీ గెలుచుకున్నారు.
తీర్మానం
ప్రతి సేవను తరలించిన తర్వాత, ఉత్పత్తిలో కుబెర్నెట్‌లను ఉపయోగించడం వల్ల కలిగే ప్రయోజనాలను చూసి మేము సంతోషించాము: వేగవంతమైన మరియు సురక్షితమైన అప్లికేషన్ విస్తరణ, స్కేలింగ్ మరియు మరింత సమర్థవంతమైన వనరుల కేటాయింపు. అంతేకాకుండా, మైగ్రేషన్ యొక్క ప్రయోజనాలు GitLab.com సేవకు మించినవి. అధికారిక హెల్మ్ చార్ట్‌లోని ప్రతి మెరుగుదల దాని వినియోగదారులకు ప్రయోజనం చేకూరుస్తుంది.
మీరు మా కుబెర్నెట్స్ వలస సాహసాల కథనాన్ని ఆస్వాదించారని నేను ఆశిస్తున్నాను. మేము అన్ని కొత్త సేవలను క్లస్టర్‌కు తరలించడం కొనసాగిస్తున్నాము. అదనపు సమాచారం క్రింది ప్రచురణలలో చూడవచ్చు:
- «";
- «";
- .
అనువాదకుని నుండి PS
మా బ్లాగులో కూడా చదవండి:
- «";
- «";
- «";
- «".
మూలం: www.habr.com