எனது பெயர் விக்டர் யாகோஃபரோவ், நான் ஓப்ஸ் (செயல்பாடு) குழுவில் தொழில்நுட்ப மேம்பாட்டு மேலாளராக DomClick இல் Kubernetes இயங்குதளத்தை உருவாக்கி வருகிறேன். எங்கள் Dev <-> Ops செயல்முறைகளின் கட்டமைப்பு, ரஷ்யாவில் உள்ள மிகப்பெரிய k8s கிளஸ்டர்களில் ஒன்றை இயக்கும் அம்சங்கள் மற்றும் எங்கள் குழு பயன்படுத்தும் DevOps/SRE நடைமுறைகள் பற்றி நான் பேச விரும்புகிறேன்.
Ops குழு
Ops குழுவில் தற்போது 15 பேர் உள்ளனர். அவர்களில் மூன்று பேர் அலுவலகத்திற்கு பொறுப்பு, இருவர் வெவ்வேறு நேர மண்டலத்தில் வேலை செய்கிறார்கள் மற்றும் இரவு உட்பட கிடைக்கும். எனவே, Ops ஐச் சேர்ந்த ஒருவர் எப்போதும் மானிட்டரில் இருப்பார் மற்றும் எந்தவொரு சிக்கலான சம்பவத்திற்கும் பதிலளிக்கத் தயாராக இருக்கிறார். எங்களிடம் இரவு ஷிப்டுகள் இல்லை, இது எங்கள் ஆன்மாவைப் பாதுகாக்கிறது மற்றும் அனைவருக்கும் போதுமான தூக்கத்தைப் பெறவும், கணினியில் மட்டுமல்ல ஓய்வு நேரத்தை செலவிடவும் வாய்ப்பளிக்கிறது.
ஒவ்வொருவருக்கும் வெவ்வேறு திறன்கள் உள்ளன: நெட்வொர்க்கர்கள், DBAக்கள், ELK ஸ்டாக் நிபுணர்கள், குபெர்னெட்ஸ் நிர்வாகிகள்/டெவலப்பர்கள், கண்காணிப்பு, மெய்நிகராக்கம், வன்பொருள் வல்லுநர்கள் போன்றவை. ஒரு விஷயம் அனைவரையும் ஒன்றிணைக்கிறது - அனைவரும் நம்மில் யாரையும் ஓரளவிற்கு மாற்றலாம்: எடுத்துக்காட்டாக, k8s கிளஸ்டரில் புதிய முனைகளை அறிமுகப்படுத்துங்கள், PostgreSQL ஐப் புதுப்பிக்கவும், CI/CD + Ansible பைப்லைனை எழுதவும், பைதான்/பாஷ்/கோவில் எதையாவது தானியங்குபடுத்தவும், வன்பொருளை இணைக்கவும் தகவல் மையம். எந்தவொரு பகுதியிலும் வலுவான திறன்கள் உங்கள் செயல்பாட்டின் திசையை மாற்றுவதைத் தடுக்காது மற்றும் வேறு சில பகுதிகளை மேம்படுத்தத் தொடங்குகின்றன. எடுத்துக்காட்டாக, நான் ஒரு நிறுவனத்தில் PostgreSQL நிபுணராக சேர்ந்தேன், இப்போது எனது முக்கிய பொறுப்பு குபெர்னெட்ஸ் கிளஸ்டர்கள். அணியில், எந்த உயரமும் வரவேற்கத்தக்கது மற்றும் அந்நிய உணர்வு மிகவும் வளர்ந்தது.
மூலம், நாங்கள் வேட்டையாடுகிறோம். வேட்பாளர்களுக்கான தேவைகள் மிகவும் நிலையானவை. தனிப்பட்ட முறையில் என்னைப் பொறுத்தவரை, ஒரு நபர் அணியில் பொருந்துவது முக்கியம், முரண்படாதவர், ஆனால் அவரது பார்வையை எவ்வாறு பாதுகாப்பது என்பதும் தெரியும், வளர விரும்புகிறார் மற்றும் புதிதாக ஏதாவது செய்ய பயப்படுவதில்லை, அவரது யோசனைகளை வழங்குகிறார். மேலும், ஸ்கிரிப்டிங் மொழிகளில் நிரலாக்கத் திறன், லினக்ஸ் மற்றும் ஆங்கிலத்தின் அடிப்படைகள் பற்றிய அறிவு தேவை. ஆங்கிலம் தேவைப்படுவதால், ஃபேகாப் ஏற்பட்டால், 10 நிமிடங்களில் அல்ல, 10 வினாடிகளில் கூகிள் மூலம் பிரச்சினைக்கு தீர்வு காண முடியும். லினக்ஸைப் பற்றிய ஆழமான அறிவைக் கொண்ட நிபுணர்களைக் கண்டுபிடிப்பது இப்போது மிகவும் கடினம்: இது வேடிக்கையானது, ஆனால் மூன்று வேட்பாளர்களில் இருவர் "சுமை சராசரி என்றால் என்ன?" என்ற கேள்விக்கு பதிலளிக்க முடியாது. இது எதனால் ஆனது?", மற்றும் "சி புரோகிராமில் இருந்து ஒரு கோர் டம்பை எவ்வாறு அசெம்பிள் செய்வது" என்ற கேள்வி, மனிதநேயமற்ற மனிதர்களின்... அல்லது டைனோசர்களின் உலகத்திலிருந்து வந்ததாகக் கருதப்படுகிறது. இதை நாம் சகித்துக்கொள்ள வேண்டும், ஏனென்றால் பொதுவாக மக்கள் மற்ற திறன்களை மிகவும் வளர்த்துக் கொண்டுள்ளனர், ஆனால் நாங்கள் லினக்ஸ் கற்பிப்போம். "மேகங்களின் நவீன உலகில் ஒரு DevOps பொறியாளர் இதையெல்லாம் ஏன் தெரிந்து கொள்ள வேண்டும்" என்ற கேள்விக்கான பதில் கட்டுரையின் நோக்கத்திற்கு வெளியே விடப்பட வேண்டும், ஆனால் மூன்று வார்த்தைகளில்: இவை அனைத்தும் தேவை.
குழு கருவிகள்
கருவிகள் குழு ஆட்டோமேஷனில் குறிப்பிடத்தக்க பங்கு வகிக்கிறது. டெவலப்பர்களுக்கு வசதியான வரைகலை மற்றும் CLI கருவிகளை உருவாக்குவதே அவர்களின் முக்கிய பணி. எடுத்துக்காட்டாக, ஒரு சில மவுஸ் கிளிக்குகளில் குபெர்னெட்டஸுக்கு ஒரு பயன்பாட்டை நேரடியாக வெளியிடவும், அதன் ஆதாரங்களை உள்ளமைக்கவும், பெட்டகத்திலிருந்து விசைகள் போன்றவற்றை அமைக்கவும் எங்கள் உள் மேம்பாட்டு மாநாடு உங்களை அனுமதிக்கிறது. முன்பு, ஜென்கின்ஸ் + ஹெல்ம் 2 இருந்தது, ஆனால் நகல்-பேஸ்ட்டை அகற்றவும், மென்பொருள் வாழ்க்கைச் சுழற்சியில் சீரான தன்மையைக் கொண்டுவரவும் எனது சொந்த கருவியை நான் உருவாக்க வேண்டியிருந்தது.
Ops குழு டெவலப்பர்களுக்காக பைப்லைன்களை எழுதுவதில்லை, ஆனால் அவர்கள் எழுதுவதில் ஏதேனும் சிக்கல்கள் இருந்தால் ஆலோசனை செய்யலாம் (சிலரிடம் இன்னும் ஹெல்ம் 3 உள்ளது).
DevOps
DevOps ஐப் பொறுத்தவரை, நாங்கள் இதைப் பார்க்கிறோம்:
தேவ் குழுக்கள் குறியீட்டை எழுதுகின்றன, கான்ஃபர் டு dev -> qa/stage -> prod. குறியீட்டின் வேகம் குறையாது மற்றும் பிழைகள் இல்லை என்பதை உறுதி செய்யும் பொறுப்பு Dev மற்றும் Ops அணிகளுக்கு உள்ளது. பகல் நேரத்தில், Ops குழுவில் இருந்து பணியில் இருப்பவர் முதலில் ஒரு சம்பவத்திற்கு தனது விண்ணப்பத்துடன் பதிலளிக்க வேண்டும், மேலும் மாலை மற்றும் இரவில், கடமையில் உள்ள நிர்வாகி (Ops) டெவலப்பருக்குத் தெரிந்தால் அவரை எழுப்ப வேண்டும். பிரச்சனை உள்கட்டமைப்பில் இல்லை என்பது உறுதி. கண்காணிப்பில் உள்ள அனைத்து அளவீடுகளும் விழிப்பூட்டல்களும் தானாகவோ அல்லது அரை தானாகவோ தோன்றும்.
ஆப்ஸின் பொறுப்புப் பகுதியானது, விண்ணப்பம் உற்பத்திக்கு வந்த தருணத்திலிருந்து தொடங்குகிறது, ஆனால் தேவ்வின் பொறுப்பு அங்கு முடிவடையவில்லை - நாங்கள் அதையே செய்கிறோம், அதே படகில் இருக்கிறோம்.
நிர்வாகி மைக்ரோ சர்வீஸ் (உதாரணமாக, Go backend + HTML5) எழுத உதவி தேவைப்பட்டால், டெவலப்பர்கள் நிர்வாகிகளுக்கு ஆலோசனை வழங்குகிறார்கள், மேலும் எந்த உள்கட்டமைப்பு சிக்கல்கள் அல்லது k8s தொடர்பான சிக்கல்கள் குறித்து நிர்வாகிகள் டெவலப்பர்களுக்கு ஆலோசனை வழங்குகிறார்கள்.
மூலம், எங்களிடம் ஒரு ஒற்றைப்பாதை இல்லை, மைக்ரோ சர்வீஸ்கள் மட்டுமே. அவற்றின் எண்ணிக்கை இதுவரை 900 முதல் 1000 வரை ப்ராட் கே8எஸ் கிளஸ்டரில் ஏற்ற இறக்கமாக இருக்கும், எண்ணால் அளந்தால் வரிசைப்படுத்தல். காய்களின் எண்ணிக்கை 1700 முதல் 2000 வரை ஏற்ற இறக்கமாக உள்ளது. தற்போது 2000 காய்கள் ப்ரொட் கிளஸ்டரில் உள்ளன.
தேவையற்ற மைக்ரோ சர்வீஸ்களை நாங்கள் கண்காணித்து, அரை தானாக வெட்டி விடுவதால், சரியான எண்களை என்னால் கொடுக்க முடியாது. K8s தேவையற்ற நிறுவனங்களைக் கண்காணிக்க உதவுகிறது , இது நிறைய வளங்களையும் பணத்தையும் மிச்சப்படுத்துகிறது.
வள மேலாண்மை
கண்காணிப்பு
நன்கு கட்டமைக்கப்பட்ட மற்றும் தகவலறிந்த கண்காணிப்பு ஒரு பெரிய கிளஸ்டரின் செயல்பாட்டில் மூலக்கல்லாகும். அனைத்து கண்காணிப்புத் தேவைகளிலும் 100% உள்ளடக்கும் உலகளாவிய தீர்வை நாங்கள் இன்னும் கண்டுபிடிக்கவில்லை, எனவே இந்த சூழலில் அவ்வப்போது வெவ்வேறு தனிப்பயன் தீர்வுகளை உருவாக்குகிறோம்.
- Zabbix. நல்ல பழைய கண்காணிப்பு, இது முதன்மையாக உள்கட்டமைப்பின் ஒட்டுமொத்த நிலையைக் கண்காணிக்கும் நோக்கம் கொண்டது. செயலாக்கம், நினைவகம், வட்டுகள், நெட்வொர்க் மற்றும் பலவற்றின் அடிப்படையில் ஒரு முனை இறக்கும் போது இது நமக்குச் சொல்கிறது. இயற்கைக்கு அப்பாற்பட்ட எதுவும் இல்லை, ஆனால் எங்களிடம் தனியான டீமான்செட் ஏஜெண்டுகள் உள்ளன, இதன் உதவியுடன், எடுத்துக்காட்டாக, கிளஸ்டரில் உள்ள டிஎன்எஸ் நிலையை நாங்கள் கண்காணிக்கிறோம்: முட்டாள்தனமான கோர்டன்ஸ் காய்களைத் தேடுகிறோம், வெளிப்புற ஹோஸ்ட்களின் கிடைக்கும் தன்மையை நாங்கள் சரிபார்க்கிறோம். இதைப் பற்றி ஏன் கவலைப்பட வேண்டும் என்று தோன்றுகிறது, ஆனால் பெரிய அளவிலான போக்குவரத்துடன் இந்த கூறு தோல்வியின் தீவிர புள்ளியாகும். ஏற்கனவே நான் , ஒரு கிளஸ்டரில் DNS செயல்திறனுடன் நான் எப்படி போராடினேன்.
- ப்ரோமிதியஸ் ஆபரேட்டர். வெவ்வேறு ஏற்றுமதியாளர்களின் தொகுப்பு, கிளஸ்டரின் அனைத்து கூறுகளின் பெரிய கண்ணோட்டத்தை அளிக்கிறது. அடுத்து, கிராஃபனாவில் உள்ள பெரிய டாஷ்போர்டுகளில் இவை அனைத்தையும் காட்சிப்படுத்துகிறோம், மேலும் விழிப்பூட்டல்களுக்கு எச்சரிக்கை மேலாளரைப் பயன்படுத்துகிறோம்.
எங்களுக்கு மற்றொரு பயனுள்ள கருவி . ஒரு குழு மற்றொரு அணியின் நுழைவுப் பாதைகளை ஒன்றுடன் ஒன்று இணைக்கும் சூழ்நிலையை நாங்கள் பல முறை சந்தித்த பிறகு அதை எழுதினோம், இதன் விளைவாக 50x பிழைகள் ஏற்பட்டன. இப்போது உற்பத்தியைப் பயன்படுத்துவதற்கு முன், டெவலப்பர்கள் யாரும் பாதிக்கப்படமாட்டார்கள் என்பதைச் சரிபார்க்கிறார்கள், மேலும் எனது குழுவிற்கு இது இன்க்ரெஸ்ஸில் உள்ள சிக்கல்களை ஆரம்ப கண்டறிவதற்கான ஒரு சிறந்த கருவியாகும். முதலில் இது நிர்வாகிகளுக்காக எழுதப்பட்டது மற்றும் அது "விகாரமானதாக" தோன்றியது, ஆனால் தேவ் குழுக்கள் கருவியைக் காதலித்த பிறகு, அது நிறைய மாறியது மற்றும் "ஒரு நிர்வாகி நிர்வாகிகளுக்காக ஒரு வலை முகத்தை உருவாக்கியது போல் இல்லை" என்பது வேடிக்கையானது. ” விரைவில் இந்த கருவியை நாங்கள் கைவிடுவோம், மேலும் குழாய் அமைக்கப்படுவதற்கு முன்பே இதுபோன்ற சூழ்நிலைகள் சரிபார்க்கப்படும்.
கியூப்பில் குழு வளங்கள்
எடுத்துக்காட்டுகளுக்குள் செல்வதற்கு முன், வளங்களை எவ்வாறு ஒதுக்குகிறோம் என்பதை விளக்குவது மதிப்பு நுண் சேவைகள்.
எந்த அணிகள் மற்றும் எந்த அளவுகளில் அவற்றைப் பயன்படுத்துகின்றன என்பதைப் புரிந்து கொள்ள வளங்கள் (செயலி, நினைவகம், உள்ளூர் SSD), ஒவ்வொரு கட்டளையையும் அதன் சொந்தமாக ஒதுக்குகிறோம் பெயர்வெளி "கியூப்" இல் மற்றும் செயலி, நினைவகம் மற்றும் வட்டு ஆகியவற்றின் அடிப்படையில் அதன் அதிகபட்ச திறன்களை கட்டுப்படுத்துகிறது, முன்பு அணிகளின் தேவைகளைப் பற்றி விவாதித்தது. அதன்படி, ஒரு கட்டளை, பொதுவாக, வரிசைப்படுத்துவதற்கு முழு கிளஸ்டரையும் தடுக்காது, ஆயிரக்கணக்கான கோர்கள் மற்றும் டெராபைட் நினைவகத்தை ஒதுக்குகிறது. பெயர்வெளிக்கான அணுகல் AD மூலம் வழங்கப்படுகிறது (நாங்கள் RBAC ஐப் பயன்படுத்துகிறோம்). பெயர்வெளிகளும் அவற்றின் வரம்புகளும் ஜிஐடி களஞ்சியத்திற்கு இழுக்கும் கோரிக்கையின் மூலம் சேர்க்கப்படும், பின்னர் அனைத்தும் தானாகவே அன்சிபிள் பைப்லைன் மூலம் உருட்டப்படும்.
ஒரு குழுவிற்கு வளங்களை ஒதுக்குவதற்கான எடுத்துக்காட்டு:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
கோரிக்கைகள் மற்றும் வரம்புகள்
கனசதுர" வேண்டுகோள் உத்தரவாதமான ஒதுக்கப்பட்ட வளங்களின் எண்ணிக்கை நெற்று (ஒன்று அல்லது அதற்கு மேற்பட்ட டாக்கர் கொள்கலன்கள்) ஒரு கிளஸ்டரில். வரம்பு என்பது உத்தரவாதமில்லாத அதிகபட்சம். சில குழுக்கள் அதன் அனைத்து பயன்பாடுகளுக்கும் பல கோரிக்கைகளை எவ்வாறு அமைத்துள்ளன என்பதை நீங்கள் அடிக்கடி வரைபடங்களில் காணலாம் மற்றும் பயன்பாட்டை "கியூப்" க்கு அனுப்ப முடியாது, ஏனெனில் அவர்களின் பெயர்வெளியில் உள்ள அனைத்து கோரிக்கைகளும் ஏற்கனவே "செலவிடப்பட்டுள்ளன".
இந்த சூழ்நிலையிலிருந்து வெளியேறுவதற்கான சரியான வழி, உண்மையான வள நுகர்வுகளைப் பார்த்து, கோரப்பட்ட தொகையுடன் (கோரிக்கை) ஒப்பிடுவதாகும்.
மேலே உள்ள ஸ்கிரீன்ஷாட்களில், "கோரிக்கை" CPUகள் உண்மையான நூல்களின் எண்ணிக்கையுடன் பொருந்துவதைக் காணலாம், மேலும் வரம்புகள் உண்மையான CPU த்ரெட்களின் எண்ணிக்கையை விட அதிகமாக இருக்கலாம் =)
இப்போது சில பெயர்வெளிகளை விரிவாகப் பார்ப்போம் (நான் நேம்ஸ்பேஸ் க்யூப்-சிஸ்டம் - “கியூப்” இன் கூறுகளுக்கான கணினி பெயர்வெளியைத் தேர்ந்தெடுத்தேன்) மற்றும் கோரப்பட்டதற்கு உண்மையில் பயன்படுத்தப்பட்ட செயலி நேரம் மற்றும் நினைவகத்தின் விகிதத்தைப் பார்ப்போம்:
உண்மையில் பயன்படுத்தப்படுவதை விட அதிக நினைவகம் மற்றும் CPU ஆகியவை கணினி சேவைகளுக்கு ஒதுக்கப்பட்டுள்ளது என்பது தெளிவாகிறது. kube-system ஐப் பொறுத்தவரை, இது நியாயமானது: nginx இன்க்ரஸ் கன்ட்ரோலர் அல்லது nodelocaldns உச்சநிலையில் CPU ஐத் தாக்கி நிறைய RAM ஐ உட்கொண்டது, எனவே இங்கே அத்தகைய இருப்பு நியாயமானது. கூடுதலாக, கடந்த 3 மணிநேரங்களுக்கு நாங்கள் விளக்கப்படங்களை நம்பியிருக்க முடியாது: ஒரு பெரிய காலத்திற்கு வரலாற்று அளவீடுகளைப் பார்ப்பது விரும்பத்தக்கது.
"பரிந்துரைகள்" அமைப்பு உருவாக்கப்பட்டது. எடுத்துக்காட்டாக, "வரம்புகளை" (அனுமதிக்கப்பட்ட மேல் பட்டை) உயர்த்துவது எந்த வளங்கள் சிறப்பாக இருக்கும் என்பதை இங்கே நீங்கள் பார்க்கலாம், இதனால் "த்ரோட்லிங்" ஏற்படாது: ஒரு வளம் ஏற்கனவே CPU அல்லது நினைவகத்தை ஒதுக்கப்பட்ட நேரத்தில் செலவழித்த தருணம் மற்றும் அது "உறையாமல்" இருக்கும் வரை காத்திருக்கிறது:
அவர்களின் பசியைக் கட்டுப்படுத்தும் காய்கள் இங்கே:
பற்றி திணறல் + வள கண்காணிப்பு, நீங்கள் ஒன்றுக்கு மேற்பட்ட கட்டுரைகளை எழுதலாம், எனவே கருத்துகளில் கேள்விகளைக் கேளுங்கள். சில வார்த்தைகளில், அத்தகைய அளவீடுகளை தானியங்குபடுத்தும் பணி மிகவும் கடினமானது மற்றும் "சாளர" செயல்பாடுகள் மற்றும் "CTE" Prometheus / VictoriaMetrics (இந்த விதிமுறைகள் மேற்கோள்களில் இருப்பதால், நிறைய நேரம் மற்றும் சமநிலைப்படுத்துதல் தேவை என்று நான் கூறலாம். PromQL இல் இது போன்ற எதுவும் இல்லை, மேலும் நீங்கள் பயமுறுத்தும் வினவல்களை உரையின் பல திரைகளாகப் பிரித்து அவற்றை மேம்படுத்த வேண்டும்).
இதன் விளைவாக, டெவலப்பர்கள் க்யூப்பில் தங்கள் பெயர்வெளிகளைக் கண்காணிப்பதற்கான கருவிகளைக் கொண்டுள்ளனர், மேலும் எந்தெந்த பயன்பாடுகள் எந்தெந்தப் பயன்பாடுகள் தங்கள் வளங்களை "வெட்டலாம்" மற்றும் எந்தெந்த சேவையகங்கள் முழு CPU-ஐ இரவு முழுவதும் வழங்கலாம் என்பதை அவர்களே தேர்வுசெய்ய முடியும்.
முறைகள்
இப்போது உள்ள நிறுவனத்தில் நாகரீகமான, நாங்கள் DevOps- மற்றும் SRE- பயிற்சியாளர் ஒரு நிறுவனத்தில் 1000 மைக்ரோ சர்வீஸ்கள், சுமார் 350 டெவலப்பர்கள் மற்றும் முழு உள்கட்டமைப்புக்கு 15 நிர்வாகிகள் இருந்தால், நீங்கள் "நாகரீகமாக" இருக்க வேண்டும்: இந்த அனைத்து "பேஸ்வேர்டுகளுக்கும்" பின்னால் அனைத்தையும் தானியங்குபடுத்த வேண்டிய அவசர தேவை உள்ளது, மேலும் நிர்வாகிகள் ஒரு இடையூறாக இருக்கக்கூடாது. செயல்முறைகளில்.
Ops ஆக, சேவை மறுமொழி விகிதங்கள் மற்றும் பிழைகள் தொடர்பான டெவலப்பர்களுக்கு பல்வேறு அளவீடுகள் மற்றும் டாஷ்போர்டுகளை வழங்குகிறோம்.
நாங்கள் பின்வரும் முறைகளைப் பயன்படுத்துகிறோம்: , и அவற்றை ஒன்றாக இணைப்பதன் மூலம். டாஷ்போர்டுகளின் எண்ணிக்கையைக் குறைக்க முயற்சிப்போம், இதன் மூலம் எந்தச் சேவை தற்போது சீரழிந்து வருகிறது என்பது ஒரு பார்வையில் தெளிவாகத் தெரியும் (உதாரணமாக, வினாடிக்கு மறுமொழி குறியீடுகள், மறுமொழி நேரம் 99 சதவீதம்) மற்றும் பல. பொதுவான டாஷ்போர்டுகளுக்கு சில புதிய அளவீடுகள் அவசியமானால், உடனடியாக அவற்றை வரைந்து சேர்க்கிறோம்.
நான் ஒரு மாதமாக வரைபடங்கள் வரையவில்லை. இது அநேகமாக ஒரு நல்ல அறிகுறியாகும்: இதன் பொருள் பெரும்பாலான "விருப்பங்கள்" ஏற்கனவே உணரப்பட்டுள்ளன. வாரத்தில் ஒரு நாளுக்கு ஒரு முறையாவது புதிய வரைபடத்தை வரைந்தேன்.
இதன் விளைவாக பெறப்பட்ட முடிவு மதிப்புமிக்கது, ஏனெனில் இப்போது டெவலப்பர்கள் "ஒருவித மெட்ரிக்கை எங்கே பார்க்க வேண்டும்" என்ற கேள்விகளுடன் நிர்வாகிகளிடம் மிகவும் அரிதாகவே செல்கிறார்கள்.
அறிமுகம் சேவை மெஷ் இது ஒரு மூலையில் உள்ளது மற்றும் அனைவருக்கும் வாழ்க்கையை மிகவும் எளிதாக்க வேண்டும், கருவிகளின் சக பணியாளர்கள் "ஆரோக்கியமான நபரின் இஸ்டியோ" என்ற சுருக்கத்தை செயல்படுத்துவதற்கு ஏற்கனவே நெருக்கமாக உள்ளனர்: ஒவ்வொரு HTTP(கள்) கோரிக்கையின் வாழ்க்கைச் சுழற்சியும் கண்காணிப்பில் தெரியும், மேலும் அது இடை-சேவை (மற்றும் மட்டுமல்ல) தொடர்புகளின் போது "எந்த கட்டத்தில் எல்லாம் உடைந்தது" என்பதை எப்போதும் புரிந்து கொள்ள முடியும். DomClick மையத்திலிருந்து செய்திகளுக்கு குழுசேரவும். =)
குபெர்னெட்ஸ் உள்கட்டமைப்பு ஆதரவு
வரலாற்று ரீதியாக, நாம் இணைக்கப்பட்ட பதிப்பைப் பயன்படுத்துகிறோம் குபேஸ்ப்ரே - குபெர்னெட்ஸை வரிசைப்படுத்துதல், நீட்டித்தல் மற்றும் புதுப்பித்தல் ஆகியவற்றில் முக்கிய பங்கு. ஒரு கட்டத்தில், kubeadm அல்லாத நிறுவல்களுக்கான ஆதரவு பிரதான கிளையிலிருந்து துண்டிக்கப்பட்டது, மேலும் kubeadm க்கு மாறுவதற்கான செயல்முறை முன்மொழியப்படவில்லை. இதன் விளைவாக, சவுத்பிரிட்ஜ் நிறுவனம் அதன் சொந்த ஃபோர்க்கை உருவாக்கியது (குபீட்ம் ஆதரவுடன் மற்றும் முக்கியமான பிரச்சனைகளுக்கு விரைவான தீர்வு).
அனைத்து k8s கிளஸ்டர்களையும் புதுப்பிப்பதற்கான செயல்முறை இதுபோல் தெரிகிறது:
- எடுத்து குபேஸ்ப்ரே சவுத்பிரிட்ஜில் இருந்து, எங்கள் த்ரெட், மெர்ஜிம் மூலம் சரிபார்க்கவும்.
- நாங்கள் புதுப்பித்தலை வெளியிடுகிறோம் மன அழுத்தம்- "கன".
- ஒரு நேரத்தில் ஒரு முனையில் புதுப்பிப்பை வெளியிடுகிறோம் (அன்சிபில் இது “தொடர்: 1”) தேவ்- "கன".
- நாங்கள் புதுப்பிக்கிறோம் ப்ரொடக்ஷன் சனிக்கிழமை மாலை ஒரு நேரத்தில் ஒரு முனை.
எதிர்காலத்தில் அதை மாற்றுவதற்கான திட்டங்கள் உள்ளன குபேஸ்ப்ரே ஏதாவது வேகமாக மற்றும் செல்ல kubeadm.
மொத்தத்தில் எங்களிடம் மூன்று "க்யூப்கள்" உள்ளன: மன அழுத்தம், தேவ் மற்றும் ப்ராட். நாங்கள் இன்னொன்றைத் தொடங்க திட்டமிட்டுள்ளோம் (சூடான காத்திருப்பு) இரண்டாவது தரவு மையத்தில் தயாரிப்பு-“கியூப்”. மன அழுத்தம் и தேவ் "மெய்நிகர் இயந்திரங்களில்" வாழ்கின்றனர் (மன அழுத்தத்திற்கான oVirt மற்றும் தேவ்விற்கான VMWare கிளவுட்). ப்ரொடக்ஷன்- "கியூப்" "வெற்று உலோகத்தில்" வாழ்கிறது: இவை 32 CPU நூல்கள், 64-128 GB நினைவகம் மற்றும் 300 GB SSD RAID 10 கொண்ட ஒரே மாதிரியான முனைகள் - மொத்தம் 50 உள்ளன. மூன்று "மெல்லிய" முனைகள் "மாஸ்டர்களுக்கு" அர்ப்பணிக்கப்பட்டவை ப்ரொடக்ஷன்- “கியூபா”: 16 GB நினைவகம், 12 CPU நூல்கள்.
விற்பனைக்கு, "வெற்று உலோகத்தை" பயன்படுத்த விரும்புகிறோம் மற்றும் தேவையற்ற அடுக்குகளை தவிர்க்கிறோம் OpenStack க்குக்கான: எங்களுக்கு "சத்தமில்லாத அண்டை" மற்றும் CPU தேவையில்லை நேரத்தை திருடுகின்றனர். நிர்வாகத்தின் சிக்கலானது உள்-ஓபன்ஸ்டாக் விஷயத்தில் தோராயமாக இரட்டிப்பாகிறது.
CI/CD “க்யூபிக்” மற்றும் பிற உள்கட்டமைப்பு கூறுகளுக்கு, நாங்கள் ஹெல்ம் 3 என்ற தனி GIT சேவையகத்தைப் பயன்படுத்துகிறோம் (இது ஹெல்ம் 2 இலிருந்து மிகவும் வேதனையான மாற்றம், ஆனால் விருப்பங்களில் நாங்கள் மிகவும் மகிழ்ச்சியடைகிறோம். அணு), ஜென்கின்ஸ், அன்சிபிள் மற்றும் டோக்கர். ஒரு களஞ்சியத்திலிருந்து வெவ்வேறு சூழல்களுக்கு அம்சக் கிளைகள் மற்றும் வரிசைப்படுத்தலை நாங்கள் விரும்புகிறோம்.
முடிவுக்கு
இது, பொதுவாக, ஒரு செயல்பாட்டு பொறியாளரின் பார்வையில், DomClick இல் DevOps செயல்முறை எப்படி இருக்கும். கட்டுரை நான் எதிர்பார்த்ததை விட குறைவான தொழில்நுட்பமாக மாறியது: எனவே, Habré இல் DomClick செய்திகளைப் பின்தொடரவும்: Kubernetes மற்றும் பலவற்றைப் பற்றிய "ஹார்ட்கோர்" கட்டுரைகள் அதிகமாக இருக்கும்.
ஆதாரம்: www.habr.com