குறிப்பு. மொழிபெயர்: GitLab இல் Kubernetes தத்தெடுப்பு நிறுவனத்தின் வளர்ச்சிக்கு பங்களிக்கும் இரண்டு முக்கிய காரணிகளில் ஒன்றாக கருதப்படுகிறது. இருப்பினும், சமீப காலம் வரை, GitLab.com ஆன்லைன் சேவையின் உள்கட்டமைப்பு மெய்நிகர் கணினிகளில் கட்டமைக்கப்பட்டது, மேலும் ஒரு வருடத்திற்கு முன்புதான் K8 களுக்கு அதன் இடம்பெயர்வு தொடங்கியது, அது இன்னும் முடிக்கப்படவில்லை. இது எவ்வாறு நிகழ்கிறது மற்றும் திட்டத்தில் பங்கேற்கும் பொறியாளர்கள் என்ன முடிவுகளை எடுக்கிறார்கள் என்பது பற்றி GitLab SRE இன்ஜினியரின் சமீபத்திய கட்டுரையின் மொழிபெயர்ப்பை வழங்குவதில் நாங்கள் மகிழ்ச்சியடைகிறோம்.
இப்போது சுமார் ஒரு வருடமாக, எங்கள் உள்கட்டமைப்பு பிரிவு GitLab.com இல் இயங்கும் அனைத்து சேவைகளையும் Kubernetes க்கு மாற்றுகிறது. இந்த நேரத்தில், குபெர்னெட்டஸுக்கு சேவைகளை நகர்த்துவது மட்டுமல்லாமல், மாற்றத்தின் போது கலப்பின வரிசைப்படுத்தலை நிர்வகிப்பது தொடர்பான சவால்களை நாங்கள் எதிர்கொண்டோம். நாம் கற்றுக்கொண்ட மதிப்புமிக்க பாடங்கள் இந்தக் கட்டுரையில் விவாதிக்கப்படும்.
GitLab.com இன் தொடக்கத்திலிருந்தே, அதன் சேவையகங்கள் மெய்நிகர் கணினிகளில் கிளவுட்டில் இயங்கின. இந்த மெய்நிகர் இயந்திரங்கள் செஃப் மூலம் நிர்வகிக்கப்படுகிறது மற்றும் எங்கள் பயன்படுத்தி நிறுவப்பட்டது . அப்ளிகேஷன் புதுப்பிக்கப்பட வேண்டும் என்றால், CI பைப்லைனைப் பயன்படுத்தி ஒருங்கிணைக்கப்பட்ட, வரிசைமுறையான முறையில் சர்வர் ஃப்ளீட்டை எளிமையாகப் புதுப்பிப்பதைக் கொண்டுள்ளது. இந்த முறை - மெதுவாக மற்றும் சிறிது என்றாலும் - GitLab.com ஆஃப்லைன் பயனர்களின் அதே நிறுவல் மற்றும் உள்ளமைவு நடைமுறைகளைப் பயன்படுத்துவதை உறுதி செய்கிறது (சுயமாக நிர்வகிக்கப்படும்) இதற்கு எங்கள் லினக்ஸ் தொகுப்புகளைப் பயன்படுத்தி GitLab நிறுவல்கள்.
GitLab இன் நகல்களை நிறுவி உள்ளமைக்கும்போது சமூகத்தின் சாதாரண உறுப்பினர்கள் அனுபவிக்கும் அனைத்து துக்கங்களையும் மகிழ்ச்சிகளையும் அனுபவிப்பது மிகவும் முக்கியம் என்பதால் நாங்கள் இந்த முறையைப் பயன்படுத்துகிறோம். இந்த அணுகுமுறை சில காலத்திற்கு நன்றாக வேலை செய்தது, ஆனால் GitLab இல் உள்ள திட்டங்களின் எண்ணிக்கை 10 மில்லியனைத் தாண்டியபோது, அது அளவிடுதல் மற்றும் வரிசைப்படுத்துதலுக்கான எங்கள் தேவைகளை இனி பூர்த்தி செய்யாது என்பதை நாங்கள் உணர்ந்தோம்.
Kubernetes மற்றும் கிளவுட்-நேட்டிவ் GitLab க்கான முதல் படிகள்
திட்டம் 2017 இல் உருவாக்கப்பட்டது கிளவுட் வரிசைப்படுத்துதலுக்காக GitLab ஐ தயார்படுத்தவும், பயனர்கள் குபெர்னெட்ஸ் கிளஸ்டர்களில் GitLab ஐ நிறுவவும். GitLab ஐ Kubernetes க்கு நகர்த்துவது SaaS இயங்குதளத்தின் அளவிடுதலை அதிகரிக்கும், வரிசைப்படுத்தல்களை எளிதாக்கும் மற்றும் கணினி வளங்களின் செயல்திறனை மேம்படுத்தும் என்பதை நாங்கள் அறிந்தோம். அதே நேரத்தில், எங்கள் பயன்பாட்டின் பல செயல்பாடுகள் பொருத்தப்பட்ட NFS பகிர்வுகளைச் சார்ந்தது, இது மெய்நிகர் இயந்திரங்களில் இருந்து மாறுவதை மெதுவாக்குகிறது.
கிளவுட் நேட்டிவ் மற்றும் குபெர்னெட்ஸை நோக்கிய உந்துதல், எங்கள் பொறியாளர்களுக்கு ஒரு படிப்படியான மாற்றத்தைத் திட்டமிட அனுமதித்தது, இதன் போது புதிய அம்சங்களைத் தொடர்ந்து உருவாக்கும்போது, நெட்வொர்க் சேமிப்பகத்தில் பயன்பாட்டின் சில சார்புகளை நாங்கள் கைவிட்டோம். 2019 கோடையில் நாங்கள் இடம்பெயர்வு திட்டமிடத் தொடங்கியதில் இருந்து, இந்த வரம்புகள் பல தீர்க்கப்பட்டுள்ளன, மேலும் GitLab.com ஐ Kubernetes க்கு மாற்றுவதற்கான செயல்முறை இப்போது சிறப்பாக நடந்து வருகிறது!
குபெர்னெட்டஸில் உள்ள GitLab.com இன் அம்சங்கள்
GitLab.com க்கு, அனைத்து பயன்பாட்டு போக்குவரத்தையும் கையாளும் ஒரு பிராந்திய GKE கிளஸ்டரைப் பயன்படுத்துகிறோம். (ஏற்கனவே தந்திரமான) இடம்பெயர்வின் சிக்கலைக் குறைக்க, உள்ளூர் சேமிப்பகம் அல்லது NFS ஐ நம்பாத சேவைகளில் கவனம் செலுத்துகிறோம். GitLab.com முக்கியமாக ஒரே மாதிரியான தண்டவாள கோட்பேஸைப் பயன்படுத்துகிறது, மேலும் பணிச்சுமை பண்புகளின் அடிப்படையில் போக்குவரத்தை அவற்றின் சொந்த முனைக் குளங்களில் தனிமைப்படுத்தப்பட்ட வெவ்வேறு முனைப்புள்ளிகளுக்கு நாங்கள் வழிநடத்துகிறோம்.
முன்பகுதியில், இந்த வகைகள் வலை, API, Git SSH/HTTPS மற்றும் ரெஜிஸ்ட்ரிக்கான கோரிக்கைகளாகப் பிரிக்கப்படுகின்றன. பின்தளத்தில், வரிசையில் உள்ள வேலைகளை பல்வேறு குணாதிசயங்களின்படி பிரிக்கிறோம் , இது பல்வேறு பணிச்சுமைகளுக்கு சேவை நிலை நோக்கங்களை (SLOs) அமைக்க அனுமதிக்கிறது.
இந்த GitLab.com சேவைகள் அனைத்தும் மாற்றப்படாத GitLab ஹெல்ம் விளக்கப்படத்தைப் பயன்படுத்தி கட்டமைக்கப்பட்டுள்ளன. உள்ளமைவு துணை விளக்கப்படங்களில் மேற்கொள்ளப்படுகிறது, நாங்கள் படிப்படியாக சேவைகளை கிளஸ்டருக்கு மாற்றும்போது தேர்ந்தெடுக்கப்பட்ட முறையில் செயல்படுத்தப்படும். Redis, Postgres, GitLab Pages மற்றும் Gitaly போன்ற எங்களின் சில நிலையான சேவைகளை இடம்பெயர்தலில் சேர்க்க வேண்டாம் என்று நாங்கள் முடிவு செய்தாலும், Kubernetes ஐப் பயன்படுத்துவது, செஃப் தற்போது நிர்வகிக்கும் VMகளின் எண்ணிக்கையை தீவிரமாகக் குறைக்க அனுமதிக்கிறது.
குபெர்னெட்ஸ் உள்ளமைவு தெரிவுநிலை மற்றும் மேலாண்மை
அனைத்து அமைப்புகளும் GitLab ஆல் நிர்வகிக்கப்படுகிறது. இதற்கு, Terraform மற்றும் Helm அடிப்படையிலான மூன்று கட்டமைப்பு திட்டங்கள் பயன்படுத்தப்படுகின்றன. GitLab ஐ இயக்க முடிந்தவரை GitLab ஐப் பயன்படுத்த முயற்சிப்போம், ஆனால் செயல்பாட்டு பணிகளுக்கு எங்களிடம் தனி GitLab நிறுவல் உள்ளது. GitLab.com வரிசைப்படுத்துதல்கள் மற்றும் புதுப்பிப்புகளைச் செய்யும்போது நீங்கள் GitLab.com இன் கிடைக்கும் தன்மையைச் சார்ந்திருக்கவில்லை என்பதை உறுதிப்படுத்த இது அவசியம்.
Kubernetes கிளஸ்டருக்கான எங்கள் பைப்லைன்கள் ஒரு தனி GitLab நிறுவலில் இயங்கினாலும், பின்வரும் முகவரிகளில் பொதுவில் கிடைக்கும் குறியீடு களஞ்சியங்களின் கண்ணாடிகள் உள்ளன:
- - GitLab ஹெல்ம் விளக்கப்படத்திற்கான GitLab.com உள்ளமைவு கட்டமைப்பு;
- - GitLab பயன்பாட்டுடன் நேரடியாக தொடர்பில்லாத சேவைகளுக்கான உள்ளமைவுகளைக் கொண்டுள்ளது. பதிவு மற்றும் கிளஸ்டர் கண்காணிப்புக்கான உள்ளமைவுகளும், PlantUML போன்ற ஒருங்கிணைந்த கருவிகளும் இதில் அடங்கும்;
- - குபெர்னெட்டஸிற்கான டெர்ராஃபார்ம் உள்ளமைவு மற்றும் மரபு VM உள்கட்டமைப்பு. கிளஸ்டரை இயக்க தேவையான அனைத்து ஆதாரங்களையும் இங்கே உள்ளமைக்கிறீர்கள், இதில் கிளஸ்டர், நோட் பூல்கள், சேவை கணக்குகள் மற்றும் ஐபி முகவரி முன்பதிவுகள் ஆகியவை அடங்கும்.
மாற்றங்கள் செய்யப்படும் போது பொது பார்வை காட்டப்படும். கிளஸ்டரில் மாற்றங்களைச் செய்வதற்கு முன் SRE பகுப்பாய்வு செய்யும் விரிவான வேறுபாட்டிற்கான இணைப்புடன்.
SRE க்கு, இணைப்பு GitLab நிறுவலில் விரிவான வேறுபாட்டிற்கு வழிவகுக்கிறது, இது உற்பத்தி மற்றும் அணுகல் குறைவாக உள்ளது. இது பணியாளர்களையும் சமூகத்தையும், செயல்பாட்டுத் திட்டத்திற்கான அணுகல் இல்லாமல் (இது SRE களுக்கு மட்டுமே திறந்திருக்கும்), முன்மொழியப்பட்ட உள்ளமைவு மாற்றங்களைக் காண அனுமதிக்கிறது. CI பைப்லைன்களுக்கான ஒரு தனிப்பட்ட நிகழ்வுடன் குறியீட்டிற்கான பொது GitLab நிகழ்வை இணைப்பதன் மூலம், உள்ளமைவு புதுப்பிப்புகளுக்கு GitLab.com இலிருந்து சுதந்திரத்தை உறுதிசெய்யும் போது, ஒரே ஒரு பணிப்பாய்வுகளை நாங்கள் பராமரிக்கிறோம்.
குடியேற்றத்தின் போது நாங்கள் கண்டுபிடித்தது
நகர்வின் போது, குபெர்னெட்டஸில் புதிய இடம்பெயர்வுகள் மற்றும் வரிசைப்படுத்தல்களுக்கு நாங்கள் விண்ணப்பிக்கிறோம் என்ற அனுபவம் கிடைத்தது.
1. கிடைக்கும் மண்டலங்களுக்கு இடையே போக்குவரத்து காரணமாக அதிகரித்த செலவுகள்
GitLab.com இல் உள்ள Git களஞ்சியக் கடற்படைக்கான தினசரி வெளியேற்ற புள்ளிவிவரங்கள் (ஒரு நாளைக்கு பைட்டுகள்)
கூகுள் தனது நெட்வொர்க்கைப் பகுதிகளாகப் பிரிக்கிறது. அவை, அணுகல் மண்டலங்களாக (AZ) பிரிக்கப்பட்டுள்ளன. Git ஹோஸ்டிங் பெரிய அளவிலான தரவுகளுடன் தொடர்புடையது, எனவே பிணைய வெளியேற்றத்தைக் கட்டுப்படுத்துவது எங்களுக்கு முக்கியம். உள் போக்குவரத்திற்கு, அதே கிடைக்கும் மண்டலத்திற்குள் இருந்தால் மட்டுமே வெளியேறுதல் இலவசம். இதை எழுதும் வரை, ஒரு வழக்கமான வேலை நாளில் தோராயமாக 100 TB தரவை வழங்குகிறோம் (அதுவும் Git களஞ்சியங்களுக்கு மட்டுமே). எங்கள் பழைய VM-அடிப்படையிலான இடவியலில் உள்ள அதே மெய்நிகர் இயந்திரங்களில் இருக்கும் சேவைகள் இப்போது வெவ்வேறு குபெர்னெட்ஸ் பாட்களில் இயங்குகின்றன. இதன் பொருள் VM க்கு முன்னர் உள்ளூரில் இருந்த சில ட்ராஃபிக் கிடைக்கும் மண்டலங்களுக்கு வெளியே பயணிக்கக்கூடும்.
பிராந்திய GKE க்ளஸ்டர்கள், பணிநீக்கத்திற்காக பல கிடைக்கும் மண்டலங்களை விரிவுபடுத்த உங்களை அனுமதிக்கின்றன. சாத்தியம் குறித்து பரிசீலித்து வருகிறோம் பெரிய அளவிலான போக்குவரத்தை உருவாக்கும் சேவைகளுக்கு. இது கிளஸ்டர்-நிலை பணிநீக்கத்தை பராமரிக்கும் போது வெளியேறும் செலவைக் குறைக்கும்.
2. வரம்புகள், ஆதார கோரிக்கைகள் மற்றும் அளவிடுதல்
registry.gitlab.com இல் உற்பத்திப் போக்குவரத்தைச் செயலாக்கும் பிரதிகளின் எண்ணிக்கை. ~15:00 UTC மணிக்கு போக்குவரத்து உச்சம்.
எங்கள் இடம்பெயர்வு கதை ஆகஸ்ட் 2019 இல் தொடங்கியது, நாங்கள் எங்கள் முதல் சேவையான GitLab கண்டெய்னர் ரெஜிஸ்ட்ரியை Kubernetes க்கு மாற்றினோம். இந்த பணி-முக்கியமான, அதிக போக்குவரத்து சேவையானது முதல் இடம்பெயர்வுக்கு ஒரு நல்ல தேர்வாக இருந்தது, ஏனெனில் இது சில வெளிப்புற சார்புகளுடன் கூடிய நிலையற்ற பயன்பாடாகும். முனைகளில் நினைவாற்றல் இல்லாததால் அதிக எண்ணிக்கையிலான வெளியேற்றப்பட்ட காய்கள் நாங்கள் சந்தித்த முதல் பிரச்சனை. இதன் காரணமாக, கோரிக்கைகளையும் வரம்புகளையும் மாற்ற வேண்டியிருந்தது.
காலப்போக்கில் நினைவக நுகர்வு அதிகரிக்கும் பயன்பாட்டின் விஷயத்தில், கோரிக்கைகளுக்கான குறைந்த மதிப்புகள் (ஒவ்வொரு காய்க்கும் நினைவகத்தை முன்பதிவு செய்தல்) மற்றும் பயன்பாட்டின் "தாராளமான" கடினமான வரம்பு ஆகியவை செறிவூட்டலுக்கு வழிவகுத்தது. (செறிவூட்டல்) முனைகள் மற்றும் அதிக அளவிலான வெளியேற்றங்கள். இந்த சிக்கலைச் சமாளிக்க, அது இருந்தது . இது கணுக்களின் அழுத்தத்தைக் குறைத்து, கணுவின் மீது அதிக அழுத்தம் கொடுக்காத வாழ்க்கைச் சுழற்சியைக் கொண்டிருப்பதை உறுதி செய்தது. இப்போது நாம் தாராளமான (மற்றும் ஏறக்குறைய ஒரே மாதிரியான) கோரிக்கையுடன் இடம்பெயர்வுகளைத் தொடங்குகிறோம் மற்றும் மதிப்புகளை வரம்பிடுகிறோம், அவற்றைத் தேவைக்கேற்ப சரிசெய்கிறோம்.
3. அளவீடுகள் மற்றும் பதிவுகள்
உள்கட்டமைப்பு பிரிவு தாமதம், பிழை விகிதங்கள் மற்றும் நிறுவப்பட்ட செறிவு ஆகியவற்றில் கவனம் செலுத்துகிறது (SLO) இணைக்கப்பட்டுள்ளது .
கடந்த ஆண்டில், உள்கட்டமைப்புப் பிரிவில் முக்கிய நிகழ்வுகளில் ஒன்று, SLO களைக் கண்காணித்து வேலை செய்வதில் முன்னேற்றம் கண்டுள்ளது. இடம்பெயர்வின் போது நாங்கள் உன்னிப்பாகக் கண்காணித்த தனிப்பட்ட சேவைகளுக்கான இலக்குகளை அமைக்க SLOக்கள் எங்களை அனுமதித்தன. ஆனால் இந்த மேம்பட்ட கவனிப்புடன் கூட, அளவீடுகள் மற்றும் விழிப்பூட்டல்களைப் பயன்படுத்தி உடனடியாக சிக்கல்களைக் காண்பது எப்போதும் சாத்தியமில்லை. எடுத்துக்காட்டாக, தாமதம் மற்றும் பிழை விகிதங்களில் கவனம் செலுத்துவதன் மூலம், இடம்பெயர்வுக்கு உட்பட்ட சேவைக்கான அனைத்து பயன்பாட்டு நிகழ்வுகளையும் நாங்கள் முழுமையாகக் காப்பதில்லை.
சில பணிச்சுமைகளை கிளஸ்டருக்கு மாற்றிய உடனேயே இந்தச் சிக்கல் கண்டறியப்பட்டது. கோரிக்கைகளின் எண்ணிக்கை சிறியதாக இருந்தாலும், மிகவும் குறிப்பிட்ட உள்ளமைவு சார்புகளைக் கொண்ட செயல்பாடுகளை நாம் சரிபார்க்க வேண்டிய போது இது மிகவும் தீவிரமானது. இடப்பெயர்வின் முக்கிய பாடங்களில் ஒன்று, கண்காணிக்கும் போது அளவீடுகள் மட்டுமல்ல, பதிவுகள் மற்றும் "நீண்ட வால்" ஆகியவற்றையும் கணக்கில் எடுத்துக்கொள்ள வேண்டும். (இது பற்றி விளக்கப்படத்தில் - தோராயமாக. மொழிபெயர்ப்பு.) பிழைகள். இப்போது ஒவ்வொரு இடம்பெயர்வுக்கும் பதிவு வினவல்களின் விரிவான பட்டியலைச் சேர்க்கிறோம் (வினவல் பதிவு) சிக்கல்கள் ஏற்பட்டால், ஒரு ஷிப்டில் இருந்து அடுத்த ஷிப்டுக்கு மாற்றக்கூடிய தெளிவான ரோல்பேக் நடைமுறைகளைத் திட்டமிடுங்கள்.
பழைய VM உள்கட்டமைப்பு மற்றும் புதிய Kubernetes அடிப்படையிலான உள்கட்டமைப்பு ஆகியவற்றில் இணையாக அதே கோரிக்கைகளை வழங்குவது ஒரு தனித்துவமான சவாலை அளித்தது. லிஃப்ட் மற்றும் ஷிப்ட் இடம்பெயர்வு போலல்லாமல் (ஒரு புதிய உள்கட்டமைப்பிற்கு "உள்ளபடியே" விண்ணப்பங்களை விரைவாக மாற்றவும்; மேலும் விவரங்களைப் படிக்கலாம், எடுத்துக்காட்டாக, - தோராயமாக மொழிபெயர்ப்பு.), "பழைய" VMகள் மற்றும் Kubernetes இல் இணையான பணிக்கு கண்காணிப்பு கருவிகள் இரண்டு சூழல்களுக்கும் இணக்கமாக இருக்க வேண்டும் மற்றும் அளவீடுகளை ஒரு பார்வையில் இணைக்க முடியும். மாறுதல் காலத்தின் போது சீரான கவனிப்பை அடைய, அதே டேஷ்போர்டுகள் மற்றும் பதிவு வினவல்களைப் பயன்படுத்துவது முக்கியம்.
4. போக்குவரத்தை புதிய கிளஸ்டருக்கு மாற்றுதல்
GitLab.com க்கு, சேவையகங்களின் ஒரு பகுதி அர்ப்பணிக்கப்பட்டுள்ளது . கேனரி பார்க் எங்கள் உள் திட்டங்களுக்கும் சேவை செய்கிறது . ஆனால் இது முதன்மையாக உள்கட்டமைப்பு மற்றும் பயன்பாட்டில் செய்யப்பட்ட மாற்றங்களைச் சோதிக்க வடிவமைக்கப்பட்டுள்ளது. முதல் இடம்பெயர்ந்த சேவையானது குறைந்த அளவிலான உள் போக்குவரத்தை ஏற்றுக்கொள்வதன் மூலம் தொடங்கப்பட்டது, மேலும் அனைத்து போக்குவரத்தையும் கிளஸ்டருக்கு அனுப்பும் முன் SLOக்கள் சந்திக்கப்படுவதை உறுதிசெய்ய இந்த முறையை நாங்கள் தொடர்ந்து பயன்படுத்துகிறோம்.
இடம்பெயர்வு விஷயத்தில், உள் திட்டங்களுக்கான கோரிக்கைகள் முதலில் Kubernetes க்கு அனுப்பப்படும், பின்னர் HAProxy மூலம் பின்தளத்திற்கான எடையை மாற்றுவதன் மூலம் மீதமுள்ள போக்குவரத்தை படிப்படியாக கிளஸ்டருக்கு மாற்றுவோம். VM இலிருந்து குபெர்னெட்டஸுக்கு இடம்பெயர்ந்தபோது, பழைய மற்றும் புதிய உள்கட்டமைப்புகளுக்கு இடையே போக்குவரத்தைத் திருப்பிவிட எளிதான வழியைக் கொண்டிருப்பது மிகவும் பயனுள்ளதாக இருந்தது, அதன்படி, இடம்பெயர்வுக்குப் பிறகு முதல் சில நாட்களில் பழைய உள்கட்டமைப்பைத் திரும்பப் பெறத் தயாராக வைத்திருங்கள்.
5. காய்களின் இருப்புத் திறன் மற்றும் அவற்றின் பயன்பாடு
ஏறக்குறைய உடனடியாக பின்வரும் சிக்கல் கண்டறியப்பட்டது: பதிவு சேவைக்கான காய்கள் விரைவாகத் தொடங்கின, ஆனால் Sidekiq க்கான காய்களை அறிமுகப்படுத்துவது . Sidekiq காய்களுக்கான நீண்ட தொடக்க நேரம் ஒரு சிக்கலாக மாறியது, நாங்கள் பணிச்சுமைகளை குபெர்னெட்டஸுக்கு மாற்றத் தொடங்கியபோது, வேலைகளை விரைவாகச் செயல்படுத்தி விரைவாக அளவிட வேண்டும்.
இந்த விஷயத்தில், பாடம் என்னவென்றால், குபெர்னெட்டஸின் கிடைமட்ட பாட் ஆட்டோஸ்கேலர் (ஹெச்பிஏ) போக்குவரத்து வளர்ச்சியை நன்றாகக் கையாளும் போது, பணிச்சுமைகளின் பண்புகளைக் கருத்தில் கொள்வதும், காய்களுக்கு உதிரித் திறனை ஒதுக்குவதும் முக்கியம் (குறிப்பாக தேவை சீரற்ற முறையில் விநியோகிக்கப்படும் போது). எங்கள் விஷயத்தில், வேலைகளில் திடீர் எழுச்சி ஏற்பட்டது, இது விரைவான அளவிடுதலுக்கு வழிவகுத்தது, இது நோட் பூலை அளவிடுவதற்கு நேரம் கிடைக்கும் முன்பே CPU வளங்களை நிறைவு செய்ய வழிவகுத்தது.
ஒரு க்ளஸ்டரில் இருந்து முடிந்தவரை கசக்கும் ஆசை எப்போதும் இருக்கும், இருப்பினும், ஆரம்பத்தில் செயல்திறன் சிக்கல்களை எதிர்கொண்டதால், நாங்கள் இப்போது தாராளமான பாட் பட்ஜெட்டில் தொடங்கி பின்னர் அதைக் குறைக்கிறோம், SLO களை உன்னிப்பாகக் கவனித்து வருகிறோம். Sidekiq சேவைக்கான காய்களை அறிமுகப்படுத்துவது குறிப்பிடத்தக்க அளவில் துரிதப்படுத்தப்பட்டுள்ளது, இப்போது சராசரியாக 40 வினாடிகள் ஆகும். அதிகாரப்பூர்வ GitLab ஹெல்ம் விளக்கப்படத்துடன் பணிபுரியும் GitLab.com மற்றும் சுய-நிர்வகிக்கப்பட்ட நிறுவல்களின் எங்கள் பயனர்கள் இரண்டையும் வென்றது.
முடிவுக்கு
ஒவ்வொரு சேவையையும் நகர்த்திய பிறகு, தயாரிப்பில் குபெர்னெட்ஸைப் பயன்படுத்துவதன் பலன்களில் நாங்கள் மகிழ்ச்சியடைந்தோம்: வேகமான மற்றும் பாதுகாப்பான பயன்பாட்டு வரிசைப்படுத்தல், அளவிடுதல் மற்றும் மிகவும் திறமையான வள ஒதுக்கீடு. மேலும், இடம்பெயர்வின் நன்மைகள் GitLab.com சேவைக்கு அப்பாற்பட்டவை. அதிகாரப்பூர்வ ஹெல்ம் விளக்கப்படத்தின் ஒவ்வொரு முன்னேற்றமும் அதன் பயனர்களுக்கு பயனளிக்கிறது.
எங்கள் குபெர்னெட்ஸ் இடம்பெயர்வு சாகசங்களின் கதையை நீங்கள் ரசித்தீர்கள் என்று நம்புகிறேன். அனைத்து புதிய சேவைகளையும் கிளஸ்டருக்கு நகர்த்துகிறோம். கூடுதல் தகவல்களை பின்வரும் வெளியீடுகளில் காணலாம்:
- «";
- «";
- .
மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்
எங்கள் வலைப்பதிவிலும் படிக்கவும்:
- «";
- «";
- «";
- «".
ஆதாரம்: www.habr.com