குபெர்னெட்டஸில் ஒரு ஆபரேட்டரை உருவாக்குதல், அதன் கட்டிடக்கலை மற்றும் அடிப்படை இயக்கக் கொள்கைகளை வடிவமைத்தல் போன்ற நடைமுறைச் சிக்கல்களுக்கு இந்த அறிக்கை அர்ப்பணிக்கப்பட்டுள்ளது.
அறிக்கையின் முதல் பகுதியில், நாங்கள் கருத்தில் கொள்வோம்:
- Kubernetes இல் ஒரு ஆபரேட்டர் என்றால் என்ன, அது ஏன் தேவைப்படுகிறது;
- சிக்கலான அமைப்புகளின் நிர்வாகத்தை இயக்குபவர் எவ்வாறு சரியாக எளிதாக்குகிறார்;
- ஆபரேட்டரால் என்ன முடியும் மற்றும் ஆபரேட்டரால் என்ன செய்ய முடியாது.
அடுத்து, ஆபரேட்டரின் உள் கட்டமைப்பைப் பற்றி விவாதிப்போம். ஆபரேட்டரின் கட்டமைப்பு மற்றும் செயல்பாட்டைப் படிப்படியாகப் பார்ப்போம். அதை விரிவாகப் பார்ப்போம்:
- ஆபரேட்டர் மற்றும் குபெர்னெட்டஸ் இடையேயான தொடர்பு;
- ஆபரேட்டர் என்ன செயல்பாடுகளை மேற்கொள்கிறார் மற்றும் குபெர்னெட்டஸுக்கு என்ன செயல்பாடுகளை வழங்குகிறார்.
குபெர்னெட்டஸில் உள்ள துண்டுகள் மற்றும் தரவுத்தள பிரதிகளை நிர்வகிப்பதைக் கவனியுங்கள்.
அடுத்து, தரவு சேமிப்பக சிக்கல்களைப் பற்றி விவாதிப்போம்:
- ஆபரேட்டரின் பார்வையில் நிலையான சேமிப்பகத்துடன் எவ்வாறு வேலை செய்வது;
- உள்ளூர் சேமிப்பகத்தைப் பயன்படுத்துவதில் உள்ள சிக்கல்கள்.
அறிக்கையின் இறுதிப் பகுதியில், பயன்பாட்டின் நடைமுறை எடுத்துக்காட்டுகளை நாங்கள் கருத்தில் கொள்வோம் Amazon அல்லது Google Cloud Service உடன். ClickHouseக்கான ஆபரேட்டரின் மேம்பாடு மற்றும் இயக்க அனுபவத்தின் உதாரணத்தின் அடிப்படையில் அறிக்கை அமைந்துள்ளது.
வீடியோக்கள்:
என் பெயர் விளாடிஸ்லாவ் கிளிமென்கோ. இன்று நான் ஒரு ஆபரேட்டரை உருவாக்கி இயக்குவதில் எங்கள் அனுபவத்தைப் பற்றி பேச விரும்பினேன், இது தரவுத்தள கிளஸ்டர்களை நிர்வகிப்பதற்கான ஒரு சிறப்பு ஆபரேட்டர். உதாரணத்திற்கு கிளிக்ஹவுஸ் கிளஸ்டரை நிர்வகிக்க.
ஆபரேட்டர் மற்றும் கிளிக்ஹவுஸ் பற்றி பேச நமக்கு ஏன் வாய்ப்பு உள்ளது?
- நாங்கள் கிளிக்ஹவுஸை ஆதரிக்கிறோம் மற்றும் மேம்படுத்துகிறோம்.
- இந்த நேரத்தில், கிளிக்ஹவுஸின் வளர்ச்சிக்கு எங்கள் பங்களிப்பை மெதுவாகச் செய்ய முயற்சிக்கிறோம். கிளிக்ஹவுஸில் செய்யப்பட்ட மாற்றங்களின் அடிப்படையில் யாண்டெக்ஸுக்குப் பிறகு நாங்கள் இரண்டாவது இடத்தில் இருக்கிறோம்.
- கிளிக்ஹவுஸ் சுற்றுச்சூழல் அமைப்பிற்கான கூடுதல் திட்டங்களை உருவாக்க முயற்சிக்கிறோம்.
இந்த திட்டங்களில் ஒன்றைப் பற்றி நான் பேச விரும்புகிறேன். இது Kubernetes க்கான ClickHouse-operator பற்றியது.
எனது அறிக்கையில் நான் இரண்டு தலைப்புகளில் தொட விரும்புகிறேன்:
- எங்கள் ClickHouse தரவுத்தள மேலாண்மை ஆபரேட்டர் Kubernetes இல் எவ்வாறு செயல்படுகிறது என்பது முதல் தலைப்பு.
- இரண்டாவது தலைப்பு, எந்த ஆபரேட்டரும் எப்படி வேலை செய்கிறார், அதாவது குபெர்னெட்டஸுடன் அது எவ்வாறு தொடர்பு கொள்கிறது என்பது.
இருப்பினும், இந்த இரண்டு கேள்விகளும் எனது அறிக்கை முழுவதும் குறுக்கிடும்.
நான் சொல்ல வருவதைக் கேட்பதில் யார் ஆர்வம் காட்டுவார்கள்?
- ஆபரேட்டர்களை இயக்குபவர்களுக்கு இது மிகவும் ஆர்வமாக இருக்கும்.
- அல்லது அது உள்ளே எவ்வாறு செயல்படுகிறது, ஆபரேட்டர் குபெர்னெட்டஸுடன் எவ்வாறு தொடர்பு கொள்கிறார் மற்றும் என்னென்ன ஆபத்துகள் தோன்றக்கூடும் என்பதைப் புரிந்துகொள்வதற்காக சொந்தமாக உருவாக்க விரும்புவோருக்கு.
இன்று நாம் என்ன விவாதிக்கப் போகிறோம் என்பதை நன்கு புரிந்து கொள்ள, குபெர்னெட்டஸ் எவ்வாறு செயல்படுகிறது மற்றும் சில அடிப்படை கிளவுட் பயிற்சிகளை மேற்கொள்வது நல்லது.
ClickHouse என்றால் என்ன? இது பகுப்பாய்வு வினவல்களின் ஆன்லைன் செயலாக்கத்தில் உள்ள விவரங்கள் கொண்ட நெடுவரிசை தரவுத்தளமாகும். மேலும் இது முற்றிலும் திறந்த மூலமாகும்.
மேலும் இரண்டு விஷயங்களை மட்டும் நாம் தெரிந்து கொள்வது முக்கியம். இது ஒரு தரவுத்தளம் என்பதை நீங்கள் அறிந்து கொள்ள வேண்டும், எனவே நான் உங்களுக்குச் சொல்வது கிட்டத்தட்ட எந்த தரவுத்தளத்திற்கும் பொருந்தும். மேலும் ClickHouse DBMS அளவீடுகள் மிகவும் நன்றாக இருக்கும் என்பது கிட்டத்தட்ட நேரியல் அளவீடுகளை அளிக்கிறது. எனவே, கிளஸ்டர் நிலை என்பது கிளிக்ஹவுஸுக்கு இயற்கையான நிலை. குபெர்னெட்டஸில் கிளிக்ஹவுஸ் கிளஸ்டருக்கு எவ்வாறு சேவை செய்வது என்பது பற்றி விவாதிப்பதில் நாங்கள் மிகவும் ஆர்வமாக உள்ளோம்.
அவர் ஏன் அங்கு தேவை? அதை ஏன் நாமே தொடர்ந்து இயக்க முடியாது? பதில்கள் ஓரளவு தொழில்நுட்பமாகவும், ஓரளவு நிறுவனமாகவும் இருக்கும்.
- நடைமுறையில், பெரிய நிறுவனங்களில் கிட்டத்தட்ட அனைத்து கூறுகளும் ஏற்கனவே குபெர்னெட்ஸில் இருக்கும் சூழ்நிலையை நாங்கள் பெருகிய முறையில் எதிர்கொள்கிறோம். தரவுத்தளங்கள் வெளியில் இருக்கும்.
- மேலும் கேள்வி அதிகமாக கேட்கப்படுகிறது: "இதை உள்ளே வைக்க முடியுமா?" எனவே, பெரிய நிறுவனங்கள் தங்கள் தரவுக் கிடங்குகளை விரைவாக நிர்வகிப்பதற்காக நிர்வாகத்தின் அதிகபட்ச ஒருங்கிணைப்பை அடைய முயற்சிக்கின்றன.
- ஒரு புதிய இடத்தில், அதாவது அதிகபட்ச பெயர்வுத்திறன், அதே விஷயத்தை மீண்டும் செய்ய உங்களுக்கு அதிகபட்ச வாய்ப்பு தேவைப்பட்டால் இது குறிப்பாக உதவுகிறது.
இது எவ்வளவு எளிதானது அல்லது கடினம்? இது, நிச்சயமாக, கையால் செய்யப்படலாம். ஆனால் இது அவ்வளவு எளிதல்ல, ஏனென்றால் குபெர்னெட்ஸை நிர்வகிப்பதற்கான கூடுதல் சிக்கலானது எங்களிடம் உள்ளது, ஆனால் அதே நேரத்தில் கிளிக்ஹவுஸின் பிரத்தியேகங்கள் மிகைப்படுத்தப்பட்டுள்ளன. மற்றும் அத்தகைய திரட்டல் முடிவு.
இவை அனைத்தும் சேர்ந்து ஒரு பெரிய அளவிலான தொழில்நுட்பங்களை வழங்குகிறது, இது நிர்வகிப்பது மிகவும் கடினமாகிறது, ஏனெனில் குபெர்னெட்டஸ் அதன் சொந்த அன்றாட சிக்கல்களை செயல்பாட்டுக்கு கொண்டு வருகிறது, மேலும் கிளிக்ஹவுஸ் அதன் சொந்த சிக்கல்களை அன்றாட செயல்பாட்டிற்கு கொண்டு வருகிறது. குறிப்பாக எங்களிடம் பல கிளிக்ஹவுஸ்கள் இருந்தால், அவற்றுடன் தொடர்ந்து ஏதாவது செய்ய வேண்டும்.
டைனமிக் உள்ளமைவு கொண்ட ClickHouse ஆனது DevOps இல் நிலையான சுமையை உருவாக்கும் ஏராளமான சிக்கல்களைக் கொண்டுள்ளது:
- கிளிக்ஹவுஸில் எதையாவது மாற்ற விரும்பினால், எடுத்துக்காட்டாக, ஒரு பிரதி, ஒரு ஷார்ட்டைச் சேர்க்கவும், பின்னர் நாம் உள்ளமைவை நிர்வகிக்க வேண்டும்.
- கிளிக்ஹவுஸ் ஒரு குறிப்பிட்ட பகிர்வு முறையைக் கொண்டிருப்பதால், தரவுத் திட்டத்தை மாற்றவும். அங்கு தரவுத் திட்டத்தை அமைப்பது, உள்ளமைவுகளை அமைப்பது அவசியம்.
- நீங்கள் கண்காணிப்பை அமைக்க வேண்டும்.
- புதிய துண்டுகளுக்காக, புதிய பிரதிகளுக்காக பதிவுகளை சேகரித்தல்.
- மீட்பை கவனித்துக் கொள்ளுங்கள்.
- மற்றும் மறுதொடக்கம்.
இவை போன்ற வழக்கமான வேலைகள், செயல்பாட்டில் நான் மிகவும் வசதியாக இருக்க விரும்புகிறேன்.
குபெர்னெட்டஸ் செயல்பாட்டில் நன்றாக உதவுகிறது, ஆனால் அடிப்படை அமைப்பு விஷயங்களில்.
குபெர்னெட்டஸ் போன்ற விஷயங்களை எளிதாக்குவதிலும் தானியக்கமாக்குவதிலும் வல்லவர்:
- மீட்பு.
- மறுதொடக்கம்.
- சேமிப்பு அமைப்பு மேலாண்மை.
அது நல்லது, அதுதான் சரியான திசை, ஆனால் தரவுத்தள கிளஸ்டரை எவ்வாறு இயக்குவது என்பது பற்றி அவர் முற்றிலும் அறியாதவர்.
எங்களுக்கு மேலும் தேவை, முழு தரவுத்தளமும் குபெர்னெட்ஸில் வேலை செய்ய வேண்டும்.
நீங்கள் அழுத்தும் ஒரு பெரிய மேஜிக் ரெட் பட்டனைப் போன்ற ஒன்றைப் பெற விரும்புகிறேன், மேலும் உங்கள் வாழ்க்கைச் சுழற்சி முழுவதும் வரிசைப்படுத்தப்பட்டு பராமரிக்கப்படும் அன்றாடப் பணிகளைத் தீர்க்க வேண்டும். குபெர்னெட்டஸில் உள்ள கிளிக்ஹவுஸ் கிளஸ்டர்.
வேலையை எளிதாக்க உதவும் ஒரு தீர்வை உருவாக்க முயற்சித்தோம். அல்டினிட்டியில் இருந்து குபெர்னெட்ஸிற்கான கிளிக்ஹவுஸ்-ஆபரேட்டர் இது.
ஒரு ஆபரேட்டர் என்பது ஒரு நிரலாகும், அதன் முக்கிய பணி மற்ற நிரல்களை நிர்வகிப்பதாகும், அதாவது இது ஒரு மேலாளர்.
மேலும் இது நடத்தை முறைகளைக் கொண்டுள்ளது. பாடப் பகுதியைப் பற்றிய இந்த குறியிடப்பட்ட அறிவை நீங்கள் அழைக்கலாம்.
DevOps இன் வாழ்க்கையை எளிதாக்குவதும் மைக்ரோமேனேஜ்மென்ட்டைக் குறைப்பதும் அவரது முக்கிய பணியாகும், இதனால் அவர் (DevOps) ஏற்கனவே உயர் மட்டத்தில் சிந்திக்கிறார், அதாவது அவர் (DevOps) மைக்ரோமேனேஜ்மென்ட்டில் ஈடுபடவில்லை, அதனால் அவர் கட்டமைக்கவில்லை. அனைத்து விவரங்களும் கைமுறையாக.
ஆபரேட்டர் ஒரு ரோபோ உதவியாளர், அவர் மைக்ரோ டாஸ்க்குகளைக் கையாளுகிறார் மற்றும் DevOps க்கு உதவுகிறார்.
ஒரு ஆபரேட்டர் ஏன் தேவை? அவர் இரண்டு துறைகளில் சிறந்து விளங்குகிறார்:
- ClickHouse உடன் கையாளும் நிபுணருக்கு போதுமான அனுபவம் இல்லை, ஆனால் ஏற்கனவே ClickHouse ஐ இயக்க வேண்டியிருக்கும் போது, ஆபரேட்டர் செயல்பாட்டை எளிதாக்குகிறது மற்றும் கிளிக்ஹவுஸ் கிளஸ்டரை மிகவும் சிக்கலான உள்ளமைவுடன் இயக்க அனுமதிக்கிறது. உள்ளே. நீங்கள் அவருக்கு உயர் மட்ட பணிகளை வழங்குகிறீர்கள், அது வேலை செய்கிறது.
- அதிக எண்ணிக்கையிலான வழக்கமான பணிகளை தானியக்கமாக்குவது அவசியமான போது அது சிறப்பாகச் செயல்படும் இரண்டாவது பணியாகும். கணினி நிர்வாகிகளிடமிருந்து மைக்ரோ டாஸ்க்குகளை நீக்குகிறது.
பயணத்தைத் தொடங்குபவர்களுக்கு அல்லது நிறைய ஆட்டோமேஷன் செய்ய வேண்டியவர்களுக்கு இது மிகவும் தேவைப்படுகிறது.
ஆபரேட்டர் அடிப்படையிலான அணுகுமுறைக்கும் பிற அமைப்புகளுக்கும் என்ன வித்தியாசம்? ஹெல்மும் உள்ளது. இது ClickHouse ஐ நிறுவ உதவுகிறது, நீங்கள் ஹெல்ம் விளக்கப்படங்களை வரையலாம், இது முழு ClickHouse கிளஸ்டரையும் நிறுவும். ஆபரேட்டருக்கும் அதே போன்றவற்றுக்கும் என்ன வித்தியாசம், எடுத்துக்காட்டாக, ஹெல்ம்?
முக்கிய அடிப்படை வேறுபாடு என்னவென்றால், ஹெல்ம் என்பது தொகுப்பு மேலாண்மை பற்றியது, மேலும் ஆபரேட்டர் ஒரு படி மேலே செல்கிறார். இது முழு வாழ்க்கைச் சுழற்சியின் ஆதரவாகும். இது நிறுவல் மட்டுமல்ல, இவை அளவிடுதல், துண்டித்தல், அதாவது வாழ்க்கைச் சுழற்சியின் போது செய்ய வேண்டிய அனைத்தும் (தேவைப்பட்டால், அகற்றுவதும்) அடங்கும் - இவை அனைத்தும் ஆபரேட்டரால் தீர்மானிக்கப்படுகின்றன. இது முழு மென்பொருள் வாழ்க்கைச் சுழற்சியையும் தானியக்கமாக்கி சேவை செய்ய முயற்சிக்கிறது. வழங்கப்பட்ட பிற தீர்வுகளிலிருந்து இதுவே அதன் அடிப்படை வேறுபாடு.
அதுதான் அறிமுகப் பகுதி, தொடரலாம்.
எங்கள் ஆபரேட்டரை எவ்வாறு உருவாக்குவது? கிளிக்ஹவுஸ் கிளஸ்டரை ஒரே ஆதாரமாக நிர்வகிப்பதற்கான சிக்கலை அணுக முயற்சிக்கிறோம்.
இங்கே படத்தின் இடது பக்கத்தில் உள்ளீடு தரவு உள்ளது. இது ஒரு கிளஸ்டர் விவரக்குறிப்புடன் கூடிய YAML ஆகும், இது குபெக்ட்ல் வழியாக கிளாசிக் முறையில் குபெர்னெட்டஸுக்கு அனுப்பப்படுகிறது. அங்கு எங்கள் ஆபரேட்டர் அதை எடுத்து தனது மேஜிக்கை செய்கிறார். வெளியீட்டில் பின்வரும் திட்டத்தைப் பெறுகிறோம். இது குபெர்னெட்டஸில் உள்ள கிளிக்ஹவுஸின் செயலாக்கமாகும்.
ஆபரேட்டர் எவ்வாறு சரியாக வேலை செய்கிறார், என்ன வழக்கமான பணிகளை தீர்க்க முடியும் என்பதை மெதுவாகப் பார்ப்போம். எங்களுக்கு குறைந்த நேரமே இருப்பதால் வழக்கமான பணிகளை மட்டுமே கருத்தில் கொள்வோம். ஆபரேட்டர் முடிவு செய்யக்கூடிய அனைத்தும் விவாதிக்கப்படாது.
நடைமுறையில் இருந்து ஆரம்பிக்கலாம். எங்கள் திட்டம் முற்றிலும் திறந்த மூலமாகும், எனவே இது GitHub இல் எவ்வாறு செயல்படுகிறது என்பதை நீங்கள் பார்க்கலாம். நீங்கள் கருத்தில் இருந்து தொடரலாம், நீங்கள் தொடங்க விரும்பினால், விரைவு தொடக்க வழிகாட்டியுடன் தொடங்கலாம்.
நீங்கள் விரிவாக புரிந்து கொள்ள விரும்பினால், ஆவணங்களை அதிகமாகவோ அல்லது குறைவாகவோ ஒழுக்கமான வடிவத்தில் பராமரிக்க முயற்சிக்கிறோம்.
ஒரு நடைமுறை சிக்கலுடன் ஆரம்பிக்கலாம். நாம் அனைவரும் தொடங்க விரும்பும் முதல் பணி, எப்படியாவது முதல் உதாரணத்தை இயக்க வேண்டும். ஆபரேட்டரைப் பயன்படுத்தி கிளிக்ஹவுஸை எவ்வாறு தொடங்குவது, அது எவ்வாறு இயங்குகிறது என்று எனக்குத் தெரியாவிட்டாலும் கூட? நாங்கள் ஒரு அறிக்கையை எழுதுகிறோம், ஏனென்றால்... k8s உடனான அனைத்து தகவல்தொடர்புகளும் மேனிஃபெஸ்டுகள் மூலம் தொடர்புகொள்வதாகும்.
அத்தகைய சிக்கலான அறிக்கை இங்கே. நாம் சிவப்பு நிறத்தில் எதை முன்னிலைப்படுத்தியுள்ளோம் என்பதில் நாம் கவனம் செலுத்த வேண்டும். டெமோ என்ற கிளஸ்டரை உருவாக்குமாறு ஆபரேட்டரிடம் கேட்டுக்கொள்கிறோம்.
இவை இப்போதைக்கு அடிப்படை உதாரணங்கள். சேமிப்பகம் இன்னும் விவரிக்கப்படவில்லை, ஆனால் சிறிது நேரம் கழித்து சேமிப்பகத்திற்குத் திரும்புவோம். இப்போதைக்கு, கிளஸ்டரின் வளர்ச்சியின் இயக்கவியலைக் கவனிப்போம்.
இந்த அறிக்கையை நாங்கள் உருவாக்கியுள்ளோம். நாங்கள் அதை எங்கள் ஆபரேட்டருக்கு வழங்குகிறோம். அவர் வேலை செய்தார், மந்திரம் செய்தார்.
நாங்கள் கன்சோலைப் பார்க்கிறோம். மூன்று கூறுகள் ஆர்வமாக உள்ளன - இவை பாட், இரண்டு சர்வீஸ்-ஏ, ஸ்டேட்ஃபுல்செட்.
ஆபரேட்டர் வேலை செய்துள்ளார், அவர் சரியாக என்ன உருவாக்கினார் என்பதை நாம் பார்க்கலாம்.
இப்படி ஒன்றை உருவாக்குகிறார். எங்களிடம் ஒவ்வொரு பிரதிக்கும் ஸ்டேட்ஃபுல்செட், பாட், கான்ஃபிக்மேப், முழு கிளஸ்டருக்கான கான்ஃபிக்மேப் உள்ளது. கிளஸ்டருக்கான நுழைவுப் புள்ளிகளாக சேவைகள் அவசியம்.
சேவைகள் மத்திய சுமை சமநிலை சேவையாகும், மேலும் ஒவ்வொரு துண்டிற்கும் ஒவ்வொரு பிரதிக்கும் பயன்படுத்தப்படலாம்.
இங்கே எங்கள் அடிப்படை கிளஸ்டர் இது போன்றது. அவர் ஒற்றை முனையிலிருந்து வந்தவர்.
மேலும் செல்வோம், சிக்கலாக்குவோம். நீங்கள் கிளஸ்டரைத் துண்டிக்க வேண்டும்.
எங்கள் பணிகள் வளர்ந்து வருகின்றன, இயக்கவியல் தொடங்குகிறது. நாங்கள் ஒரு துண்டு சேர்க்க விரும்புகிறோம். வளர்ச்சியைப் பின்பற்றுகிறோம். நாங்கள் எங்கள் விவரக்குறிப்பை மாற்றுகிறோம். எங்களுக்கு இரண்டு துண்டுகள் வேண்டும் என்று குறிப்பிடுகிறோம்.
கணினியின் வளர்ச்சியுடன் மாறும் வகையில் உருவாகும் அதே கோப்பு இதுவாகும். சேமிப்பக எண், சேமிப்பகம் மேலும் விவாதிக்கப்படும், இது ஒரு தனி தலைப்பு.
நாங்கள் YAML ஆபரேட்டருக்கு உணவளித்து என்ன நடக்கிறது என்று பார்க்கிறோம்.
ஆபரேட்டர் யோசித்து பின்வரும் நிறுவனங்களை உருவாக்கினார். எங்களிடம் ஏற்கனவே இரண்டு பாட்கள், மூன்று சேவைகள் மற்றும் திடீரென்று 2 ஸ்டேட்ஃபுல் செட்டுகள் உள்ளன. ஏன் 2 ஸ்டேட்ஃபுல் செட்?
வரைபடத்தில் இது இப்படி இருந்தது - இது எங்கள் ஆரம்ப நிலை, எங்களிடம் ஒரு காய் இருந்தபோது.
இது இப்படி ஆனது. இதுவரை எல்லாம் எளிமையானது, அது நகலெடுக்கப்பட்டது.
ஏன் இரண்டு ஸ்டேட்ஃபுல் செட் ஆனது? குபெர்னெட்டஸில் காய்கள் எவ்வாறு நிர்வகிக்கப்படுகின்றன என்ற கேள்வியை இங்கே நாம் வேறுபடுத்தி விவாதிக்க வேண்டும்.
ஸ்டேட்ஃபுல்செட் எனப்படும் ஒரு பொருள் உள்ளது, இது ஒரு டெம்ப்ளேட்டில் இருந்து பாட்களின் தொகுப்பை உருவாக்க உங்களை அனுமதிக்கிறது. இங்கே முக்கிய காரணி டெம்ப்ளேட் ஆகும். ஒரு ஸ்டேட்ஃபுல் செட்டில் ஒரு டெம்ப்ளேட்டைப் பயன்படுத்தி பல பாட்களை நீங்கள் தொடங்கலாம். மேலும் இங்குள்ள முக்கிய சொற்றொடர் "ஒரு டெம்ப்ளேட்டிற்கு பல காய்கள்" என்பதாகும்.
முழு கிளஸ்டரையும் ஒரு ஸ்டேட்ஃபுல்செட்டில் பேக் செய்ய ஒரு பெரிய ஆசை இருந்தது. இது வேலை செய்யும், அதில் எந்த பிரச்சனையும் இல்லை. ஆனால் ஒரு எச்சரிக்கை உள்ளது. நாம் ஒரு பன்முக கிளஸ்டரை இணைக்க விரும்பினால், அதாவது, கிளிக்ஹவுஸின் பல பதிப்புகளிலிருந்து, கேள்விகள் எழத் தொடங்குகின்றன. ஆம், ஸ்டேட்ஃபுல்செட் ஒரு ரோலிங் புதுப்பிப்பைச் செய்ய முடியும், மேலும் அங்கு நீங்கள் ஒரு புதிய பதிப்பை வெளியிடலாம், ஒரே நேரத்தில் பல முனைகளுக்கு மேல் முயற்சிக்க வேண்டாம் என்பதை விளக்குங்கள்.
ஆனால் நாம் பணியை விரிவுபடுத்தி, முற்றிலும் பன்முகத்தன்மை கொண்ட கிளஸ்டரை உருவாக்க விரும்புகிறோம் என்றும், ரோலிங் புதுப்பிப்பைப் பயன்படுத்தி பழைய பதிப்பிலிருந்து புதியதாக மாற்ற விரும்பவில்லை என்றும், ஆனால் வெவ்வேறு பதிப்புகளின் அடிப்படையில் ஒரு பன்முக கிளஸ்டரை உருவாக்க விரும்புகிறோம். கிளிக்ஹவுஸ் மற்றும் வெவ்வேறு சேமிப்பகத்தின் அடிப்படையில். எடுத்துக்காட்டாக, தனித்தனி வட்டுகளில் சில பிரதிகளை உருவாக்க விரும்புகிறோம், மெதுவானவற்றில், பொதுவாக, ஒரு பன்முகத்தன்மை கொண்ட கிளஸ்டரை முழுமையாக உருவாக்க வேண்டும். ஸ்டேட்ஃபுல்செட் ஒரு டெம்ப்ளேட்டிலிருந்து தரப்படுத்தப்பட்ட தீர்வை உருவாக்குவதால், இதைச் செய்ய வழி இல்லை.
சிறிது யோசனைக்குப் பிறகு, இதை இப்படிச் செய்வோம் என்று முடிவு செய்யப்பட்டது. எங்களிடம் ஒவ்வொரு பிரதியும் அதன் சொந்த ஸ்டேட்ஃபுல் செட்டில் உள்ளது. இந்த தீர்வுக்கு சில குறைபாடுகள் உள்ளன, ஆனால் நடைமுறையில் இது அனைத்தும் ஆபரேட்டரால் முழுமையாக இணைக்கப்பட்டுள்ளது. மற்றும் நிறைய நன்மைகள் உள்ளன. நாம் விரும்பும் சரியான கிளஸ்டரை உருவாக்கலாம், எடுத்துக்காட்டாக, முற்றிலும் பன்முகத்தன்மை வாய்ந்த ஒன்று. எனவே, ஒரு நகலுடன் இரண்டு துண்டுகள் உள்ள ஒரு கிளஸ்டரில், எங்களிடம் 2 ஸ்டேட்ஃபுல் செட் மற்றும் 2 பாட்கள் இருக்கும், ஏனெனில் ஒரு பன்முகத்தன்மை கொண்ட கிளஸ்டரை உருவாக்க மேலே கூறப்பட்ட காரணங்களுக்காக இந்த அணுகுமுறையைத் தேர்ந்தெடுத்தோம்.
நடைமுறை சிக்கல்களுக்கு திரும்புவோம். எங்கள் கிளஸ்டரில் நாம் பயனர்களை உள்ளமைக்க வேண்டும், அதாவது. குபெர்னெட்டஸில் கிளிக்ஹவுஸின் சில உள்ளமைவுகளை நீங்கள் செய்ய வேண்டும். ஆபரேட்டர் இதற்கான அனைத்து சாத்தியங்களையும் வழங்குகிறது.
நமக்குத் தேவையானதை நேரடியாக YAMLல் எழுதலாம். அனைத்து உள்ளமைவு விருப்பங்களும் இந்த YAML இலிருந்து நேரடியாக ClickHouse configs இல் வரைபடமாக்கப்படுகின்றன, பின்னர் அவை கிளஸ்டர் முழுவதும் விநியோகிக்கப்படும்.
இப்படி எழுதலாம். இது உதாரணத்திற்கு. கடவுச்சொல்லை குறியாக்கம் செய்ய முடியும். நிச்சயமாக அனைத்து ClickHouse உள்ளமைவு விருப்பங்களும் ஆதரிக்கப்படுகின்றன. இதோ ஒரு உதாரணம்.
கிளஸ்டர் உள்ளமைவு ConfigMap ஆக விநியோகிக்கப்படுகிறது. நடைமுறையில், ConfigMap புதுப்பிப்பு உடனடியாக நடக்காது, எனவே ஒரு பெரிய கிளஸ்டர் இருந்தால், கட்டமைப்பைத் தள்ளும் செயல்முறை சிறிது நேரம் எடுக்கும். ஆனால் இவை அனைத்தும் பயன்படுத்த மிகவும் வசதியானது.
பணியை சிக்கலாக்குவோம். கிளஸ்டர் உருவாகி வருகிறது. நாங்கள் தரவைப் பிரதிபலிக்க விரும்புகிறோம். அதாவது, எங்களிடம் ஏற்கனவே இரண்டு துண்டுகள் உள்ளன, ஒவ்வொன்றும் ஒரு பிரதி, மற்றும் பயனர்கள் உள்ளமைக்கப்பட்டுள்ளனர். நாங்கள் வளர்ந்து வருகிறோம், நகலெடுக்க விரும்புகிறோம்.
நகலெடுக்க நமக்கு என்ன தேவை?
எங்களுக்கு ZooKeeper தேவை. ClickHouse இல், ZooKeeper ஐப் பயன்படுத்தி பிரதி உருவாக்கப்படுகிறது. ZooKeeper தேவைப்படுவதால், வெவ்வேறு ClickHouse பிரதிகள் எந்த ClickHouse இல் எந்த தரவுத் தொகுதிகள் உள்ளன என்பதில் ஒருமித்த கருத்து இருக்கும்.
ZooKeeper ஐ யார் வேண்டுமானாலும் பயன்படுத்தலாம். ஒரு நிறுவனத்திற்கு வெளிப்புற ZooKeeper இருந்தால், அதைப் பயன்படுத்தலாம். இல்லையெனில், நீங்கள் எங்கள் களஞ்சியத்திலிருந்து நிறுவலாம். இந்த முழு விஷயத்தையும் எளிதாக்கும் ஒரு நிறுவி உள்ளது.
முழு அமைப்பின் தொடர்புத் திட்டம் இப்படி மாறும். எங்களிடம் குபெர்னெட்ஸ் ஒரு தளமாக உள்ளது. இது ClickHouse அறிக்கையை செயல்படுத்துகிறது. ZooKeeper நான் இங்கே படம் பிடித்தேன். மேலும் ஆபரேட்டர் ClickHouse மற்றும் ZooKeeper இரண்டுடனும் தொடர்பு கொள்கிறது. அதாவது, ஒரு தொடர்பு பெறப்படுகிறது.
K8s க்கு தரவை வெற்றிகரமாக நகலெடுக்க கிளிக்ஹவுஸுக்கு இவை அனைத்தும் அவசியம்.
நகலெடுப்பதற்கான மேனிஃபெஸ்ட் எப்படி இருக்கும் என்பதைப் பற்றி இப்போது பணியைப் பார்ப்போம்.
எங்கள் மேனிஃபெஸ்ட்டில் இரண்டு பிரிவுகளைச் சேர்க்கிறோம். முதலாவதாக ZooKeeper ஐ எங்கு பெறுவது என்பது குபெர்னெட்ஸின் உள்ளே அல்லது வெளிப்புறமாக இருக்கலாம். இது ஒரு விளக்கம் மட்டுமே. நாங்கள் பிரதிகளை ஆர்டர் செய்கிறோம். அந்த. எங்களுக்கு இரண்டு பிரதிகள் வேண்டும். மொத்தத்தில், வெளியீட்டில் 4 காய்கள் இருக்க வேண்டும். சேமிப்பகத்தைப் பற்றி எங்களுக்கு நினைவிருக்கிறது, அது இன்னும் சிறிது தூரம் திரும்பும். சேமிப்பு என்பது தனி பாடல்.
இது இப்படி இருந்தது.
இது இப்படி ஆகிவிடுகிறது. பிரதிகள் சேர்க்கப்படுகின்றன. 4 வது பொருந்தவில்லை, அவற்றில் பல இருக்கலாம் என்று நாங்கள் நம்புகிறோம். மேலும் ZooKeeper பக்கத்தில் சேர்க்கப்பட்டுள்ளது. வடிவங்கள் மிகவும் சிக்கலானதாகி வருகின்றன.
அடுத்த பணியைச் சேர்க்க வேண்டிய நேரம் இது. நிரந்தர சேமிப்பகத்தைச் சேர்ப்போம்.
நிலையான சேமிப்பகத்திற்கு, எங்களிடம் பல்வேறு விருப்பங்கள் உள்ளன.
நாம் கிளவுட் வழங்குநரில் இயங்கினால், எடுத்துக்காட்டாக, அமேசான், கூகிள் ஆகியவற்றைப் பயன்படுத்தினால், கிளவுட் சேமிப்பகத்தைப் பயன்படுத்த ஒரு பெரிய ஆசை உள்ளது. இது மிகவும் வசதியானது, நல்லது.
மற்றும் இரண்டாவது விருப்பம் உள்ளது. ஒவ்வொரு முனையிலும் உள்ளூர் வட்டுகள் இருக்கும் போது, இது உள்ளூர் சேமிப்பிற்கானது. இந்த விருப்பத்தை செயல்படுத்துவது மிகவும் கடினம், ஆனால் அதே நேரத்தில் அது அதிக உற்பத்தித் திறன் கொண்டது.
கிளவுட் ஸ்டோரேஜ் பற்றி நம்மிடம் என்ன இருக்கிறது என்று பார்ப்போம்.
நன்மைகள் உள்ளன. இது கட்டமைக்க மிகவும் எளிதானது. கிளவுட் வழங்குநரிடமிருந்து நாங்கள் ஆர்டர் செய்கிறோம், தயவு செய்து, அத்தகைய மற்றும் அத்தகைய திறன்களின் சேமிப்பிடத்தை எங்களுக்கு வழங்குங்கள். வகுப்புகள் வழங்குநர்களால் சுயாதீனமாக திட்டமிடப்படுகின்றன.
மற்றும் ஒரு குறைபாடு உள்ளது. சிலருக்கு, இது விமர்சனமற்ற குறைபாடு. நிச்சயமாக, சில செயல்திறன் மேலடுக்குகள் இருக்கும். இது பயன்படுத்த மிகவும் வசதியானது, நம்பகமானது, ஆனால் செயல்திறனில் சில சாத்தியமான குறைபாடுகள் உள்ளன.
மற்றும் இருந்து கிளிக்ஹவுஸ் செயல்திறனில் கவனம் செலுத்துகிறது, இது சாத்தியமான அனைத்தையும் பிழிகிறது என்று நீங்கள் கூறலாம், எனவே பல வாடிக்கையாளர்கள் அதிகபட்ச செயல்திறனைக் கசக்க முயற்சிக்கின்றனர்.
அதிலிருந்து அதிகப் பலன்களைப் பெற, எங்களுக்கு உள்ளூர் சேமிப்பு தேவை.
Kubernetes இல் உள்ளூர் சேமிப்பகத்தைப் பயன்படுத்துவதற்கு Kubernetes மூன்று சுருக்கங்களை வழங்குகிறது. இது:
- காலி டைர்
- ஹோஸ்ட்பாத்.
- உள்ளூர்
அவை எவ்வாறு வேறுபடுகின்றன, எவ்வாறு ஒத்திருக்கின்றன என்பதைப் பார்ப்போம்.
முதலாவதாக, மூன்று அணுகுமுறைகளிலும், எங்களிடம் சேமிப்பிடம் உள்ளது - இவை ஒரே இயற்பியல் k8s முனையில் அமைந்துள்ள உள்ளூர் வட்டுகள். ஆனால் அவர்களுக்கு சில வேறுபாடுகள் உள்ளன.
எளிமையான ஒன்றைத் தொடங்குவோம், அதாவது காலி டிர். நடைமுறையில் இது என்ன? எங்கள் விவரக்குறிப்பில், உள்ளூர் வட்டில் உள்ள ஒரு கோப்புறைக்கான அணுகலை எங்களுக்கு வழங்குமாறு கொள்கலன் அமைப்பிடம் (பெரும்பாலும் டோக்கர்) கேட்கிறோம்.
நடைமுறையில், டோக்கர் அதன் சொந்த பாதையில் எங்காவது ஒரு தற்காலிக கோப்புறையை உருவாக்கி அதை நீண்ட ஹாஷ் என்று அழைக்கிறது. மற்றும் அதை அணுக ஒரு இடைமுகத்தை வழங்குகிறது.
செயல்திறன் வாரியாக இது எவ்வாறு செயல்படும்? இது உள்ளூர் வட்டு வேகத்தில் வேலை செய்யும், அதாவது. இது உங்கள் திருகுக்கான முழு அணுகல்.
ஆனால் இந்த வழக்கு அதன் குறைபாடு உள்ளது. இந்த விஷயத்தில் தொடர்ந்து மிகவும் சந்தேகத்திற்குரியது. முதல் முறையாக டோக்கர் கொள்கலன்களுடன் நகரும்போது, பெர்சிஸ்டண்ட் தொலைந்துவிடும். குபெர்னெட்டஸ் சில காரணங்களுக்காக இந்த Pod ஐ வேறு வட்டுக்கு நகர்த்த விரும்பினால், தரவு இழக்கப்படும்.
இந்த அணுகுமுறை சோதனைகளுக்கு நல்லது, ஏனெனில் இது ஏற்கனவே சாதாரண வேகத்தைக் காட்டுகிறது, ஆனால் இந்த விருப்பம் தீவிரமான ஒன்றுக்கு ஏற்றது அல்ல.
எனவே, இரண்டாவது அணுகுமுறை உள்ளது. இது ஹோஸ்ட்பாத். முந்தைய ஸ்லைடையும் இதையும் பார்த்தால், ஒரே ஒரு வித்தியாசத்தை மட்டும் பார்க்கலாம். எங்கள் கோப்புறை டோக்கரை நேரடியாக குபெர்னெட்ஸ் முனைக்கு அனுப்பியது. இங்கே கொஞ்சம் வேகமாக இருக்கிறது. எங்கள் தரவைச் சேமிக்க விரும்பும் உள்ளூர் கோப்பு முறைமையில் பாதையை நேரடியாக எழுதுகிறோம்.
இந்த முறை நன்மைகளைக் கொண்டுள்ளது. இது ஏற்கனவே ஒரு உண்மையான நிலையானது மற்றும் ஒரு உன்னதமானது. எங்கள் வட்டில், தரவு சில முகவரிகளுக்கு எழுதப்படும்.
தீமைகளும் உண்டு. இது நிர்வாகத்தின் சிக்கலானது. எங்கள் குபெர்னெட்டுகள் பாடை மற்றொரு இயற்பியல் முனைக்கு நகர்த்த விரும்பலாம். இங்குதான் DevOps செயல்பாட்டுக்கு வருகிறது. இந்த பாதைகளில் நீங்கள் ஏதாவது பொருத்தப்பட்டிருக்கும் அத்தகைய முனைகளுக்கு மட்டுமே இந்த காய்களை நகர்த்த முடியும் என்பதையும், ஒரு நேரத்தில் ஒன்றுக்கு மேற்பட்ட முனைகள் இருக்கக்கூடாது என்பதையும் இது முழு அமைப்பிற்கும் சரியாக விளக்க வேண்டும். அது போதும் கஷ்டம்.
குறிப்பாக இந்த நோக்கங்களுக்காக, இந்த சிக்கலான அனைத்தையும் மறைக்க எங்கள் ஆபரேட்டரில் டெம்ப்ளேட்களை உருவாக்கினோம். நீங்கள் எளிமையாகச் சொல்லலாம்: "ஒவ்வொரு இயற்பியல் முனைக்கும் மற்றும் அத்தகைய பாதையில் கிளிக்ஹவுஸின் ஒரு நிகழ்வை நான் வைத்திருக்க விரும்புகிறேன்."
ஆனால் இந்த தேவை எங்களுக்கு மட்டும் இல்லை, எனவே குபெர்னெட்டஸைச் சேர்ந்த மனிதர்களும் மக்கள் உடல் வட்டுகளை அணுக விரும்புகிறார்கள் என்பதை புரிந்துகொள்கிறார்கள், எனவே அவர்கள் மூன்றாவது அடுக்கை வழங்குகிறார்கள்.
இது உள்ளூர் என்று அழைக்கப்படுகிறது. முந்தைய ஸ்லைடிலிருந்து நடைமுறையில் எந்த வித்தியாசமும் இல்லை. இந்த காய்களை முனையிலிருந்து முனைக்கு மாற்ற முடியாது என்பதை கைமுறையாக உறுதிப்படுத்துவதற்கு முன்புதான், அவை உள்ளூர் இயற்பியல் வட்டில் சில பாதையில் இணைக்கப்பட வேண்டும், ஆனால் இப்போது இந்த அறிவு அனைத்தும் குபெர்னெட்டஸில் இணைக்கப்பட்டுள்ளது. மேலும் இது கட்டமைக்க மிகவும் எளிதாக இருக்கும்.
நமது நடைமுறைச் சிக்கலுக்குத் திரும்புவோம். YAML டெம்ப்ளேட்டிற்கு திரும்புவோம். இங்கே எங்களிடம் உண்மையான சேமிப்பு உள்ளது. நாங்கள் திரும்பியுள்ளோம். கிளாசிக் VolumeClaim டெம்ப்ளேட்டை k8s இல் உள்ளவாறு அமைத்துள்ளோம். எந்த வகையான சேமிப்பிடத்தை நாங்கள் விரும்புகிறோம் என்பதை நாங்கள் விவரிக்கிறோம்.
அதன் பிறகு, k8s சேமிப்பிடத்தைக் கோரும். ஸ்டேட்ஃபுல் செட்டில் எங்களுக்கு ஒதுக்குங்கள். இறுதியில், இது கிளிக்ஹவுஸின் வசம் மாறும்.
எங்களிடம் இந்த திட்டம் இருந்தது. எங்களின் பெர்சிஸ்டெண்ட் ஸ்டோரேஜ் சிவப்பு நிறத்தில் இருந்தது, அதைச் செய்ய வேண்டும் என்பதைக் குறிக்கிறது.
மேலும் அது பச்சை நிறமாக மாறும். இப்போது K8s கிளஸ்டர் திட்டத்தில் கிளிக்ஹவுஸ் முழுமையாக முடிக்கப்பட்டுள்ளது. எங்களிடம் துண்டுகள், பிரதிகள், மிருகக்காட்சிசாலைகள் உள்ளன, எங்களிடம் ஒரு உண்மையான பெர்சிஸ்டண்ட் உள்ளது, இது ஒரு வழியில் அல்லது வேறு வழியில் செயல்படுத்தப்படுகிறது. இத்திட்டம் ஏற்கனவே முழுமையாக செயல்பாட்டில் உள்ளது.
நாங்கள் தொடர்ந்து வாழ்கிறோம். எங்கள் கிளஸ்டர் வளர்ந்து வருகிறது. அலெக்ஸி முயற்சி செய்து கிளிக்ஹவுஸின் புதிய பதிப்பை வெளியிடுகிறார்.
ஒரு நடைமுறை பணி எழுகிறது - எங்கள் கிளஸ்டரில் கிளிக்ஹவுஸின் புதிய பதிப்பைச் சோதிக்க. மேலும், இயற்கையாகவே, நீங்கள் அனைத்தையும் வெளியிட விரும்பவில்லை; தொலைதூர மூலையில் எங்காவது ஒரு பிரதியில் ஒரு புதிய பதிப்பை வைக்க விரும்புகிறீர்கள், மேலும் ஒரு புதிய பதிப்பு அல்ல, ஆனால் ஒரே நேரத்தில் இரண்டு, ஏனெனில் அவை அடிக்கடி வெளிவருகின்றன.
இதைப் பற்றி நாம் என்ன சொல்ல முடியும்?
இங்கே எங்களுக்கு அத்தகைய வாய்ப்பு உள்ளது. இவை பாட் டெம்ப்ளேட்கள். நீங்கள் வண்ணம் தீட்டலாம், எங்கள் ஆபரேட்டர் முற்றிலும் பன்முகத்தன்மை கொண்ட கிளஸ்டரை உருவாக்க உங்களை அனுமதிக்கிறது. அந்த. உள்ளமைக்கவும், ஒரு கொத்து அனைத்து பிரதிகளிலிருந்து தொடங்கி, ஒவ்வொரு தனிப்பட்ட பிரதியிலும் முடிவடையும், எந்த பதிப்பு கிளிக்ஹவுஸ் வேண்டும், எந்த பதிப்பில் சேமிப்பிடம் வேண்டும். நமக்குத் தேவையான கட்டமைப்பில் கிளஸ்டரை முழுமையாகக் கட்டமைக்க முடியும்.
உள்ளே கொஞ்சம் ஆழமாகச் செல்வோம். இதற்கு முன், ClickHouse இன் பிரத்தியேகங்கள் தொடர்பாக ClickHouse-operator எவ்வாறு செயல்படுகிறது என்பதைப் பற்றி பேசினோம்.
எந்த ஆபரேட்டரும் பொதுவாக எப்படி செயல்படுகிறார், அதே போல் அது K8s உடன் எவ்வாறு தொடர்பு கொள்கிறது என்பதைப் பற்றி இப்போது நான் சில வார்த்தைகளைச் சொல்ல விரும்புகிறேன்.
முதலில் K8s உடன் தொடர்புகொள்வதைப் பார்ப்போம். நாம் kubectl விண்ணப்பிக்கும்போது என்ன நடக்கும்? எங்கள் பொருள்கள் API மூலம் etcd இல் தோன்றும்.
எடுத்துக்காட்டாக, அடிப்படை குபெர்னெட்ஸ் பொருள்கள்: பாட், ஸ்டேட்ஃபுல்செட், சேவை மற்றும் பலவற்றின் பட்டியலில்.
இருப்பினும், உடல் ரீதியாக எதுவும் நடக்கவில்லை. இந்த பொருள்கள் ஒரு கிளஸ்டரில் பொருளாக்கப்பட வேண்டும்.
இங்குதான் கட்டுப்படுத்தி வருகிறது. கன்ட்ரோலர் என்பது இந்த விளக்கங்களை செயல்படுத்தக்கூடிய ஒரு சிறப்பு k8s கூறு ஆகும். உடல் ரீதியாக எப்படி, என்ன செய்ய வேண்டும் என்பது அவருக்குத் தெரியும். கொள்கலன்களை எவ்வாறு இயக்குவது என்பது அவருக்குத் தெரியும், சர்வர் வேலை செய்ய அங்கு என்ன கட்டமைக்கப்பட வேண்டும்.
மேலும் இது K8 களில் நமது பொருட்களைப் பொருளாக்குகிறது.
ஆனால் நாங்கள் காய்கள் மற்றும் ஸ்டேட்ஃபுல்செட்களுடன் மட்டும் செயல்பட விரும்புகிறோம், ஒரு கிளிக்ஹவுஸ் இன்ஸ்டாலேஷன், அதாவது கிளிக்ஹவுஸ் வகையின் ஒரு பொருளை உருவாக்க விரும்புகிறோம். இதுவரை அப்படி ஒரு வாய்ப்பு இல்லை.
ஆனால் K8s மற்றொரு நல்ல விஷயம் உள்ளது. எங்காவது இதுபோன்ற சிக்கலான நிறுவனம் இருக்க வேண்டும் என்று நாங்கள் விரும்புகிறோம், அதில் எங்கள் கொத்து காய்கள் மற்றும் ஸ்டேட்ஃபுல்செட் ஆகியவற்றிலிருந்து சேகரிக்கப்படும்.
மேலும் இதற்கு என்ன செய்ய வேண்டும்? முதலில், Custom Resource Definition படத்தில் வருகிறது. அது என்ன? இது K8s க்கான விளக்கமாகும், உங்களிடம் இன்னும் ஒரு தரவு வகை இருக்கும், நாங்கள் தனிப்பயன் ஆதாரத்தை ஸ்டேட்ஃபுல்செட்டில் சேர்க்க விரும்புகிறோம், இது உள்ளே சிக்கலானதாக இருக்கும். இது தரவு கட்டமைப்பின் விளக்கமாகும்.
நாங்கள் அதை kubectl apply வழியாகவும் அனுப்புகிறோம். குபர்னெட்ஸ் அதை மகிழ்ச்சியுடன் எடுத்துக் கொண்டார்.
இப்போது எங்கள் சேமிப்பகத்தில், etcd இல் உள்ள பொருளுக்கு ClickHouseInstallation எனப்படும் தனிப்பயன் ஆதாரத்தை பதிவு செய்யும் வாய்ப்பு உள்ளது.
ஆனால் இப்போதைக்கு மேற்கொண்டு எதுவும் நடக்காது. அதாவது, துண்டுகள் மற்றும் பிரதிகளை விவரிக்கும் YAML கோப்பை இப்போது உருவாக்கி, "kubectl பொருந்தும்" என்று சொன்னால், குபெர்னெட்டஸ் அதை ஏற்று, etcd இல் வைத்து, "அருமை, ஆனால் என்ன செய்வது என்று எனக்குத் தெரியவில்லை. இதனுடன். ClickHouseInstallation ஐ எவ்வாறு பராமரிப்பது என்று எனக்குத் தெரியவில்லை."
அதன்படி, குபெர்னெட்டஸுக்கு புதிய தரவு வகையை வழங்குவதற்கு யாராவது உதவ வேண்டும். இடதுபுறத்தில் நேட்டிவ் டேட்டா வகைகளுடன் வேலை செய்யும் நேட்டிவ் குபெர்னெட்ஸ் கன்ட்ரோலர் உள்ளது. வலதுபுறத்தில் தனிப்பயன் தரவு வகைகளுடன் வேலை செய்யக்கூடிய தனிப்பயன் கட்டுப்படுத்தி இருக்க வேண்டும்.
மற்றொரு வழியில் இது ஒரு ஆபரேட்டர் என்று அழைக்கப்படுகிறது. நான் அதை குறிப்பாக இங்கு குபெர்னெட்டஸ் என்று சேர்த்துள்ளேன், ஏனெனில் இது K8sக்கு வெளியேயும் செயல்படுத்தப்படலாம். பெரும்பாலும், நிச்சயமாக, அனைத்து ஆபரேட்டர்களும் குபெர்னெட்ஸில் செயல்படுத்தப்படுகிறார்கள், ஆனால் அது வெளியே நிற்பதை எதுவும் தடுக்கவில்லை, எனவே இங்கே அது சிறப்பாக வெளியே நகர்த்தப்படுகிறது.
இதையொட்டி, ஆபரேட்டர் என்றும் அழைக்கப்படும் தனிப்பயன் கட்டுப்படுத்தி, API வழியாக குபெர்னெட்டஸுடன் தொடர்பு கொள்கிறது. API உடன் எவ்வாறு தொடர்புகொள்வது என்பது ஏற்கனவே தெரியும். தனிப்பயன் வளத்திலிருந்து நாம் உருவாக்க விரும்பும் சிக்கலான சுற்றுகளை எவ்வாறு செயல்படுத்துவது என்பது அவருக்கு ஏற்கனவே தெரியும். இதைத்தான் ஆபரேட்டர் செய்கிறார்.
ஆபரேட்டர் எப்படி வேலை செய்கிறார்? அவர் அதை எப்படி செய்கிறார் என்பதைப் பார்க்க வலது பக்கத்தைப் பார்ப்போம். ஆபரேட்டர் இதையெல்லாம் எவ்வாறு செயல்படுத்துகிறது மற்றும் K8s உடன் மேலும் தொடர்பு எவ்வாறு நடைபெறுகிறது என்பதை நாங்கள் கண்டுபிடிப்போம்.
ஆபரேட்டர் என்பது ஒரு நிரல். அவள் நிகழ்வு சார்ந்தவள். ஆபரேட்டர் Kubernetes API ஐப் பயன்படுத்தி நிகழ்வுகளுக்கு குழுசேர்கிறார். Kubernetes API இல் நீங்கள் நிகழ்வுகளுக்கு குழுசேரக்கூடிய நுழைவு புள்ளிகள் உள்ளன. K8s இல் ஏதாவது மாற்றம் ஏற்பட்டால், குபெர்னெட்டஸ் நிகழ்வுகளை அனைவருக்கும் அனுப்புகிறார், அதாவது. இந்த API புள்ளிக்கு குழுசேர்ந்தவர்கள் அறிவிப்புகளைப் பெறுவார்கள்.
ஆபரேட்டர் நிகழ்வுகளுக்கு சந்தா செலுத்துகிறார், மேலும் சில வகையான எதிர்வினைகளைச் செய்ய வேண்டும். வளர்ந்து வரும் நிகழ்வுகளுக்கு பதிலளிப்பதே அதன் பணி.
சில புதுப்பிப்புகளால் நிகழ்வுகள் உருவாக்கப்படுகின்றன. எங்கள் YAML கோப்பு ClickHouseInstallation பற்றிய விளக்கத்துடன் வருகிறது. அவர் kubectl apply மூலம் etcdக்கு சென்றார். ஒரு நிகழ்வு அங்கு வேலை செய்தது, இதன் விளைவாக, இந்த நிகழ்வு கிளிக்ஹவுஸ்-ஆபரேட்டருக்கு வந்தது. ஆபரேட்டர் இந்த விளக்கத்தைப் பெற்றார். மேலும் அவர் ஏதாவது செய்ய வேண்டும். ClickHouseInstallation ஆப்ஜெக்ட்டுக்கு புதுப்பிப்பு வந்திருந்தால், நீங்கள் கிளஸ்டரைப் புதுப்பிக்க வேண்டும். கிளஸ்டரை புதுப்பிப்பதே ஆபரேட்டரின் பணி.
அவன் என்ன செய்கிறான்? முதலில், இந்தப் புதுப்பிப்பை என்ன செய்வோம் என்பதற்கான செயல் திட்டத்தை உருவாக்க வேண்டும். புதுப்பிப்புகள் மிகச் சிறியதாக இருக்கலாம், அதாவது. YAML செயல்பாட்டில் சிறியது, ஆனால் கிளஸ்டரில் மிகப் பெரிய மாற்றங்களுக்கு வழிவகுக்கும். எனவே, ஆபரேட்டர் ஒரு திட்டத்தை உருவாக்குகிறார், பின்னர் அவர் அதை கடைபிடிக்கிறார்.
அவர் இந்தத் திட்டத்தின்படி, காய்கள், சேவைகள், அதாவது, இந்த கட்டமைப்பை உள்ளே கொதிக்க வைக்கத் தொடங்குகிறார். அதன் முக்கிய பணியை செய்ய வேண்டும். இது குபெர்னெட்ஸில் கிளிக்ஹவுஸ் கிளஸ்டரை உருவாக்குவது போன்றது.
இப்போது அத்தகைய சுவாரஸ்யமான விஷயத்தைத் தொடுவோம். இது குபெர்னெட்டஸ் மற்றும் ஆபரேட்டருக்கு இடையேயான பொறுப்புப் பிரிவாகும், அதாவது. குபெர்னெட்ஸ் என்ன செய்கிறார், ஆபரேட்டர் என்ன செய்கிறார் மற்றும் அவர்கள் எப்படி ஒருவருக்கொருவர் தொடர்பு கொள்கிறார்கள்.
கணினி விஷயங்களுக்கு குபெர்னெட்ஸ் பொறுப்பு, அதாவது. ஒரு அமைப்பு-நோக்கமாக விளங்கக்கூடிய பொருள்களின் அடிப்படை தொகுப்பிற்கு. குபெர்னெட்டஸ் காய்களை எவ்வாறு தொடங்குவது, கொள்கலன்களை எவ்வாறு மறுதொடக்கம் செய்வது, மவுண்ட் தொகுதிகளை எவ்வாறு செய்வது, கான்ஃபிக்மேப்பில் எவ்வாறு வேலை செய்வது, அதாவது. அமைப்பு என்று சொல்லக்கூடிய எதையும்.
ஆபரேட்டர்கள் களங்களில் செயல்படுகிறார்கள். ஒவ்வொரு ஆபரேட்டரும் அதன் சொந்த பாடப் பகுதிக்காக உருவாக்கப்பட்டுள்ளது. நாங்கள் அதை ClickHouse க்காக செய்தோம்.
மேலும் ஒரு பிரதியைச் சேர்ப்பது, வரைபடத்தை உருவாக்குவது, கண்காணிப்பை அமைப்பது போன்ற பாடப் பகுதியின் அடிப்படையில் ஆபரேட்டர் துல்லியமாக தொடர்பு கொள்கிறார். இதனால் பிரிவு ஏற்படுகிறது.
நாம் சேர்க்கும் பிரதிச் செயலைச் செய்யும்போது, கவலைகளைப் பிரிப்பது எப்படி நிகழ்கிறது என்பதற்கான நடைமுறை உதாரணத்தைப் பார்ப்போம்.
ஆபரேட்டர் ஒரு பணியைப் பெறுகிறார் - ஒரு பிரதியைச் சேர்க்க. ஆபரேட்டர் என்ன செய்கிறார்? ஒரு புதிய ஸ்டேட்ஃபுல்செட் உருவாக்கப்பட வேண்டும் என்று ஆபரேட்டர் கணக்கிடுவார், அதில் அத்தகைய டெம்ப்ளேட்டுகள், தொகுதி உரிமைகோரல் விவரிக்கப்பட வேண்டும்.
அவர் அனைத்தையும் தயார் செய்து K8 களுக்கு அனுப்புகிறார். தனக்கு ConfigMap, StatefulSet, Volume தேவை என்று கூறுகிறார். குபெர்னெட்ஸ் வேலை செய்கிறார். அவர் செயல்படும் அடிப்படை அலகுகளை அவர் செயல்படுத்துகிறார்.
பின்னர் கிளிக்ஹவுஸ்-ஆபரேட்டர் மீண்டும் செயல்பாட்டுக்கு வருகிறது. அவரிடம் ஏற்கனவே ஒரு உடல் நிலை உள்ளது, அதில் அவர் ஏற்கனவே ஏதாவது செய்ய முடியும். கிளிக்ஹவுஸ்-ஆபரேட்டர் மீண்டும் டொமைன் அடிப்படையில் செயல்படுகிறது. அந்த. குறிப்பாக ClickHouse, ஒரு கிளஸ்டரில் ஒரு பிரதியைச் சேர்க்க, முதலில், இந்தக் கிளஸ்டரில் இருக்கும் தரவுத் திட்டத்தை நீங்கள் கட்டமைக்க வேண்டும். மேலும், இரண்டாவதாக, இந்த பிரதியானது கண்காணிப்பில் சேர்க்கப்பட வேண்டும், இதனால் அதை தெளிவாகக் கண்டறிய முடியும். ஆபரேட்டர் ஏற்கனவே இதை உள்ளமைத்துள்ளார்.
அதன் பிறகுதான் கிளிக்ஹவுஸ் செயல்பாட்டுக்கு வருகிறது, அதாவது. மற்றொரு உயர் நிலை நிறுவனம். இது ஏற்கனவே ஒரு தரவுத்தளமாகும். இது அதன் சொந்த உதாரணத்தைக் கொண்டுள்ளது, அடுத்த கட்டமைக்கப்பட்ட பிரதி, இது கிளஸ்டரில் சேரத் தயாராக உள்ளது.
ஒரு பிரதியைச் சேர்ப்பது போதுமானதாக இருக்கும் போது அது நிறைவேற்றுதல் மற்றும் பொறுப்பைப் பிரித்தல் சங்கிலி மாறிவிடும்.
நாங்கள் எங்கள் நடைமுறை பணிகளை தொடர்கிறோம். உங்களிடம் ஏற்கனவே ஒரு கிளஸ்டர் இருந்தால், நீங்கள் உள்ளமைவை நகர்த்தலாம்.
ஏற்கனவே உள்ள xml மூலம் நீங்கள் ஒட்டக்கூடிய வகையில் நாங்கள் அதை உருவாக்கியுள்ளோம், அதை ClickHouse புரிந்துகொள்கிறது.
நீங்கள் கிளிக்ஹவுஸை நன்றாக மாற்றலாம். ஹோஸ்ட்பாத், லோக்கல் ஸ்டோரேஜ் பற்றி விளக்கும்போது நான் பேசியது வெறும் மண்டல வரிசைப்படுத்தல். மண்டல வரிசைப்படுத்தலைச் சரியாகச் செய்வது இதுதான்.
அடுத்த நடைமுறை பணி கண்காணிப்பு.
எங்கள் கிளஸ்டர் மாறினால், நாம் அவ்வப்போது கண்காணிப்பை உள்ளமைக்க வேண்டும்.
வரைபடத்தைப் பார்ப்போம். இங்கே பச்சை அம்புகளை நாங்கள் ஏற்கனவே கருதினோம். இப்போது சிவப்பு அம்புகளைப் பார்ப்போம். இப்படித்தான் எங்கள் கிளஸ்டரைக் கண்காணிக்க விரும்புகிறோம். கிளிக்ஹவுஸ் கிளஸ்டரிலிருந்து அளவீடுகள் எப்படி ப்ரோமிதியஸிலும், பின்னர் கிராஃபனாவிலும் நுழைகின்றன.
கண்காணிப்பதில் என்ன சிரமம்? இது ஏன் ஒருவித சாதனையாக முன்வைக்கப்படுகிறது? சிரமம் இயக்கவியலில் உள்ளது. எங்களிடம் ஒரு கிளஸ்டர் இருக்கும்போது அது நிலையானதாக இருக்கும்போது, நாம் ஒரு முறை கண்காணிப்பை அமைக்கலாம், மேலும் கவலைப்பட வேண்டாம்.
ஆனால் நம்மிடம் நிறைய கொத்துகள் இருந்தால், அல்லது ஏதாவது மாறிக்கொண்டே இருந்தால், செயல்முறை மாறும். கண்காணிப்பை தொடர்ந்து மறுகட்டமைப்பது வளங்களையும் நேரத்தையும் வீணடிப்பதாகும், அதாவது. வெறும் சோம்பல் கூட. இதை தானியக்கமாக்க வேண்டும். செயல்முறையின் இயக்கவியலில் சிரமம் உள்ளது. ஆபரேட்டர் இதை நன்றாக தானியக்கமாக்குகிறது.
எங்கள் கிளஸ்டர் எவ்வாறு வளர்ந்தது? ஆரம்பத்தில் அவர் அப்படித்தான் இருந்தார்.
அப்போது அவன் இப்படித்தான் இருந்தான்.
கடைசியில் அவர் இப்படி ஆகிவிட்டார்.
மற்றும் கண்காணிப்பு ஆபரேட்டரால் தானாகவே செய்யப்படுகிறது. ஒற்றை நுழைவு புள்ளி.
மேலும் வெளியேறும் போது, கிராஃபனா டாஷ்போர்டைப் பார்க்கும்போது, எங்கள் கிளஸ்டரின் வாழ்க்கை உள்ளே எப்படி கொதிக்கிறது என்பதைப் பார்க்கிறோம்.
மூலம், கிராஃபானா டாஷ்போர்டு எங்கள் ஆபரேட்டருடன் மூலக் குறியீட்டில் விநியோகிக்கப்படுகிறது. நீங்கள் இணைத்து பயன்படுத்தலாம். இந்த ஸ்கிரீன்ஷாட் எங்கள் DevOps மூலம் எனக்கு வழங்கப்பட்டது.
அடுத்து எங்கு செல்ல விரும்புகிறோம்? இது:
- சோதனை ஆட்டோமேஷனை உருவாக்குங்கள். முக்கிய பணி புதிய பதிப்புகளின் தானியங்கி சோதனை ஆகும்.
- ZooKeeper உடனான ஒருங்கிணைப்பை தானியக்கமாக்க விரும்புகிறோம். ZooKeeper-ஆபரேட்டருடன் ஒருங்கிணைக்க திட்டங்கள் உள்ளன. அந்த. ZooKeeper க்காக ஒரு ஆபரேட்டர் எழுதப்பட்டுள்ளது மற்றும் இரண்டு ஆபரேட்டர்களும் மிகவும் வசதியான தீர்வை உருவாக்க ஒருங்கிணைக்கத் தொடங்குவது தர்க்கரீதியானது.
- மிகவும் சிக்கலான வாழ்க்கைச் சோதனைகளைச் செய்ய விரும்புகிறோம்.
- டெம்ப்ளேட்களின் பரம்பரை - முடிந்தது, அதாவது ஆபரேட்டரின் அடுத்த வெளியீட்டில் நாம் ஏற்கனவே டெம்ப்ளேட்டுகளின் பரம்பரைப் பெறுவோம் என்பதை பச்சை நிறத்தில் முன்னிலைப்படுத்தினேன். இது ஒரு சக்திவாய்ந்த கருவியாகும், இது துண்டுகளிலிருந்து சிக்கலான உள்ளமைவுகளை உருவாக்க உங்களை அனுமதிக்கிறது.
- மேலும் சிக்கலான பணிகளை தானியக்கமாக்க விரும்புகிறோம். அதில் முக்கியமானது ரீ ஷார்டிங்.
சில இடைநிலை முடிவுகளை எடுத்துக் கொள்வோம்.
இதன் விளைவாக நாம் என்ன பெறுகிறோம்? மற்றும் அதைச் செய்வது மதிப்புள்ளதா இல்லையா? தரவுத்தளத்தை குபெர்னெட்டஸுக்கு இழுத்து, பொதுவாக ஆபரேட்டரையும், குறிப்பாக அலிட்னிட்டி ஆபரேட்டரையும் பயன்படுத்த முயற்சிப்பது அவசியமா?
வெளியீட்டில் நாம் பெறுகிறோம்:
- கட்டமைப்பு, வரிசைப்படுத்தல் மற்றும் பராமரிப்பு ஆகியவற்றின் குறிப்பிடத்தக்க எளிமைப்படுத்தல் மற்றும் தானியங்கு.
- உடனடியாக உள்ளமைக்கப்பட்ட கண்காணிப்பு.
- மேலும் சிக்கலான சூழ்நிலைகளுக்கு பயன்படுத்த தயாராக உள்ள குறியிடப்பட்ட வார்ப்புருக்கள். பிரதியைச் சேர்ப்பது போன்ற செயலை கைமுறையாகச் செய்ய வேண்டியதில்லை. ஆபரேட்டர் இதைச் செய்கிறார்.
கடைசியாக ஒரே ஒரு கேள்வி மட்டுமே உள்ளது. எங்களிடம் ஏற்கனவே Kubernetes, மெய்நிகராக்கத்தில் தரவுத்தளம் உள்ளது. குறிப்பாக கிளிக்ஹவுஸ் செயல்திறனுக்காக உகந்ததாக இருப்பதால், அத்தகைய தீர்வின் செயல்திறன் பற்றி என்ன?
எல்லாம் நன்றாக இருக்கிறது என்பதே பதில்! நான் விரிவாகச் செல்லமாட்டேன்; இது ஒரு தனி அறிக்கையின் தலைப்பு.
ஆனால் TSBS போன்ற ஒரு திட்டம் உள்ளது. அதன் முக்கிய பணி என்ன? இது ஒரு தரவுத்தள செயல்திறன் சோதனை. சூடாகவும், மென்மையை மென்மையாகவும் ஒப்பிடும் முயற்சி இது.
அவர் எப்படி வேலை செய்கிறார்? ஒரு செட் தரவு உருவாக்கப்படுகிறது. ஒரே சோதனைத் தொகுப்பில் உள்ள இந்தத் தரவு வெவ்வேறு தரவுத்தளங்களில் இயங்குகிறது. ஒவ்வொரு தரவுத்தளமும் ஒரு சிக்கலை முடிந்தவரை தீர்க்கிறது. பின்னர் நீங்கள் முடிவுகளை ஒப்பிடலாம்.
இது ஏற்கனவே ஒரு பெரிய அளவிலான தரவுத்தளங்களை ஆதரிக்கிறது. நான் மூன்று முக்கியவற்றை அடையாளம் கண்டுள்ளேன். இது:
- கால அளவீடு.
- InfluxDB.
- கிளிக்ஹவுஸ்.
இதேபோன்ற மற்றொரு தீர்வுடன் ஒப்பீடு செய்யப்பட்டது. RedShift உடன் ஒப்பீடு. அமேசானில் ஒப்பீடு செய்யப்பட்டது. கிளிக்ஹவுஸ் இந்த விஷயத்தில் எல்லோரையும் விட மிகவும் முன்னால் உள்ளது.
நான் சொன்னதில் இருந்து என்ன முடிவுகளை எடுக்க முடியும்?
- குபெர்னெட்டஸில் DB சாத்தியம். ஒருவேளை, நீங்கள் எதையும் செய்ய முடியும், ஆனால் பொதுவாக உங்களால் முடியும் போல் தெரிகிறது. எங்கள் ஆபரேட்டரின் உதவியுடன் Kubernetes இல் கிளிக்ஹவுஸ் நிச்சயமாக சாத்தியமாகும்.
- ஆபரேட்டர் செயல்முறைகளை தானியக்கமாக்க உதவுகிறது மற்றும் உண்மையில் வாழ்க்கையை எளிதாக்குகிறது.
- செயல்திறன் சாதாரணமானது.
- இதைப் பயன்படுத்தலாம் மற்றும் பயன்படுத்த வேண்டும் என்று எங்களுக்குத் தோன்றுகிறது.
திறந்த மூல - எங்களுடன் சேருங்கள்!
நான் ஏற்கனவே கூறியது போல், ஆபரேட்டர் முற்றிலும் ஓப்பன் சோர்ஸ் தயாரிப்பு என்பதால், அதிகபட்சம் மக்கள் இதைப் பயன்படுத்தினால் மிகவும் நன்றாக இருக்கும். எங்களுடன் சேர்! நாங்கள் உங்களுக்காக காத்திருக்கிறோம்!
நன்றி!
உங்கள் கேள்விகள்
அறிக்கைக்கு நன்றி! என் பெயர் அன்டன். நான் SEMrush இல் இருந்து வருகிறேன். பதிவு செய்வதில் என்ன இருக்கிறது என்று யோசித்துக்கொண்டிருக்கிறேன். கண்காணிப்பு பற்றி நாங்கள் கேள்விப்படுகிறோம், ஆனால் முழு கிளஸ்டரைப் பற்றியும் பேசினால், பதிவு செய்வது பற்றி எதுவும் இல்லை. எடுத்துக்காட்டாக, வன்பொருளில் ஒரு கிளஸ்டரை உருவாக்கியுள்ளோம். நாங்கள் மையப்படுத்தப்பட்ட பதிவுகளைப் பயன்படுத்துகிறோம், நிலையான வழிமுறைகளைப் பயன்படுத்தி அவற்றை ஒரு பொதுவான குவியலாக சேகரிக்கிறோம். பின்னர் அங்கிருந்து நமக்கு விருப்பமான தரவைப் பெறுகிறோம்.
நல்ல கேள்வி, அதாவது டோடோ பட்டியலில் உள்நுழைதல். எங்கள் ஆபரேட்டர் இதை இன்னும் தானியக்கமாக்கவில்லை. இது இன்னும் வளர்ந்து வருகிறது, திட்டம் இன்னும் இளமையாக உள்ளது. பதிவு செய்ய வேண்டியதன் அவசியத்தை நாங்கள் புரிந்துகொள்கிறோம். இதுவும் மிக முக்கியமான தலைப்பு. மேலும் இது கண்காணிப்பை விட குறைவான முக்கியத்துவம் வாய்ந்தது அல்ல. ஆனால் செயல்படுத்துவதற்கான பட்டியலில் முதலில் கண்காணிப்பு இருந்தது. மரம் வெட்டுதல் இருக்கும். இயற்கையாகவே, கிளஸ்டரின் வாழ்க்கையின் அனைத்து அம்சங்களையும் தானியக்கமாக்க முயற்சிக்கிறோம். எனவே, பதில் என்னவென்றால், இந்த நேரத்தில் ஆபரேட்டருக்கு, துரதிர்ஷ்டவசமாக, இதை எப்படி செய்வது என்று தெரியவில்லை, ஆனால் அது திட்டங்களில் உள்ளது, நாங்கள் அதை செய்வோம். நீங்கள் சேர விரும்பினால், கோரிக்கையை இழுக்கவும்.
வணக்கம்! அறிக்கைக்கு நன்றி! என்னிடம் நிலையான தொகுதிகள் தொடர்பான நிலையான கேள்வி உள்ளது. இந்த ஆபரேட்டருடன் ஒரு கட்டமைப்பை உருவாக்கும்போது, எந்த முனையில் ஒரு குறிப்பிட்ட வட்டு அல்லது கோப்புறை இணைக்கப்பட்டுள்ளது என்பதை ஆபரேட்டர் எவ்வாறு தீர்மானிப்பது? டிஸ்க் உள்ள இந்த முனைகளில் நமது ClickHouse ஐ வைப்பதை முதலில் அவருக்கு விளக்க வேண்டும்?
நான் புரிந்துகொண்ட வரையில், இந்தக் கேள்வி உள்ளூர் சேமிப்பகத்தின் தொடர்ச்சியாகும், குறிப்பாக அதன் ஹோஸ்ட்பாத் பகுதி. இது முழு அமைப்பிற்கும் விளக்குவது போன்றது, அத்தகைய மற்றும் அத்தகைய முனையில் பாட் தொடங்கப்பட வேண்டும், எங்களிடம் உடல் ரீதியாக இணைக்கப்பட்ட வட்டு உள்ளது, இது அத்தகைய பாதையில் பொருத்தப்பட்டுள்ளது. நான் மிக மேலோட்டமாகத் தொட்ட முழுப் பகுதி இது, ஏனெனில் அங்குள்ள பதில் மிகப் பெரியது.
சுருக்கமாக இது போல் தெரிகிறது. இயற்கையாகவே, இந்த தொகுதிகளை நாம் வழங்க வேண்டும். இந்த நேரத்தில், உள்ளூர் சேமிப்பகத்தில் டைனமிக் ஏற்பாடு இல்லை, எனவே DevOps வட்டுகளை தாங்களாகவே வெட்ட வேண்டும், இந்த தொகுதிகள். நீங்கள் குபெர்னெட்டஸ் வழங்குவதை அவர்கள் விளக்க வேண்டும், நீங்கள் அத்தகைய மற்றும் அத்தகைய வகுப்பின் நிலையான தொகுதிகளை வைத்திருக்க வேண்டும், அவை அத்தகைய மற்றும் அத்தகைய முனைகளில் அமைந்துள்ளன. அத்தகைய மற்றும் அத்தகைய உள்ளூர் சேமிப்பக வகுப்பு தேவைப்படும் காய்கள் லேபிள்களைப் பயன்படுத்தி அத்தகைய மற்றும் அத்தகைய முனைகளுக்கு மட்டுமே அனுப்பப்பட வேண்டும் என்பதை நீங்கள் குபெர்னெட்டஸுக்கு விளக்க வேண்டும். இந்த நோக்கங்களுக்காக, ஆபரேட்டருக்கு சில வகையான லேபிளை ஒதுக்கும் திறன் உள்ளது மற்றும் ஒரு ஹோஸ்ட் நிகழ்விற்கு ஒன்று. தேவைகள், லேபிள்கள், எளிமையான சொற்களில் மட்டுமே இயங்கும் வகையில் குபெர்னெட்ஸால் காய்கள் வழியமைக்கப்படும். நிர்வாகிகள் லேபிள்கள் மற்றும் வட்டுகளை கைமுறையாக ஒதுக்குகிறார்கள். பின்னர் அது செதில்கள்.
மூன்றாவது விருப்பம் உள்ளூர் அதை கொஞ்சம் எளிதாக்க உதவுகிறது. நான் ஏற்கனவே வலியுறுத்தியபடி, இது ஒரு கடினமான டியூனிங் வேலை, இது இறுதியில் அதிகபட்ச செயல்திறனைப் பெற உதவுகிறது.
இது தொடர்பாக எனக்கு இரண்டாவது கேள்வி உள்ளது. நாம் ஒரு முனையை இழக்கிறோமா இல்லையா என்பது நமக்கு முக்கியமில்லாத வகையில் குபெர்னெட்டஸ் வடிவமைக்கப்பட்டுள்ளது. இந்த விஷயத்தில் நாம் என்ன செய்ய வேண்டும், நமது துண்டு தொங்கும் முனையை நாம் இழந்திருந்தால்?
ஆம், குபெர்னெட்டஸ் ஆரம்பத்தில் எங்கள் காய்களுடனான எங்கள் உறவு கால்நடைகளைப் போன்றது என்று நிலைநிறுத்தப்பட்டது, ஆனால் இங்கே எங்களுடன் ஒவ்வொரு வட்டும் ஒரு செல்லப்பிள்ளை போல் மாறிவிடும். நாம் அவர்களை தூக்கி எறிய முடியாத அளவுக்கு ஒரு சிக்கல் உள்ளது. மேலும் குபெர்னெட்டஸின் வளர்ச்சி முற்றிலும் நிராகரிக்கப்பட்ட வளத்தைப் போல, அதை முற்றிலும் தத்துவ ரீதியாக நடத்துவது சாத்தியமில்லை என்ற திசையில் செல்கிறது.
இப்போது ஒரு நடைமுறை கேள்வி. வட்டு இருந்த முனையை நீங்கள் இழந்தால் என்ன செய்வது? இங்கே பிரச்சினை உயர் மட்டத்தில் தீர்க்கப்படுகிறது. ClickHouse விஷயத்தில், உயர் மட்டத்தில் வேலை செய்யும் பிரதிகள் எங்களிடம் உள்ளன, அதாவது. கிளிக்ஹவுஸ் மட்டத்தில்.
விளைந்த மனநிலை என்ன? தரவு இழக்கப்படாமல் இருப்பதை உறுதிசெய்வதற்கு DevOps பொறுப்பாகும். அவர் நகலெடுப்பை சரியாக அமைக்க வேண்டும் மற்றும் நகலெடுப்பு இயங்குவதை உறுதி செய்ய வேண்டும். ClickHouse மட்டத்தில் உள்ள பிரதியானது நகல் தரவுகளைக் கொண்டிருக்க வேண்டும். இது ஆபரேட்டர் தீர்க்கும் பணி அல்ல. குபெர்னெட்டஸ் தானே தீர்க்கும் பிரச்சனை அல்ல. இது கிளிக்ஹவுஸ் மட்டத்தில் உள்ளது.
உங்கள் இரும்பு முனை விழுந்தால் என்ன செய்வது? இரண்டாவது ஒன்றை வைப்பது, வட்டை சரியாக நகர்த்துவது, லேபிள்களைப் பயன்படுத்துவது அவசியம் என்று மாறிவிடும். அதன் பிறகு, குபெர்னெட்ஸ் ஒரு பாட் நிகழ்வை இயக்கக்கூடிய தேவைகளை இது பூர்த்தி செய்யும். குபெர்னெட்ஸ் அதைத் தொடங்குவார். உங்கள் காய்களின் எண்ணிக்கை குறிப்பிட்டதை விட போதுமானதாக இல்லை. நான் காட்டிய சுழற்சியில் அது செல்லும். மிக உயர்ந்த மட்டத்தில், எங்களிடம் ஒரு பிரதி உள்ளது என்பதை கிளிக்ஹவுஸ் புரிந்து கொள்ளும், அது இன்னும் காலியாக உள்ளது மற்றும் அதற்கு தரவை மாற்றத் தொடங்க வேண்டும். அந்த. இந்த செயல்முறை இன்னும் மோசமாக தானியக்கமாக உள்ளது.
அறிக்கைக்கு நன்றி! எல்லா வகையான மோசமான விஷயங்கள் நடக்கும்போது, ஆபரேட்டர் செயலிழந்து மறுதொடக்கம் செய்யப்படுகிறது, அந்த நேரத்தில் நிகழ்வுகள் வரும், நீங்கள் எப்படியாவது இதைச் செய்கிறீர்களா?
ஆபரேட்டர் செயலிழந்து மறுதொடக்கம் செய்தால் என்ன நடக்கும், இல்லையா?
ஆம். அந்த நேரத்தில் நிகழ்வுகள் வந்தன.
இந்த விஷயத்தில் என்ன செய்வது என்பது ஆபரேட்டருக்கும் குபெர்னெட்டஸுக்கும் இடையில் ஓரளவு பகிர்ந்து கொள்ளப்படுகிறது. நடந்த நிகழ்வை மீண்டும் இயக்கும் திறன் குபெர்னெட்டஸுக்கு உள்ளது. அவர் மீண்டும் இயக்குகிறார். மேலும், நிகழ்வுப் பதிவு அவர் மீது மீண்டும் இயக்கப்படும்போது, இந்த நிகழ்வுகள் செயலற்றவை என்பதை உறுதிப்படுத்துவதே ஆபரேட்டரின் பணியாகும். மேலும் ஒரே நிகழ்வு மீண்டும் மீண்டும் நிகழும் நமது அமைப்பு உடைந்து விடாது. எங்கள் ஆபரேட்டர் இந்த பணியை சமாளிக்கிறார்.
வணக்கம்! அறிக்கைக்கு நன்றி! டிமிட்ரி ஜவியாலோவ், நிறுவனம் ஸ்மெடோவ். ஆபரேட்டருக்கு ஹாப்ராக்ஸியுடன் தனிப்பயனாக்குதல் விருப்பங்களைச் சேர்க்க திட்டமிடப்பட்டுள்ளதா? நிலையான ஒன்றைத் தவிர வேறு சில பேலன்சர்கள் சுவாரஸ்யமாக உள்ளன, இதனால் அது புத்திசாலித்தனமானது மற்றும் கிளிக்ஹவுஸ் உண்மையானது என்பதை புரிந்துகொள்கிறது.
நீங்கள் உள் நுழைவதைப் பற்றி பேசுகிறீர்களா?
ஆம், இன்க்ரெஸ்ஸை ஹாப்ராக்ஸியுடன் மாற்றவும். ஹாப்ராக்ஸியில், கிளஸ்டரின் இடவியலைக் குறிப்பிடலாம், அதில் பிரதிகள் உள்ளன.
நாங்கள் இன்னும் அதைப் பற்றி சிந்திக்கவில்லை. உங்களுக்கு இது தேவைப்பட்டால் மற்றும் அது ஏன் தேவை என்பதை விளக்கினால், அதை செயல்படுத்த முடியும், குறிப்பாக நீங்கள் பங்கேற்க விரும்பினால். விருப்பத்தை கருத்தில் கொள்வதில் நாங்கள் மகிழ்ச்சியடைவோம். குறுகிய பதில் இல்லை, தற்போது எங்களிடம் அத்தகைய செயல்பாடு இல்லை. உதவிக்குறிப்புக்கு நன்றி, நாங்கள் இந்த விஷயத்தைப் பார்ப்போம். நீங்கள் பயன்பாட்டு வழக்கையும் விளக்கினால், நடைமுறையில் இது ஏன் தேவைப்படுகிறது, எடுத்துக்காட்டாக, GitHub இல் சிக்கல்களை உருவாக்கினால், அது நன்றாக இருக்கும்.
ஏற்கனவே உள்ளது.
நன்றாக. எந்த ஆலோசனைகளுக்கும் நாங்கள் தயாராக இருக்கிறோம். மற்றும் ஹாப்ராக்ஸி டோடோ பட்டியலில் சேர்க்கப்பட்டுள்ளது. டோடோ பட்டியல் வளர்ந்து வருகிறது, இன்னும் சுருங்கவில்லை. ஆனால் இது நல்லது, தயாரிப்பு தேவை என்று அர்த்தம்.
ஆதாரம்: www.habr.com