ஹே ஹப்ர்!
நாங்கள் Exness இயங்குதளக் குழுவைப் பிரதிநிதித்துவப்படுத்துகிறோம். முன்னதாக, எங்கள் சகாக்கள் ஏற்கனவே ஒரு கட்டுரையை எழுதியுள்ளனர் . இன்று நாங்கள் குபெர்னெட்டஸுக்கு சேவைகளை மாற்றிய அனுபவத்தைப் பகிர்ந்து கொள்ள விரும்புகிறோம்.
தொடங்குவதற்கு, என்ன விவாதிக்கப்படும் என்பதை நன்கு புரிந்துகொள்ள சில எண்களை நாங்கள் உங்களுக்கு வழங்குகிறோம்:
- எங்கள் மேம்பாட்டுத் துறையானது 100க்கும் மேற்பட்ட நபர்களைக் கொண்டுள்ளது, இதில் 10க்கும் மேற்பட்ட வெவ்வேறு குழுக்கள் தன்னிறைவான QA, DevOps மற்றும் Scrum செயல்முறைகளைக் கொண்டுள்ளன. டெவலப்மெண்ட் ஸ்டேக் - பைதான், PHP, C++, Java மற்றும் Golang.
- சோதனை மற்றும் உற்பத்தி சூழல்களின் அளவு ஒவ்வொன்றும் சுமார் 2000 கொள்கலன்கள் ஆகும். அவர்கள் தங்கள் சொந்த மெய்நிகராக்கத்தில் மற்றும் VMware இன் கீழ் Rancher v1.6 ஐ இயக்குகிறார்கள்.
உள்நோக்கம்
அவர்கள் சொல்வது போல், எதுவும் நிரந்தரமாக நீடிக்காது, மேலும் ராஞ்சர் பதிப்பு 1.6 க்கான ஆதரவின் முடிவை நீண்ட காலத்திற்கு முன்பே அறிவித்தார். ஆம், மூன்று ஆண்டுகளுக்கும் மேலாக, அதை எவ்வாறு தயாரிப்பது மற்றும் எழும் சிக்கல்களைத் தீர்ப்பது என்பதை நாங்கள் கற்றுக்கொண்டோம், ஆனால் அடிக்கடி சரிசெய்ய முடியாத சிக்கல்களை நாங்கள் எதிர்கொள்கிறோம். Rancher 1.6 ஆனது உரிமைகளை வழங்குவதற்கான ஒரு ossified அமைப்பையும் கொண்டுள்ளது, அங்கு நீங்கள் கிட்டத்தட்ட அனைத்தையும் செய்யலாம் அல்லது எதுவும் செய்ய முடியாது.
தனியுரிம மெய்நிகராக்கம் தரவு சேமிப்பகம் மற்றும் அதன் பாதுகாப்பின் மீது அதிக கட்டுப்பாட்டை வழங்கியது என்றாலும், நிறுவனத்தின் நிலையான வளர்ச்சி, திட்டங்களின் எண்ணிக்கை மற்றும் அவற்றுக்கான தேவைகள் ஆகியவற்றின் அடிப்படையில் ஏற்றுக்கொள்ள கடினமாக இருந்த இயக்கச் செலவுகளை அது விதித்தது.
IaC தரநிலைகளைப் பின்பற்றவும், தேவைப்பட்டால், எந்தப் புவியியல் இடத்திலும் விற்பனையாளர் பூட்டு இல்லாமல் திறனை விரைவாகப் பெறவும், மேலும் அதை விரைவாகக் கைவிடவும் விரும்புகிறோம்.
முதல் படிகள்
முதலாவதாக, நவீன தொழில்நுட்பங்கள் மற்றும் தீர்வுகளை நம்பியிருக்க விரும்புகிறோம், இது அணிகள் வேகமான வளர்ச்சி சுழற்சியைக் கொண்டிருக்கவும், ஆற்றலை வழங்கும் தளத்துடன் தொடர்புகொள்வதற்கான செயல்பாட்டுச் செலவுகளைக் குறைக்கவும் அனுமதிக்கும்.
நிச்சயமாக, எங்கள் நினைவுக்கு வந்த முதல் விஷயம் குபெர்னெட்டஸ், ஆனால் நாங்கள் உற்சாகமடையவில்லை, அது சரியான தேர்வா என்பதைப் பார்க்க ஒரு சிறிய ஆராய்ச்சி செய்தோம். நாங்கள் ஓப்பன்சோர்ஸ் தீர்வுகளை மட்டுமே மதிப்பீடு செய்தோம், நியாயமற்ற போரில், குபெர்னெட்ஸ் நிபந்தனையின்றி வெற்றி பெற்றார்.
அடுத்து கிளஸ்டர்களை உருவாக்குவதற்கான கருவியைத் தேர்ந்தெடுக்கும் கேள்வி வந்தது. நாங்கள் மிகவும் பிரபலமான தீர்வுகளை ஒப்பிட்டுப் பார்த்தோம்: kops, kubespray, kubeadm.
தொடங்குவதற்கு, kubeadm மிகவும் சிக்கலான பாதையாக எங்களுக்குத் தோன்றியது, மாறாக ஒரு வகையான "சைக்கிள்" கண்டுபிடிப்பாளர் போன்றது மற்றும் கோப்ஸுக்கு போதுமான நெகிழ்வுத்தன்மை இல்லை.
மற்றும் வெற்றியாளர்:
எங்களுடைய சொந்த மெய்நிகராக்கம் மற்றும் AWS ஆகியவற்றைப் பரிசோதிக்கத் தொடங்கினோம், எங்கள் முந்தைய வள மேலாண்மை முறையைப் போன்ற ஒன்றை மீண்டும் உருவாக்க முயற்சிக்கிறோம், அங்கு அனைவரும் ஒரே "கிளஸ்டர்" பகிர்ந்துள்ளோம். இப்போது எங்களிடம் 10 சிறிய மெய்நிகர் இயந்திரங்களின் முதல் கிளஸ்டர் உள்ளது, அவற்றில் இரண்டு AWS இல் அமைந்துள்ளன. நாங்கள் அங்கு அணிகளை நகர்த்த முயற்சிக்க ஆரம்பித்தோம், எல்லாம் "நல்லது" என்று தோன்றியது, மேலும் கதையை முடிக்க முடியும், ஆனால்...
முதல் சிக்கல்கள்
Ansible என்பது குபேஸ்ப்ரேயில் கட்டமைக்கப்பட்டுள்ளது, இது IaC ஐப் பின்தொடர அனுமதிக்கும் ஒரு கருவி அல்ல: முனைகளை ஆணையிடும்போது/நீக்கம் செய்யும்போது, தொடர்ந்து ஏதோ தவறு ஏற்பட்டது மற்றும் சில வகையான தலையீடுகள் தேவைப்பட்டன, மேலும் வெவ்வேறு OSகளைப் பயன்படுத்தும் போது, பிளேபுக் வித்தியாசமாக நடந்துகொண்டது. . கிளஸ்டரில் உள்ள அணிகள் மற்றும் முனைகளின் எண்ணிக்கை அதிகரித்ததால், பிளேபுக் முடிக்க அதிக நேரம் எடுத்துக்கொள்வதை நாங்கள் கவனிக்க ஆரம்பித்தோம், இதன் விளைவாக, எங்கள் பதிவு 3,5 மணிநேரம் ஆனது, உங்களுடையது என்ன? 🙂
குபேஸ்ப்ரே வெறும் அன்சிபிள் போல் தெரிகிறது, முதல் பார்வையில் எல்லாம் தெளிவாக உள்ளது, ஆனால்:
பயணத்தின் தொடக்கத்தில், AWS மற்றும் மெய்நிகராக்கத்தில் மட்டுமே திறன்களைத் தொடங்குவதே பணியாக இருந்தது, ஆனால் பின்னர், அடிக்கடி நடப்பது போல, தேவைகள் மாறின.
இதன் வெளிச்சத்தில், வளங்களை ஒரு ஆர்கெஸ்ட்ரேஷன் அமைப்பில் இணைக்கும் எங்கள் பழைய முறை பொருத்தமானது அல்ல என்பது தெளிவாகியது - கொத்துகள் மிகவும் தொலைவில் இருக்கும் மற்றும் வெவ்வேறு வழங்குநர்களால் நிர்வகிக்கப்படும் சந்தர்ப்பங்களில்.
மேலும் மேலும். எல்லா அணிகளும் ஒரே கிளஸ்டரில் வேலை செய்யும் போது, தவறாக நிறுவப்பட்ட NodeSelectors கொண்ட பல்வேறு சேவைகள் மற்றொரு குழுவின் "வெளிநாட்டு" ஹோஸ்டுக்கு பறந்து அங்குள்ள வளங்களைப் பயன்படுத்த முடியும், மேலும் கறைபடிந்திருந்தால், ஒன்று அல்லது மற்றொரு சேவை வேலை செய்யவில்லை என்று தொடர்ந்து கோரிக்கைகள் வந்தன. மனித காரணி காரணமாக சரியாக விநியோகிக்கப்படவில்லை. மற்றுமொரு பிரச்சனை, செலவைக் கணக்கிடுவது, குறிப்பாக முனைகளில் சேவைகளை விநியோகிப்பதில் உள்ள சிக்கல்களைக் கருத்தில் கொண்டு.
ஊழியர்களுக்கான உரிமைகளை வழங்குவது ஒரு தனி கதை: ஒவ்வொரு அணியும் கிளஸ்டரின் "தலைமையில்" இருக்க விரும்புகிறது மற்றும் அதை முழுமையாக நிர்வகிக்க விரும்புகிறது, இது ஒரு முழுமையான சரிவை ஏற்படுத்தக்கூடும், ஏனெனில் அணிகள் அடிப்படையில் ஒருவருக்கொருவர் சுயாதீனமாக உள்ளன.
எப்படி இருக்க வேண்டும்?
மேற்கூறியவற்றையும், மேலும் சுதந்திரமாக இருக்க வேண்டும் என்ற அணிகளின் விருப்பங்களையும் கணக்கில் எடுத்துக்கொண்டு, நாங்கள் ஒரு எளிய முடிவை எடுத்தோம்: ஒரு அணி - ஒரு கிளஸ்டர்.
எனவே எங்களுக்கு இரண்டாவது கிடைத்தது:
பின்னர் மூன்றாவது கிளஸ்டர்:
பின்னர் நாங்கள் சிந்திக்க ஆரம்பித்தோம்: ஒரு வருடத்தில் எங்கள் அணிகள் ஒன்றுக்கு மேற்பட்ட கிளஸ்டர்களைக் கொண்டிருக்கும் என்று சொல்லலாமா? வெவ்வேறு புவியியல் பகுதிகளில், எடுத்துக்காட்டாக, அல்லது வெவ்வேறு வழங்குநர்களின் கட்டுப்பாட்டின் கீழ்? அவர்களில் சிலர் சில சோதனைகளுக்கு ஒரு தற்காலிக கிளஸ்டரை விரைவாக வரிசைப்படுத்த விரும்புவார்கள்.
முழு குபர்னெட்ஸ் வருவார்! இது ஒருவித MultiKubernetes, அது மாறிவிடும்.
அதே நேரத்தில், நாம் அனைவரும் எப்படியாவது இந்த கிளஸ்டர்கள் அனைத்தையும் பராமரிக்க வேண்டும், அவற்றுக்கான அணுகலை எளிதாக நிர்வகிக்க முடியும், அத்துடன் புதியவற்றை உருவாக்கவும், கைமுறையான தலையீடு இல்லாமல் பழையவற்றை நீக்கவும் வேண்டும்.
குபெர்னெட்ஸ் உலகில் எங்கள் பயணத்தின் தொடக்கத்திலிருந்து சிறிது நேரம் கடந்துவிட்டது, மேலும் கிடைக்கக்கூடிய தீர்வுகளை மறுபரிசீலனை செய்ய முடிவு செய்தோம். இது ஏற்கனவே சந்தையில் உள்ளது என்று மாறியது - Rancher 2.2.
எங்கள் ஆராய்ச்சியின் முதல் கட்டத்தில், Rancher Labs ஏற்கனவே பதிப்பு 2 இன் முதல் வெளியீட்டை உருவாக்கியது, ஆனால் இரண்டு அளவுருக்கள் அல்லது அதிகாரப்பூர்வ HELM விளக்கப்படத்தைப் பயன்படுத்தி வெளிப்புற சார்புகள் இல்லாமல் ஒரு கொள்கலனைத் தொடங்குவதன் மூலம் மிக விரைவாக உயர்த்த முடியும் என்றாலும், அது கசப்பானதாகத் தோன்றியது. எங்களுக்கு, மேலும் இந்த முடிவை நாங்கள் நம்ப முடியுமா, அது உருவாக்கப்படுமா அல்லது விரைவில் கைவிடப்படுமா என்பது எங்களுக்குத் தெரியாது. UI இல் உள்ள கிளஸ்டர் = கிளிக்குகள் முன்னுதாரணமும் எங்களுக்குப் பொருந்தவில்லை, மேலும் RKE உடன் இணைக்க விரும்பவில்லை, ஏனெனில் இது ஒரு குறுகிய கவனம் செலுத்தும் கருவியாகும்.
பதிப்பு Rancher 2.2 ஏற்கனவே மிகவும் வேலை செய்யக்கூடிய தோற்றத்தைக் கொண்டிருந்தது மற்றும் முந்தையவற்றுடன், பல வெளிப்புற வழங்குநர்களுடன் ஒருங்கிணைப்பு, உரிமைகள் மற்றும் kubeconfig கோப்புகளை விநியோகிக்கும் ஒரு புள்ளி, ஒரு kubectl ஐ அறிமுகப்படுத்துதல் போன்ற பல சுவாரஸ்யமான அம்சங்களைக் கொண்டிருந்தது. UI இல் உங்கள் உரிமைகளுடன் கூடிய படம், உள்ளமைக்கப்பட்ட பெயர்வெளிகள் அல்லது திட்டப்பணிகள்.
Rancher 2 ஐச் சுற்றி ஏற்கனவே ஒரு சமூகம் உருவாக்கப்பட்டுள்ளது, மேலும் அதை நிர்வகிக்க HashiCorp Terraform எனப்படும் வழங்குநர் உருவாக்கப்பட்டது, இது எல்லாவற்றையும் ஒன்றாக இணைக்க உதவியது.
என்ன நடந்தது
இதன் விளைவாக, ராஞ்சர் இயங்கும் ஒரு சிறிய கிளஸ்டரை நாங்கள் முடித்தோம், மற்ற அனைத்து கிளஸ்டர்களுக்கும், அதனுடன் இணைக்கப்பட்ட பல கிளஸ்டர்களுக்கும் அணுகலாம், எல்.டி.ஏ.பி கோப்பகத்தில் பயனரைச் சேர்ப்பது போல், எந்த ஒரு அணுகலும் வழங்கப்படலாம். அது எங்கு அமைந்துள்ளது மற்றும் எந்த வழங்குநரின் வளங்களைப் பயன்படுத்துகிறது.
கிட்லாப்-சிஐ மற்றும் டெர்ராஃபார்மைப் பயன்படுத்தி, கிளவுட் வழங்குநர்கள் அல்லது எங்கள் சொந்த உள்கட்டமைப்பில் ஏதேனும் உள்ளமைவின் கிளஸ்டரை உருவாக்கி அவற்றை ராஞ்சருடன் இணைக்க உங்களை அனுமதிக்கும் ஒரு அமைப்பு உருவாக்கப்பட்டது. இவை அனைத்தும் IaC பாணியில் செய்யப்படுகின்றன, அங்கு ஒவ்வொரு கிளஸ்டரும் ஒரு களஞ்சியத்தால் விவரிக்கப்படுகிறது, மேலும் அதன் நிலை பதிப்பு செய்யப்படுகிறது. அதே நேரத்தில், பெரும்பாலான தொகுதிகள் வெளிப்புற களஞ்சியங்களிலிருந்து இணைக்கப்பட்டுள்ளன, இதனால் எஞ்சியிருப்பது மாறிகளை அனுப்புவது அல்லது நிகழ்வுகளுக்கான உங்கள் தனிப்பயன் உள்ளமைவை விவரிக்கிறது, இது குறியீடு மீண்டும் மீண்டும் செய்யும் சதவீதத்தைக் குறைக்க உதவுகிறது.
நிச்சயமாக, எங்கள் பயணம் இன்னும் வெகு தொலைவில் உள்ளது, இன்னும் பல சுவாரஸ்யமான பணிகள் உள்ளன, அதாவது எந்த கிளஸ்டர்களின் பதிவுகள் மற்றும் அளவீடுகள், சர்வீஸ் மெஷ், மல்டிகிளஸ்டரில் சுமைகளை நிர்வகிப்பதற்கான கிடாப்கள் மற்றும் பல. எங்கள் அனுபவம் உங்களுக்கு சுவாரஸ்யமாக இருக்கும் என்று நம்புகிறோம்!
கட்டுரை A. Antipov, A. Ganush, Platform Engineers ஆகியோரால் எழுதப்பட்டது.
ஆதாரம்: www.habr.com