இன்று நான் எப்படி விண்ணப்பங்களை எழுதுவது மற்றும் குபெர்னெட்ஸில் உங்கள் விண்ணப்பம் நன்றாக வேலை செய்வதற்கு என்ன தேவைகள் என்பதைப் பற்றி பேச திட்டமிட்டுள்ளேன். பயன்பாட்டில் எந்த தலைவலியும் இல்லை, எனவே நீங்கள் அதைச் சுற்றி எந்த "கிராச்சுகளையும்" கண்டுபிடித்து உருவாக்க வேண்டியதில்லை - மேலும் அனைத்தும் குபெர்னெட்டஸ் விரும்பிய வழியில் செயல்படுகின்றன.
இந்த விரிவுரை "" மாலைப் பள்ளியின் திறந்த தத்துவார்த்த விரிவுரைகளை நீங்கள் பார்க்கலாம் . வீடியோவை விட உரையை விரும்புவோருக்கு, இந்த கட்டுரையை நாங்கள் தயார் செய்துள்ளோம்.
எனது பெயர் பாவெல் செலிவனோவ், தற்போது நான் Mail.ru Cloud Solutions இல் முன்னணி DevOps பொறியியலாளராக உள்ளேன், நாங்கள் மேகங்களை உருவாக்குகிறோம், நாங்கள் மேலாண்மை kubernetes ஐ உருவாக்குகிறோம் மற்றும் பல. எனது பணிகளில் இப்போது வளர்ச்சிக்கான உதவி, இந்த மேகங்களை உருட்டுதல், நாங்கள் எழுதும் பயன்பாடுகளை உருட்டுதல் மற்றும் எங்கள் பயனர்களுக்கு நாங்கள் வழங்கும் கருவிகளை நேரடியாக உருவாக்குதல் ஆகியவை அடங்கும்.
நான் DevOps செய்து வருகிறேன், கடந்த, அநேகமாக, மூன்று வருடங்களாக நான் நினைக்கிறேன். ஆனால், கொள்கையளவில், டெவொப்ஸ் செய்வதை நான் ஐந்து வருடங்களாக செய்து வருகிறேன். அதற்கு முன், நான் பெரும்பாலும் நிர்வாக விஷயங்களில் ஈடுபட்டிருந்தேன். நான் நீண்ட காலத்திற்கு முன்பு குபர்னெட்டஸுடன் வேலை செய்யத் தொடங்கினேன் - நான் அதனுடன் வேலை செய்யத் தொடங்கி சுமார் நான்கு ஆண்டுகள் கடந்துவிட்டன.
பொதுவாக, நான் குபெர்னெட்டஸ் பதிப்பு 1.3 ஆக இருந்தபோது தொடங்கினேன், ஒருவேளை, ஒருவேளை 1.2 - அது இன்னும் ஆரம்ப நிலையில் இருந்தபோது. இப்போது அது ஆரம்ப நிலையில் இல்லை - மேலும் குபெர்னெட்டஸைச் செய்ய விரும்பும் பொறியாளர்களுக்கு சந்தையில் பெரும் தேவை உள்ளது என்பது வெளிப்படையானது. மேலும் நிறுவனங்களுக்கு அத்தகைய நபர்களுக்கு மிக அதிக தேவை உள்ளது. எனவே, உண்மையில், இந்த விரிவுரை தோன்றியது.
நான் எதைப் பற்றி பேசுவேன் என்ற திட்டத்தின் படி நாம் பேசினால், அது இப்படித் தெரிகிறது, அடைப்புக்குறிக்குள் அது எழுதப்பட்டுள்ளது (TL;DR) - “மிக நீளமானது; படிக்காதே". இன்றைய எனது விளக்கக்காட்சி முடிவில்லா பட்டியல்களைக் கொண்டிருக்கும்.
உண்மையில், அத்தகைய விளக்கக்காட்சிகள் உருவாக்கப்படும்போது நானே விரும்புவதில்லை, ஆனால் இது ஒரு தலைப்பு, நான் இந்த விளக்கக்காட்சியைத் தயாரிக்கும் போது, இந்த தகவலை எவ்வாறு வித்தியாசமாக ஒழுங்கமைப்பது என்பதை நான் உண்மையில் கண்டுபிடிக்கவில்லை.
ஏனென்றால், இந்த தகவல் “ctrl+c, ctrl+v”, மற்றவற்றுடன், DevOps பிரிவில் உள்ள எங்கள் விக்கியில் இருந்து, டெவலப்பர்களுக்கான தேவைகளை நாங்கள் எழுதியுள்ளோம்: “நண்பர்களே, உங்கள் பயன்பாட்டை நாங்கள் தொடங்குகிறோம் குபர்னெட்ஸ், இது இப்படி இருக்க வேண்டும்."
அதனால்தான் விளக்கக்காட்சி இவ்வளவு பெரிய பட்டியலாக மாறியது. மன்னிக்கவும். முடிந்தால் போரடிக்காமல் இருக்க முடிந்தவரை சொல்ல முயற்சிக்கிறேன்.
நாம் இப்போது என்ன பார்க்கப் போகிறோம்:
- இவை முதலில், பதிவுகள் (விண்ணப்பப் பதிவுகள்?), குபெர்னெட்டஸில் அவற்றை என்ன செய்வது, அவற்றை என்ன செய்வது, அவை என்னவாக இருக்க வேண்டும்;
- குபெர்னெட்டஸில் உள்ள உள்ளமைவுகளை என்ன செய்வது, குபெர்னெட்டிற்கான பயன்பாட்டை உள்ளமைக்க சிறந்த மற்றும் மோசமான வழிகள் யாவை;
- அணுகல்தன்மை சரிபார்ப்புகள் பொதுவாக என்ன, அவை எப்படி இருக்க வேண்டும் என்பதைப் பற்றி பேசலாம்;
- ஒரு அழகான பணிநிறுத்தம் என்றால் என்ன என்பதைப் பற்றி பேசலாம்;
- வளங்களைப் பற்றி மீண்டும் பேசுவோம்;
- தரவு சேமிப்பகம் என்ற தலைப்பில் மீண்டும் ஒருமுறை தொடுவோம்;
- இந்த மர்மமான கிளவுட்-நேட்டிவ் அப்ளிகேஷன் என்னவென்று முடிவில் நான் உங்களுக்கு சொல்கிறேன். Cloudnativeness, இந்த வார்த்தையின் பெயரடை.
பதிவுகள்
பதிவுகளுடன் தொடங்க பரிந்துரைக்கிறேன் - இந்த பதிவுகளை குபெர்னெட்டஸில் எங்கு நகர்த்த வேண்டும். இப்போது நீங்கள் குபெர்னெட்ஸில் ஒரு பயன்பாட்டைத் தொடங்கியுள்ளீர்கள். கிளாசிக் படி, முந்தைய பயன்பாடுகள் எப்போதும் ஒரு கோப்பில் எங்காவது பதிவுகளை எழுதின. பயன்பாட்டைத் தொடங்கிய டெவலப்பரின் ஹோம் டைரக்டரியில் உள்ள ஒரு கோப்பிற்கு தவறான பயன்பாடுகள் பதிவுகளை எழுதின. நல்ல பயன்பாடுகள் எங்கோ உள்ள ஒரு கோப்பில் பதிவுகளை எழுதின /var/log.
அதன்படி, மேலும், நல்ல நிர்வாகிகள் தங்கள் உள்கட்டமைப்புகளில் இந்த பதிவுகளை சுழற்றக்கூடிய சில விஷயங்களைக் கட்டமைத்துள்ளனர் - அதே rsyslog, இந்த பதிவுகளைப் பார்த்து, அவற்றுக்கு ஏதாவது நேர்ந்தால், அவற்றில் நிறைய உள்ளன, அது காப்புப் பிரதிகளை உருவாக்குகிறது, பதிவுகளை அங்கே வைக்கிறது. , பழைய கோப்புகளை நீக்குகிறது, ஒரு வாரம், ஆறு மாதங்கள் மற்றும் இன்னும் சில. கோட்பாட்டில், பயன்பாடு பதிவுகளை எழுதுவதால், உற்பத்தி சேவையகங்களில் (போர் சேவையகங்கள்?) இடம் தீர்ந்துவிடாது. மேலும், அதன்படி, பதிவுகள் காரணமாக முழு உற்பத்தியும் நிறுத்தப்படவில்லை.
நாம் குபெர்னெட்டஸின் உலகத்திற்குச் சென்று அதையே அங்கு இயக்கும்போது, நீங்கள் கவனம் செலுத்தக்கூடிய முதல் விஷயம் என்னவென்றால், மக்கள், ஒரு கோப்பில் பதிவுகளை எழுதியது போல், அவற்றைத் தொடர்ந்து எழுதுகிறார்கள்.
குபெர்னெட்டஸைப் பற்றி நாம் பேசினால், டாக்கர் கொள்கலனில் இருந்து எங்காவது பதிவுகளை எழுதுவதற்கான சரியான இடம், பயன்பாட்டிலிருந்து Stdout/Stderr என்று அழைக்கப்படும், அதாவது, இயக்க முறைமையின் நிலையான வெளியீட்டு ஸ்ட்ரீம்களுக்கு எழுதுவதுதான். நிலையான பிழை வெளியீடு. டோக்கரில் மற்றும் குறிப்பாக குபெர்னெட்டிஸில் பதிவுகளை வைப்பதற்கான மிகவும் சரியான, எளிமையான மற்றும் மிகவும் தர்க்கரீதியான வழி இதுவாகும். ஏனெனில் உங்கள் விண்ணப்பம் Stdout/Stderr இல் பதிவுகளை எழுதினால், இந்தப் பதிவுகளை என்ன செய்வது என்று டோக்கர் மற்றும் குபெர்னெட்ஸ் ஆட்-ஆன் முடிவு செய்ய வேண்டும். டோக்கர் இயல்புநிலையாக அதன் சிறப்பு கோப்புகளை JSON வடிவத்தில் உருவாக்கும்.
இங்கே கேள்வி எழுகிறது, இந்த பதிவுகளை அடுத்து என்ன செய்வீர்கள்? எளிதான வழி தெளிவானது, நாம் செய்யக்கூடிய திறன் உள்ளது kubectl logs இந்த "காய்களின்" பதிவுகளைப் பாருங்கள். ஆனால், அநேகமாக, இது ஒரு நல்ல வழி அல்ல - பதிவுகளுடன் வேறு ஏதாவது செய்ய வேண்டும்.
இப்போதைக்கு, பதிவுகள் என்ற தலைப்பில் நாங்கள் தொட்டதால், பதிவுகள் போன்ற ஒரு விஷயத்தைப் பற்றி ஒரே நேரத்தில் பேசலாம். அதாவது, இது குபர்னெட்டஸுக்கு நேரடியாகப் பொருந்தாது, ஆனால் பதிவுகளை என்ன செய்வது என்று சிந்திக்கத் தொடங்கும் போது, இதைப் பற்றியும் சிந்திப்பது நல்லது.
ஒரு இணக்கமான வழியில், நமக்கு ஒரு வகையான கருவி தேவை, அது எங்கள் டாக்கர் அதன் கோப்புகளில் வைக்கும் இந்த பதிவுகளை எடுத்து எங்காவது அனுப்பும். பொதுவாக, குபெர்னெட்ஸிற்குள் டீமான்செட் வடிவில் சில வகையான ஏஜெண்டுகளை நாங்கள் தொடங்குவோம் - இது ஒரு பதிவு சேகரிப்பான், இது டோக்கர் சேகரிக்கும் பதிவுகள் எங்குள்ளது என்று எளிமையாகக் கூறப்படும். இந்த சேகரிப்பு முகவர் அவற்றை எடுத்துச் செல்கிறார், ஒருவேளை எப்படியாவது அவற்றைப் பாகுபடுத்தி, சில கூடுதல் மெட்டா தகவல்களுடன் அவற்றை வளப்படுத்தி, இறுதியில், அவற்றை எங்காவது சேமிப்பதற்காக அனுப்புகிறார். மாறுபாடுகள் ஏற்கனவே சாத்தியமாகும். மிகவும் பொதுவானது அநேகமாக Elasticsearch ஆகும், அங்கு நீங்கள் பதிவுகளை சேமிக்கலாம் மற்றும் நீங்கள் வசதியாக அங்கிருந்து அவற்றை மீட்டெடுக்கலாம். பின்னர், கோரிக்கையைப் பயன்படுத்தி, கிபானாவைப் பயன்படுத்தி, எடுத்துக்காட்டாக, அவற்றின் அடிப்படையில் வரைபடங்களை உருவாக்குதல், அவற்றின் அடிப்படையில் விழிப்பூட்டல்களை உருவாக்குதல் மற்றும் பல.
மிக முக்கியமான யோசனை, நான் அதை மீண்டும் மீண்டும் செய்ய விரும்புகிறேன், டோக்கரின் உள்ளே, குறிப்பாக குபெர்னெட்ஸின் உள்ளே, உங்கள் பதிவுகளை ஒரு கோப்பில் சேமிப்பது மிகவும் மோசமான யோசனை.
ஏனெனில் முதலில், ஒரு கோப்பில் கொள்கலனில் உள்ள பதிவுகளைப் பெறுவது கடினம். நீங்கள் முதலில் கொள்கலனுக்குள் செல்ல வேண்டும், அங்கு செயல்படுத்தவும், பின்னர் பதிவுகளைப் பார்க்கவும். அடுத்த புள்ளி என்னவென்றால், உங்களிடம் ஒரு கோப்பில் பதிவுகள் இருந்தால், கொள்கலன்கள் பொதுவாக குறைந்தபட்ச சூழலைக் கொண்டிருக்கும், மேலும் பதிவுகளுடன் சாதாரண வேலைக்கு பொதுவாகத் தேவைப்படும் பயன்பாடுகள் எதுவும் இல்லை. அவற்றை புதைத்து, அவற்றைப் பாருங்கள், உரை திருத்தியில் திறக்கவும். அடுத்த கணம், ஒரு கொள்கலனுக்குள் ஒரு கோப்பில் பதிவுகள் இருக்கும்போது, இந்த கொள்கலன் நீக்கப்பட்டால், அதனுடன் பதிவுகள் இறந்துவிடும் என்பதை நீங்கள் புரிந்துகொள்கிறீர்கள். அதன்படி, கன்டெய்னரை மறுதொடக்கம் செய்தால், மேலும் பதிவுகள் இல்லை என்று அர்த்தம். மீண்டும், மோசமான விருப்பம்.
கடைசி விஷயம் என்னவென்றால், கொள்கலன்களுக்குள் நீங்கள் வழக்கமாக உங்கள் விண்ணப்பத்தை வைத்திருக்கிறீர்கள், அவ்வளவுதான் - இது வழக்கமாக இயங்கும் ஒரே செயல்முறையாகும். உங்கள் பதிவுகளுடன் கோப்புகளை சுழற்றக்கூடிய எந்த செயல்முறையையும் பற்றி பேசவே இல்லை. பதிவுகள் ஒரு கோப்பில் எழுதத் தொடங்கியவுடன், மன்னிக்கவும், உற்பத்தி சேவையகத்தை இழக்கத் தொடங்குவோம். ஏனெனில், முதலில், அவற்றைக் கண்டுபிடிப்பது கடினம், யாரும் அவற்றைக் கண்காணிப்பதில்லை, மேலும் யாரும் அவற்றைக் கட்டுப்படுத்துவதில்லை - அதன்படி, சேவையகத்தில் உள்ள இடம் வெறுமனே இயங்கும் வரை கோப்பு முடிவில்லாமல் வளரும். எனவே, டோக்கரில், குறிப்பாக குபெர்னெட்டஸில், ஒரு கோப்பில் உள்நுழைவது மோசமான யோசனை என்று நான் மீண்டும் சொல்கிறேன்.
அடுத்த புள்ளி, இங்கே நான் இதைப் பற்றி மீண்டும் பேச விரும்புகிறேன் - பதிவுகள் என்ற தலைப்பில் நாங்கள் தொடுவதால், அவற்றுடன் வேலை செய்வதற்கு வசதியாக பதிவுகள் எப்படி இருக்க வேண்டும் என்பதைப் பற்றி பேசுவது நல்லது. நான் கூறியது போல், தலைப்பு நேரடியாக குபெர்னெட்டஸுடன் தொடர்புடையது அல்ல, ஆனால் இது DevOps என்ற தலைப்புடன் நன்றாக தொடர்புடையது. இந்த இரண்டு வெவ்வேறு துறைகளுக்கு இடையேயான வளர்ச்சி கலாச்சாரம் மற்றும் நட்பு என்ற தலைப்பில் - Dev மற்றும் Ops, இதனால் அனைவரும் வசதியாக இருப்பார்கள்.
அதாவது, இன்று, பதிவுகள் JSON வடிவத்தில் எழுதப்பட வேண்டும். உங்களிடம் சில புரிந்துகொள்ள முடியாத பயன்பாடுகள் இருந்தால், அது புரிந்துகொள்ள முடியாத வடிவங்களில் பதிவுகளை எழுதுகிறது, ஏனெனில் நீங்கள் ஒருவித அச்சு அல்லது அதுபோன்ற ஒன்றைச் செருகினால், சாதாரண பதிவுகளை செயல்படுத்த உங்களை அனுமதிக்கும் ஒருவித கட்டமைப்பை, சில வகையான ரேப்பர்களை கூகிள் செய்ய வேண்டிய நேரம் இது; JSON இல் பதிவு செய்யும் அளவுருக்களை இயக்கவும், ஏனெனில் JSON ஒரு எளிய வடிவம், பாகுபடுத்துவது எளிது.
உங்கள் JSON சில அளவுகோல்களின்படி வேலை செய்யவில்லை என்றால், யாருக்கும் தெரியாது, குறைந்தபட்சம் பாகுபடுத்தக்கூடிய வடிவத்தில் பதிவுகளை எழுதுங்கள். இங்கே, மாறாக, எடுத்துக்காட்டாக, நீங்கள் ஒரு கொத்து கொள்கலன்களை இயக்குகிறீர்கள் அல்லது nginx உடன் செயலாக்குகிறீர்கள் என்றால், ஒவ்வொன்றும் அதன் சொந்த பதிவு அமைப்புகளைக் கொண்டிருந்தால், அது உங்களுக்கு மிகவும் சிரமமாக இருக்கும் என்ற உண்மையைப் பற்றி சிந்திக்க வேண்டியது அவசியம். அவற்றை அலச. ஏனெனில் ஒவ்வொரு புதிய nginx நிகழ்விற்கும் நீங்கள் உங்கள் சொந்த பாகுபடுத்தி எழுத வேண்டும், ஏனெனில் அவை பதிவுகளை வித்தியாசமாக எழுதுகின்றன. மீண்டும், இந்த அனைத்து nginx நிகழ்வுகளும் ஒரே மாதிரியான லாக்கிங் உள்ளமைவைக் கொண்டிருப்பதையும், அவற்றின் அனைத்து பதிவுகளையும் முற்றிலும் ஒரே மாதிரியாக எழுதுவதை உறுதிசெய்வது பற்றி சிந்திக்க வேண்டியது அவசியம். இது முற்றிலும் அனைத்து பயன்பாடுகளுக்கும் பொருந்தும்.
முடிவில், பல வரி வடிவ பதிவுகள் தவிர்க்கப்பட வேண்டிய நெருப்பில் எரிபொருளைச் சேர்க்க விரும்புகிறேன். இங்கே விஷயம் என்னவென்றால், நீங்கள் எப்போதாவது பதிவு சேகரிப்பாளர்களுடன் பணிபுரிந்திருந்தால், அவர்கள் உங்களுக்கு என்ன உறுதியளிக்கிறார்கள் என்பதை நீங்கள் பார்த்திருக்கலாம், அவர்கள் பல வரி பதிவுகளுடன் வேலை செய்யலாம், அவற்றை எவ்வாறு சேகரிப்பது என்று தெரிந்துகொள்வது மற்றும் பல. உண்மையில், என் கருத்துப்படி, இன்று ஒரு சேகரிப்பாளரும் பல வரி பதிவுகளை சாதாரணமாக, முழுமையாக மற்றும் பிழைகள் இல்லாமல் சேகரிக்க முடியாது. ஒரு மனித வழியில், அது வசதியானது மற்றும் பிழையற்றது.
ஆனால் ஸ்டேக் ட்ரேஸ் எப்போதும் பல வரி பதிவுகள் மற்றும் அவற்றை எவ்வாறு தவிர்ப்பது. இங்கே கேள்வி என்னவென்றால், பதிவு என்பது ஒரு நிகழ்வின் பதிவு, மற்றும் ஸ்டாக்ட்ரேஸ் உண்மையில் ஒரு பதிவு அல்ல. நாங்கள் பதிவுகளை சேகரித்து எலாஸ்டிக் தேடலில் எங்காவது வைத்து, பின்னர் அவற்றிலிருந்து வரைபடங்களை வரைந்து, உங்கள் தளத்தில் பயனர் செயல்பாடு குறித்த சில அறிக்கைகளை உருவாக்கினால், ஸ்டாக் ட்ரேஸ் கிடைத்தால், எதிர்பாராத ஒன்று நடக்கிறது என்று அர்த்தம். உங்கள் பயன்பாட்டில் கையாளப்படாத சூழ்நிலை. ஸ்டாக் ட்ரேஸை எங்காவது கண்காணிக்கக்கூடிய அமைப்பில் தானாகவே பதிவேற்றுவது அர்த்தமுள்ளதாக இருக்கிறது.
இது ஸ்டாக் ட்ரேஸ் உடன் வேலை செய்ய பிரத்யேகமாக உருவாக்கப்பட்ட மென்பொருள் (அதே சென்ட்ரி). இது உடனடியாக தானியங்கு பணிகளை உருவாக்கலாம், அவற்றை ஒருவருக்கு ஒதுக்கலாம், ஸ்டாக்ட்ரேஸ்கள் ஏற்படும் போது எச்சரிக்கை செய்யலாம், இந்த ஸ்டாக்ட்ரேஸ்களை ஒரு வகை மூலம் தொகுக்கலாம் மற்றும் பல. கொள்கையளவில், பதிவுகளைப் பற்றி பேசும்போது ஸ்டாக்ட்ரேஸ்களைப் பற்றி பேசுவது மிகவும் அர்த்தமல்ல, ஏனென்றால் இவை எல்லாவற்றிற்கும் மேலாக, வெவ்வேறு நோக்கங்களுடன் வெவ்வேறு விஷயங்கள்.
கட்டமைப்பு
அடுத்து நாம் குபெர்னெட்ஸில் உள்ளமைவு பற்றி பேசுகிறோம்: அதை என்ன செய்வது மற்றும் குபெர்னெட்டஸில் உள்ள பயன்பாடுகள் எவ்வாறு கட்டமைக்கப்பட வேண்டும். பொதுவாக, டோக்கர் என்பது கொள்கலன்களைப் பற்றியது அல்ல என்று நான் பொதுவாகச் சொல்கிறேன். Docker என்பது கன்டெய்னர்களைப் பற்றியது என்பது அனைவருக்கும் தெரியும், Docker உடன் அதிகம் வேலை செய்யாதவர்கள் கூட. நான் மீண்டும் சொல்கிறேன், டோக்கர் என்பது கொள்கலன்களைப் பற்றியது அல்ல.
டோக்கர், என் கருத்துப்படி, தரநிலைகளைப் பற்றியது. நடைமுறையில் எல்லாவற்றிற்கும் தரநிலைகள் உள்ளன: உங்கள் பயன்பாட்டை உருவாக்குவதற்கான தரநிலைகள், உங்கள் பயன்பாட்டை நிறுவுவதற்கான தரநிலைகள்.
இந்த விஷயம் - நாங்கள் இதை முன்பு பயன்படுத்தினோம், இது கொள்கலன்களின் வருகையுடன் குறிப்பாக பிரபலமாகிவிட்டது - இந்த விஷயம் ENV (சுற்றுச்சூழல்) மாறிகள் என்று அழைக்கப்படுகிறது, அதாவது உங்கள் இயக்க முறைமையில் இருக்கும் சூழல் மாறிகள். உங்கள் பயன்பாட்டை உள்ளமைக்க இது பொதுவாக ஒரு சிறந்த வழியாகும், ஏனென்றால் உங்களிடம் JAVA, Python, Go, Perl, God forbid ஆகியவற்றில் பயன்பாடுகள் இருந்தால், அவை அனைத்தும் தரவுத்தள ஹோஸ்ட், தரவுத்தள பயனர், தரவுத்தள கடவுச்சொல் மாறிகள் ஆகியவற்றைப் படிக்கலாம், அது சிறந்தது. தரவுத்தள திட்டத்தில் அதே வழியில் உள்ளமைக்கப்பட்ட நான்கு வெவ்வேறு மொழிகளில் பயன்பாடுகள் உள்ளன. வேறு வேறு கட்டமைப்புகள் எதுவும் இல்லை.
ENV மாறிகளைப் பயன்படுத்தி எல்லாவற்றையும் கட்டமைக்க முடியும். குபெர்னெட்டஸைப் பற்றி நாம் பேசும்போது, ENV மாறிகளை வரிசைப்படுத்துதலுக்குள் நேரடியாக அறிவிக்க ஒரு சிறந்த வழி உள்ளது. அதன்படி, நாங்கள் ரகசியத் தரவைப் பற்றி பேசுகிறோம் என்றால், உடனடியாக ENV மாறிகள் (தரவுத்தளங்களுக்கான கடவுச்சொற்கள் போன்றவை) ரகசியத் தரவை ஒரு ரகசியமாகத் தள்ளலாம், ஒரு ரகசிய கிளஸ்டரை உருவாக்கி, நாங்கள் நேரடியாக அறிவிக்கவில்லை என்பதை ENV விளக்கத்தில் குறிப்பிடலாம். இந்த மாறியின் மதிப்பு மற்றும் இந்த தரவுத்தள கடவுச்சொல் மாறியின் மதிப்பு ரகசியத்திலிருந்து படிக்கப்படும். இது நிலையான குபெர்னெட்ஸ் நடத்தை. உங்கள் பயன்பாடுகளை உள்ளமைக்க இது மிகவும் சிறந்த விருப்பமாகும். குறியீடு மட்டத்தில், மீண்டும் இது டெவலப்பர்களுக்கு பொருந்தும். நீங்கள் DevOps ஆக இருந்தால், நீங்கள் கேட்கலாம்: “நண்பர்களே, சூழல் மாறிகளைப் படிக்க உங்கள் பயன்பாட்டிற்குக் கற்றுக் கொடுங்கள். மேலும் நாங்கள் அனைவரும் மகிழ்ச்சியாக இருப்போம்.
நிறுவனத்தில் உள்ள அனைவரும் அதே பெயரிடப்பட்ட சுற்றுச்சூழல் மாறிகளைப் படித்தால், அது மிகவும் நல்லது. சிலர் போஸ்ட்கிரெஸ் தரவுத்தளத்திற்காகக் காத்திருக்கிறார்கள், மற்றவர்கள் தரவுத்தளத்தின் பெயருக்காகக் காத்திருக்கிறார்கள், மற்றவர்கள் வேறு ஏதாவது காத்திருக்கிறார்கள், மற்றவர்கள் ஏதாவது ஒரு dbn க்காகக் காத்திருக்கிறார்கள், அதன்படி, சீரான தன்மை உள்ளது.
உங்களிடம் பல சூழல் மாறிகள் இருக்கும்போது, நீங்கள் வரிசைப்படுத்தலைத் திறக்கும்போது சிக்கல் வருகிறது - மேலும் ஐநூறு வரி சூழல் மாறிகள் உள்ளன. இந்த விஷயத்தில், நீங்கள் வெறுமனே வளர்ந்த சூழல் மாறிகள் - மேலும் நீங்கள் இனி உங்களை சித்திரவதை செய்ய தேவையில்லை. இந்த வழக்கில், கட்டமைப்புகளைப் பயன்படுத்தத் தொடங்குவது அர்த்தமுள்ளதாக இருக்கும். அதாவது, கட்டமைப்புகளைப் பயன்படுத்த உங்கள் பயன்பாட்டைப் பயிற்றுவிக்கவும்.
ஒரே கேள்வி என்னவென்றால், கட்டமைப்புகள் நீங்கள் நினைப்பது அல்ல. config.pi என்பது பயன்படுத்த வசதியான கட்டமைப்பு அல்ல. அல்லது உங்கள் சொந்த வடிவத்தில் சில கட்டமைப்புகள், மாற்றாக பரிசளிக்கப்பட்டவை - இதுவும் நான் சொல்லும் கட்டமைப்பு அல்ல.
நான் பேசுவது ஏற்றுக்கொள்ளக்கூடிய வடிவங்களில் உள்ளமைவு, அதாவது, மிகவும் பிரபலமான தரநிலை .yaml தரநிலை ஆகும். அதை எப்படி படிக்க வேண்டும் என்பது தெளிவாக உள்ளது, இது மனிதனால் படிக்கக்கூடியது, பயன்பாட்டில் இருந்து எப்படி படிக்க வேண்டும் என்பது தெளிவாக உள்ளது.
அதன்படி, YAML ஐத் தவிர, நீங்கள் JSON ஐப் பயன்படுத்தலாம், பாகுபடுத்துவது YAML ஐப் போலவே வசதியானது. மக்கள் வாசிப்பதற்கு மிகவும் சிரமமாக உள்ளது குறிப்பிடத்தக்கது. நீங்கள் வடிவமைப்பை முயற்சி செய்யலாம், a la ini. மனிதக் கண்ணோட்டத்தில் படிக்க இது மிகவும் வசதியானது, ஆனால் நீங்கள் எப்போதாவது உங்கள் சொந்த கட்டமைப்புகளை உருவாக்க விரும்பினால், ini வடிவம் ஏற்கனவே உருவாக்க சிரமமாக இருக்கலாம் என்ற பொருளில், அதை தானாகவே செயலாக்குவது சிரமமாக இருக்கலாம்.
ஆனால் எப்படியிருந்தாலும், நீங்கள் எந்த வடிவமைப்பைத் தேர்வுசெய்தாலும், குபெர்னெட்டஸின் பார்வையில் அது மிகவும் வசதியானது. உங்கள் முழு கட்டமைப்பையும் குபெர்னெட்டஸில், கான்ஃபிக்மேப்பில் வைக்கலாம். பின்னர் இந்த configmap ஐ எடுத்து, அதை உங்கள் பாட்டின் உள்ளே சில குறிப்பிட்ட கோப்பகத்தில் ஏற்றும்படி கேட்கவும், அங்கு உங்கள் பயன்பாடு இந்த configmap இல் இருந்து உள்ளமைவை ஒரு கோப்பாகப் படிக்கும். உண்மையில், உங்கள் பயன்பாட்டில் நிறைய உள்ளமைவு விருப்பங்கள் இருக்கும்போது இதைச் செய்வது நல்லது. அல்லது இது ஒருவித சிக்கலான அமைப்பு, கூடு உள்ளது.
உங்களிடம் configmap இருந்தால், உங்கள் பயன்பாட்டை நீங்கள் நன்றாகக் கற்பிக்கலாம், எடுத்துக்காட்டாக, configmap பொருத்தப்பட்டிருக்கும் கோப்பில் ஏற்படும் மாற்றங்களைத் தானாகக் கண்காணிக்கவும், மேலும் கட்டமைப்புகள் மாறும்போது தானாகவே உங்கள் பயன்பாட்டை மீண்டும் ஏற்றவும். இது பொதுவாக ஒரு சிறந்த விருப்பமாக இருக்கும்.
மீண்டும், நான் ஏற்கனவே இதைப் பற்றி பேசினேன் - ரகசிய தகவல் கட்டமைப்பு வரைபடத்தில் இல்லை, ரகசிய தகவல் மாறிகளில் இல்லை, ரகசிய தகவல் இரகசியங்களில் இல்லை. அங்கிருந்து, இந்த ரகசிய தகவலை இராஜதந்திரத்துடன் இணைக்கவும். வழக்கமாக நாம் குபெர்னெட்டஸ் பொருள்கள், வரிசைப்படுத்தல்கள், கட்டமைப்பு வரைபடங்கள், சேவைகள் பற்றிய அனைத்து விளக்கங்களையும் கிட்டில் சேமித்து வைப்போம். அதன்படி, நீங்கள் நிறுவனத்தில் உள்நாட்டில் வைத்திருக்கும் உங்கள் ஜிட்டாக இருந்தாலும், தரவுத்தளத்திற்கு கடவுச்சொல்லை git இல் வைப்பது தவறான யோசனை. ஏனெனில், குறைந்தபட்சம், git எல்லாவற்றையும் நினைவில் வைத்துக் கொள்கிறது மற்றும் அங்கிருந்து கடவுச்சொற்களை அகற்றுவது அவ்வளவு எளிதானது அல்ல.
சுகாதார சோதனை
அடுத்த விஷயம், ஹெல்த் செக் எனப்படும் விஷயம். பொதுவாக, உடல்நலப் பரிசோதனை என்பது உங்கள் விண்ணப்பம் செயல்படுகிறதா என்பதைச் சரிபார்க்கும். அதே நேரத்தில், நாங்கள் பெரும்பாலும் சில வலை பயன்பாடுகளைப் பற்றி பேசுகிறோம், அதன்படி, சுகாதார சோதனையின் பார்வையில் (இங்கு மேலும் மேலும் மொழிபெயர்க்காமல் இருப்பது நல்லது) இது சில சிறப்பு URL ஆக இருக்கும். ஒரு நிலையான, அவர்கள் வழக்கமாக செய்கிறார்கள் /health.
இந்த URL ஐ அணுகும்போது, அதற்கேற்ப, எங்கள் பயன்பாடு "ஆம், சரி, என்னுடன் எல்லாம் நன்றாக இருக்கிறது, 200" அல்லது "இல்லை, எனக்கு எல்லாம் சரியாகவில்லை, சுமார் 500" என்று கூறுகிறது. அதன்படி, எங்கள் பயன்பாடு http இல்லை என்றால், ஒரு வலை பயன்பாடு அல்ல, நாங்கள் இப்போது சில வகையான டீமான்களைப் பற்றி பேசுகிறோம், சுகாதார சோதனைகளை எவ்வாறு செய்வது என்பதை நாம் கண்டுபிடிக்கலாம். அதாவது, அது தேவையில்லை, பயன்பாடு http இல்லை என்றால், எல்லாம் ஒரு சுகாதார சோதனை இல்லாமல் வேலை செய்கிறது, இதை எந்த வகையிலும் செய்ய முடியாது. கோப்பில் உள்ள சில தகவல்களை நீங்கள் அவ்வப்போது புதுப்பிக்கலாம், உங்கள் டீமனுக்கு சில சிறப்பு கட்டளைகளை கொண்டு வரலாம், daemon status, இது "ஆம், எல்லாம் நன்றாக இருக்கிறது, டீமான் வேலை செய்கிறது, அது உயிருடன் இருக்கிறது" என்று சொல்லும்.
இது எதற்காக? முதல் மற்றும் மிகவும் வெளிப்படையான விஷயம், ஒருவேளை ஏன் ஒரு சுகாதார சோதனை தேவை - பயன்பாடு வேலை செய்கிறது என்பதை புரிந்து கொள்ள. அதாவது, இது வெறும் முட்டாள்தனம், இப்போது இருக்கும் போது, அது வேலை செய்வது போல் தெரிகிறது, அது வேலை செய்கிறது என்பதை நீங்கள் உறுதியாக நம்பலாம். பயன்பாடு இயங்குகிறது, கொள்கலன் இயங்குகிறது, நிகழ்வு வேலை செய்கிறது, எல்லாம் நன்றாக இருக்கிறது - பின்னர் பயனர்கள் ஏற்கனவே தொழில்நுட்ப ஆதரவிலிருந்து அனைத்து தொலைபேசி எண்களையும் துண்டித்துவிட்டு “நீங்கள் என்ன ..., நீங்கள் தூங்கிவிட்டேன், எதுவும் வேலை செய்யவில்லை.
ஒரு உடல்நலப் பரிசோதனை என்பது பயனரின் பார்வையில் இருந்து அது செயல்படுவதைப் பார்ப்பதற்கான ஒரு வழியாகும். முறைகளில் ஒன்று. அதை இப்படி வைப்போம். குபெர்னெட்டஸின் பார்வையில், பயன்பாடு எப்போது தொடங்குகிறது என்பதைப் புரிந்துகொள்வதற்கான ஒரு வழியாகும், ஏனென்றால் கொள்கலன் எப்போது தொடங்கப்பட்டது, உருவாக்கப்பட்டது மற்றும் தொடங்கப்பட்டது மற்றும் இந்த கொள்கலனில் பயன்பாடு நேரடியாக தொடங்கப்பட்டது ஆகியவற்றுக்கு இடையே வேறுபாடு இருப்பதை நாங்கள் புரிந்துகொள்கிறோம். ஏனென்றால், நாம் சில சராசரி ஜாவா பயன்பாட்டை எடுத்து, அதை டாக்கில் தொடங்க முயற்சித்தால், நாற்பது வினாடிகள், அல்லது ஒரு நிமிடம் அல்லது பத்து நேரம் கூட, அது நன்றாகத் தொடங்கும். இந்த வழக்கில், நீங்கள் குறைந்தபட்சம் அதன் துறைமுகங்களைத் தட்டலாம், அது அங்கு பதிலளிக்காது, அதாவது, போக்குவரத்தைப் பெற இன்னும் தயாராக இல்லை.
மீண்டும், ஒரு உடல்நலப் பரிசோதனையின் உதவியுடனும், நாங்கள் இங்கு திரும்புகிறோம் என்ற உண்மையின் உதவியுடனும், பயன்பாட்டில் கொள்கலன் உயர்ந்துள்ளது மட்டுமல்லாமல், பயன்பாடும் தொடங்கியுள்ளது என்பதை குபெர்னெட்ஸில் புரிந்து கொள்ள முடியும், அது ஏற்கனவே பதிலளிக்கிறது சுகாதார சோதனை, அதாவது நாம் போக்குவரத்தை அங்கு அனுப்பலாம்.
நான் இப்போது பேசுவது குபெர்னெட்டஸில் உள்ள தயார்நிலை/வாழ்க்கை சோதனைகள் என்று அழைக்கப்படுகிறது; அதன்படி, சமநிலையில் பயன்பாடு கிடைப்பதற்கு எங்கள் தயார்நிலை சோதனைகள் பொறுப்பாகும். அதாவது, பயன்பாட்டில் தயார்நிலை சோதனைகள் நடத்தப்பட்டால், எல்லாம் சரியாகிவிடும், கிளையன்ட் போக்குவரத்து பயன்பாட்டிற்கு செல்கிறது. தயார்நிலை சோதனைகள் செய்யப்படாவிட்டால், பயன்பாடு வெறுமனே பங்கேற்காது, இந்த குறிப்பிட்ட நிகழ்வு சமநிலையில் பங்கேற்காது, இது சமநிலையிலிருந்து அகற்றப்படுகிறது, கிளையன்ட் போக்குவரத்து ஓட்டம் இல்லை. அதன்படி, குபெர்னெட்டஸில் லைவ்னெஸ் சோதனைகள் தேவை, இதனால் பயன்பாடு சிக்கினால், அதை மறுதொடக்கம் செய்யலாம். குபெர்னெட்ஸில் அறிவிக்கப்பட்ட பயன்பாட்டிற்கு லைவ்னெஸ் சோதனை வேலை செய்யவில்லை என்றால், பயன்பாடு சமநிலையிலிருந்து அகற்றப்படாமல், அது மீண்டும் தொடங்கப்படும்.
இங்கே நான் குறிப்பிட விரும்பும் ஒரு முக்கியமான விஷயம்: ஒரு நடைமுறைக் கண்ணோட்டத்தில், ஆயத்த சோதனை பொதுவாக அடிக்கடி பயன்படுத்தப்படுகிறது மற்றும் உயிரோட்ட சோதனையை விட அடிக்கடி தேவைப்படுகிறது. அதாவது, வெறுமனே சிந்தனையின்றி தயார்நிலை மற்றும் உயிரோட்டம் சோதனைகள் இரண்டையும் அறிவிப்பது, ஏனெனில் குபெர்னெட்டஸ் அதைச் செய்ய முடியும், மேலும் அது செய்யக்கூடிய அனைத்தையும் பயன்படுத்துவோம், இது மிகவும் நல்ல யோசனையல்ல. ஏன் என்று விளக்குகிறேன். ஏனெனில், சோதனையில் புள்ளி எண் இரண்டு, உங்கள் உடல்நலச் சோதனைகளில் அடிப்படை சேவையைச் சரிபார்ப்பது நல்லது. இதன் பொருள், உங்களிடம் சில தகவல்களை வழங்கும் வலை பயன்பாடு இருந்தால், அது இயற்கையாகவே எங்கிருந்தோ எடுக்க வேண்டும். உதாரணமாக, தரவுத்தளத்தில். சரி, இந்த REST API இல் வரும் தகவலை அதே தரவுத்தளத்தில் சேமிக்கிறது. பின்னர், அதற்கேற்ப, உங்கள் ஹெல்த் செக், தொடர்பு கொண்ட ஸ்லாஷ்ஹெல்த் போலவே பதிலளித்தால், பயன்பாடு “200, சரி, எல்லாம் நன்றாக இருக்கிறது” என்று கூறுகிறது, அதே நேரத்தில் உங்கள் பயன்பாட்டின் தரவுத்தளத்தை அணுக முடியாது, மேலும் ஹெல்த் செக் பயன்பாடு “200, சரி, எல்லாம் நன்றாக இருக்கிறது ” - இது மோசமான உடல்நலப் பரிசோதனை. இப்படிச் செயல்படக்கூடாது.
அதாவது, உங்கள் விண்ணப்பம், கோரிக்கை வரும்போது /health"200, சரி" என்று மட்டும் பதிலளிக்காது, அது முதலில் தரவுத்தளத்திற்குச் செல்கிறது, அதனுடன் இணைக்க முயற்சிக்கிறது, ஒன்றைத் தேர்ந்தெடுப்பது போன்ற அடிப்படையான ஒன்றைச் செய்கிறது, அதில் இணைப்பு இருக்கிறதா என்று சரிபார்க்கிறது. தரவுத்தளம் மற்றும் நீங்கள் தரவுத்தளத்தை வினவலாம். இவை அனைத்தும் வெற்றிகரமாக இருந்தால், பதில் "200, சரி." அது வெற்றிபெறவில்லை என்றால், பிழை இருப்பதாகவும், தரவுத்தளம் கிடைக்கவில்லை என்றும் கூறுகிறது.
எனவே, இது சம்பந்தமாக, நான் மீண்டும் தயார்நிலை/உயிர்த்தன்மை சோதனைகளுக்குத் திரும்புகிறேன் - உங்களுக்கு ஏன் பெரும்பாலும் தயார்நிலை சோதனை தேவை, ஆனால் உயிரோட்ட சோதனை கேள்விக்குறியாக உள்ளது. ஏனென்றால் நான் சொன்னது போலவே நீங்கள் சுகாதார சோதனைகளை விவரித்தால், அது நிகழ்வு பகுதியில் இல்லை என்று மாறிவிடும்.в или со всех instanceஒரு தரவுத்தளத்தில், எடுத்துக்காட்டாக. நீங்கள் தயார்நிலை சோதனையை அறிவித்தபோது, எங்கள் சுகாதார சோதனைகள் தோல்வியடையத் தொடங்கின, அதன்படி தரவுத்தளத்தை அணுக முடியாத அனைத்து பயன்பாடுகளும், அவை சமநிலையிலிருந்து வெறுமனே அணைக்கப்பட்டு, உண்மையில் புறக்கணிக்கப்பட்ட நிலையில் "தொங்கு" மற்றும் அவற்றின் தரவுத்தளங்களுக்கு காத்திருக்கின்றன. வேலை.
நாங்கள் ஒரு உயிரோட்ட சோதனையை அறிவித்திருந்தால், கற்பனை செய்து பாருங்கள், எங்கள் தரவுத்தளம் உடைந்துவிட்டது, மேலும் உங்கள் குபெர்னெட்டஸில் பாதியளவு எல்லாம் மறுதொடக்கம் செய்யத் தொடங்குகிறது, ஏனெனில் உயிரோட்ட சோதனை தோல்வியடைந்தது. இதன் பொருள் நீங்கள் மறுதொடக்கம் செய்ய வேண்டும். இது நீங்கள் விரும்புவது இல்லை, நடைமுறையில் எனக்கு தனிப்பட்ட அனுபவம் கூட இருந்தது. எங்களிடம் அரட்டை பயன்பாடு இருந்தது, அது JS இல் எழுதப்பட்டு மோங்கோ தரவுத்தளத்தில் கொடுக்கப்பட்டது. பிரச்சனை என்னவென்றால், குபெர்னெட்டஸுடனான எனது பணியின் தொடக்கத்தில் இருந்தது, குபெர்னெட்டஸுடன் இதைச் செய்ய முடியும் என்ற கொள்கையின் அடிப்படையில் சோதனைகளின் தயார்நிலை, உயிரோட்டத்தை நாங்கள் விவரித்தோம், எனவே நாங்கள் அதைப் பயன்படுத்துவோம். அதன்படி, ஒரு கட்டத்தில் மோங்கோ கொஞ்சம் "மந்தமானது" மற்றும் மாதிரி தோல்வியடையத் தொடங்கியது. அதன்படி, மழைப்பொழிவு சோதனையின்படி, காய்கள் "கொல்ல" தொடங்கியது.
நீங்கள் புரிந்துகொண்டபடி, அவர்கள் "கொல்லப்படும்போது", இது ஒரு அரட்டை, அதாவது, வாடிக்கையாளர்களிடமிருந்து நிறைய இணைப்புகள் அதில் தொங்கிக்கொண்டிருக்கின்றன. அவர்களும் "கொல்லப்பட்டனர்" - இல்லை, வாடிக்கையாளர்கள் அல்ல, இணைப்புகள் மட்டுமே - அனைத்தும் ஒரே நேரத்தில் இல்லை, மேலும் அவர்கள் ஒரே நேரத்தில் கொல்லப்படாததால், சில முந்தைய, சில பின்னர், அவை ஒரே நேரத்தில் தொடங்குவதில்லை. நேரம். பிளஸ் ஸ்டாண்டர்ட் ரேண்டம், ஒவ்வொரு முறையும் பயன்பாட்டின் தொடக்க நேரத்தை மில்லிசெகண்ட் துல்லியத்துடன் எங்களால் கணிக்க முடியாது, எனவே அவர்கள் அதை ஒரு நேரத்தில் ஒரு முறை செய்கிறார்கள். ஒரு இன்ஃபோஸ்பாட் உயர்கிறது, சமநிலையில் சேர்க்கப்படுகிறது, எல்லா வாடிக்கையாளர்களும் அங்கு வருகிறார்கள், அது அத்தகைய சுமையைத் தாங்க முடியாது, ஏனென்றால் அது தனியாக உள்ளது, மேலும் தோராயமாகச் சொன்னால், அவர்களில் ஒரு டஜன் பேர் அங்கு வேலை செய்கிறார்கள், அது விழுகிறது. அடுத்தவர் எழுகிறார், முழு சுமையும் அவர் மீது உள்ளது, அவரும் விழுகிறார். சரி, இந்த நீர்வீழ்ச்சிகள் தொடர்ந்து விழுகின்றன. இறுதியில், இது எவ்வாறு தீர்க்கப்பட்டது - இந்த பயன்பாட்டிற்கான பயனர் போக்குவரத்தை நாங்கள் கண்டிப்பாக நிறுத்த வேண்டும், எல்லா நிகழ்வுகளும் உயரட்டும், பின்னர் அனைத்து பயனர் போக்குவரத்தையும் ஒரே நேரத்தில் தொடங்க வேண்டும், இதனால் அது ஏற்கனவே பத்து நிகழ்வுகளிலும் விநியோகிக்கப்பட்டது.
இந்த லைவ்னஸ் சோதனை அறிவிக்கப்படாமல் இருந்திருந்தால், இது அனைத்தையும் மறுதொடக்கம் செய்யும்படி கட்டாயப்படுத்தும், பயன்பாடு அதைச் சரியாகக் கையாண்டிருக்கும். ஆனால் சமநிலையிலிருந்து அனைத்தும் எங்களுக்கு முடக்கப்பட்டுள்ளன, ஏனெனில் தரவுத்தளங்கள் அணுக முடியாதவை மற்றும் அனைத்து பயனர்களும் "விழுந்துவிட்டனர்". பின்னர், இந்த தரவுத்தளம் கிடைக்கும்போது, எல்லாம் சமநிலையில் சேர்க்கப்படும், ஆனால் பயன்பாடுகள் மீண்டும் தொடங்க வேண்டிய அவசியமில்லை, மேலும் இதில் நேரத்தையும் வளங்களையும் வீணாக்க வேண்டிய அவசியமில்லை. அவை அனைத்தும் ஏற்கனவே இங்கே உள்ளன, அவை போக்குவரத்துக்கு தயாராக உள்ளன, எனவே போக்குவரத்து திறக்கிறது, எல்லாம் நன்றாக இருக்கிறது - பயன்பாடு இடத்தில் உள்ளது, எல்லாம் தொடர்ந்து வேலை செய்கிறது.
எனவே, தயார்நிலை மற்றும் உயிரோட்ட சோதனைகள் வேறுபட்டவை, மேலும், நீங்கள் கோட்பாட்டளவில் வெவ்வேறு சுகாதார சோதனைகள், ஒரு வகை ஆரங்கள், ஒரு வகை லிவ், எடுத்துக்காட்டாக, வெவ்வேறு விஷயங்களைச் சரிபார்க்கலாம். தயார்நிலை சோதனைகளின் போது, உங்கள் பின்தளங்களைச் சரிபார்க்கவும். எடுத்துக்காட்டாக, ஒரு உயிரோட்ட சோதனையில், உயிர்வாழ்வு சோதனை பொதுவாக பதிலளிக்கக்கூடிய ஒரு பயன்பாடு மட்டுமே என்பதை நீங்கள் சரிபார்க்க மாட்டீர்கள்.
ஏனென்றால், உயிர்த்தன்மை சோதனையானது, நாம் "சிக்கப்படும்" போதுதான். முடிவில்லாத சுழற்சி தொடங்கப்பட்டது அல்லது வேறு ஏதாவது - மேலும் கோரிக்கைகள் செயலாக்கப்படவில்லை. எனவே, அவற்றைப் பிரிப்பதும் - அவற்றில் வெவ்வேறு தர்க்கங்களைச் செயல்படுத்துவதும் கூட அர்த்தமுள்ளதாக இருக்கிறது.
நீங்கள் பரிசோதனை செய்யும்போது, உடல்நலப் பரிசோதனை செய்யும்போது என்ன பதில் சொல்ல வேண்டும் என்பது குறித்து. உண்மையில் வலி தான். இதைப் பற்றி நன்கு தெரிந்தவர்கள் சிரிப்பார்கள் - ஆனால் தீவிரமாக, 200% வழக்குகளில் “XNUMX” என்று பதிலளிக்கும் சேவைகளை நான் என் வாழ்க்கையில் பார்த்திருக்கிறேன். அதாவது யார் வெற்றி பெற்றவர். ஆனால் அதே நேரத்தில் பதிலின் உடலில் அவர்கள் "அத்தகைய பிழை" என்று எழுதுகிறார்கள்.
அதாவது, பதில் நிலை உங்களுக்கு வருகிறது - எல்லாம் வெற்றிகரமாக உள்ளது. ஆனால் அதே நேரத்தில், நீங்கள் உடலை அலச வேண்டும், ஏனென்றால் உடல் "மன்னிக்கவும், கோரிக்கை பிழையுடன் முடிந்தது" என்று கூறுகிறது, இது உண்மைதான். இதை நிஜ வாழ்க்கையில் பார்த்தேன்.
சிலர் அதை வேடிக்கையாகக் காணவில்லை, மற்றவர்கள் அதை மிகவும் வேதனையாகக் கருதுகிறார்கள், ஒரு எளிய விதியைக் கடைப்பிடிப்பது இன்னும் மதிப்புக்குரியது. சுகாதார சோதனைகளில், மற்றும் கொள்கையளவில் இணைய பயன்பாடுகளுடன் பணிபுரியும் போது.
எல்லாம் சரியாக நடந்தால், இருநூறாவது பதிலுடன் பதிலளிக்கவும். கொள்கையளவில், எந்த இருநூறாவது பதில் உங்களுக்கு பொருந்தும். நீங்கள் ராக்சியை நன்றாகப் படித்து, சில பதில் நிலைகள் மற்றவற்றிலிருந்து வேறுபட்டவை என்று தெரிந்தால், பொருத்தமானவற்றுடன் பதிலளிக்கவும்: 204, 5, 10, 15, எதுவாக இருந்தாலும். இது நன்றாக இல்லை என்றால், "இரண்டு பூஜ்ஜியம் பூஜ்ஜியம்." எல்லாம் மோசமாகி, உடல்நலப் பரிசோதனை பதிலளிக்கவில்லை என்றால், ஏதேனும் ஐநூறில் பதில் சொல்லுங்கள். மீண்டும், எவ்வாறு பதிலளிப்பது என்பதை நீங்கள் புரிந்து கொண்டால், வெவ்வேறு பதில் நிலைகள் எவ்வாறு ஒருவருக்கொருவர் வேறுபடுகின்றன. உங்களுக்குப் புரியவில்லை என்றால், ஏதேனும் தவறு நடந்தால், உடல்நலச் சோதனைகளுக்குப் பதிலளிக்க 502 உங்கள் விருப்பம்.
இது மற்றொரு விஷயம், நான் அடிப்படை சேவைகளை சரிபார்ப்பது பற்றி கொஞ்சம் திரும்ப விரும்புகிறேன். நீங்கள் தொடங்கினால், எடுத்துக்காட்டாக, உங்கள் பயன்பாட்டிற்கு பின்னால் இருக்கும் அனைத்து அடிப்படை சேவைகளையும் சரிபார்க்கவும் - பொதுவாக எல்லாம். மைக்ரோ சர்வீஸ் கட்டமைப்பின் பார்வையில் நாங்கள் எதைப் பெறுகிறோம், "குறைந்த இணைப்பு" போன்ற ஒரு கருத்து எங்களிடம் உள்ளது - அதாவது, உங்கள் சேவைகள் ஒருவருக்கொருவர் குறைந்தபட்சமாக சார்ந்திருக்கும் போது. அவற்றில் ஒன்று தோல்வியுற்றால், இந்த செயல்பாடு இல்லாத மற்ற அனைத்தும் தொடர்ந்து செயல்படும். சில செயல்பாடுகள் வேலை செய்யாது. அதன்படி, நீங்கள் அனைத்து சுகாதார சோதனைகளையும் ஒன்றோடொன்று இணைக்கிறீர்கள் என்றால், நீங்கள் உள்கட்டமைப்பில் ஒரு விஷயம் வீழ்ச்சியடைவீர்கள், மேலும் அது விழுந்ததால், அனைத்து சேவைகளின் அனைத்து சுகாதார சோதனைகளும் தோல்வியடையத் தொடங்குகின்றன - மேலும் பொதுவாக அதிக உள்கட்டமைப்பு உள்ளது. முழு மைக்ரோ சர்வீஸ் கட்டிடக்கலை எண். அங்கே எல்லாம் இருண்டு போனது.
எனவே, நீங்கள் அடிப்படை சேவைகளை சரிபார்க்க வேண்டும் என்பதை மீண்டும் மீண்டும் கூற விரும்புகிறேன், நூறு சதவீத வழக்குகளில் உங்கள் விண்ணப்பம் அதன் வேலையைச் செய்ய முடியாது. அதாவது, உங்களிடம் REST API இருந்தால், அதன் மூலம் பயனர் தரவுத்தளத்தில் சேமிக்கிறார் அல்லது தரவுத்தளத்திலிருந்து மீட்டெடுக்கிறார் என்றால், தரவுத்தளம் இல்லாத நிலையில், உங்கள் பயனர்களுடன் பணிபுரிய உத்தரவாதம் அளிக்க முடியாது என்பது தர்க்கரீதியானது.
ஆனால் உங்கள் பயனர்கள், நீங்கள் தரவுத்தளத்தில் இருந்து வெளியே எடுக்கும்போது, வேறு சில மெட்டாடேட்டாவுடன் கூடுதலாக செறிவூட்டப்பட்டிருந்தால், மற்றொரு பின்தளத்தில் இருந்து, நீங்கள் ஃபிரண்டெண்டிற்கு பதிலை அனுப்பும் முன் உள்ளிடுகிறீர்கள் - இந்த பின்தளம் கிடைக்கவில்லை என்றால், நீங்கள் உங்கள் மெட்டாடேட்டாவின் எந்தப் பகுதியும் இல்லாமல் பதிலளிக்கவும்.
அடுத்து, அப்ளிகேஷன்களைத் தொடங்கும் போது எங்களிடம் ஒரு வேதனையான சிக்கல் உள்ளது.
உண்மையில், இது குபெர்னெட்டஸுக்கு மட்டுமே பொருந்தாது; ஒருவித வெகுஜன வளர்ச்சி மற்றும் குறிப்பாக DevOps கலாச்சாரம் குபெர்னெட்டஸின் அதே நேரத்தில் பரவத் தொடங்கியது. எனவே, பொதுவாக, குபெர்னெட்ஸ் இல்லாமல் உங்கள் விண்ணப்பத்தை நீங்கள் அழகாக மூட வேண்டும். குபர்னெட்டஸுக்கு முன்பே, மக்கள் இதைச் செய்தார்கள், ஆனால் குபர்னெட்டஸின் வருகையுடன், நாங்கள் அதைப் பற்றி மொத்தமாகப் பேச ஆரம்பித்தோம்.
அழகான பணிநிறுத்தம்
பொதுவாக, கிரேஸ்ஃபுல் ஷட் டவுன் என்றால் என்ன, அது ஏன் தேவைப்படுகிறது? சில காரணங்களால் உங்கள் பயன்பாடு செயலிழக்கும்போது, நீங்கள் செய்ய வேண்டியது இது app stop - அல்லது நீங்கள் எடுத்துக்காட்டாக, இயக்க முறைமையிலிருந்து ஒரு சமிக்ஞையைப் பெறுகிறீர்கள், உங்கள் பயன்பாடு அதைப் புரிந்துகொண்டு அதைப் பற்றி ஏதாவது செய்ய வேண்டும். உங்கள் விண்ணப்பம் SIGTERMஐப் பெறும்போது, "SIGTERM, தொடருவோம், வேலை செய்யுங்கள், ஒன்றும் செய்யாதீர்கள்" என்பது போன்ற மோசமான சூழ்நிலை நிச்சயமாக உள்ளது. இது முற்றிலும் மோசமான விருப்பம்.
உங்கள் விண்ணப்பம் ஒரு SIGTERM ஐப் பெறும்போது, “அவர்கள் செக்டெர்ம் என்று சொன்னால், நாங்கள் முடிவடைகிறோம், நான் பார்க்கவில்லை, எந்த பயனர் கோரிக்கையும் எனக்குத் தெரியாது, என்ன மாதிரியானவை என்று எனக்குத் தெரியவில்லை” என்பது கிட்டத்தட்ட சமமான மோசமான விருப்பமாகும். நான் இப்போது பணிபுரியும் கோரிக்கைகள், அவர்கள் SIGTERM என்று சொன்னார்கள், அதாவது நாங்கள் முடிக்கிறோம் " இதுவும் ஒரு மோசமான விருப்பம்.
எந்த விருப்பம் நல்லது? முதல் புள்ளி, செயல்பாடுகளின் நிறைவை கணக்கில் எடுத்துக்கொள்ள வேண்டும். உங்கள் சேவையகம் SIGTERMஐப் பெற்றால் அது என்ன செய்கிறது என்பதைக் கணக்கில் எடுத்துக்கொள்வது ஒரு நல்ல வழி.
SIGTERM என்பது ஒரு மென்மையான பணிநிறுத்தம், இது சிறப்பாக வடிவமைக்கப்பட்டுள்ளது, இது குறியீட்டு மட்டத்தில் இடைமறிக்கப்படலாம், செயலாக்க முடியும், இப்போது, காத்திருங்கள், முதலில் நம்மிடம் உள்ள வேலையை முடிப்போம், பின்னர் வெளியேறுவோம்.
குபெர்னெட்டஸ் கண்ணோட்டத்தில், இது போல் தெரிகிறது. குபெர்னெட்டஸ் கிளஸ்டரில் இயங்கும் ஒரு பானிடம், "தயவுசெய்து நிறுத்துங்கள், விலகிச் செல்லுங்கள்" அல்லது மறுதொடக்கம் ஏற்படும் அல்லது குபெர்னெட்டஸ் காய்களை மீண்டும் உருவாக்கும்போது ஒரு புதுப்பிப்பு ஏற்படும் போது, குபெர்னெட்ஸ் அதே SIGTERM செய்தியை பாட்க்கு அனுப்புகிறார், காத்திருக்கிறார் சில நேரம், மற்றும் , இது அவர் காத்திருக்கும் நேரம், இதுவும் கட்டமைக்கப்பட்டுள்ளது, டிப்ளோமாக்களில் இது போன்ற ஒரு சிறப்பு அளவுரு உள்ளது மற்றும் அது கிரேஸ்ஃபுல் ஷட் டவுன் டைம்அவுட் என்று அழைக்கப்படுகிறது. நீங்கள் புரிந்து கொண்டபடி, அது ஒன்றும் இல்லை என்று அழைக்கப்படவில்லை, இப்போது நாம் அதைப் பற்றி பேசுவது ஒன்றும் இல்லை.
பயன்பாட்டிற்கு SIGTERM ஐ அனுப்பும் நேரத்திற்கு இடையில் எவ்வளவு நேரம் காத்திருக்க வேண்டும் என்பதையும், பயன்பாடு ஏதோவொன்றிற்காக பைத்தியமாகிவிட்டதாகவோ அல்லது “சிக்கிக்கொண்டதாகவோ” தெரிகிறது மற்றும் அது முடிவடையப் போவதில்லை என்பதை நாம் புரிந்து கொள்ளும்போது, எவ்வளவு நேரம் காத்திருக்க வேண்டும் என்பதை நாம் குறிப்பாகச் சொல்லலாம். அதை SIGKILL ஐ அனுப்பவும், அதாவது அதன் வேலையை கடினமாக முடிக்கவும். அதாவது, அதற்கேற்ப, எங்களிடம் சில வகையான டீமான் இயங்குகிறது, இது செயல்பாடுகளை செயல்படுத்துகிறது. சராசரியாக டீமான் செயல்படும் எங்கள் செயல்பாடுகள் ஒரு நேரத்தில் 30 வினாடிகளுக்கு மேல் நீடிக்காது என்பதை நாங்கள் புரிந்துகொள்கிறோம். அதன்படி, SIGTERM வரும்போது, SIGTERMக்குப் பிறகு அதிகபட்சமாக 30 வினாடிகளுக்குப் பிறகு நமது டீமான் முடிக்க முடியும் என்பதை நாங்கள் புரிந்துகொள்கிறோம். நாம் அதை எழுதுகிறோம், உதாரணமாக, 45 வினாடிகள் ஒரு சந்தர்ப்பத்தில் மற்றும் SIGTERM என்று கூறுகிறோம். அதன் பிறகு 45 வினாடிகள் காத்திருக்கிறோம். கோட்பாட்டில், இந்த நேரத்தில் பேய் தனது வேலையை முடித்து தன்னை முடித்திருக்க வேண்டும். ஆனால் திடீரென்று அது முடியவில்லை என்றால், அது பெரும்பாலும் சிக்கிக்கொண்டது என்று அர்த்தம் - இது இனி எங்கள் கோரிக்கைகளை சாதாரணமாகச் செயல்படுத்தாது. மேலும் 45 வினாடிகளில் நீங்கள் அவரை பாதுகாப்பாக கீழே இறக்கிவிடலாம்.
இங்கே, உண்மையில், 2 அம்சங்களைக் கூட கணக்கில் எடுத்துக்கொள்ளலாம். முதலில், நீங்கள் ஒரு கோரிக்கையைப் பெற்றிருந்தால், நீங்கள் எப்படியாவது அதனுடன் வேலை செய்யத் தொடங்கினீர்கள், மேலும் பயனருக்குப் பதிலைக் கொடுக்கவில்லை, ஆனால் நீங்கள் SIGTERM ஐப் பெற்றீர்கள், எடுத்துக்காட்டாக. அதைச் செம்மைப்படுத்தி பயனருக்குப் பதிலளிப்பது அர்த்தமுள்ளதாக இருக்கிறது. இந்த விஷயத்தில் இதுவே முதலிடத்தில் உள்ளது. இங்கே புள்ளி எண் இரண்டு என்னவென்றால், நீங்கள் உங்கள் சொந்த விண்ணப்பத்தை எழுதினால், பொதுவாக உங்கள் விண்ணப்பத்திற்கான கோரிக்கையைப் பெறும் வகையில் கட்டமைப்பை உருவாக்குங்கள், பின்னர் நீங்கள் சில வேலைகளைத் தொடங்குங்கள், எங்கிருந்தோ கோப்புகளை பதிவிறக்கம் செய்யத் தொடங்குங்கள், தரவுத்தளத்தைப் பதிவிறக்குவது மற்றும் என்ன செய்வது. - அந்த. பொதுவாக, உங்கள் பயனர், உங்கள் கோரிக்கை அரை மணி நேரம் தொங்குகிறது மற்றும் நீங்கள் அவருக்கு பதிலளிக்க காத்திருக்கிறது - பின்னர், பெரும்பாலும், நீங்கள் கட்டிடக்கலை வேலை செய்ய வேண்டும். அதாவது, உங்கள் செயல்பாடுகள் குறுகியதாக இருந்தால், SIGTERM ஐப் புறக்கணித்து அதை மாற்றியமைப்பது அர்த்தமுள்ளதாக இருக்கும் என்ற பொது அறிவையும் கணக்கில் எடுத்துக்கொள்ளுங்கள். உங்கள் செயல்பாடுகள் நீண்டதாக இருந்தால், இந்த விஷயத்தில் SIGTERM ஐ புறக்கணிப்பதில் அர்த்தமில்லை. இது போன்ற நீண்ட செயல்பாடுகளைத் தவிர்க்க கட்டிடக்கலையை மறுவடிவமைப்பு செய்வது அர்த்தமுள்ளதாக இருக்கிறது. அதனால் பயனர்கள் சுற்றித் திரிந்து காத்திருக்க வேண்டாம். எனக்குத் தெரியாது, அங்கு ஒருவித வெப்சாக்கெட்டை உருவாக்கவும், உங்கள் சர்வர் ஏற்கனவே கிளையண்டிற்கு அனுப்பும் ரிவர்ஸ் ஹூக்குகளை உருவாக்கவும், வேறு எதையும் செய்யவும், ஆனால் பயனரை அரை மணி நேரம் செயலிழக்கச் செய்ய வேண்டாம், நீங்கள் அமர்வுக்கு காத்திருக்கவும். அவனுக்கு பதில் சொல்லு. ஏனெனில் அது எங்கே உடைந்து விடும் என்று கணிக்க முடியாது.
உங்கள் விண்ணப்பம் முடிவடையும் போது, நீங்கள் சில பொருத்தமான வெளியேறும் குறியீட்டை வழங்க வேண்டும். அதாவது, உங்கள் விண்ணப்பத்தை மூட, நிறுத்தும்படி கேட்கப்பட்டால், அது சாதாரணமாக தன்னைத்தானே நிறுத்திக்கொள்ள முடிந்தால், நீங்கள் சில வகையான வெளியேறும் குறியீடு 1,5,255 மற்றும் பலவற்றைத் திருப்பித் தர வேண்டியதில்லை. பூஜ்ஜியக் குறியீடு இல்லாத எதுவும், குறைந்தபட்சம் லினக்ஸ் கணினிகளில், இது தோல்வியுற்றதாகக் கருதப்படுகிறது. அதாவது, இந்த வழக்கில் உங்கள் விண்ணப்பம் பிழையுடன் முடிந்ததாகக் கருதப்படுகிறது. அதன்படி, இணக்கமான முறையில், உங்கள் விண்ணப்பம் பிழையின்றி பூர்த்தி செய்யப்பட்டால், வெளியீட்டில் 0 என்று கூறுகிறீர்கள். சில காரணங்களால் உங்கள் விண்ணப்பம் தோல்வியடைந்தால், வெளியீட்டில் 0 அல்லாதது எனக் கூறுவீர்கள். இந்த தகவலுடன் நீங்கள் வேலை செய்யலாம்.
மற்றும் கடைசி விருப்பம். உங்கள் பயனர் கோரிக்கையை அனுப்பினால், அதைச் செயல்படுத்தும் போது அரை மணி நேரம் செயலிழக்கச் செய்தால் அது மோசமானது. ஆனால் பொதுவாக, வாடிக்கையாளரின் தரப்பிலிருந்து பொதுவாக மதிப்புக்குரியது என்ன என்பதையும் நான் சொல்ல விரும்புகிறேன். உங்களிடம் மொபைல் பயன்பாடு, முன்-முனை போன்றவை இருந்தால் பரவாயில்லை. பொதுவாக பயனரின் அமர்வு நிறுத்தப்படலாம், எதுவும் நடக்கலாம் என்பதை கணக்கில் எடுத்துக்கொள்வது அவசியம். ஒரு கோரிக்கை அனுப்பப்படலாம், எடுத்துக்காட்டாக, செயலாக்கம் குறைவாக உள்ளது மற்றும் எந்த பதிலும் இல்லை. உங்கள் முன்பக்கம் அல்லது உங்கள் மொபைல் அப்ளிகேஷன் - பொதுவாக எந்த முன்பக்கமும், அதை அப்படியே வைத்துக் கொள்வோம் - இதை கணக்கில் எடுத்துக்கொள்ள வேண்டும். நீங்கள் வெப்சாக்கெட்டுகளுடன் பணிபுரிந்தால், இது பொதுவாக நான் அனுபவித்த மிக மோசமான வலி.
சில வழக்கமான அரட்டைகளின் டெவலப்பர்களுக்கு இது தெரியாதபோது, வெப்சாக்கெட் உடைந்துவிடும். அவர்களுக்கு, ப்ராக்ஸியில் ஏதாவது நடக்கும் போது, நாங்கள் கட்டமைப்பை மாற்றுவோம், அது மீண்டும் ஏற்றப்படும். இயற்கையாகவே, இந்த வழக்கில் அனைத்து நீண்ட கால அமர்வுகளும் கிழிந்தன. டெவலப்பர்கள் எங்களிடம் ஓடி வந்து சொல்கிறார்கள்: "நண்பர்களே, நீங்கள் என்ன செய்கிறீர்கள், எங்கள் வாடிக்கையாளர்களுக்கு அரட்டை உடைந்து விட்டது!" நாங்கள் அவர்களிடம் சொல்கிறோம்: "நீங்கள் என்ன செய்கிறீர்கள்? உங்கள் வாடிக்கையாளர்களை மீண்டும் இணைக்க முடியவில்லையா? அவர்கள் கூறுகிறார்கள்: "இல்லை, அமர்வுகள் கிழிக்கப்படாமல் இருக்க வேண்டும்." சுருக்கமாக, இது உண்மையில் முட்டாள்தனம். வாடிக்கையாளர் பக்கத்தை கணக்கில் எடுத்துக்கொள்ள வேண்டும். குறிப்பாக, நான் சொல்வது போல், வெப்சாக்கெட்டுகள் போன்ற நீண்ட கால அமர்வுகளில், அது உடைந்து, பயனரால் கவனிக்கப்படாமல், நீங்கள் அத்தகைய அமர்வுகளை மீண்டும் நிறுவ முடியும். பின்னர் எல்லாம் சரியானது.
Ресурсы
உண்மையில், இங்கே நான் உங்களுக்கு ஒரு நேரடியான கதையைச் சொல்கிறேன். மீண்டும் நிஜ வாழ்க்கையிலிருந்து. வளங்களைப் பற்றி நான் கேள்விப்பட்டதில் மிக மோசமான விஷயம்.
இந்த விஷயத்தில் உள்ள ஆதாரங்கள், அதாவது, சில வகையான கோரிக்கைகள், உங்கள் குபெர்னெட்டஸ் கிளஸ்டர்களில் நீங்கள் போடக்கூடிய வரம்புகள். ஒரு டெவலப்பரிடமிருந்து நான் கேள்விப்பட்ட வேடிக்கையான விஷயம்... முந்தைய பணியிடத்தில் எனது சக டெவலப்பர்களில் ஒருவர் ஒருமுறை கூறினார்: "எனது விண்ணப்பம் கிளஸ்டரில் தொடங்காது." அது தொடங்கவில்லை என்பதை நான் பார்த்தேன், ஆனால் அது ஆதாரங்களுக்கு பொருந்தவில்லை, அல்லது அவை மிகச் சிறிய வரம்புகளை அமைத்துள்ளன. சுருக்கமாக, ஆதாரங்கள் காரணமாக பயன்பாடு தொடங்க முடியாது. நான் சொல்கிறேன்: "ஆதாரங்கள் காரணமாக இது தொடங்காது, உங்களுக்கு எவ்வளவு தேவை என்பதை நீங்கள் முடிவு செய்து போதுமான மதிப்பை அமைக்கவும்." அவர் கூறுகிறார்: "என்ன வகையான வளங்கள்?" Kubernetes, கோரிக்கைகளுக்கான வரம்புகள் மற்றும் blah, blah, blah அமைக்கப்பட வேண்டும் என்பதை நான் அவருக்கு விளக்க ஆரம்பித்தேன். அந்த நபர் ஐந்து நிமிடங்கள் கேட்டு, தலையசைத்து கூறினார்: “நான் ஒரு டெவலப்பராக வேலை செய்ய இங்கு வந்தேன், எந்த ஆதாரங்களையும் பற்றி நான் எதுவும் தெரிந்து கொள்ள விரும்பவில்லை. நான் இங்கே குறியீடு எழுத வந்தேன், அவ்வளவுதான். வருத்தமாக இருக்கிறது. டெவலப்பரின் பார்வையில் இது மிகவும் சோகமான கருத்து. குறிப்பாக நவீன உலகில், முற்போக்கான டெவொப்ஸ் பற்றி பேசலாம்.
ஆதாரங்கள் ஏன் தேவைப்படுகின்றன? குபர்நெட்டஸில் 2 வகையான வளங்கள் உள்ளன. சில கோரிக்கைகள் என்று அழைக்கப்படுகின்றன, மற்றவை வரம்புகள் என்று அழைக்கப்படுகின்றன. ஆதாரங்கள் மூலம், அடிப்படையில் எப்போதும் இரண்டு அடிப்படைக் கட்டுப்பாடுகள் மட்டுமே உள்ளன என்பதை நாம் புரிந்துகொள்வோம். அதாவது, குபெர்னெட்ஸில் இயங்கும் ஒரு கொள்கலனுக்கான CPU நேர வரம்புகள் மற்றும் RAM வரம்புகள்.
ஒரு வரம்பு உங்கள் பயன்பாட்டில் வளத்தை எவ்வாறு பயன்படுத்தலாம் என்பதற்கான உச்ச வரம்பை வைக்கிறது. அதாவது, வரம்புகளில் 1ஜிபி ரேம் என்று சொன்னால், உங்கள் அப்ளிகேஷன் 1ஜிபிக்கு மேல் ரேமைப் பயன்படுத்த முடியாது. அவர் திடீரென்று விரும்பி இதைச் செய்ய முயற்சித்தால், ஓம் கில்லர் எனப்படும் ஒரு செயல்முறை, நினைவாற்றலுக்கு அப்பாற்பட்டது, அதாவது, உங்கள் விண்ணப்பத்தை வந்து அழித்துவிடும் - அதாவது, அது வெறுமனே மறுதொடக்கம் செய்யும். CPU அடிப்படையில் பயன்பாடுகள் மறுதொடக்கம் செய்யப்படாது. CPU ஐப் பொறுத்தவரை, ஒரு பயன்பாடு வரம்புகளில் குறிப்பிடப்பட்டதை விட அதிகமாகப் பயன்படுத்த முயற்சித்தால், CPU கண்டிப்பாகத் தேர்ந்தெடுக்கப்படும். இது மறுதொடக்கம் செய்ய வழிவகுக்காது. இதுவே எல்லை - இதுவே மேல் எல்லை.
மற்றும் ஒரு கோரிக்கை உள்ளது. உங்கள் குபெர்னெட்ஸ் கிளஸ்டரில் உள்ள கணுக்கள் எவ்வாறு பயன்பாடுகளால் நிரப்பப்பட்டுள்ளன என்பதை குபெர்னெட்ஸ் எவ்வாறு புரிந்துகொள்கிறார் என்பது கோரிக்கையாகும். அதாவது, கோரிக்கை என்பது உங்கள் விண்ணப்பத்தின் ஒரு வகையான அர்ப்பணிப்பு. நான் பயன்படுத்த விரும்புவதை இது கூறுகிறது: "இவ்வளவு CPU மற்றும் இவ்வளவு நினைவகத்தை எனக்காக ஒதுக்கி வைக்க விரும்புகிறேன்." அத்தகைய எளிமையான ஒப்புமை. மொத்தத்தில் 8 CPUகள் இருக்கும், எனக்குத் தெரியாத ஒரு முனை நம்மிடம் இருந்தால் என்ன செய்வது. ஒரு பாட் அங்கு வருகிறது, அதன் கோரிக்கைகள் 1 CPU என்று கூறுகின்றன, அதாவது முனையில் 7 CPUகள் உள்ளன. அதாவது, 8 காய்கள் இந்த முனைக்கு வந்தவுடன், ஒவ்வொன்றும் அவற்றின் கோரிக்கைகளில் 1 CPU உள்ளது, குபெர்னெட்ஸின் பார்வையில், முனை CPU தீர்ந்து விட்டது, மேலும் கோரிக்கைகளுடன் கூடிய காய்கள் இருக்க முடியாது. இந்த முனையில் தொடங்கப்பட்டது. அனைத்து முனைகளிலும் CPU தீர்ந்துவிட்டால், CPU தீர்ந்துவிட்டதால், உங்கள் காய்களை இயக்குவதற்கு பொருத்தமான கணுக்கள் கிளஸ்டரில் இல்லை என்று Kubernetes சொல்லத் தொடங்கும்.
கோரிக்கைகள் ஏன் தேவை, ஏன் கோரிக்கைகள் இல்லாமல், குபெர்னெட்ஸில் எதையும் தொடங்க வேண்டிய அவசியமில்லை என்று நினைக்கிறேன்? ஒரு கற்பனையான சூழ்நிலையை கற்பனை செய்வோம். கோரிக்கைகள் இல்லாமல் உங்கள் பயன்பாட்டைத் தொடங்குகிறீர்கள், உங்களிடம் எவ்வளவு உள்ளது, எந்த முனைகளுக்கு நீங்கள் அதைத் தள்ளலாம் என்று குபெர்னெட்டஸுக்குத் தெரியாது. சரி, அவர் முனைகளில் தள்ளுகிறார், தள்ளுகிறார், தள்ளுகிறார். ஒரு கட்டத்தில், உங்கள் பயன்பாட்டிற்கு ட்ராஃபிக்கைப் பெறத் தொடங்குவீர்கள். பயன்பாடுகளில் ஒன்று திடீரென்று வரம்புகளுக்கு ஏற்ப வளங்களைப் பயன்படுத்தத் தொடங்குகிறது. அருகிலுள்ள மற்றொரு பயன்பாடு உள்ளது மற்றும் அதற்கு ஆதாரங்களும் தேவை என்று மாறிவிடும். கணு உண்மையில் ஆதாரங்கள் இல்லாமல் இயங்கத் தொடங்குகிறது, எடுத்துக்காட்டாக, OP. கணு உண்மையில் ஆதாரங்கள் இல்லாமல் இயங்கத் தொடங்குகிறது, எடுத்துக்காட்டாக, சீரற்ற அணுகல் நினைவகம் (ரேம்). ஒரு முனையின் சக்தி தீர்ந்துவிட்டால், முதலில் டோக்கர் பதிலளிப்பதை நிறுத்திவிடும், பின்னர் க்யூப்லெட், பின்னர் OS. அவர்கள் வெறுமனே மயக்கமடைந்துவிடுவார்கள், எல்லாமே உங்களுக்காக வேலை செய்வதை நிச்சயமாக நிறுத்திவிடும். அதாவது, இது உங்கள் முனை சிக்கலுக்கு வழிவகுக்கும் மற்றும் நீங்கள் அதை மறுதொடக்கம் செய்ய வேண்டும். சுருக்கமாக, நிலைமை மிகவும் நன்றாக இல்லை.
உங்களிடம் கோரிக்கைகள் இருந்தால், வரம்புகள் மிகவும் வேறுபட்டவை அல்ல, குறைந்தபட்சம் வரம்புகள் அல்லது கோரிக்கைகளை விட பல மடங்கு அதிகமாக இல்லை, பின்னர் நீங்கள் குபெர்னெட்டஸ் கிளஸ்டர்களின் முனைகளில் இதுபோன்ற சாதாரண, பகுத்தறிவு பயன்பாடுகளை நிரப்பலாம். அதே நேரத்தில், குபெர்னெட்டஸ் தோராயமாக எதை எங்கு வைக்கிறது, எந்தெந்த இடத்தில் எவ்வளவு பயன்படுத்தப்படுகிறது என்பதை அறிந்திருக்கிறார். அதாவது, இது போன்ற ஒரு தருணம். அதைப் புரிந்துகொள்வது முக்கியம். இது சுட்டிக்காட்டப்படுவதைக் கட்டுப்படுத்துவது முக்கியம்.
தரவு சேமிப்பு
எங்கள் அடுத்த புள்ளி தரவு சேமிப்பகம் பற்றியது. அவர்களுடன் என்ன செய்வது மற்றும் பொதுவாக, குபெர்னெட்டஸில் விடாமுயற்சியுடன் என்ன செய்வது?
நான் நினைக்கிறேன், மீண்டும், நமக்குள் , குபெர்னெட்டஸில் தரவுத்தளத்தைப் பற்றி ஒரு தலைப்பு இருந்தது. மேலும், "குபெர்னெட்டஸில் ஒரு தரவுத்தளத்தை இயக்க முடியுமா?" என்று கேட்டபோது, உங்கள் சக ஊழியர்கள் உங்களிடம் என்ன சொன்னார்கள் என்பது எனக்குத் தெரியும் என்று எனக்குத் தோன்றுகிறது. சில காரணங்களால், குபர்னெட்டஸில் தரவுத்தளத்தை இயக்க முடியுமா என்று நீங்கள் கேள்வி கேட்டால், அது சாத்தியமற்றது என்று உங்கள் சகாக்கள் உங்களிடம் சொல்ல வேண்டும் என்று எனக்குத் தோன்றுகிறது.
இங்கே தர்க்கம் எளிது. ஒரு வேளை, நான் மீண்டும் ஒருமுறை விளக்குகிறேன், விநியோகிக்கப்பட்ட பிணைய சேமிப்பகத்தின் தவறான-சகிப்புத்தன்மை கொண்ட அமைப்பை உருவாக்க நீங்கள் மிகவும் அருமையான பையனாக இருந்தால், இந்த விஷயத்தில் தரவுத்தளத்தை எவ்வாறு பொருத்துவது, கொள்கலன்களில் உள்ள கிளவுட் நேட்டிவ் எப்படி வேலை செய்ய வேண்டும் என்பதைப் புரிந்து கொள்ளுங்கள். பொதுவாக ஒரு தரவுத்தளத்தில். பெரும்பாலும், அதை எவ்வாறு இயக்குவது என்பது பற்றி உங்களுக்கு எந்த கேள்வியும் இல்லை. உங்களிடம் இதுபோன்ற கேள்வி இருந்தால், அது அனைத்தும் வெளிப்பட்டு, உற்பத்தியில் மரணம் வரை சரியாக நிற்கிறது மற்றும் ஒருபோதும் வீழ்ச்சியடையாது என்பதை உறுதிப்படுத்த விரும்பினால், இது நடக்காது. இந்த அணுகுமுறையால் உங்களை காலில் சுட்டுக்கொள்வது உறுதி. எனவே செய்யாமல் இருப்பது நல்லது.
எங்கள் பயன்பாடு சேமிக்க விரும்பும் தரவு, பயனர்கள் பதிவேற்றும் சில படங்கள், அதன் செயல்பாட்டின் போது எங்கள் பயன்பாடு உருவாக்கும் சில விஷயங்கள், எடுத்துக்காட்டாக, தொடக்கத்தில் நாம் என்ன செய்ய வேண்டும்? குபெர்னெட்டஸில் அவர்களை என்ன செய்வது?
பொதுவாக, சிறப்பாக, ஆம், நிச்சயமாக, குபெர்னெட்டஸ் மிகவும் சிறப்பாக வடிவமைக்கப்பட்டுள்ளது மற்றும் பொதுவாக ஆரம்பத்தில் நிலையற்ற பயன்பாடுகளுக்காக உருவாக்கப்பட்டது. அதாவது, தகவல்களைச் சேமிக்காத பயன்பாடுகளுக்கு. இது உகந்தது.
ஆனால், நிச்சயமாக, சிறந்த விருப்பம் எப்போதும் இல்லை. அதனால் என்ன? முதல் மற்றும் எளிமையான விஷயம் என்னவென்றால், சில வகையான S3 ஐ எடுத்துக்கொள்வது, அது வீட்டில் தயாரிக்கப்பட்டது அல்ல, இது எப்படி வேலை செய்கிறது என்பது தெளிவாகத் தெரியவில்லை, ஆனால் சில வழங்குநரிடமிருந்து. ஒரு நல்ல, சாதாரண வழங்குநர் - மற்றும் S3 ஐப் பயன்படுத்த உங்கள் பயன்பாட்டைக் கற்பிக்கவும். அதாவது, உங்கள் பயனர் ஒரு கோப்பைப் பதிவேற்ற விரும்பினால், "இங்கே, தயவுசெய்து, அதை S3 இல் பதிவேற்றவும்" என்று கூறவும். அவர் அதைப் பெற விரும்பினால், "இங்கே S3க்கான இணைப்பு உள்ளது, அதை இங்கிருந்து எடுங்கள்" என்று கூறுங்கள். இது உகந்தது.
திடீரென்று சில காரணங்களால் இந்த சிறந்த விருப்பம் பொருந்தவில்லை என்றால், நீங்கள் எழுதாத, நீங்கள் உருவாக்காத ஒரு பயன்பாடு உங்களிடம் இருந்தால், அல்லது அது ஒருவித பயங்கரமான மரபு, இது S3 நெறிமுறையைப் பயன்படுத்த முடியாது, ஆனால் உள்ளூர் கோப்பகங்களுடன் வேலை செய்ய வேண்டும். உள்ளூர் கோப்புறைகள். அதிகமாகவோ அல்லது குறைவாகவோ எளிமையான ஒன்றை எடுத்துக் கொள்ளுங்கள், குபெர்னெட்ஸை வரிசைப்படுத்துங்கள். அதாவது, சில குறைந்தபட்ச பணிகளுக்கு உடனடியாக Ceph க்கு வேலி போடுவது ஒரு மோசமான யோசனையாக எனக்குத் தோன்றுகிறது. ஏனெனில் செஃப், நிச்சயமாக, நல்லவர் மற்றும் நாகரீகமானவர். ஆனால் நீங்கள் என்ன செய்கிறீர்கள் என்பதை நீங்கள் உண்மையில் புரிந்து கொள்ளவில்லை என்றால், நீங்கள் Ceph இல் ஏதாவது ஒன்றைப் போட்டால், நீங்கள் அதை மிக எளிதாகவும் எளிதாகவும் அங்கிருந்து வெளியேற முடியாது. ஏனெனில், உங்களுக்குத் தெரிந்தபடி, Ceph அதன் கிளஸ்டரில் தரவை பைனரி வடிவத்தில் சேமிக்கிறது, மற்றும் எளிய கோப்புகளின் வடிவத்தில் அல்ல. எனவே, திடீரென்று Ceph கிளஸ்டர் உடைந்து விட்டால், அங்கிருந்து உங்கள் தரவை மீண்டும் பெற முடியாது என்பதற்கான முழுமையான மற்றும் அதிக நிகழ்தகவு உள்ளது.
செஃப் பற்றிய பாடத்தை நாங்கள் நடத்துவோம், உங்களால் முடியும் .
எனவே, NFS சர்வர் போன்ற எளிமையான ஒன்றைச் செய்வது நல்லது. Kubernetes அவர்களுடன் வேலை செய்யலாம், நீங்கள் ஒரு NFS சேவையகத்தின் கீழ் ஒரு கோப்பகத்தை ஏற்றலாம் - உங்கள் பயன்பாடு ஒரு உள்ளூர் கோப்பகம் போன்றது. அதே நேரத்தில், இயற்கையாகவே, நீங்கள் மீண்டும், உங்கள் NFS உடன் ஏதாவது செய்ய வேண்டும் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும், சில நேரங்களில் அது அணுக முடியாததாகிவிடும் என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும் மற்றும் இந்த விஷயத்தில் நீங்கள் என்ன செய்வீர்கள் என்ற கேள்வியைக் கருத்தில் கொள்ள வேண்டும். ஒருவேளை அது ஒரு தனி இயந்திரத்தில் எங்காவது காப்புப் பிரதி எடுக்கப்பட வேண்டும்.
செயல்பாட்டின் போது உங்கள் பயன்பாடு சில கோப்புகளை உருவாக்கினால் என்ன செய்வது என்பது பற்றி நான் பேசிய அடுத்த புள்ளி. எடுத்துக்காட்டாக, இது தொடங்கும் போது, அது சில நிலையான கோப்பை உருவாக்குகிறது, இது பயன்பாடு தொடங்கும் நேரத்தில் மட்டுமே பெறும் சில தகவல்களை அடிப்படையாகக் கொண்டது. என்ன ஒரு கணம். அத்தகைய தரவு அதிகம் இல்லை என்றால், நீங்கள் கவலைப்பட வேண்டியதில்லை, இந்த பயன்பாட்டை உங்களுக்காக நிறுவி வேலை செய்யுங்கள். இங்கே ஒரே கேள்வி என்ன, பாருங்கள். மிக பெரும்பாலும், வேர்ட்பிரஸ் போன்ற அனைத்து வகையான மரபு அமைப்புகளும், குறிப்பாக சில வகையான புத்திசாலித்தனமான செருகுநிரல்கள், புத்திசாலித்தனமான PHP டெவலப்பர்கள் மாற்றியமைக்கப்பட்டால், அதை எவ்வாறு உருவாக்குவது என்பது அவர்களுக்குத் தெரியும். அதன்படி, ஒன்று ஒரு கோப்பை உருவாக்குகிறது, இரண்டாவது இரண்டாவது கோப்பை உருவாக்குகிறது. அவை வேறுபட்டவை. வாடிக்கையாளர்களின் குபெர்னெட்ஸ் கிளஸ்டரில் சமநிலைப்படுத்துவது தற்செயலாக நடக்கிறது. அதன்படி, அவர்கள் எப்படி ஒன்றாக வேலை செய்வது என்று தெரியவில்லை என்று மாறிவிடும். ஒன்று ஒரு தகவலை அளிக்கிறது, மற்றொன்று பயனருக்கு மற்றொரு தகவலை அளிக்கிறது. இதைத்தான் நீங்கள் தவிர்க்க வேண்டும். அதாவது, Kubernetes இல், நீங்கள் தொடங்கும் அனைத்தும் பல நிகழ்வுகளில் வேலை செய்ய முடியும் என்பது உறுதி. ஏனெனில் குபெர்னெட்ஸ் ஒரு நகரும் விஷயம். அதன்படி, அவர் எப்போது வேண்டுமானாலும், யாரையும் கேட்காமல் எதையும் நகர்த்த முடியும். எனவே, நீங்கள் இதை எண்ண வேண்டும். ஒரு சந்தர்ப்பத்தில் தொடங்கப்பட்ட அனைத்தும் விரைவில் அல்லது பின்னர் தோல்வியடையும். உங்களுக்கு எவ்வளவு இட ஒதுக்கீடு இருக்கிறதோ, அவ்வளவு சிறந்தது. ஆனால் மீண்டும், நான் சொல்கிறேன், உங்களிடம் இதுபோன்ற சில கோப்புகள் இருந்தால், அவற்றை உங்கள் கீழ் வைக்கலாம், அவை ஒரு சிறிய அளவு எடையுள்ளதாக இருக்கும். அவற்றில் இன்னும் கொஞ்சம் இருந்தால், நீங்கள் அவற்றை கொள்கலனுக்குள் தள்ளக்கூடாது.
குபெர்னெட்டஸில் இதுபோன்ற ஒரு அற்புதமான விஷயம் இருப்பதாக நான் அறிவுறுத்துகிறேன், நீங்கள் அளவைப் பயன்படுத்தலாம். குறிப்பாக, காலி டைப் வகையின் தொகுதி உள்ளது. அதாவது, நீங்கள் தொடங்கிய சேவையகத்தில் குபெர்னெட்ஸ் தானாகவே அதன் சேவை கோப்பகங்களில் ஒரு கோப்பகத்தை உருவாக்கும். நீங்கள் அதைப் பயன்படுத்திக்கொள்ள அவர் அதை உங்களுக்குக் கொடுப்பார். ஒரே ஒரு முக்கியமான புள்ளி உள்ளது. அதாவது, உங்கள் தரவு கொள்கலனுக்குள் சேமிக்கப்படாது, மாறாக நீங்கள் இயங்கும் ஹோஸ்டில் சேமிக்கப்படும். மேலும், குபெர்னெட்ஸ் சாதாரண உள்ளமைவின் கீழ் இத்தகைய வெற்று டயர்களைக் கட்டுப்படுத்த முடியும் மற்றும் அவற்றின் அதிகபட்ச அளவைக் கட்டுப்படுத்த முடியும் மற்றும் அதை மீற அனுமதிக்காது. பாட் ரீஸ்டார்ட் செய்யும் போது நீங்கள் வெற்று டைரில் எழுதியது தொலைந்து போகவில்லை என்பது தான் ஒரே விஷயம். அதாவது, உங்கள் காய் தவறுதலாக விழுந்து மீண்டும் உயர்ந்தால், காலியான டிரில் உள்ள தகவல்கள் எங்கும் செல்லாது. புதிய தொடக்கத்தில் அவர் அதை மீண்டும் பயன்படுத்தலாம் - அது நல்லது. உங்கள் நெற்று எங்காவது வெளியேறினால், இயற்கையாகவே அவர் தரவு இல்லாமல் வெளியேறுவார். அதாவது, வெற்று டைருடன் தொடங்கப்பட்ட முனையிலிருந்து பாட் மறைந்தவுடன், வெற்று டைர் நீக்கப்படும்.
வெற்று டைரில் வேறு என்ன நல்லது? உதாரணமாக, இது ஒரு தற்காலிக சேமிப்பாக பயன்படுத்தப்படலாம். எங்கள் பயன்பாடு பறக்கும்போது எதையாவது உருவாக்குகிறது, பயனர்களுக்குக் கொடுக்கிறது மற்றும் அதை நீண்ட நேரம் செய்கிறது என்று கற்பனை செய்யலாம். எனவே, பயன்பாடு, எடுத்துக்காட்டாக, அதை உருவாக்கி பயனர்களுக்குக் கொடுக்கிறது, அதே நேரத்தில் அதை எங்காவது சேமித்து வைக்கிறது, இதனால் அடுத்த முறை பயனர் அதே விஷயத்திற்கு வரும்போது, உடனடியாக அதை உருவாக்குவது வேகமாக இருக்கும். நினைவகத்தில் உருவாக்க குபெர்னெட்டஸிடம் காலியான தீர்வைக் கேட்கலாம். இதனால், உங்கள் தற்காலிக சேமிப்புகள் பொதுவாக மின்னல் வேகத்தில் வேலை செய்யும் - வட்டு அணுகல் வேகத்தின் அடிப்படையில். அதாவது, உங்களிடம் நினைவகத்தில் ஒரு வெற்று டயர் உள்ளது, OS இல் அது நினைவகத்தில் சேமிக்கப்படுகிறது, ஆனால் உங்களுக்காக, பாட்டின் உள்ளே இருக்கும் பயனருக்கு, இது ஒரு உள்ளூர் கோப்பகமாகத் தெரிகிறது. குறிப்பாக எந்த மந்திரத்தையும் கற்பிக்க உங்களுக்கு ஆப்ஸ் தேவையில்லை. நீங்கள் நேரடியாக எடுத்து உங்கள் கோப்பை ஒரு கோப்பகத்தில் வைக்கிறீர்கள், ஆனால், உண்மையில், OS இல் நினைவகத்தில். குபர்னெட்டஸின் அடிப்படையில் இது மிகவும் வசதியான அம்சமாகும்.
மினியோவுக்கு என்ன பிரச்சனைகள் உள்ளன? மினியோவின் முக்கிய பிரச்சனை என்னவென்றால், இந்த விஷயம் வேலை செய்ய, அது எங்காவது இயங்க வேண்டும், மேலும் சில வகையான கோப்பு முறைமை இருக்க வேண்டும், அதாவது சேமிப்பகம். Cep க்கு இருக்கும் அதே பிரச்சனைகளை இங்கே நாம் சந்திக்கிறோம். அதாவது, மினியோ அதன் கோப்புகளை எங்காவது சேமிக்க வேண்டும். இது உங்கள் கோப்புகளுக்கான HTTP இடைமுகம். மேலும், செயல்பாடு அமேசானின் S3 ஐ விட மோசமாக உள்ளது. முன்னதாக, பயனரை சரியாக அங்கீகரிக்க முடியவில்லை. இப்போது, எனக்குத் தெரிந்தவரை, இது ஏற்கனவே வெவ்வேறு அங்கீகாரங்களுடன் வாளிகளை உருவாக்க முடியும், ஆனால் மீண்டும், முக்கிய பிரச்சனை, குறைந்தபட்சம் அடிப்படை சேமிப்பக அமைப்பு என்று எனக்குத் தோன்றுகிறது.
நினைவகத்தில் உள்ள Empty dir வரம்புகளை எவ்வாறு பாதிக்கிறது? எந்த வகையிலும் வரம்புகளை பாதிக்காது. இது ஹோஸ்டின் நினைவகத்தில் உள்ளது, உங்கள் கொள்கலனின் நினைவகத்தில் இல்லை. அதாவது, உங்கள் கொள்கலன் அதன் ஆக்கிரமிக்கப்பட்ட நினைவகத்தின் ஒரு பகுதியாக நினைவகத்தில் உள்ள காலியான டிரைக் காணாது. தொகுப்பாளர் இதைப் பார்க்கிறார். அதன்படி, ஆம், குபெர்னெட்டஸின் பார்வையில், நீங்கள் இதைப் பயன்படுத்தத் தொடங்கும் போது, உங்கள் நினைவகத்தின் ஒரு பகுதியை வெற்று தீர்விற்கு அர்ப்பணிக்கிறீர்கள் என்பதைப் புரிந்துகொள்வது நல்லது. அதற்கேற்ப, பயன்பாடுகள் காரணமாக மட்டுமல்ல, இந்த வெற்று டயர்களுக்கு யாரோ எழுதுவதால் நினைவகம் தீர்ந்துவிடும் என்பதை புரிந்து கொள்ளுங்கள்.
Cloudnativeness
Cloudnative என்றால் என்ன என்பதுதான் இறுதி துணை தலைப்பு. அது ஏன் தேவைப்படுகிறது? Cloudnativeness மற்றும் பல.
அதாவது, நவீன கிளவுட் உள்கட்டமைப்பில் வேலை செய்யும் திறன் மற்றும் எழுதப்பட்ட பயன்பாடுகள். ஆனால், உண்மையில், கிளவுட்நேட்டிவ் அத்தகைய மற்றொரு அம்சத்தைக் கொண்டுள்ளது. இது ஒரு நவீன கிளவுட் உள்கட்டமைப்பின் அனைத்து தேவைகளையும் கணக்கில் எடுத்துக்கொள்ளும் ஒரு பயன்பாடு மட்டுமல்ல, இந்த நவீன கிளவுட் உள்கட்டமைப்புடன் எவ்வாறு செயல்படுவது என்பதும் தெரியும், இந்த மேகங்களில் இது வேலை செய்வதன் நன்மைகள் மற்றும் தீமைகளைப் பயன்படுத்திக் கொள்ளுங்கள். மிகையாகச் சென்று மேகங்களில் வேலை செய்யாதீர்கள், ஆனால் கிளவுட்டில் வேலை செய்வதன் நன்மைகளைப் பயன்படுத்திக் கொள்ளுங்கள்.
குபர்னெட்டஸை ஒரு உதாரணத்திற்கு எடுத்துக்கொள்வோம். உங்கள் பயன்பாடு குபெர்னெட்டஸில் இயங்குகிறது. உங்கள் விண்ணப்பம் எப்போதுமே அல்லது உங்கள் பயன்பாட்டிற்கான நிர்வாகிகள் எப்போதும் சேவைக் கணக்கை உருவாக்க முடியும். அதாவது, குபெர்னெட்டஸில் உள்ள அங்கீகாரத்திற்கான கணக்கு அதன் சர்வரிலேயே உள்ளது. நமக்குத் தேவையான சில உரிமைகளைச் சேர்க்கவும். உங்கள் பயன்பாட்டிலிருந்து குபெர்னெட்ஸை அணுகலாம். இந்த வழியில் நீங்கள் என்ன செய்ய முடியும்? எடுத்துக்காட்டாக, பயன்பாட்டிலிருந்து, உங்களின் பிற பயன்பாடுகள், இதே போன்ற பிற நிகழ்வுகள் எங்கு உள்ளன என்பதைப் பற்றிய தரவைப் பெறுங்கள், மேலும் அத்தகைய தேவை இருந்தால், எப்படியாவது குபெர்னெட்டஸின் மேல் கிளஸ்டர் செய்யுங்கள்.
மீண்டும், சமீபத்தில் எங்களுக்கு ஒரு வழக்கு இருந்தது. வரிசையை கண்காணிக்கும் ஒரு கட்டுப்படுத்தி எங்களிடம் உள்ளது. இந்த வரிசையில் சில புதிய பணிகள் தோன்றும்போது, அது குபெர்னெட்டஸுக்குச் செல்கிறது - மேலும் குபெர்னெட்டஸின் உள்ளே அது ஒரு புதிய பாட் உருவாக்குகிறது. இந்த பாட் சில புதிய பணிகளை வழங்குகிறது மற்றும் இந்த பாட்டின் கட்டமைப்பிற்குள், பாட் பணியைச் செய்கிறது, கட்டுப்படுத்திக்கு ஒரு பதிலை அனுப்புகிறது, மேலும் கட்டுப்படுத்தி இந்தத் தகவலைக் கொண்டு ஏதாவது செய்கிறது. எடுத்துக்காட்டாக, இது ஒரு தரவுத்தளத்தை சேர்க்கிறது. அதாவது, மீண்டும், இது எங்கள் பயன்பாடு குபெர்னெட்ஸில் இயங்குகிறது என்பதன் ஒரு பிளஸ் ஆகும். எப்படியாவது விரிவடைந்து, எங்கள் பயன்பாட்டின் செயல்பாட்டை மிகவும் வசதியாக மாற்ற, உள்ளமைக்கப்பட்ட குபெர்னெட்ஸ் செயல்பாட்டைப் பயன்படுத்தலாம். அதாவது, ஒரு பயன்பாட்டை எவ்வாறு தொடங்குவது, ஒரு தொழிலாளியை எவ்வாறு தொடங்குவது என்பது பற்றிய சில வகையான மந்திரங்களை மறைக்க வேண்டாம். குபெர்னெட்டஸில், விண்ணப்பம் பைத்தானில் எழுதப்பட்டிருந்தால், பயன்பாட்டில் கோரிக்கையை அனுப்பலாம்.
குபெர்னெட்டஸுக்கு அப்பால் சென்றாலும் இதுவே பொருந்தும். எங்களிடம் எங்கள் குபெர்னெட்கள் எங்காவது இயங்குகின்றன - அது ஒருவித மேகக்கட்டத்தில் இருந்தால் நல்லது. மீண்டும், நாம் இயங்கும் மேகத்தின் திறன்களை நாம் பயன்படுத்தலாம் மற்றும் பயன்படுத்த வேண்டும் என்று நான் நம்புகிறேன். மேகம் நமக்கு வழங்கும் அடிப்படை விஷயங்களிலிருந்து. சமநிலைப்படுத்துதல், அதாவது, கிளவுட் பேலன்சர்களை உருவாக்கி அவற்றைப் பயன்படுத்தலாம். இது நாம் பயன்படுத்தக்கூடியவற்றின் நேரடி நன்மை. ஏனெனில் கிளவுட் பேலன்சிங், முதலில், அது எவ்வாறு செயல்படுகிறது, எப்படி கட்டமைக்கப்படுகிறது என்பதற்கான பொறுப்பை முட்டாள்தனமாக நம்மிடமிருந்து நீக்குகிறது. மேலும் இது மிகவும் வசதியானது, ஏனென்றால் வழக்கமான குபெர்னெட்ஸ் மேகங்களுடன் ஒருங்கிணைக்க முடியும்.
அளவிடுதலுக்கும் இதுவே செல்கிறது. வழக்கமான Kubernetes கிளவுட் வழங்குநர்களுடன் ஒருங்கிணைக்க முடியும். கொத்து கணுக்கள் தீர்ந்துவிட்டால், அதாவது, முனையின் இடம் தீர்ந்துவிட்டால், நீங்கள் சேர்க்க வேண்டும் - குபெர்னெட்டஸ் உங்கள் கிளஸ்டரில் புதிய முனைகளைச் சேர்த்து, அவற்றில் காய்களைத் தொடங்கத் தொடங்கும். அதாவது, உங்கள் சுமை வரும்போது, அடுப்புகளின் எண்ணிக்கை அதிகரிக்கத் தொடங்குகிறது. இந்த காய்களுக்கு கிளஸ்டரில் உள்ள கணுக்கள் தீர்ந்துவிட்டால், குபெர்னெட்டஸ் புதிய முனைகளை அறிமுகப்படுத்துகிறது, அதன்படி, காய்களின் எண்ணிக்கை இன்னும் அதிகரிக்கலாம். மேலும் இது மிகவும் வசதியானது. பறக்கும்போது கொத்துக்களை அளவிட இது ஒரு நேரடி வாய்ப்பு. மிக வேகமாக இல்லை, இது ஒரு நொடி அல்ல, புதிய முனைகளைச் சேர்க்க ஒரு நிமிடம் போன்றது.
ஆனால் எனது அனுபவத்திலிருந்து, மீண்டும், இது நான் பார்த்ததிலேயே மிகச்சிறந்த விஷயம். Cloudnative கிளஸ்டர் நாளின் நேரத்தை அடிப்படையாகக் கொண்டு அளவிடப்படும் போது. இது ஒரு பின்நிலை சேவையாகும், இது பின் அலுவலகத்தில் உள்ளவர்களால் பயன்படுத்தப்பட்டது. அதாவது, அவர்கள் காலை 9 மணிக்கு வேலைக்கு வருகிறார்கள், கணினியில் உள்நுழையத் தொடங்குகிறார்கள், அதன்படி, கிளவுட்நேட்டிவ் கிளஸ்டர், அனைத்தும் இயங்கும் இடத்தில், வீங்கத் தொடங்குகிறது, புதிய காய்களைத் தொடங்குகிறது, இதனால் வேலைக்கு வரும் அனைவரும் பயன்பாட்டுடன் வேலை செய்யலாம். இரவு 8 மணி அல்லது மாலை 6 மணிக்கு அவர்கள் வேலையை விட்டு வெளியேறும் போது, குபெர்னெட்ஸ் கிளஸ்டர்கள் இனி யாரும் அப்ளிகேஷனைப் பயன்படுத்துவதில்லை என்பதைக் கவனித்து சுருங்கத் தொடங்கும். 30 சதவீதம் வரை சேமிப்பு உத்தரவாதம். அந்த நேரத்தில் இது அமேசானில் வேலை செய்தது; அந்த நேரத்தில் ரஷ்யாவில் இதை இவ்வளவு சிறப்பாக செய்யக்கூடியவர்கள் யாரும் இல்லை.
நான் உங்களுக்கு நேரடியாகச் சொல்கிறேன், நாங்கள் குபெர்னெட்ஸைப் பயன்படுத்துவதாலும், மேகக்கணியின் திறன்களைப் பயன்படுத்திக் கொள்வதாலும், சேமிப்பு 30 சதவிகிதம். இப்போது இது ரஷ்யாவில் செய்யப்படலாம். நிச்சயமாக நான் யாருக்கும் விளம்பரம் செய்ய மாட்டேன், ஆனால் இதைச் செய்யக்கூடிய வழங்குநர்கள் உள்ளனர் என்று சொல்லலாம், அதை ஒரு பொத்தானின் பெட்டிக்கு வெளியே வழங்கவும்.
நான் உங்கள் கவனத்தை ஈர்க்க விரும்பும் கடைசி புள்ளி ஒன்று உள்ளது. உங்கள் பயன்பாடு, உங்கள் உள்கட்டமைப்பு Cloudnative ஆக இருக்க, இறுதியாக Infrastructure எனப்படும் அணுகுமுறையை ஒரு குறியீடாக மாற்றியமைக்கத் தொடங்குவது அர்த்தமுள்ளதாக இருக்கும். அதாவது, உங்கள் விண்ணப்பம் அல்லது உங்கள் உள்கட்டமைப்பு, சரியாக அதே வழியில் தேவைப்படுகிறது. குறியீடு உங்கள் விண்ணப்பம், உங்கள் வணிக தர்க்கத்தை குறியீடு வடிவில் விவரிக்கவும். அதைக் குறியீடாகக் கொண்டு வேலை செய்யுங்கள், அதாவது, அதைச் சோதித்து, உருட்டவும், கிட்டில் சேமித்து வைக்கவும், அதற்கு சிஐசிடியைப் பயன்படுத்தவும்.
இதுவே, முதலாவதாக, உங்கள் உள்கட்டமைப்பின் மீது எப்போதும் கட்டுப்பாட்டைக் கொண்டிருக்கவும், அது எந்த நிலையில் உள்ளது என்பதைப் புரிந்துகொள்ளவும் உங்களை அனுமதிக்கிறது. இரண்டாவதாக, பிழைகளை ஏற்படுத்தும் கைமுறை செயல்பாடுகளைத் தவிர்க்கவும். மூன்றாவதாக, விற்றுமுதல் என்று அழைக்கப்படுவதைத் தவிர்க்கவும், நீங்கள் தொடர்ந்து அதே கையேடு பணிகளைச் செய்ய வேண்டியிருக்கும் போது. நான்காவதாக, தோல்வி ஏற்பட்டால் மிக வேகமாக மீட்க இது உங்களை அனுமதிக்கிறது. ரஷ்யாவில், நான் இதைப் பற்றி பேசும் ஒவ்வொரு முறையும், "ஆமாம், இது தெளிவாக உள்ளது, ஆனால் உங்களிடம் அணுகுமுறைகள் உள்ளன, சுருக்கமாக, எதையும் சரிசெய்ய வேண்டிய அவசியமில்லை." ஆனால் அது உண்மைதான். உங்கள் உள்கட்டமைப்பில் ஏதேனும் உடைந்தால், கிளவுட்நேட்டிவ் அணுகுமுறையின் பார்வையிலும், உள்கட்டமைப்பை ஒரு குறியீடாகப் பார்க்கும் பார்வையிலும், அதைச் சரிசெய்வதற்குப் பதிலாக, சேவையகத்திற்குச் சென்று, உடைந்ததைக் கண்டறிந்து அதைச் சரிசெய்வது எளிது. சேவையகத்தை நீக்கி மீண்டும் உருவாக்கவும். இதையெல்லாம் நான் மீட்டெடுப்பேன்.
இந்த பிரச்சினைகள் அனைத்தும் இன்னும் விரிவாக விவாதிக்கப்படுகின்றன . இணைப்பைப் பின்தொடர்வதன் மூலம் நிரல் மற்றும் நிபந்தனைகளை நீங்கள் அறிந்து கொள்ளலாம். வசதியான விஷயம் என்னவென்றால், ஒரு நாளைக்கு 1-2 மணிநேரம் வீட்டிலிருந்தோ அல்லது வேலையிலோ படிப்பதன் மூலம் நீங்கள் குபெர்னெட்டஸில் தேர்ச்சி பெறலாம்.
ஆதாரம்: www.habr.com