Kubernetes හි යෙදුමක් සංවර්ධනය කිරීම සඳහා අවශ්‍යතා

අද මම යෙදුම් ලියන්නේ කෙසේද යන්න සහ Kubernetes හි හොඳින් ක්‍රියා කිරීමට ඔබගේ යෙදුම සඳහා අවශ්‍යතා මොනවාද යන්න ගැන කතා කිරීමට අදහස් කරමි. යෙදුම සමඟ කිසිදු හිසරදයක් ඇති නොවන පරිදි, ඔබට එය වටා “සීරීම්” නිර්මාණය කිරීමට සහ ගොඩනැගීමට අවශ්‍ය නොවේ - සහ සෑම දෙයක්ම කුබර්නෙටස් විසින්ම අදහස් කළ ආකාරයටම ක්‍රියා කරයි.

මෙම දේශනය "" හි කොටසකි.Kubernetes හි Slurm Night School" ඔබට සවස පාසලේ විවෘත න්‍යායාත්මක දේශන නැරඹිය හැකිය Youtube මත, ධාවන ලැයිස්තුවකට සමූහගත කර ඇත. වීඩියෝ වලට වඩා පෙළ කැමති අය සඳහා, අපි මෙම ලිපිය සකස් කර ඇත.

මගේ නම Pavel Selivanov, දැනට මම Mail.ru Cloud Solutions හි ප්‍රමුඛ DevOps ඉංජිනේරුවෙක්, අපි වලාකුළු සාදන්නෙමු, අපි කළමනාකරණ kubernetes සාදන්නෙමු. මගේ කර්තව්‍යයන්ට දැන් සංවර්ධනයට සහාය වීම, මෙම වලාකුළු පෙරළීම, අප ලියන යෙදුම් පෙරළීම සහ අපගේ පරිශීලකයින් සඳහා අප සපයන මෙවලම් කෙලින්ම සංවර්ධනය කිරීම ඇතුළත් වේ.

මම DevOps කරමින් සිටිමි, මම හිතන්නේ පසුගිය, බොහෝ විට, අවුරුදු තුනක් තිස්සේ. නමුත්, ප්‍රතිපත්තිමය වශයෙන්, මම දැන් අවුරුදු පහක පමණ කාලයක් DevOps කරන දේ කරමින් සිටිමි. ඊට කලින් මම වැඩිපුරම සම්බන්ධ වුණේ ඇඩ්මින් වැඩවලට. මම බොහෝ කලකට පෙර Kubernetes සමඟ වැඩ කිරීමට පටන් ගතිමි - මම එය සමඟ වැඩ කිරීමට පටන් ගෙන වසර හතරක් පමණ ගත වී ඇත.

පොදුවේ ගත් කල, මම ආරම්භ කළේ Kubernetes අනුවාදය 1.3 වන විට, බොහෝ විට, සහ සමහර විට 1.2 - එය තවමත් ළදරු අවධියේ සිටියදී. දැන් එය තවදුරටත් ළදරු අවධියේ නැත - කුබර්නෙට්ස් කිරීමට කැමති ඉංජිනේරුවන් සඳහා වෙළඳපොලේ විශාල ඉල්ලුමක් ඇති බව පැහැදිලිය. තවද එවැනි පුද්ගලයින් සඳහා සමාගම් ඉතා ඉහළ ඉල්ලුමක් ඇත. එබැවින්, ඇත්ත වශයෙන්ම, මෙම දේශනය පෙනී සිටියේය.

මම කතා කරන දෙයෙහි සැලැස්මට අනුව අපි කතා කරන්නේ නම්, එය මේ ආකාරයට පෙනේ, වරහන් තුළ එය ලියා ඇත (TL; DR) - “දිග වැඩියි; කියවන්න එපා". අද මගේ ඉදිරිපත් කිරීම නිමක් නැති ලැයිස්තු වලින් සමන්විත වේ.

ඇත්ත වශයෙන්ම, එවැනි ඉදිරිපත් කිරීම් සිදු කරන විට මමම කැමති නැත, නමුත් මෙය එවැනි මාතෘකාවක් වන අතර, මම මෙම ඉදිරිපත් කිරීම සකස් කරන විට, මෙම තොරතුරු වෙනස් ආකාරයකින් සංවිධානය කරන්නේ කෙසේදැයි මම තේරුම් නොගත්තෙමි.

මක්නිසාද යත්, විශාල වශයෙන්, මෙම තොරතුරු “ctrl+c, ctrl+v” වන අතර, වෙනත් දේ අතර, සංවර්ධකයින් සඳහා අපට ලිඛිත අවශ්‍යතා ඇති DevOps කොටසේ අපගේ විකි: “යාලුවනේ, එවිට අපි ඔබේ යෙදුම දියත් කරමු Kubernetes, එය මේ වගේ විය යුතුයි."

ඉදිරිපත් කිරීම එතරම් විශාල ලැයිස්තුවක් බවට පත් වූයේ එබැවිනි. සමාවන්න. පුළුවන් නම් කම්මැලි නොවෙන්න පුළුවන් තරම් කියන්න බලන්නම්.

අපි දැන් බලන්න යන දේ:

• මේවා, පළමුව, ලඝු-සටහන් (යෙදුම් ලඝු?), Kubernetes හි ඔවුන් සමඟ කළ යුතු දේ, ඒවා සමඟ කළ යුතු දේ, ඒවා විය යුතු දේ;
• Kubernetes හි වින්‍යාස කිරීම් සමඟ කළ යුතු දේ, Kubernetes සඳහා යෙදුමක් වින්‍යාස කිරීමට හොඳම සහ නරකම ක්‍රම මොනවාද;
• සාමාන්‍යයෙන් ප්‍රවේශ්‍යතා පිරික්සුම් මොනවාද, ඒවා කෙබඳු විය යුතුද යන්න ගැන කතා කරමු;
• අලංකාර වසා දැමීමක් යනු කුමක්ද යන්න ගැන කතා කරමු;
• අපි නැවතත් සම්පත් ගැන කතා කරමු;
• දත්ත ගබඩා කිරීමේ මාතෘකාව නැවත වරක් ස්පර්ශ කරමු;
• සහ අවසානයේ මම ඔබට කියන්නම් මෙම අද්භූත වලාකුළු-දේශීය යෙදුම යනු කුමක්ද යන්නයි. Cloudnativeness, මෙම පදයේ විශේෂණ පදයක් ලෙස.

සටහන්

මම යෝජනා කරන්නේ ලඝු-සටහන් වලින් ආරම්භ කිරීමටයි - මෙම ලොග Kubernetes හි තල්ලු කළ යුතු ස්ථානය සමඟ. දැන් ඔබ Kubernetes හි යෙදුමක් දියත් කර ඇත. සම්භාව්‍ය වලට අනුව, පෙර යෙදුම් සෑම විටම ගොනුවක කොතැනක හෝ ලඝු-සටහන් ලිවීය. අයහපත් යෙදුම් යෙදුම දියත් කළ සංවර්ධකයාගේ මුල් නාමාවලියෙහි ගොනුවකට ලඝු-සටහන් ලියා ඇත. හොඳ යෙදුම් කොහේ හරි ගොනුවකට ලඝු-සටහන් ලිවීය /var/log.

ඒ අනුව, තව දුරටත්, හොඳ පරිපාලකයින් ඔවුන්ගේ යටිතල ව්‍යුහය තුළ මෙම ලොග් කරකැවිය හැකි සමහර දේවල් වින්‍යාස කර ඇත - එම rsyslog, මෙම ලොග් දෙස බලන අතර ඒවාට යමක් සිදු වූ විට, ඒවායින් බොහොමයක් තිබේ, එය උපස්ථ පිටපත් නිර්මාණය කරයි, ලඝු-සටහන් එහි තබයි. , පැරණි ගොනු මකා දමයි, සතියකට වඩා, මාස හයක් සහ තවත් සමහරක්. න්‍යායාත්මකව, අපට ප්‍රතිපාදන තිබිය යුතු අතර එමඟින් යෙදුම ලඝු-සටහන් ලියන නිසා නිෂ්පාදන සේවාදායකයන්හි (සටන් සේවාදායක?) ඉඩ අවසන් නොවේ. තවද, ඒ අනුව, ලඝු-සටහන් නිසා මුළු නිෂ්පාදනයම නතර නොවීය.

අපි Kubernetes ලෝකයට ගොස් එකම දේ එහි ධාවනය කරන විට, ඔබට අවධානය යොමු කළ හැකි පළමු දෙය නම්, ඔවුන් ගොනුවක ලඝු-සටහන් ලියා ඇති පරිදි, ඒවා දිගටම ලිවීමයි.

අපි Kubernetes ගැන කතා කරන්නේ නම්, ඩොකර් කන්ටේනරයක සිට කොතැනක හෝ ලඝු-සටහන් ලිවීමට සුදුසුම ස්ථානය හුදෙක් යෙදුමේ සිට ඊනියා Stdout/Stderr වෙත, එනම්, මෙහෙයුම් පද්ධතියේ සම්මත ප්‍රතිදාන ප්‍රවාහයන් වෙත ලිවීම බව පෙනේ. සම්මත දෝෂ ප්රතිදානය . මෙය Docker හි සහ විශේෂයෙන්ම Kubernetis හි ප්‍රතිපත්තිමය වශයෙන් ලඝු-සටහන් තැබීමට වඩාත්ම නිවැරදි, සරලම සහ වඩාත්ම තාර්කික ක්‍රමයයි. මක්නිසාද යත් ඔබේ යෙදුම Stdout/Stderr වෙත ලොග ලියන්නේ නම්, මෙම ලොග සමඟ කුමක් කළ යුතුද යන්න තීරණය කිරීම Docker සහ Kubernetes ඇඩෝනයට භාරයි. ඩොකර් පෙරනිමියෙන් එහි විශේෂ ගොනු JSON ආකෘතියෙන් ගොඩනඟයි.

මෙහිදී ප්‍රශ්නය පැනනගින්නේ, මෙම ලඝු-සටහන් සමඟ ඔබ ඊළඟට කරන්නේ කුමක්ද? පහසුම මාර්ගය පැහැදිලිය, අපට කිරීමට හැකියාව ඇත kubectl logs සහ මෙම "පොඩ්" වල මෙම ලඝු-සටහන් දෙස බලන්න. එහෙත්, බොහෝ විට, මෙය ඉතා හොඳ විකල්පයක් නොවේ - ලඝු-සටහන් සමඟ වෙනත් දෙයක් කළ යුතුය.

දැනට, අපි ලඝු-සටහන් මාතෘකාව ස්පර්ශ කළ බැවින්, ලඝු-සටහන් වැනි දෙයක් ගැන අපි එකවරම කතා කරමු. ඒ කියන්නෙ මේක කෙලින්ම Kubernetes ට අදාල නෑ, ඒත් logs වලට මොකද කරන්නෙ කියල හිතන්න පටන් ගත්තම මේ ගැනත් හිතුවොත් හොඳයි.

අපට යම් ආකාරයක මෙවලමක් අවශ්‍ය වේ, මිත්‍රශීලී ආකාරයකින්, එය අපගේ ඩොකර් විසින් ගොනු කරන ලද මෙම ලඝු-සටහන් එහි ගොනු තුළට ගෙන ඒවා කොහේ හෝ යවනු ලැබේ. විශාල වශයෙන්, අපි සාමාන්‍යයෙන් Kubernetes තුළ යම් ආකාරයක නියෝජිතයෙකු දියත් කරන්නෙමු DaemonSet - ලොග් එකතු කරන්නකු, එය ඩොකර් එකතු කරන ලඝු-සටහන් පිහිටා ඇත්තේ කොතැනදැයි සරලව කියනු ලැබේ. මෙම එකතු කිරීමේ නියෝජිතයා ඒවා සරලව ගෙන යයි, සමහර විට ඒවා කෙසේ හෝ විග්‍රහ කරයි, සමහර විට අමතර මෙටා-තොරතුරු වලින් ඒවා පොහොසත් කර, අවසානයේ, ඒවා කොහේ හරි ගබඩා කිරීම සඳහා යවයි. එහි වෙනස්කම් දැනටමත් හැකි ය. වඩාත් සුලභ වන්නේ ඉලාස්ටික් සෙවුම් ය, එහිදී ඔබට ලඝු-සටහන් ගබඩා කළ හැකි අතර ඔබට පහසුවෙන් ඒවා එතැනින් ලබා ගත හැක. ඉන්පසු, ඉල්ලීමක් භාවිතා කිරීම, කිබානා භාවිතා කිරීම, උදාහරණයක් ලෙස, ඒවා මත පදනම්ව ප්‍රස්ථාර තැනීම, ඒවා මත පදනම්ව ඇඟවීම් තැනීම සහ යනාදිය.

වැදගත්ම අදහස, මට එය නැවත නැවත කිරීමට අවශ්‍යයි, ඩොකර් තුළ, විශේෂයෙන් කුබර්නෙටස් තුළ, ඔබේ ලොග් ගොනු ගොනුවක ගබඩා කිරීම ඉතා නරක අදහසකි.

මක්නිසාද යත් පළමුව, කන්ටේනරය තුළ ඇති ලඝු-සටහන් ගොනුවකට ලබා ගැනීම දුෂ්කර ය. ඔබ මුලින්ම කන්ටේනරය තුළට ගොස්, එහි ක්රියාත්මක කරන්න, පසුව ලොග් දෙස බලන්න. ඊළඟ කරුණ නම්, ඔබ ගොනුවක් තුළ ලඝු-සටහන් තිබේ නම්, බහාලුම් සාමාන්යයෙන් අවම පරිසරයක් ඇති අතර සාමාන්යයෙන් ලොග් සමඟ සාමාන්ය වැඩ සඳහා අවශ්ය වන උපයෝගිතා නොමැත. ඒවා වළලන්න, ඒවා බලන්න, පෙළ සංස්කාරකයක විවෘත කරන්න. ඊළඟ මොහොතේ තමයි අපිට කන්ටේනර් එකක් ඇතුලේ ෆයිල් එකක ලොග් තියෙද්දී මේ කන්ටේනරය මැකුණොත් ඔයාලට තේරෙනවා නේද ඒ එක්කම ලොග් මැරෙනවා. ඒ අනුව, කන්ටේනරය නැවත ආරම්භ කිරීම යනු තවත් ලඝු-සටහන් නොමැති බවයි. නැවතත්, නරක විකල්පය.

අවසාන කරුණ නම් බහාලුම් තුළ ඔබට සාමාන්‍යයෙන් ඔබේ යෙදුම ඇති අතර එය එයයි - එය සාමාන්‍යයෙන් ක්‍රියාත්මක වන එකම ක්‍රියාවලියයි. ඔබගේ ලඝු-සටහන් සමඟ ගොනු කරකවන කිසිදු ක්‍රියාවලියක් ගැන කතා කිරීමක් නැත. ලොග් ගොනුවකට ලිවීමට පටන් ගත් වහාම, මෙයින් අදහස් කරන්නේ, සමාවෙන්න, අපට නිෂ්පාදන සේවාදායකය අහිමි වීමට පටන් ගන්නා බවයි. මක්නිසාද යත්, පළමුව, ඒවා සොයා ගැනීම දුෂ්කර ය, කිසිවෙකු ඒවා ලුහුබඳින්නේ නැත, කිසිවෙකු ඒවා පාලනය නොකරයි - ඒ අනුව, සේවාදායකයේ ඉඩ සරලව අවසන් වන තුරු ගොනුව නිමක් නැතිව වර්ධනය වේ. ඒ නිසා මම ආයෙත් කියනවා Docker, විශේෂයෙන්ම Kubernetes වල file එකකට log වෙන එක නරක අදහසක්.

ඊළඟ කරුණ, මෙන්න මට මේ ගැන නැවත කතා කිරීමට අවශ්‍යයි - අපි ලඝු-සටහන් යන මාතෘකාව ස්පර්ශ කරන බැවින්, ඔවුන් සමඟ වැඩ කිරීම පහසු කිරීම සඳහා ලොග් පෙනිය යුතු ආකාරය ගැන කතා කිරීම හොඳ වනු ඇත. මම කී පරිදි, මාතෘකාව Kubernetes සමඟ කෙලින්ම සම්බන්ධ නොවේ, නමුත් එය DevOps මාතෘකාවට ඉතා හොඳින් සම්බන්ධ වේ. සංවර්ධන සංස්කෘතිය සහ මෙම විවිධ දෙපාර්තමේන්තු දෙක අතර මිත්‍රත්වය යන මාතෘකාව මත - Dev සහ Ops, එවිට සෑම කෙනෙකුටම සුවපහසු වේ.

මෙයින් අදහස් කරන්නේ ඉතා මැනවින්, අද, ලඝු-සටහන් JSON ආකෘතියෙන් ලිවිය යුතු බවයි. ඔබ යම් ආකාරයක මුද්‍රණයක් හෝ එවැනි දෙයක් ඇතුළු කරන නිසා තේරුම්ගත නොහැකි ආකෘතිවලින් ලඝු-සටහන් ලියන ඔබේම නොතේරෙන යෙදුමක් තිබේ නම්, සාමාන්‍ය ලොග් කිරීම ක්‍රියාත්මක කිරීමට ඔබට ඉඩ සලසන යම් ආකාරයක රාමුවක්, යම් ආකාරයක දවටනයක් ගූගල් කිරීමට කාලයයි; එහි JSON හි ලොග් කිරීමේ පරාමිති සක්‍රීය කරන්න, මන්ද JSON යනු සරල ආකෘතියකි, එය විග්‍රහ කිරීම සරල ය.

ඔබගේ JSON යම් නිර්ණායක අනුව ක්‍රියා නොකරන්නේ නම්, කවුරුවත් දන්නේ නැත, එවිට අවම වශයෙන් විග්‍රහ කළ හැකි ආකෘතියකින් ලොග් ලියන්න. මෙන්න, ඒ වෙනුවට, ඔබ බහාලුම් පොකුරක් ධාවනය කරන්නේ නම් හෝ nginx සමඟ ක්‍රියාවලි කරන්නේ නම් සහ ඒ සෑම එකක්ම තමන්ගේම ලොග් කිරීමේ සැකසුම් තිබේ නම්, එය ඔබට ඉතා අපහසු වනු ඇතැයි සිතීම වටී. ඒවා විග්‍රහ කරන්න. මක්නිසාද යත්, එක් එක් නව nginx අවස්ථාව සඳහා ඔබ ඔබේම විග්‍රහයක් ලිවිය යුතු බැවිනි, මන්ද ඔවුන් ලඝු-සටහන් වෙනස් ලෙස ලියන බැවිනි. නැවතත්, මෙම සියලු nginx අවස්ථා එකම ලොග් කිරීමේ වින්‍යාසය ඇති බවත් ඒවායේ සියලුම ලඝු-සටහන් ඒකාකාරව ලියා ඇති බවත් සහතික කර ගැනීම ගැන සිතීම වටී. සියලුම යෙදුම් සඳහාද එයම අදාළ වේ.

අවසානයේදී, මට ගින්නට ඉන්ධන එකතු කිරීමට අවශ්‍යයි, ඉතා මැනවින්, බහු-රේඛා ආකෘති ලොග් වළක්වා ගත යුතුය. මෙන්න කාරණය, ඔබ කවදා හෝ ලොග් එකතු කරන්නන් සමඟ වැඩ කර ඇත්නම්, බොහෝ විට ඔවුන් ඔබට පොරොන්දු වන දේ ඔබ දැක ඇති, ඔවුන්ට බහු-රේඛා ලොග සමඟ වැඩ කළ හැකි බව, ඒවා එකතු කරන ආකාරය දැන ගැනීම සහ යනාදිය. ඇත්ත වශයෙන්ම, මගේ මතය අනුව, අද එක් එකතුකරන්නෙකුට බහු-රේඛා ලොග් සාමාන්යයෙන්, සම්පූර්ණයෙන් සහ දෝෂ නොමැතිව එකතු කළ නොහැක. මානව ආකාරයෙන්, එය පහසු සහ දෝෂ රහිත වේ.

නමුත් ස්ටැක් ට්‍රේස් සෑම විටම බහු රේඛා ලඝු-සටහන් වන අතර ඒවා වළක්වා ගන්නේ කෙසේද. මෙහි ඇති ප්‍රශ්නය නම්, ලඝු-සටහන යනු සිදුවීමක වාර්තාවක් වන අතර, stactrace යනු ඇත්ත වශයෙන්ම ලොගයක් නොවේ. අපි ලඝු-සටහන් එකතු කර ඒවා Elasticsearch හි කොතැනක හෝ තබා ඒවායින් ප්‍රස්ථාර අඳින්නේ නම්, ඔබේ වෙබ් අඩවියේ පරිශීලක ක්‍රියාකාරකම් පිළිබඳ වාර්තා කිහිපයක් ගොඩනඟන්නේ නම්, ඔබට තොග හෝඩුවාවක් ලැබුණු විට, එයින් අදහස් වන්නේ අනපේක්ෂිත දෙයක් සිදුවෙමින් පවතින බවයි. ඔබේ යෙදුමේ හැසිරවිය නොහැකි තත්වයක්. තවද ඒවා හඹා යා හැකි පද්ධතියකට ස්වයංක්‍රීයව කොතැනක හෝ ස්ටැක් ට්‍රේස් එකක් උඩුගත කිරීම අර්ථවත් කරයි.

මෙය ස්ටැක් ට්‍රේස් සමඟ වැඩ කිරීම සඳහා විශේෂයෙන් සාදන ලද මෘදුකාංගයකි (එකම සෙන්ට්‍රි). එය වහාම ස්වයංක්‍රීය කාර්යයන් නිර්මාණය කළ හැකිය, ඒවා යමෙකුට පැවරිය හැකිය, ස්ටැක්ට්‍රේස් සිදු වූ විට අනතුරු ඇඟවීම, මෙම ස්ටැක්ට්‍රේස් එක් වර්ගයකින් කාණ්ඩගත කිරීම යනාදිය. ප්‍රතිපත්තිමය වශයෙන්, අපි ලඝු-සටහන් ගැන කතා කරන විට ස්ථිතික ගැන කතා කිරීම එතරම් තේරුමක් නැත, මන්ද මේවා සියල්ලට පසු, විවිධ අරමුණු සහිත විවිධ දේවල් ය.

වින්‍යාසය

ඊළඟට අපි Kubernetes හි වින්‍යාස කිරීම ගැන කතා කරමු: එය සමඟ කළ යුතු දේ සහ Kubernetes තුළ ඇති යෙදුම් වින්‍යාසගත කළ යුතු ආකාරය. සාමාන්‍යයෙන් මම සාමාන්‍යයෙන් කියන්නේ Docker කියන්නේ බහාලුම් ගැන නෙවෙයි. Docker කියන්නේ කන්ටේනර් ගැන කියලා කවුරුත් දන්නවා, Docker එක්ක වැඩිය වැඩ කරලා නැති අය පවා. මම නැවත කියනවා, Docker යනු බහාලුම් ගැන නොවේ.

Docker, මගේ මතය අනුව, සම්මතයන් ගැන. ප්‍රායෝගිකව සෑම දෙයක් සඳහාම ප්‍රමිතීන් තිබේ: ඔබේ යෙදුම ගොඩනැගීමේ ප්‍රමිතීන්, ඔබේ යෙදුම ස්ථාපනය කිරීමේ ප්‍රමිතීන්.

මේ දෙය - අපි එය කලින් භාවිතා කළෙමු, එය බහාලුම් පැමිණීමත් සමඟ එය විශේෂයෙන් ජනප්‍රිය විය - මෙම දෙය ENV (පරිසර) විචල්‍යයන් ලෙස හැඳින්වේ, එනම් ඔබේ මෙහෙයුම් පද්ධතියේ ඇති පරිසර විචල්‍යයන්. මෙය සාමාන්‍යයෙන් ඔබගේ යෙදුම වින්‍යාස කිරීමට කදිම ක්‍රමයකි, මන්ද ඔබට JAVA, Python, Go, Perl, God forbid හි යෙදුම් තිබේ නම් සහ ඒවා සියල්ලටම දත්ත සමුදා ධාරකය, දත්ත සමුදා පරිශීලකයා, දත්ත සමුදා මුරපද විචල්‍යයන් කියවිය හැකි බැවින්, එය වඩාත් සුදුසු වේ. ඔබ සතුව විවිධ භාෂා හතරකින් යෙදුම් එකම ආකාරයෙන් දත්ත සමුදා සැලැස්මේ වින්‍යාස කර ඇත. තවත් වෙනස් සැකසුම් නොමැත.

ENV විචල්‍යයන් භාවිතයෙන් සෑම දෙයක්ම වින්‍යාසගත කළ හැක. අපි Kubernetes ගැන කතා කරන විට, Deployment තුළම ENV විචල්‍යයන් ප්‍රකාශ කිරීමට විශිෂ්ට ක්‍රමයක් තිබේ. ඒ අනුව, අපි රහස් දත්ත ගැන කතා කරන්නේ නම්, අපට වහාම ENV විචල්‍යයන්ගෙන් (දත්ත සමුදායට මුරපද ආදිය) රහස් දත්ත රහසකට තල්ලු කළ හැකිය, රහස් පොකුරක් සාදා අපි කෙලින්ම ප්‍රකාශ නොකරන බව Deployment හි ENV විස්තරයේ සඳහන් කළ හැකිය. මෙම විචල්‍යයේ අගය සහ මෙම දත්ත සමුදා මුරපද විචල්‍යයේ අගය රහසෙන් කියවනු ඇත. මෙය සම්මත Kubernetes හැසිරීමයි. ඔබගේ යෙදුම් වින්‍යාස කිරීමට මෙය වඩාත් සුදුසු විකල්පය වේ. කේත මට්ටමින්, නැවතත් මෙය සංවර්ධකයින්ට අදාළ වේ. ඔබ DevOps නම්, ඔබට මෙසේ ඇසිය හැක: "යාලුවනේ, කරුණාකර පරිසර විචල්‍යයන් කියවීමට ඔබේ යෙදුමට උගන්වන්න. ඒ වගේම අපි හැමෝම සතුටින් ඉන්නම්."

සමාගමේ සියලුම දෙනා එකම නම් කරන ලද පරිසර විචල්‍යයන් කියවන්නේ නම්, එය විශිෂ්ටයි. සමහරු postgres දත්ත සමුදාය සඳහා බලා සිටීම, තවත් සමහරු දත්ත සමුදායේ නම එනතුරු බලා සිටීම, තවත් අය වෙනත් දෙයක් සඳහා බලා සිටීම, තවත් අය යම් ආකාරයක dbn සඳහා බලා සිටීම, ඒ අනුව, ඒ අනුව, ඒකාකාරී බව සිදු නොවන පරිදි.

ප්‍රශ්නය පැමිණෙන්නේ ඔබ සතුව බොහෝ පරිසර විචල්‍යයන් ඇති විට ඔබ යෙදවීම විවෘත කරන විට - සහ පාරිසරික විචල්‍ය පේළි පන්සියයක් ඇත. මෙම අවස්ථාවෙහිදී, ඔබ හුදෙක් පරිසරයේ විචල්‍යයන් ඉක්මවා ඇත - තවද ඔබට තවදුරටත් ඔබට වධ හිංසා කිරීමට අවශ්‍ය නොවේ. මෙම අවස්ථාවේදී, configs භාවිතා කිරීම ආරම්භ කිරීම අර්ථවත් වනු ඇත. එනම්, configs භාවිතා කිරීමට ඔබගේ යෙදුම පුහුණු කරන්න.

එකම ප්‍රශ්නය වන්නේ configs ඔබ සිතන දේ නොවේ. Config.pi යනු භාවිතා කිරීමට පහසු වින්‍යාසයක් නොවේ. නැතහොත් ඔබේම ආකෘතියේ සමහර වින්‍යාසය, විකල්ප වශයෙන් තෑගි - මෙයද මා අදහස් කරන වින්‍යාසය නොවේ.

මම කතා කරන්නේ පිළිගත හැකි ආකෘතිවල වින්‍යාස කිරීම, එනම්, වඩාත්ම ජනප්‍රිය සම්මතය වන්නේ .yaml සම්මතයයි. එය කියවිය යුතු ආකාරය පැහැදිලිය, එය මිනිසුන්ට කියවිය හැකි ය, යෙදුමෙන් එය කියවිය යුතු ආකාරය පැහැදිලිය.

ඒ අනුව, YAML ට අමතරව, ඔබට, උදාහරණයක් ලෙස, JSON භාවිතා කළ හැකිය, එහි සිට යෙදුම් වින්‍යාසය කියවීම සම්බන්ධයෙන් විග්‍රහ කිරීම YAML තරම්ම පහසු වේ. එය කියවීමට මිනිසුන්ට වඩාත් අපහසු වන බව සැලකිය යුතුය. ඔබට ආකෘතිය උත්සාහ කළ හැකිය, a la ini. මානව දෘෂ්ටි කෝණයකින් කියවීමට එය බෙහෙවින් පහසු ය, නමුත් ඔබට කවදා හෝ ඔබේම වින්‍යාසයන් ජනනය කිරීමට අවශ්‍ය නම්, ini ආකෘතිය දැනටමත් උත්පාදනය කිරීමට අපහසු විය හැකිය යන අර්ථයෙන් එය ස්වයංක්‍රීයව සැකසීමට අපහසු විය හැකිය.

නමුත් ඕනෑම අවස්ථාවක, ඔබ තෝරාගත් ආකෘතිය කුමක් වුවත්, කාරණය වන්නේ කුබර්නෙටේස් දෘෂ්ටි කෝණයෙන් එය ඉතා පහසු වීමයි. ඔබට ඔබේ සම්පූර්ණ වින්‍යාසය Kubernetes තුළ, ConfigMap තුළ තැබිය හැකිය. ඉන්පසු මෙම වින්‍යාස සිතියම ගෙන කිසියම් නිශ්චිත නාමාවලියක එය ඔබගේ පොඩ් එක තුළ සවි කරන ලෙස ඉල්ලා සිටින්න, එහිදී ඔබේ යෙදුම මෙම වින්‍යාස සිතියමෙන් වින්‍යාසය හුදෙක් ගොනුවක් ලෙස කියවනු ඇත. ඇත්ත වශයෙන්ම, ඔබගේ යෙදුමේ බොහෝ වින්‍යාස විකල්ප ඇති විට මෙය කිරීම හොඳ දෙයකි. නැතහොත් එය යම් ආකාරයක සංකීර්ණ ව්‍යුහයක් පමණි, කැදැල්ලක් ඇත.

ඔබට වින්‍යාස සිතියමක් තිබේ නම්, ඔබට ඔබේ යෙදුම ඉතා හොඳින් ඉගැන්විය හැකිය, උදාහරණයක් ලෙස, වින්‍යාස සිතියම සවි කර ඇති ගොනුවේ වෙනස්කම් ස්වයංක්‍රීයව නිරීක්ෂණය කිරීමට සහ වින්‍යාසයන් වෙනස් වූ විට ඔබේ යෙදුම ස්වයංක්‍රීයව නැවත පූරණය කිරීමට. මෙය සාමාන්යයෙන් කදිම විකල්පයක් වනු ඇත.

නැවතත්, මම දැනටමත් මේ ගැන කතා කර ඇත - රහස් තොරතුරු configmap තුළ නොමැත, රහස් තොරතුරු විචල්යයන් තුළ නොවේ, රහස් තොරතුරු රහස් වල නොවේ. එතැන් සිට මෙම රහස් තොරතුරු රාජ්‍ය තාන්ත්‍රිකත්වයට සම්බන්ධ කරන්න. සාමාන්‍යයෙන් අපි Kubernetes objects, deployments, configmaps, services වල සියලුම විස්තර git වල ගබඩා කරනවා. ඒ අනුව, ඔබ ආයතනයේ අභ්‍යන්තරව ඇති ඔබගේ git වුවද දත්ත ගබඩාවට මුරපදය git තුළ දැමීම නරක අදහසකි. මක්නිසාද යත්, අවම වශයෙන්, git සෑම දෙයක්ම මතක තබා ගන්නා අතර එහි ඇති මුරපදය ඉවත් කිරීම එතරම් පහසු නැත.

සෞඛ්ය පරීක්ෂාව

ඊළඟ කාරණය තමයි මේ සෞඛ්‍ය පරීක්‍ෂාව කියන දේ. සාමාන්‍යයෙන්, සෞඛ්‍ය පරීක්‍ෂණයක් යනු ඔබේ යෙදුම ක්‍රියාත්මක වේද යන්න පරීක්ෂා කිරීමයි. ඒ අතරම, අපි බොහෝ විට කතා කරන්නේ ඇතැම් වෙබ් යෙදුම් ගැන වන අතර, ඒ සඳහා සෞඛ්‍ය පරීක්‍ෂණයේ දෘෂ්ටි කෝණයෙන් (මෙහි සහ තවදුරටත් පරිවර්තනය නොකිරීම වඩා හොඳය) මෙය ඔවුන් විසින් සකසන විශේෂ URL එකක් වනු ඇත. සම්මතයක්, ඔවුන් සාමාන්යයෙන් කරන්නේ /health.

මෙම URL වෙත ප්‍රවේශ වන විට, ඒ අනුව, අපගේ යෙදුම පවසන්නේ “ඔව්, හරි, මට හැම දෙයක්ම හොඳයි, 200” හෝ “නැහැ, මට හැම දෙයක්ම හොඳයි, 500ක් විතර.” ඒ අනුව, අපගේ යෙදුම http නොවේ, වෙබ් යෙදුමක් නොවේ නම්, අපි දැන් කතා කරන්නේ යම් ආකාරයක ඩීමන් ගැන නම්, අපට සෞඛ්‍ය පරීක්ෂාවන් කරන්නේ කෙසේදැයි සොයා ගත හැකිය. එනම්, එය අවශ්ය නොවේ, යෙදුම http නොවේ නම්, සෞඛ්ය පරීක්ෂාවකින් තොරව සෑම දෙයක්ම ක්රියා කරන අතර මෙය කිසිම ආකාරයකින් කළ නොහැකිය. ඔබට ගොනුවේ සමහර තොරතුරු වරින් වර යාවත්කාලීන කළ හැකිය, ඔබට ඔබේ ඩීමන් සඳහා විශේෂ විධානයක් ඉදිරිපත් කළ හැකිය, වැනි, daemon status, "ඔව්, හැම දෙයක්ම හොඳයි, ඩීමන් වැඩ කරනවා, එය ජීවමානයි" කියා පවසනු ඇත.

එය කුමක් සදහාද? පළමු හා වඩාත්ම පැහැදිලි දෙය නම් සෞඛ්‍ය පරීක්‍ෂණයක් අවශ්‍ය වන්නේ මන්දැයි යන්නයි - යෙදුම ක්‍රියාත්මක වන බව තේරුම් ගැනීමට. මම නම් කියන්නේ නිකන් මෝඩ කමක්, දැන් උඩට ගියාම වැඩ කරනවා වගේ පේන නිසා වැඩේ හරි කියලා ෂුවර්. යෙදුම ක්‍රියාත්මක වන බවත්, බහාලුම ක්‍රියාත්මක වන බවත්, අවස්ථාව ක්‍රියාත්මක වන බවත්, සියල්ල හොඳින් බවත් පෙනී යයි - එවිට පරිශීලකයින් දැනටමත් තාක්ෂණික සහායෙන් සියලුම දුරකථන අංක කපා දමා “ඔබ කුමක්ද ..., ඔබ නින්ද ගියා, කිසිම දෙයක් වැඩ කරන්නේ නැහැ.

සෞඛ්‍ය පරීක්‍ෂණයක් යනු එය ක්‍රියාත්මක වන බව පරිශීලකයාගේ දෘෂ්ටිකෝණයෙන් දැකීමට එවැනි ක්‍රමයක් පමණි. ක්රම වලින් එකක්. අපි එය මෙසේ දමමු. Kubernetes ගේ දෘෂ්ටි කෝණයෙන්, මෙය යෙදුම ආරම්භ වන විට තේරුම් ගත හැකි ක්‍රමයකි, මන්ද බහාලුම් දියත් කළ විට, සාදන ලද සහ ආරම්භ කළ විට සහ යෙදුම කෙලින්ම මෙම බහාලුම් තුළ දියත් කළ විට අතර වෙනසක් ඇති බව අපට වැටහෙන බැවිනි. මොකද අපි සාමාන්‍ය ජාවා ඇප්ලිකේෂන් ටිකක් අරගෙන ඩොක් එකේ දියත් කරන්න හැදුවොත් තත්පර හතළිහක්, එහෙමත් නැත්නම් විනාඩියක් හෝ දහයක් වුණත් හොඳට පටන් ගන්න පුළුවන්. මෙම අවස්ථාවේදී, ඔබට අවම වශයෙන් එහි වරායන්ට තට්ටු කළ හැකිය, එය එහි පිළිතුරු නොදෙනු ඇත, එනම්, එය තවමත් ගමනාගමනය ලබා ගැනීමට සූදානම් නැත.

නැවතත්, සෞඛ්‍ය පරීක්‍ෂණයක ආධාරයෙන් සහ අපි මෙතැනට හැරෙන කාරණයේ ආධාරයෙන්, යෙදුමේ කන්ටේනරය ඉහළ ගොස් ඇතිවා පමණක් නොව, යෙදුමම ආරම්භ වී ඇති බව අපට Kubernetes හි තේරුම් ගත හැකිය, එය දැනටමත් ප්‍රතිචාර දක්වයි සෞඛ්‍ය පරීක්‍ෂාව, ඒ කියන්නේ අපිට එතනට ට්‍රැෆික් යවන්න පුළුවන්.

මම දැන් කතා කරන දෙය Kubernetes තුළ ඇති සූදානම/සජීවී පරීක්ෂණ ලෙස හැඳින්වේ; ඒ අනුව, සමතුලිතතාවයේ යෙදුම ලබා ගැනීමට අපගේ සූදානම පරීක්ෂණ වගකිව යුතුය. එනම්, යෙදුමේ සූදානම පරීක්ෂණ සිදු කරන්නේ නම්, සියල්ල හරි, සේවාදායක ගමනාගමනය යෙදුමට යයි. සූදානම පරීක්ෂණ සිදු නොකරන්නේ නම්, යෙදුම සරලව සහභාගී නොවේ, මෙම විශේෂිත අවස්ථාව සමතුලිතතාවයට සහභාගී නොවේ, එය සමතුලිතතාවයෙන් ඉවත් කරනු ලැබේ, සේවාදායක ගමනාගමනය ගලා එන්නේ නැත. ඒ අනුව, යෙදුම සිරවී ඇත්නම්, එය නැවත ආරම්භ කළ හැකි වන පරිදි Kubernetes තුළ සජීවී පරීක්ෂණ අවශ්‍ය වේ. Kubernetes හි ප්‍රකාශ කරන ලද යෙදුමක් සඳහා සජීවී පරීක්ෂණය ක්‍රියා නොකරන්නේ නම්, යෙදුම සමතුලිතතාවයෙන් ඉවත් නොකෙරේ, එය නැවත ආරම්භ වේ.

මම සඳහන් කිරීමට කැමති වැදගත් කරුණක් මෙන්න: ප්‍රායෝගික දෘෂ්ටි කෝණයකින්, සූදානම පරීක්ෂණය සාමාන්‍යයෙන් බොහෝ විට භාවිතා වන අතර සජීවී පරීක්ෂණයට වඩා බොහෝ විට අවශ්‍ය වේ. එනම්, හුදෙක් නොසැලකිලිමත් ලෙස සූදානම සහ සජීවී පරීක්ෂණ දෙකම ප්රකාශ කිරීම, Kubernetes හට එය කළ හැකි නිසාත්, එය කළ හැකි සෑම දෙයක්ම භාවිතා කරමු, එය ඉතා හොඳ අදහසක් නොවේ. මම පැහැදිලි කරන්නම් ඇයි කියලා. මක්නිසාද යත් පරීක්‍ෂණයේ අංක දෙක වන කරුණ නම් ඔබේ සෞඛ්‍ය පරීක්‍ෂාවේදී යටින් පවතින සේවාව පරීක්ෂා කිරීම හොඳ අදහසකි. මෙයින් අදහස් කරන්නේ ඔබට යම් තොරතුරු ලබා දෙන වෙබ් යෙදුමක් තිබේ නම්, එය ස්වභාවිකවම, කොහෙන් හෝ ගත යුතු බවයි. උදාහරණයක් ලෙස දත්ත සමුදායක. හොඳයි, එය මෙම REST API තුළට එන තොරතුරු එකම දත්ත ගබඩාවට සුරකියි. එවිට, ඒ අනුව, ඔබේ සෞඛ්‍ය පරීක්‍ෂණය සම්බන්ධ වූ slashhealth මෙන් සරලව ප්‍රතිචාර දක්වන්නේ නම්, යෙදුම “200, හරි, සියල්ල හොඳින්” යැයි පවසන අතර ඒ සමඟම ඔබේ යෙදුමේ දත්ත ගබඩාවට ප්‍රවේශ විය නොහැකි අතර සෞඛ්‍ය පරීක්‍ෂණ යෙදුම “200, හරි, සියල්ල හොඳින් ” - මෙය නරක සෞඛ්‍ය පරීක්‍ෂණයකි. එය ක්‍රියාත්මක විය යුත්තේ මේ ආකාරයට නොවේ.

එනම්, ඔබගේ අයදුම්පත, ඉල්ලීමක් පැමිණි විට /health, එය නිකම්ම ප්‍රතිචාර නොදක්වයි, “200, හරි”, එය පළමුව යන්නේ, උදාහරණයක් ලෙස, දත්ත සමුදායට, එයට සම්බන්ධ වීමට උත්සාහ කරයි, එහි ඉතා මූලික දෙයක් කරයි, එකක් තෝරන්න වැනි, එහි සම්බන්ධතාවයක් තිබේදැයි පරීක්ෂා කරයි. දත්ත සමුදාය සහ ඔබට දත්ත සමුදාය විමසිය හැක. මේ සියල්ල සාර්ථක වූයේ නම්, පිළිතුර "200, හරි" යන්නයි. එය සාර්ථක නොවන්නේ නම්, දෝෂයක් ඇති බව කියයි, දත්ත සමුදාය නොමැත.

එබැවින්, මේ සම්බන්ධයෙන්, මම නැවතත් සූදානම/සජීවී පරීක්ෂණ වෙත ආපසු යන්නෙමි - ඔබට බොහෝ විට සූදානම පරීක්ෂණයක් අවශ්‍ය වන්නේ ඇයි, නමුත් සජීවී පරීක්ෂණයක් ප්‍රශ්නාර්ථයකි. මක්නිසාද යත් ඔබ සෞඛ්‍ය පරීක්‍ෂාවන් මා පැවසූ ආකාරයටම විස්තර කරන්නේ නම්, එය උදාහරණ කොටසේ නොමැති බව පෙනේ.в или со всех instanceඋදාහරණයක් ලෙස දත්ත සමුදායක. ඔබ සූදානම පරීක්ෂණයක් ප්‍රකාශ කළ විට, අපගේ සෞඛ්‍ය පරීක්ෂාවන් අසාර්ථක වීමට පටන් ගත් අතර, ඒ අනුව දත්ත සමුදායට ප්‍රවේශ විය නොහැකි සියලුම යෙදුම්, ඒවා හුදෙක් සමතුලිතතාවයෙන් ක්‍රියා විරහිත කර ඇති අතර ඇත්ත වශයෙන්ම නොසලකා හරින ලද තත්වයක “එල්ලෙනු” ඇති අතර ඒවායේ දත්ත සමුදායන් සඳහා රැඳී සිටින්න. කාර්යය.

අපි සජීවී පරීක්ෂණයක් ප්‍රකාශ කර ඇත්නම්, සිතන්න, අපගේ දත්ත සමුදාය බිඳී ගොස් ඇති අතර, සජීවී පරීක්ෂණය අසාර්ථක වීම නිසා ඔබේ කුබර්නෙටස් හි සියල්ලෙන් අඩක් නැවත ආරම්භ වීමට පටන් ගනී. මෙයින් අදහස් කරන්නේ ඔබ නැවත ආරම්භ කළ යුතු බවයි. මෙය ඔබට කිසිසේත් අවශ්‍ය නොවේ, මට ප්‍රායෝගිකව පුද්ගලික අත්දැකීම් පවා තිබුණි. JS වලින් ලියා මොංගෝ දත්ත ගබඩාවකට සංග්‍රහ කළ චැට් යෙදුමක් අප සතුව තිබුණි. ගැටලුව වූයේ එය Kubernetes සමඟ මගේ වැඩ ආරම්භයේදීම, අපි Kubernetes එය කළ හැකි මූලධර්මය මත පරීක්ෂණවල සූදානම, සජීවී බව විස්තර කළෙමු, එබැවින් අපි එය භාවිතා කරන්නෙමු. ඒ අනුව, යම් අවස්ථාවක දී Mongo ටිකක් "අඳුරු" බවට පත් වූ අතර නියැදිය අසාර්ථක වීමට පටන් ගත්තේය. ඒ අනුව, වැසි පරීක්ෂණයට අනුව, කරල් "මරන්න" පටන් ගත්තේය.

ඔබ තේරුම් ගත් පරිදි, ඔවුන් "මරා දැමූ" විට, මෙය චැට් එකක් වේ, එනම්, එය මත එල්ලා ඇති ගනුදෙනුකරුවන්ගේ සම්බන්ධතා බොහොමයක් තිබේ. ඔවුන් ද “මරා දමනු ලැබේ” - නැත, සේවාදායකයින් නොවේ, සම්බන්ධතා පමණි - සියල්ලම එකවර නොවේ, සහ ඔවුන් එකවර මරා නොදැමීම නිසා, සමහරක් කලින්, සමහරක් පසුව, ඒවා එකවරම ආරම්භ නොවේ. කාලය. ප්ලස් සම්මත අහඹු ලෙස, අපට සෑම අවස්ථාවකදීම යෙදුමේ ආරම්භක වේලාව මිලි තත්පර නිරවද්‍යතාවයෙන් පුරෝකථනය කළ නොහැක, එබැවින් ඔවුන් එය වරකට එක් අවස්ථාවක සිදු කරයි. එක් ඉන්ෆොස්පොට් එකක් ඉහළ යයි, සමතුලිතතාවයට එකතු වේ, සියලුම සේවාදායකයින් එහි පැමිණේ, එයට එවැනි බරක් දරාගත නොහැක, මන්ද එය තනිවම වන අතර, දළ වශයෙන් කිවහොත්, ඔවුන්ගෙන් දුසිමක් පමණ එහි වැඩ කරන අතර එය වැටේ. ඊළඟ එක නැඟිටිනවා, මුළු බරම ඔහු මත, ඔහුත් වැටෙනවා. හොඳයි, මෙම දිය ඇල්ල දිගටම ගලා යයි. අවසානයේදී, මෙය විසඳන ලද ආකාරය - අපට මෙම යෙදුම වෙත පරිශීලක ගමනාගමනය දැඩි ලෙස නැවැත්වීමට සිදු විය, සියලු අවස්ථා ඉහළ යාමට ඉඩ දී සියලුම පරිශීලක ගමනාගමනය එකවර ආරම්භ කිරීමට එය දැනටමත් අවස්ථා දහයම අතර බෙදා හැර ඇත.

එය සියල්ල නැවත ආරම්භ කිරීමට බල කරන මෙම සජීවී පරීක්ෂණය නිවේදනය නොකළේ නම්, යෙදුම එය හොඳින් හසුරුවනු ඇත. නමුත් දත්ත සමුදායන් වෙත ප්‍රවේශ විය නොහැකි අතර සියලුම පරිශීලකයින් "වැටී" ඇති නිසා සමතුලිතතාවයේ සිට සෑම දෙයක්ම අපට අක්‍රීය කර ඇත. එවිට, මෙම දත්ත සමුදාය ලබා ගත හැකි වූ විට, සෑම දෙයක්ම සමතුලිතතාවයට ඇතුළත් වේ, නමුත් යෙදුම් නැවත ආරම්භ කිරීමට අවශ්ය නොවන අතර, මේ සඳහා කාලය හා සම්පත් නාස්ති කිරීමට අවශ්ය නොවේ. ඔවුන් සියල්ලන්ම දැනටමත් මෙහි ඇත, ඔවුන් ගමනාගමනය සඳහා සූදානම්ව සිටිති, එබැවින් ගමනාගමනය විවෘත වේ, සියල්ල හොඳින් ඇත - යෙදුම ක්‍රියාත්මක වේ, සියල්ල දිගටම ක්‍රියාත්මක වේ.

එමනිසා, සූදානම සහ සජීවී පරීක්ෂණ වෙනස් වේ, ඊටත් වඩා, ඔබට න්‍යායාත්මකව විවිධ සෞඛ්‍ය පරීක්ෂාවන්, එක් වර්ගයක රේඩිය, එක් වර්ගයක ලිව්, උදාහරණයක් ලෙස, විවිධ දේ පරීක්ෂා කළ හැකිය. සූදානම පරීක්ෂා කිරීමේදී, ඔබේ පසුපෙළ පරීක්ෂා කරන්න. සහ සජීවී පරීක්ෂණයකදී, උදාහරණයක් ලෙස, සජීවී පරීක්ෂණය සාමාන්‍යයෙන් ප්‍රතිචාර දක්වන යෙදුමක් පමණක් බව ඔබ විසින් පරීක්ෂා නොකරයි, එයට ප්‍රතිචාර දැක්වීමට හැකි නම්.

මක්නිසාද සජීවී පරීක්ෂණය, විශාල වශයෙන්, අප "හිරවී" සිටින විටය. නිමක් නැති ලූපයක් හෝ වෙනත් දෙයක් ආරම්භ වී ඇත - සහ තවත් ඉල්ලීම් සැකසෙන්නේ නැත. එමනිසා, ඒවා වෙන් කිරීම පවා අර්ථවත් කරයි - සහ ඒවා තුළ විවිධ තර්ක ක්‍රියාත්මක කිරීම.

ඔබට පරීක්ෂණයක් ඇති විට, ඔබ සෞඛ්‍ය පරීක්‍ෂා කරන විට පිළිතුරු දිය යුතු දේ සම්බන්ධයෙන්. ඒක ඇත්තටම වේදනාවක් විතරයි. මෙය හුරුපුරුදු අය බොහෝ විට සිනාසෙනු ඇත - නමුත් බැරෑරුම් ලෙස, 200% ක්ම “XNUMX” ලෙස පිළිතුරු දෙන සේවාවන් මම මගේ ජීවිතයේ දැක ඇත්තෙමි. එනම් සාර්ථක වන්නේ කවුද යන්නයි. නමුත් ඒ සමඟම ප්‍රතිචාරයේ ශරීරය තුළ ඔවුන් “එවැනි සහ එවැනි දෝෂයක්” ලියයි.

එනම්, ප්රතිචාර තත්ත්වය ඔබ වෙත පැමිණේ - සියල්ල සාර්ථකයි. නමුත් ඒ සමඟම, ඔබ ශරීරය විග්‍රහ කළ යුතුය, මන්ද ශරීරය “කණගාටුයි, ඉල්ලීම දෝෂයකින් අවසන් විය” යැයි පවසන අතර මෙය යථාර්ථයක් පමණි. මම මෙය සැබෑ ජීවිතයේදී දුටුවෙමි.

සමහර අයට එය විහිළුවක් ලෙස නොපෙනෙන අතර අනෙක් අයට එය ඉතා වේදනාකාරී බව පෙනේ, එය තවමත් සරල රීතියක් පිළිපැදීම වටී. සෞඛ්‍ය පරීක්‍ෂණවලදී සහ ප්‍රතිපත්තිමය වශයෙන් වෙබ් යෙදුම් සමඟ වැඩ කිරීමේදී.

සෑම දෙයක්ම හොඳින් සිදු වූවා නම්, දෙසිය වැනි පිළිතුරෙන් පිළිතුරු දෙන්න. ප්‍රතිපත්තිමය වශයෙන්, ඕනෑම දෙසීයක පිළිතුරක් ඔබට ගැලපේ. ඔබ ragsy හොඳින් කියවා සමහර ප්‍රතිචාර තත්ත්වයන් අනෙක් ඒවාට වඩා වෙනස් බව දන්නේ නම්, සුදුසු ඒවා සමඟ පිළිතුරු දෙන්න: 204, 5, 10, 15, කුමක් වුවත්. එය ඉතා හොඳ නොවේ නම්, "ශුන්‍ය ශුන්‍ය දෙක" පමණි. සෑම දෙයක්ම නරක අතට හැරී සෞඛ්‍ය පරීක්ෂාව ප්‍රතිචාර නොදක්වන්නේ නම්, ඕනෑම පන්සියයකින් පිළිතුරු දෙන්න. නැවතත්, ඔබ ප්‍රතිචාර දැක්විය යුතු ආකාරය තේරුම් ගන්නේ නම්, විවිධ ප්‍රතිචාර තත්ත්වයන් එකිනෙකට වෙනස් වන ආකාරය. ඔබට නොතේරෙන්නේ නම්, යමක් වැරදී ගියහොත් සෞඛ්‍ය පරීක්‍ෂණවලට ප්‍රතිචාර දැක්වීමට 502 ඔබේ විකල්පයයි.

මෙය තවත් කරුණකි, මට යටින් පවතින සේවාවන් පරීක්ෂා කිරීම ගැන ටිකක් ආපසු යාමට අවශ්‍යයි. ඔබ ආරම්භ කරන්නේ නම්, උදාහරණයක් ලෙස, ඔබගේ යෙදුම පිටුපස ඇති සියලුම යටින් පවතින සේවාවන් පරීක්ෂා කිරීම - පොදුවේ සියල්ල. ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පයේ දෘෂ්ටි කෝණයෙන් අපට ලැබෙන දේ, අපට “අඩු සම්බන්ධ කිරීම” වැනි සංකල්පයක් ඇත - එනම්, ඔබේ සේවාවන් අවම වශයෙන් එකිනෙකා මත රඳා පවතින විට. ඒවායින් එකක් අසමත් වුවහොත්, මෙම ක්‍රියාකාරීත්වය නොමැති අනෙක් සියල්ල සරලව ක්‍රියා කරයි. සමහර ක්‍රියාකාරීත්වය ක්‍රියා නොකරයි. ඒ අනුව, ඔබ සියලු සෞඛ්‍ය පරීක්‍ෂණ එකිනෙක ගැටගසා ගත්තොත්, ඔබ අවසන් වන්නේ යටිතල ව්‍යූහයට එක් දෙයක් වැටීමෙන් වන අතර, එය වැටුණු නිසා, සියලුම සේවාවන්හි සියලුම සෞඛ්‍ය පරීක්‍ෂණ ද අසාර්ථක වීමට පටන් ගනී - සහ පොදුවේ තවත් යටිතල පහසුකම් ඇත. සම්පූර්ණ ක්ෂුද්‍ර සේවා ගෘහ නිර්මාණ ශිල්පය අංක. එහි සියල්ල අඳුරු විය.

එමනිසා, ඔබට යටින් පවතින සේවාවන් පරීක්ෂා කිරීමට අවශ්‍ය බව මට මෙය නැවත නැවතත් කිරීමට අවශ්‍යයි, ඒවා නොමැතිව ඔබේ අයදුම්පත්‍රය සියයට සියයක් තුළ එහි කාර්යය කළ නොහැක. එනම්, පරිශීලකයා දත්ත සමුදාය වෙත සුරකින හෝ දත්ත සමුදායෙන් ලබා ගන්නා REST API ඔබට තිබේ නම්, දත්ත සමුදායක් නොමැති විට, ඔබේ පරිශීලකයින් සමඟ වැඩ කිරීම සහතික කළ නොහැක.

නමුත් ඔබේ පරිශීලකයින්, ඔබ ඔවුන් දත්ත සමුදායෙන් පිටතට ගන්නා විට, වෙනත් පාර-දත්ත සමඟ අතිරේකව පොහොසත් කර ඇත්නම්, ඔබ ඉදිරිපස වෙත ප්‍රතිචාරයක් යැවීමට පෙර ඇතුළත් කරන වෙනත් පසුබිමකින් - සහ මෙම පසුපෙළ නොමැති නම්, මෙයින් අදහස් කරන්නේ ඔබ ඔබේ පාරදත්ත කොටසක් නොමැතිව පිළිතුරු දෙන්න.

ඊළඟට, යෙදුම් දියත් කිරීමේදී අපට වේදනාකාරී ගැටළු ද ඇත.

ඇත්ත වශයෙන්ම, මෙය විශාල වශයෙන් Kubernetes සඳහා පමණක් අදාළ නොවේ; එය සිදු වූයේ යම් ආකාරයක මහා සංවර්ධන සංස්කෘතියක් සහ විශේෂයෙන් DevOps සංස්කෘතියක් Kubernetes ලෙසම ව්‍යාප්ත වීමට පටන් ගත් බැවිනි. එමනිසා, විශාල වශයෙන්, ඔබ Kubernetes නොමැතිව ඔබේ යෙදුම අලංකාර ලෙස වසා දැමිය යුතු බව පෙනේ. Kubernetes ට පෙර සිටම මිනිසුන් මෙය කළ නමුත් Kubernetes පැමිණීමත් සමඟ අපි ඒ ගැන විශාල වශයෙන් කතා කරන්නෙමු.

අලංකාර වසා දැමීම

පොදුවේ ගත් කල, Graceful Shutdown යනු කුමක්ද සහ එය අවශ්‍ය වන්නේ ඇයි? මෙය ඔබගේ යෙදුම කිසියම් හේතුවක් නිසා බිඳ වැටුණු විට, ඔබ විසින් කළ යුතු වේ app stop - හෝ ඔබට ලැබෙන්නේ, උදාහරණයක් ලෙස, මෙහෙයුම් පද්ධතියෙන් සංඥාවක්, ඔබේ යෙදුම එය තේරුම් ගෙන ඒ ගැන යමක් කළ යුතුය. නරකම අවස්ථාව නම්, ඔබගේ යෙදුමට SIGTERM එකක් ලැබෙන විට සහ "SIGTERM, අපි රැඳී සිටිමු, වැඩ කරන්න, කිසිවක් නොකරන්න" වැනිය. මෙය සම්පූර්ණයෙන්ම නරක විකල්පයකි.

ඔබේ යෙදුමට SIGTERM එකක් ලැබෙන විට සමාන නරක විකල්පයක් වන්නේ “ඔවුන් කිව්වා segterm, ඒ කියන්නේ අපි අවසන් කරනවා, මම දැකලා නැහැ, මම කිසිම පරිශීලක ඉල්ලීමක් දන්නේ නැහැ, මම දන්නේ නැහැ මොන වගේද කියලා. මම දැන් වැඩ කරන ඉල්ලීම්, ඔවුන් කිව්වා SIGTERM, ඒ කියන්නේ අපි ඉවරයි " මෙයද නරක විකල්පයකි.

කුමන විකල්පය හොඳද? පළමු කරුණ වන්නේ මෙහෙයුම් අවසන් කිරීම සැලකිල්ලට ගැනීමයි. හොඳ විකල්පයක් වන්නේ ඔබේ සේවාදායකයට SIGTERM එකක් ලැබුණහොත් එය කරන්නේ කුමක්ද යන්න තවමත් සැලකිල්ලට ගැනීමයි.

SIGTERM යනු මෘදු වසා දැමීමකි, එය විශේෂයෙන් නිර්මාණය කර ඇත, එය කේත මට්ටමෙන් බාධා කළ හැකිය, එය සැකසිය හැක, දැන් කියන්න, ඉන්න, අපි මුලින්ම අප සතුව ඇති කාර්යය අවසන් කරන්නෙමු, පසුව අපි පිටවෙමු.

Kubernetes දෘෂ්ටිකෝණයෙන්, එය පෙනෙන්නේ මෙයයි. අපි Kubernetes පොකුරේ ක්‍රියාත්මක වන Pod එකකට, "කරුණාකර නවත්වන්න, යන්න" යැයි පැවසූ විට හෝ අපව නැවත ආරම්භ කළ විට හෝ Kubernetes කරල් ප්‍රතිනිර්මාණය කරන විට යාවත්කාලීන කිරීමක් සිදු වූ විට, Kubernetes එම SIGTERM පණිවිඩයම පොඩ් වෙත යවයි, බලා සිටියි. යම් කාලයක්, සහ , මෙය ඔහු බලා සිටින කාලයයි, එය ද වින්‍යාස කර ඇත, ඩිප්ලෝමා වල එවැනි විශේෂ පරාමිතියක් ඇති අතර එය Graceful ShutdownTimeout ලෙස හැඳින්වේ. ඔබ තේරුම් ගත් පරිදි, එය නිෂ්ඵල ලෙස හඳුන්වනු නොලැබේ, සහ අපි දැන් ඒ ගැන කතා කරන්නේ කිසිවක් සඳහා නොවේ.

අපි යෙදුමට SIGTERM යවන කාලය සහ යෙදුම යම් දෙයකට පිස්සු වැටී ඇති බවක් හෝ “හිරවී ඇති” බවක් පෙනෙන අතර එය අවසන් නොවන බව අපට වැටහෙන විට අපි කොපමණ කාලයක් බලා සිටිය යුතුද යන්න එහිදී අපට විශේෂයෙන් පැවසිය හැකිය - සහ අපට අවශ්‍ය වන්නේ එය SIGKILL යවන්න, එනම්, වෙහෙස මහන්සි වී එහි කාර්යය සම්පූර්ණ කරන්න. එනම්, ඒ අනුව, අපට යම් ආකාරයක ඩීමන් ධාවනයක් ඇත, එය මෙහෙයුම් සකසයි. සාමාන්‍යයෙන් ඩීමන් ක්‍රියා කරන අපගේ මෙහෙයුම් වරකට තත්පර 30කට වඩා නොපවතින බව අපට වැටහේ. ඒ අනුව, SIGTERM පැමිණි විට, අපගේ ඩීමන් හට SIGTERM ට පසු තත්පර 30ක් අවසන් කළ හැකි බව අපට වැටහේ. අපි එය ලියා, උදාහරණයක් ලෙස, තත්පර 45 ක් සහ SIGTERM යැයි කියමු. ඊට පස්සේ අපි තත්පර 45 ක් ඉන්න. න්‍යායාත්මකව, මෙම කාලය තුළ යක්ෂයා තම කාර්යය සම්පූර්ණ කර අවසන් විය යුතුය. නමුත් හදිසියේම එය කළ නොහැකි වූවා නම්, එයින් අදහස් වන්නේ එය බොහෝ විට සිරවී ඇති බවයි - එය තවදුරටත් අපගේ ඉල්ලීම් සාමාන්‍ය පරිදි ක්‍රියා නොකරයි. තත්පර 45 කින් ඔබට ආරක්ෂිතව, ඇත්ත වශයෙන්ම, ඔහුව ඇණ ගැසිය හැකිය.

මෙහිදී, ඇත්ත වශයෙන්ම, අංශ 2 ක් පවා සැලකිල්ලට ගත හැකිය. පළමුව, ඔබට ඉල්ලීමක් ලැබුනේ නම්, ඔබ එය සමඟ කෙසේ හෝ වැඩ කිරීමට පටන් ගත් අතර පරිශීලකයාට ප්‍රතිචාරයක් නොදැක්වූ නමුත් ඔබට SIGTERM ලැබුණු බව තේරුම් ගන්න. එය පිරිපහදු කර පරිශීලකයාට පිළිතුරක් ලබා දීම අර්ථවත් කරයි. මේ සම්බන්ධයෙන් අංක එක මෙයයි. මෙහි අංක දෙක නම්, ඔබ ඔබේම යෙදුමක් ලියන්නේ නම්, සාමාන්‍යයෙන් ඔබේ යෙදුම සඳහා ඉල්ලීමක් ලැබෙන ආකාරයට ගෘහ නිර්මාණ ශිල්පය ගොඩනඟා ගන්න, එවිට ඔබ යම් වැඩකටයුතු ආරම්භ කරන්න, කොහේ හෝ සිට ගොනු බාගත කිරීම, දත්ත සමුදායක් බාගත කිරීම සහ වෙනත් දේ. - එම. පොදුවේ, ඔබේ පරිශීලකයා, ඔබේ ඉල්ලීම පැය භාගයක් එල්ලා ඔහුට පිළිතුරු දෙන තෙක් බලා සිටී - එවිට, බොහෝ විට, ඔබ ගෘහ නිර්මාණ ශිල්පය මත වැඩ කිරීමට අවශ්ය වේ. එනම්, ඔබේ මෙහෙයුම් කෙටි නම්, SIGTERM නොසලකා හැරීම සහ එය වෙනස් කිරීම අර්ථවත් බව සාමාන්‍ය බුද්ධිය පවා සැලකිල්ලට ගන්න. ඔබගේ මෙහෙයුම් දිගු නම්, මෙම අවස්ථාවේදී SIGTERM නොසලකා හැරීම තේරුමක් නැත. එවැනි දිගු මෙහෙයුම් වළක්වා ගැනීම සඳහා ගෘහ නිර්මාණ ශිල්පය නැවත සැලසුම් කිරීම අර්ථවත් කරයි. ඒ නිසා පරිශීලකයන් නිකම්ම එල්ලී බලා නොසිටින්න. මම දන්නේ නැහැ, එහි යම් ආකාරයක වෙබ් සොකට් එකක් සාදන්න, ඔබේ සේවාදායකය දැනටමත් සේවාදායකයාට යවන ප්‍රතිලෝම කොකු සාදන්න, වෙනත් ඕනෑම දෙයක්, නමුත් පරිශීලකයාට පැය භාගයක් එල්ලී සිටීමට බල නොකරන්න සහ ඔබ එනතුරු සැසියක් බලා සිටින්න. ඔහුට උත්තර දෙන්න. මක්නිසාද යත් එය කැඩී යා හැකි ස්ථානය අනාවැකි කිව නොහැකි බැවිනි.

ඔබගේ යෙදුම අවසන් වූ විට, ඔබ සුදුසු පිටවීමේ කේතයක් සැපයිය යුතුය. එනම්, ඔබගේ යෙදුම වසා දැමීමට, නැවැත්වීමට ඉල්ලා සිටියේ නම් සහ එය සාමාන්‍ය ලෙස නැවැත්වීමට හැකි වූයේ නම්, ඔබට යම් ආකාරයක පිටවීමේ කේතයක් 1,5,255 සහ යනාදිය ආපසු ලබා දීමට අවශ්‍ය නොවේ. ශුන්‍ය කේතය නොවන ඕනෑම දෙයක්, අවම වශයෙන් ලිනක්ස් පද්ධතිවල, මට මෙය විශ්වාසයි, අසාර්ථක ලෙස සලකනු ලැබේ. එනම්, මෙම නඩුවේ ඔබගේ අයදුම්පත දෝෂයකින් අවසන් වූ බව සලකනු ලැබේ. ඒ අනුව, මිත්‍රශීලී ආකාරයකින්, ඔබේ අයදුම්පත දෝෂයකින් තොරව සම්පූර්ණ කළහොත්, ඔබ ප්‍රතිදානයේ 0 යැයි කියනු ඇත. කිසියම් හේතුවක් නිසා ඔබගේ යෙදුම අසාර්ථක වුවහොත්, ඔබ ප්‍රතිදානයේ 0 නොවන බව කියයි. තවද ඔබට මෙම තොරතුරු සමඟ වැඩ කළ හැකිය.

සහ අවසාන විකල්පය. ඔබගේ පරිශීලකයා ඉල්ලීමක් යවා ඔබ එය සකසන අතරතුර පැය භාගයක් එල්ලී සිටින විට එය නරක ය. නමුත් පොදුවේ ගත් කල, සේවාදායකයාගේ පැත්තෙන් පොදුවේ වටින දේ ගැන ද කියන්නට කැමැත්තෙමි. ඔබට ජංගම යෙදුමක්, ඉදිරිපස අන්තයක් ආදිය තිබේද යන්න ගැටළුවක් නොවේ. සාමාන්යයෙන් පරිශීලකයාගේ සැසිය අවසන් කළ හැකි බව සැලකිල්ලට ගත යුතුය, ඕනෑම දෙයක් සිදුවිය හැකිය. ඉල්ලීමක් යැවිය හැක, උදාහරණයක් ලෙස, යටින් සකසන ලද අතර ප්‍රතිචාරයක් නොලැබේ. ඔබගේ ඉදිරිපස හෝ ඔබගේ ජංගම යෙදුම - පොදුවේ ඕනෑම ඉදිරිපස, අපි එය එසේ කරමු - මෙය සැලකිල්ලට ගත යුතුය. ඔබ වෙබ් සොකට් සමඟ වැඩ කරන්නේ නම්, මෙය සාමාන්‍යයෙන් මට ඇති වූ දරුණුතම වේදනාවයි.

සමහර සාමාන්‍ය කතාබස් වල සංවර්ධකයින් එය නොදන්නා විට, වෙබ් සොකට් එක කැඩී යා හැක. ඔවුන් සඳහා, ප්‍රොක්සියේ යමක් සිදු වූ විට, අපි වින්‍යාසය පමණක් වෙනස් කරමු, එය නැවත පූරණය කරයි. ස්වාභාවිකවම, මෙම නඩුවේ සියලුම දිගුකාලීන සැසි ඉරා ඇත. සංවර්ධකයින් අප වෙත දුව ගොස් මෙසේ පවසති: "යාලුවනේ, ඔබ මොකද කරන්නේ, අපගේ සියලුම ගනුදෙනුකරුවන් සඳහා කතාබස් බිඳ වැටී ඇත!" අපි ඔවුන්ට කියනවා: “ඔබ මොකද කරන්නේ? ඔබේ ගනුදෙනුකරුවන්ට නැවත සම්බන්ධ වීමට නොහැකිද? ඔවුන් කියනවා: "නැහැ, අපට සැසි ඉරා නොදැමීමට අවශ්යයි." කෙටියෙන් කිවහොත්, මෙය ඇත්ත වශයෙන්ම විකාරයකි. සේවාදායකයාගේ පැත්ත සැලකිල්ලට ගත යුතුය. විශේෂයෙන්ම, මම පවසන පරිදි, වෙබ්සොකට් වැනි දිගුකාලීන සැසි සමඟ, එය බිඳ දැමිය හැකි අතර, පරිශීලකයාගේ අවධානයට ලක් නොවී, එවැනි සැසි නැවත ස්ථාපනය කිරීමට ඔබට හැකි විය යුතුය. එතකොට හැම දෙයක්ම පරිපූර්ණයි.

සම්පත්

ඇත්තටම, මෙන්න මම ඔබට සරල කතාවක් කියන්නම්. නැවතත් සැබෑ ජීවිතයෙන්. සම්පත් ගැන මා අසා ඇති අසනීපම දෙය.

මෙම නඩුවේ සම්පත්, මම අදහස් කරන්නේ, යම් ආකාරයක ඉල්ලීම්, ඔබේ Kubernetes පොකුරු වල කරල් මත තැබිය හැකි සීමාවන්. සංවර්ධකයෙකුගෙන් මට ඇසුණු හාස්‍යජනකම දෙය... පෙර සේවා ස්ථානයක මගේ සෙසු සංවර්ධකයෙකු වරක් පැවසුවේ: "මගේ යෙදුම පොකුරෙන් ආරම්භ නොවනු ඇත." එය ආරම්භ නොවන බව මම බැලුවෙමි, නමුත් එක්කෝ එය සම්පත් වලට නොගැලපේ, නැතහොත් ඔවුන් ඉතා කුඩා සීමාවන් තබා ඇත. කෙටියෙන් කිවහොත්, සම්පත් නිසා යෙදුම ආරම්භ කළ නොහැක. මම කියනවා: "එය සම්පත් නිසා ආරම්භ නොවනු ඇත, ඔබට කොපමණ අවශ්යදැයි තීරණය කර ප්රමාණවත් අගයක් සකසන්න." ඔහු මෙසේ කියයි: "මොන ආකාරයේ සම්පත්ද?" Kubernetes, ඉල්ලීම් සඳහා සීමාවන් සහ blah, blah, blah සැකසිය යුතු බව මම ඔහුට පැහැදිලි කිරීමට පටන් ගතිමි. මිනිසා විනාඩි පහක් සවන් දී, හිස නමා මෙසේ කීවේය: “මම මෙහි පැමිණියේ සංවර්ධකයෙකු ලෙස වැඩ කිරීමට, මට කිසිදු සම්පත් ගැන කිසිවක් දැන ගැනීමට අවශ්‍ය නැත. මම මෙතනට ආවේ කේතය ලියන්න, ඒක තමයි." එය කනගාටුවට කරුණක්. මෙය සංවර්ධකයෙකුගේ දෘෂ්ටි කෝණයෙන් ඉතා කණගාටුදායක සංකල්පයකි. විශේෂයෙන්ම නූතන ලෝකයේ, එසේ කතා කිරීමට, ප්රගතිශීලී devops.

සම්පත් කොහෙත්ම අවශ්ය වන්නේ ඇයි? Kubernetes හි සම්පත් වර්ග 2 ක් ඇත. සමහර ඒවා ඉල්ලීම් ලෙස හැඳින්වේ, අනෙක් ඒවා සීමාවන් ලෙස හැඳින්වේ. සෑම විටම මූලික වශයෙන් ඇත්තේ මූලික සීමාවන් දෙකක් පමණක් බව සම්පත් මගින් අපට වැටහෙනු ඇත. එනම්, Kubernetes හි ධාවනය වන බහාලුමක් සඳහා CPU කාල සීමාවන් සහ RAM සීමාවන්.

සීමාවක් ඔබේ යෙදුමේ සම්පතක් භාවිතා කළ හැකි ආකාරය පිළිබඳ ඉහළ සීමාවක් තබයි. එනම්, ඒ අනුව, ඔබ සීමාවන් තුළ 1GB RAM ප්‍රමාණයක් යැයි පැවසුවහොත්, එවිට ඔබගේ යෙදුමට 1GB RAM ප්‍රමාණයකට වඩා භාවිතා කිරීමට නොහැකි වනු ඇත. ඔහුට හදිසියේම අවශ්‍ය වී මෙය කිරීමට උත්සාහ කළහොත්, Oom killer නම් ක්‍රියාවලියක්, මතකයෙන් බැහැරව, එනම්, පැමිණ ඔබේ යෙදුම විනාශ කරයි - එනම්, එය සරලව නැවත ආරම්භ වේ. CPU මත පදනම්ව යෙදුම් නැවත ආරම්භ නොවනු ඇත. CPU සම්බන්ධයෙන් ගත් කල, යම් යෙදුමක් සීමාවන්හි දක්වා ඇති ප්‍රමාණයට වඩා වැඩි ප්‍රමාණයක් භාවිතා කිරීමට උත්සාහ කරන්නේ නම්, CPU සරලව තෝරා ගනු ලැබේ. මෙය නැවත ආරම්භ කිරීමට හේතු නොවේ. මෙය සීමාවයි - මෙය ඉහළ සීමාවයි.

ඒ වගේම ඉල්ලීමක් තියෙනවා. ඉල්ලීමක් වන්නේ ඔබේ Kubernetes පොකුරේ ඇති නෝඩ් යෙදුම්වලින් පිරී ඇති ආකාරය Kubernetes තේරුම් ගන්නේ කෙසේද යන්නයි. එනම්, ඉල්ලීමක් යනු ඔබගේ අයදුම්පතෙහි කැපවීමකි. මට භාවිතා කිරීමට අවශ්‍ය දේ එහි සඳහන් වේ: "ඔබ මා වෙනුවෙන් මෙතරම් CPU සහ මෙතරම් මතකය වෙන් කර දෙනවාට මම කැමතියි." එවැනි සරල සමානකමක්. මම දන්නේ නැහැ, මුළු CPU 8 ක් ඇති නෝඩයක් අපට තිබේ නම් කුමක් කළ යුතුද? ඒවගේම එතනට පොඩ් එකක් එනවා, එයාගේ ඉල්ලීම් වලට කියනවා CPU 1, ඒ කියන්නේ node එකේ CPU 7ක් ඉතුරුයි. එනම්, ඒ අනුව, මෙම නෝඩයට පොඩ් 8 ක් පැමිණි විගසම, ඒවායේ ඉල්ලීම්වල CPU 1 බැගින් ඇත, නෝඩයේ, Kubernetes ගේ දෘෂ්ටි කෝණයෙන් මෙන්, CPU අවසන් වී ඇති අතර ඉල්ලීම් සහිත තවත් කරල් විය නොහැක. මෙම node මත දියත් කරන ලදී. සියලුම නෝඩ් වල CPU අවසන් වුවහොත්, CPU අවසන් වී ඇති නිසා ඔබේ පොඩ්ස් ක්‍රියාත්මක කිරීමට සුදුසු නෝඩ් පොකුරේ නොමැති බව Kubernetes කියන්නට පටන් ගනී.

ඉල්ලීම් අවශ්‍ය වන්නේ ඇයි සහ ඉල්ලීම් නොමැතිව කුබර්නෙට්ස් හි කිසිවක් දියත් කිරීමට අවශ්‍ය නැතැයි මම සිතමි? අපි උපකල්පිත තත්වයක් සිතමු. ඔබ ඉල්ලීම් නොමැතිව ඔබගේ යෙදුම දියත් කරයි, Kubernetes ඔබ සතුව ඇති දේ කොපමණද, ඔබට එය තල්ලු කළ හැකි නෝඩ් මොනවාදැයි නොදනී. හොඳයි, ඔහු තල්ලු කරයි, තල්ලු කරයි, නෝඩ් මතට තල්ලු කරයි. යම් අවස්ථාවක දී, ඔබ ඔබේ යෙදුම වෙත ගමනාගමනය ලබා ගැනීමට පටන් ගනී. තවද එක් යෙදුමක් හදිසියේම සීමාවන්ට අනුව එහි ඇති සීමාවන් දක්වා සම්පත් භාවිතා කිරීමට පටන් ගනී. අසල තවත් යෙදුමක් ඇති බවත් එයට සම්පත් ද අවශ්‍ය බවත් පෙනේ. නෝඩය ඇත්ත වශයෙන්ම භෞතිකව සම්පත් අවසන් වීමට පටන් ගනී, උදාහරණයක් ලෙස, OP. නෝඩය ඇත්ත වශයෙන්ම සම්පත් වලින් භෞතිකව ධාවනය වීමට පටන් ගනී, උදාහරණයක් ලෙස, සසම්භාවී ප්රවේශ මතකය (RAM). නෝඩයක බලය අවසන් වූ විට, පළමුව ඩොකර් ප්‍රතිචාර දැක්වීම නවත්වනු ඇත, පසුව කියුබ්ලට්, පසුව මෙහෙයුම් පද්ධතිය. ඔවුන් හුදෙක් සිහිසුන් වනු ඇති අතර සෑම දෙයක්ම නියත වශයෙන්ම ඔබ වෙනුවෙන් වැඩ කිරීම නවත්වනු ඇත. එනම්, මෙය ඔබගේ නෝඩය හිරවීමට තුඩු දෙනු ඇති අතර ඔබට එය නැවත ආරම්භ කිරීමට සිදුවනු ඇත. කෙටියෙන් කිවහොත්, තත්වය එතරම් හොඳ නැත.

ඔබට ඉල්ලීම් ඇති විට, සීමාවන් ඉතා වෙනස් නොවේ, අවම වශයෙන් සීමාවන් හෝ ඉල්ලීම් වලට වඩා බොහෝ ගුණයක් නොවේ, එවිට ඔබට Kubernetes පොකුරු නෝඩ් හරහා එවැනි සාමාන්‍ය, තාර්කික යෙදුම් පිරවීමක් කළ හැකිය. ඒ අතරම, Kubernetes එය කොතැනක තබන දේ, කොපමණ භාවිතා කරන්නේද යන්න පිළිබඳව දළ වශයෙන් දනී. එනම්, එය එවැනි මොහොතක් පමණි. එය තේරුම් ගැනීම වැදගත්ය. තවද මෙය ඇඟවුම් කර ඇති බව පාලනය කිරීම වැදගත් වේ.

දත්ත ගබඩාව

අපගේ ඊළඟ කරුණ වන්නේ දත්ත ගබඩා කිරීම ගැන ය. ඔවුන් සමඟ කළ යුත්තේ කුමක්ද සහ පොදුවේ, Kubernetes හි නොපසුබට උත්සාහයෙන් කුමක් කළ යුතුද?

මම හිතන්නේ, නැවතත්, අපේ ඇතුළත සවස පාසල, Kubernetes හි දත්ත සමුදාය පිළිබඳ මාතෘකාවක් විය. “කුබර්නෙට්ස් හි දත්ත ගබඩාවක් ක්‍රියාත්මක කළ හැකිද?” යනුවෙන් ඇසූ විට ඔබේ සගයන් ඔබට පැවසූ දේ මම දළ වශයෙන් දන්නා බව මට පෙනේ. කිසියම් හේතුවක් නිසා, කුබර්නෙටස් හි දත්ත ගබඩාවක් ක්‍රියාත්මක කළ හැකිද යන ප්‍රශ්නය ඔබ අසන්නේ නම්, එය කළ නොහැකි බව ඔබේ සගයන් ඔබට පැවසිය යුතු බව මට පෙනේ.

මෙහි තර්කනය සරලයි. යම් අවස්ථාවක දී, මම නැවත වරක් පැහැදිලි කරන්නම්, ඔබ බෙදා හරින ලද ජාල ආචයනයේ තරමක් දෝෂ-ඉවසන පද්ධතියක් ගොඩනගා ගත හැකි ඇත්තෙන්ම සිසිල් පුද්ගලයෙක් නම්, මෙම නඩුවට දත්ත සමුදායක් සවි කරන්නේ කෙසේද, බහාලුම්වල ඇති ක්ලවුඩ් ස්වදේශික ක්‍රියා කළ යුතු ආකාරය තේරුම් ගන්න. පොදුවේ දත්ත ගබඩාවක. බොහෝ දුරට, එය ක්රියාත්මක කරන්නේ කෙසේද යන්න පිළිබඳව ඔබට ප්රශ්නයක් නොමැත. ඔබට එවැනි ප්‍රශ්නයක් තිබේ නම්, ඒ සියල්ල දිග හැරෙන අතර නිෂ්පාදනයේදී මරණය දක්වාම පවතින බවත් කිසි විටෙකත් වැටෙන්නේ නැති බවත් සහතික කර ගැනීමට ඔබට අවශ්‍ය නම්, මෙය සිදු නොවේ. මෙම ප්රවේශය සමඟ ඔබ පාදයේ වෙඩි තැබීම සහතික කර ඇත. ඒ නිසා එහෙම නොකර ඉන්න එක හොඳයි.

අපගේ යෙදුම ගබඩා කිරීමට කැමති දත්ත, පරිශීලකයින් උඩුගත කරන සමහර පින්තූර, අපගේ යෙදුම එහි ක්‍රියාකාරිත්වය අතරතුර උත්පාදනය කරන සමහර දේවල්, උදාහරණයක් ලෙස, ආරම්භයේදී අප කුමක් කළ යුතුද? Kubernetes හි ඔවුන් සමඟ කුමක් කළ යුතුද?

පොදුවේ ගත් කල, ඉතා මැනවින්, ඔව්, ඇත්ත වශයෙන්ම, Kubernetes ඉතා හොඳින් නිර්මාණය කර ඇති අතර සාමාන්‍යයෙන් මුලින් සංකල්පිත යෙදුම් සඳහා සංකල්පනය කරන ලදී. එනම්, තොරතුරු කිසිසේත් ගබඩා නොකරන යෙදුම් සඳහා ය. මෙය කදිමයි.

එහෙත්, ඇත්ත වශයෙන්ම, පරිපූර්ණ විකල්පය සෑම විටම නොපවතී. ඉතින් කුමක් ද? පළමු හා සරලම කරුණ නම් යම් ආකාරයක S3 වර්ගයක් ගැනීමයි, එය ගෙදර හැදූ එකක් නොවේ, එය ක්‍රියා කරන ආකාරය ද අපැහැදිලි ය, නමුත් සමහර සැපයුම්කරුවන්ගෙන්. හොඳ, සාමාන්‍ය සැපයුම්කරුවෙකු - සහ S3 භාවිතා කිරීමට ඔබේ යෙදුමට උගන්වන්න. එනම්, ඔබේ පරිශීලකයාට ගොනුවක් උඩුගත කිරීමට අවශ්‍ය වූ විට, "මෙන්න, කරුණාකර එය S3 වෙත උඩුගත කරන්න" යැයි පවසන්න. ඔහුට එය ලැබීමට අවශ්‍ය වූ විට, “මෙන්න S3 වෙත සබැඳියක් ආපසු මෙතැනින් ගන්න” යැයි පවසන්න. මෙය කදිමයි.

හදිසියේම කිසියම් හේතුවක් නිසා මෙම පරමාදර්ශී විකල්පය සුදුසු නොවේ නම්, ඔබ ලියා නැති යෙදුමක් තිබේ නම්, ඔබ සංවර්ධනය නොකරනවා නම්, හෝ එය යම් ආකාරයක භයානක උරුමයක් නම්, එය S3 ප්රොටෝකෝලය භාවිතා කළ නොහැක, නමුත් දේශීය නාමාවලි සමඟ වැඩ කළ යුතුය. දේශීය ෆෝල්ඩර . වැඩි හෝ අඩු සරල දෙයක් ගන්න, Kubernetes යොදවන්න. එනම්, සමහර අවම කාර්යයන් සඳහා වහාම Ceph වැටක් දැමීම, මට පෙනෙන පරිදි, නරක අදහසකි. මක්නිසාද යත්, Ceph, ඇත්ත වශයෙන්ම, හොඳ සහ විලාසිතාවකි. නමුත් ඔබ ඇත්තටම කරන්නේ කුමක්ද යන්න ඔබට නොතේරෙන්නේ නම්, ඔබ Ceph මත යමක් තැබූ පසු, ඔබට ඉතා පහසුවෙන් සහ සරලව එය නැවත කිසි දිනෙක එතැනින් ඉවත් කර ගත නොහැක. මන්ද, ඔබ දන්නා පරිදි, Ceph එහි පොකුරේ දත්ත ගබඩා කරන්නේ ද්විමය ආකාරයෙන් මිස සරල ගොනු ආකාරයෙන් නොවේ. එමනිසා, හදිසියේම Ceph පොකුර බිඳවැටෙන්නේ නම්, එවිට ඔබට නැවත කිසි දිනෙක ඔබේ දත්ත ලබා නොගැනීමේ සම්පූර්ණ සහ ඉහළ සම්භාවිතාවක් ඇත.

අපි Ceph පිළිබඳ පාඨමාලාවක් ඇත, ඔබට පුළුවන් වැඩසටහන ගැන හුරුපුරුදු වී අයදුම්පතක් ඉදිරිපත් කරන්න.

එබැවින්, NFS සේවාදායකයක් වැනි සරල දෙයක් කිරීම වඩා හොඳය. Kubernetes හට ඔවුන් සමඟ වැඩ කළ හැකිය, ඔබට NFS සේවාදායකයක් යටතේ නාමාවලියක් සවි කළ හැකිය - ඔබගේ යෙදුම දේශීය නාමාවලියක් වැනිය. ඒ අතරම, ස්වාභාවිකවම, ඔබ නැවත වරක්, ඔබේ NFS සමඟ යමක් කළ යුතු බව ඔබ තේරුම් ගත යුතුය, සමහර විට එය ප්‍රවේශ විය නොහැකි බව ඔබ තේරුම් ගත යුතු අතර මෙම නඩුවේදී ඔබ කරන්නේ කුමක්ද යන ප්‍රශ්නය සලකා බලන්න. සමහර විට එය වෙනම යන්ත්රයක් මත කොහේ හරි උපස්ථ කළ යුතුය.

මම කතා කළ ඊළඟ කරුණ නම් ඔබගේ යෙදුම ක්‍රියාත්මක වන විට ගොනු කිහිපයක් ජනනය කරන්නේ නම් කුමක් කළ යුතුද යන්නයි. උදාහරණයක් ලෙස, එය ආරම්භ වන විට, එය යම් ස්ථිතික ගොනුවක් ජනනය කරයි, එය යෙදුම දියත් කරන අවස්ථාවේදී පමණක් ලැබෙන සමහර තොරතුරු මත පදනම් වේ. මොන මොහොතක්ද. එවැනි දත්ත විශාල ප්‍රමාණයක් නොමැති නම්, ඔබට කිසිසේත් කරදර විය යුතු නැත, මෙම යෙදුම ඔබ වෙනුවෙන් ස්ථාපනය කර වැඩ කරන්න. මෙහි ඇති එකම ප්‍රශ්නය කුමක්ද, බලන්න. බොහෝ විට, වර්ඩ්ප්‍රෙස් සහ යනාදිය වැනි සියලුම ආකාරයේ උරුම පද්ධති, විශේෂයෙන් වෙනස් කරන ලද යම් ආකාරයක දක්ෂ ප්ලගීන, දක්ෂ PHP සංවර්ධකයින් සමඟ, ඔවුන් බොහෝ විට එය කරන්නේ කෙසේදැයි දන්නා අතර එමඟින් ඔවුන් තමන්ටම යම් ආකාරයක ගොනුවක් ජනනය කරයි. ඒ අනුව, එක් ගොනුවක් උත්පාදනය කරයි, දෙවැන්න දෙවන ගොනුව ජනනය කරයි. ඔවුන් වෙනස් ය. ගනුදෙනුකරුවන්ගේ Kubernetes පොකුරේ සමතුලිත වීම අහම්බෙන් සිදු වේ. ඒ අනුව, ඔවුන් උදාහරණයක් ලෙස එකට වැඩ කරන්නේ කෙසේදැයි නොදන්නා බව පෙනී යයි. එකක් එක් තොරතුරක් ලබා දෙයි, අනෙක පරිශීලකයාට තවත් තොරතුරක් ලබා දෙයි. ඔබ වැළකී සිටිය යුත්තේ මෙයයි. එනම්, Kubernetes හි, ඔබ දියත් කරන සෑම දෙයක්ම අවස්ථා කිහිපයකදී වැඩ කිරීමට හැකි බවට සහතික වේ. මොකද Kubernetes කියන්නේ චංචල දෙයක්. ඒ අනුව, ඔහුට අවශ්‍ය ඕනෑම වේලාවක, කිසිවෙකුගෙන් කිසිවක් නොවිමසා ඕනෑම දෙයක් චලනය කළ හැකිය. එමනිසා, ඔබ මෙය ගණන් ගත යුතුය. එක් අවස්ථාවක දියත් කරන ලද සෑම දෙයක්ම ඉක්මනින් හෝ පසුව අසාර්ථක වනු ඇත. ඔබට වෙන් කිරීම් වැඩි වන තරමට වඩා හොඳය. නමුත් නැවතත්, මම කියන්නේ, ඔබ සතුව එවැනි ලිපිගොනු කිහිපයක් තිබේ නම්, ඔබට ඒවා ඔබ යටතේ තැබිය හැකිය, ඒවා කුඩා ප්රමාණයක් බරයි. ඔවුන්ගෙන් ටිකක් වැඩිපුර තිබේ නම්, ඔබ බොහෝ විට ඒවා කන්ටේනරය තුළට තල්ලු නොකළ යුතුය.

Kubernetes හි එවැනි පුදුම දෙයක් ඇති බව මම උපදෙස් දෙන්නෙමි, ඔබට පරිමාව භාවිතා කළ හැකිය. විශේෂයෙන්ම, හිස් ඩිර් වර්ගයේ පරිමාවක් ඇත. එනම්, Kubernetes ඔබ ආරම්භ කළ සේවාදායකයේ එහි සේවා නාමාවලි තුළ ස්වයංක්‍රීයව නාමාවලියක් සාදනු ඇත. තවද ඔබට එය භාවිතා කළ හැකි වන පරිදි ඔහු එය ඔබට දෙනු ඇත. එක් වැදගත් කරුණක් පමණි. එනම්, ඔබේ දත්ත ගබඩා වන්නේ බහාලුම තුළ නොව, ඔබ ධාවනය කරන ධාරකයේ ය. එපමනක් නොව, Kubernetes සාමාන්ය වින්යාසය යටතේ එවැනි හිස් dirs පාලනය කළ හැකි අතර ඔවුන්ගේ උපරිම ප්රමාණය පාලනය කිරීමට හැකි වන අතර එය ඉක්මවා යාමට ඉඩ නොදේ. එකම කරුණ නම් ඔබ හිස් dir වලින් ලියා ඇති දේ පොඩ් නැවත ආරම්භ කිරීමේදී නැති නොවීමයි. එනම් ඔබේ පොඩ් වැරදීමකින් වැටී නැවත නැඟී ඇත්නම් හිස් ඩිර් එකේ තොරතුරු කොහේවත් යන්නේ නැත. ඔහුට එය නව ආරම්භයකින් නැවත භාවිතා කළ හැකිය - එය හොඳයි. ඔබේ පොඩ් කොහේ හරි ගියොත්, ස්වභාවිකවම ඔහු දත්ත නොමැතිව පිටව යනු ඇත. එනම් හිස් ඩිර් සමඟ දියත් කළ නෝඩ් එකේ පොඩ් එක අතුරුදහන් වූ වහාම හිස් ඩිර් මකයි.

හිස් ඩිර් ගැන තවත් හොඳ කුමක්ද? උදාහරණයක් ලෙස, එය හැඹිලියක් ලෙස භාවිතා කළ හැකිය. අපගේ යෙදුම පියාසර කරන විට යමක් ජනනය කරයි, එය පරිශීලකයින්ට ලබා දෙයි, සහ දිගු කාලයක් එය කරයි යැයි සිතමු. එමනිසා, යෙදුම, උදාහරණයක් ලෙස, එය උත්පාදනය කර පරිශීලකයින්ට ලබා දෙන අතර, ඒ සමඟම එය කොතැනක හෝ ගබඩා කරයි, එවිට පරිශීලකයා ඊළඟ වතාවේ එකම දේ සඳහා පැමිණෙන විට, එය වහාම උත්පාදනය කිරීම වේගවත් වනු ඇත. මතකයේ නිර්මාණය කිරීමට හිස් ඩිර් කුබර්නෙටස්ගෙන් ඉල්ලා සිටිය හැක. මේ අනුව, ඔබේ හැඹිලි සාමාන්‍යයෙන් අකුණු වේගයෙන් ක්‍රියා කළ හැකිය - තැටි ප්‍රවේශ වේගය අනුව. එනම්, ඔබට මතකයේ හිස් ඩිර් එකක් ඇත, මෙහෙයුම් පද්ධතිය තුළ එය මතකයේ ගබඩා කර ඇත, නමුත් ඔබට, පොඩ් එක තුළ සිටින පරිශීලකයාට එය දේශීය නාමාවලියක් ලෙස පෙනේ. ඔබට විශේෂයෙන් කිසිම මැජික් ඉගැන්වීමට යෙදුම අවශ්‍ය නොවේ. ඔබ කෙලින්ම ගෙන ගොස් ඔබේ ගොනුව ඩිරෙක්ටරියක තබන්න, නමුත් ඇත්ත වශයෙන්ම OS මත මතකයේ ඇත. මෙය Kubernetes අනුවද ඉතා පහසු අංගයකි.

Minio ට ඇති ගැටළු මොනවාද? Minio හි ඇති ප්‍රධාන ගැටළුව නම්, මෙම දෙය ක්‍රියාත්මක වීමට නම්, එය කොහේ හරි ක්‍රියාත්මක විය යුතු අතර, යම් ආකාරයක ගොනු පද්ධතියක් තිබිය යුතුය, එනම් ගබඩා කිරීම. Cep ට ඇති එකම ගැටළු මෙහි දී අපට හමු වේ. එනම්, Minio එහි ගොනු කොහේ හෝ ගබඩා කළ යුතුය. එය හුදෙක් ඔබගේ ගොනු වලට HTTP අතුරුමුහුණතකි. එපමනක් නොව, ක්‍රියාකාරීත්වය පැහැදිලිවම Amazon හි S3 වලට වඩා දුර්වලය. මීට පෙර, පරිශීලකයාට නිසි ලෙස අවසර දීමට එයට නොහැකි විය. දැන්, මා දන්නා පරිදි, එය දැනටමත් විවිධ අවසරයන් සහිත බාල්දි නිර්මාණය කළ හැකිය, නමුත් නැවතත්, මට පෙනෙන පරිදි, ප්රධාන ගැටළුව වන්නේ, කතා කිරීමට, අවම වශයෙන් යටින් පවතින ගබඩා පද්ධතියයි.

මතකයේ ඇති Empty dir සීමාවන්ට බලපාන්නේ කෙසේද? කිසිම ආකාරයකින් සීමාවන්ට බලපාන්නේ නැත. එය ධාරකයාගේ මතකයේ මිස ඔබේ බහාලුම් මතකයේ නොවේ. එනම්, ඔබේ බහාලුම් මතකයේ ඇති හිස් ඩිර් එහි වාඩිලාගත් මතකයේ කොටසක් ලෙස නොපෙනේ. සත්කාරක සමාගම මෙය දකිනවා. ඒ අනුව ඔව්, kubernetes ගේ පැත්තෙන් බැලුවම මේක පාවිච්චි කරන්න පටන් ගත්තම ඔයා ඔයාගේ මතකයෙන් කොටසක් හිස් dir වලට කැප කරනවා කියලා තේරුම් ගත්තොත් හොඳයි. ඒ අනුව, මතකය ඉවත් විය හැක්කේ යෙදුම් නිසා පමණක් නොව, යමෙකු මෙම හිස් ලිපිවලට ලියන නිසා බව තේරුම් ගන්න.

වලාකුළු ස්වභාවය

අවසාන උප මාතෘකාව වන්නේ Cloudnative යනු කුමක්ද යන්නයි. එය අවශ්ය වන්නේ ඇයි? Cloudnativeness සහ එසේ ය.

එනම්, නවීන ක්ලවුඩ් යටිතල ව්‍යුහයක වැඩ කිරීමට හැකියාව ඇති සහ ලියා ඇති යෙදුම්. නමුත්, ඇත්ත වශයෙන්ම, Cloudnative හි තවත් එවැනි අංගයක් ඇත. මෙය නවීන වලාකුළු යටිතල ව්‍යුහයක සියලුම අවශ්‍යතා සැලකිල්ලට ගන්නා යෙදුමක් පමණක් නොව, මෙම නවීන වලාකුළු යටිතල ව්‍යුහය සමඟ වැඩ කරන්නේ කෙසේදැයි ද දන්නා අතර, එය මෙම වලාකුළු තුළ ක්‍රියා කරන බවෙහි වාසි සහ අවාසි වලින් ප්‍රයෝජන ගන්න. නිකම්ම උඩින් ගොස් වලාකුළු වල වැඩ නොකරන්න, නමුත් වලාකුළේ වැඩ කිරීමේ ප්රතිලාභවලින් ප්රයෝජන ගන්න.

අපි උදාහරණයක් ලෙස Kubernetes ගනිමු. ඔබගේ යෙදුම Kubernetes හි ධාවනය වේ. ඔබගේ යෙදුමට සෑම විටම හෝ ඔබගේ යෙදුම සඳහා පරිපාලකයින්ට සෑම විටම සේවා ගිණුමක් සෑදිය හැක. එනම්, Kubernetes හි අවසරය සඳහා ගිණුමක් එහි සේවාදායකයේ ඇත. එහිදී අපට අවශ්‍ය අයිතිවාසිකම් කිහිපයක් එක් කරන්න. තවද ඔබට ඔබගේ යෙදුම තුලින් Kubernetes වෙත ප්‍රවේශ විය හැක. ඔබට මේ ආකාරයෙන් කුමක් කළ හැකිද? උදාහරණයක් ලෙස, යෙදුමෙන්, ඔබේ අනෙකුත් යෙදුම්, වෙනත් සමාන අවස්ථා පිහිටා ඇති ස්ථානය පිළිබඳ දත්ත ලබා ගන්න, සහ එවැනි අවශ්‍යතාවයක් තිබේ නම්, කෙසේ හෝ Kubernetes මුදුනේ පොකුරු කරන්න.

නැවතත්, අපට මෑතකදී නඩුවක් තිබුණි. අපට පෝලිම නිරීක්ෂණය කරන එක් පාලකයෙක් සිටී. මෙම පෝලිමේ සමහර නව කාර්යයන් දිස්වන විට, එය කුබර්නෙටස් වෙත යයි - සහ කුබර්නෙටස් තුළ එය නව පොඩ් එකක් නිර්මාණය කරයි. මෙම පොඩ්ඩයට යම් නව කාර්යයක් ලබා දෙන අතර මෙම පොඩ් රාමුව තුළ, පොඩ් කාර්යය ඉටු කරයි, පාලකයටම ප්‍රතිචාරයක් යවයි, පසුව පාලකය මෙම තොරතුරු සමඟ යමක් කරයි. උදාහරණයක් ලෙස, එය දත්ත සමුදායක් එකතු කරයි. එනම්, නැවතත්, මෙය අපගේ යෙදුම Kubernetes හි ක්‍රියාත්මක වීමේ ප්ලස් එකකි. අපගේ යෙදුමේ ක්‍රියාකාරිත්වය කෙසේ හෝ පුළුල් කිරීමට සහ වඩාත් පහසු කිරීමට අපට ගොඩනඟන ලද Kubernetes ක්‍රියාකාරීත්වයම භාවිතා කළ හැකිය. එනම්, යෙදුමක් දියත් කරන්නේ කෙසේද, සේවකයෙකු දියත් කරන්නේ කෙසේද යන්න පිළිබඳ යම් ආකාරයක මැජික් සඟවන්න එපා. Kubernetes හි, යෙදුම Python වලින් ලියා ඇත්නම් ඔබ යෙදුම තුළ ඉල්ලීමක් යවන්න.

අපි Kubernetes ඔබ්බට ගියොත් එයම අදාළ වේ. අපේ Kubernetes කොහේ හරි දුවනවා - එය යම් ආකාරයක වලාකුළක තිබේ නම් හොඳයි. නැවතත්, අපට භාවිතා කළ හැකි අතර, මම විශ්වාස කරන පරිදි, අප ධාවනය වන වලාකුළෙහිම හැකියාවන් භාවිතා කළ යුතුය. වලාකුළ අපට සපයන මූලික දේවල් වලින්. සමතුලිත කිරීම, එනම්, අපට ක්ලවුඩ් බැලන්සර් සාදා ඒවා භාවිතා කළ හැකිය. මෙය අපට භාවිතා කළ හැකි සෘජු වාසියකි. මන්ද වලාකුළු තුලනය, පළමුව, එය ක්‍රියා කරන ආකාරය, එය වින්‍යාස කර ඇති ආකාරය පිළිබඳ වගකීම මෝඩ ලෙස අපෙන් ඉවත් කරයි. ඊට අමතරව, එය ඉතා පහසු ය, මන්ද සාමාන්‍ය කුබර්නෙටස් වලාකුළු සමඟ ඒකාබද්ධ කළ හැකි බැවිනි.

පරිමාණය සඳහා ද එය එසේම වේ. නිත්‍ය Kubernetes හට Cloud සපයන්නන් සමඟ ඒකාබද්ධ විය හැක. පොකුරේ නෝඩ් අවසන් වී ඇත්නම්, එනම් නෝඩ් අවකාශය අවසන් වී ඇත්නම්, ඔබ එකතු කළ යුතු බව තේරුම් ගන්නේ කෙසේදැයි දනී - Kubernetes විසින්ම ඔබේ පොකුරට නව නෝඩ් එකතු කර ඒවා මත කරල් දියත් කිරීමට පටන් ගනී. එනම්, ඔබේ බර පැමිණි විට, උදුන ගණන වැඩි වීමට පටන් ගනී. මෙම කරල් සඳහා පොකුරේ ඇති නෝඩ් අවසන් වූ විට, Kubernetes නව නෝඩ් දියත් කරන අතර, ඒ අනුව, කරල් ගණන තවමත් වැඩි විය හැක. ඒ වගේම හරිම පහසුයි. මෙය පියාසර කරන විට පොකුර පරිමාණය කිරීමට සෘජු අවස්ථාවකි. ඉතා වේගවත් නොවේ, එය තත්පරයක් නොවන අර්ථයෙන්, නව නෝඩ් එකතු කිරීම සඳහා එය මිනිත්තුවක් වැනි ය.

නමුත් මගේ අත්දැකීමෙන් නැවතත්, එය මා මෙතෙක් දැක ඇති සිසිල්ම දෙයයි. Cloudnative පොකුර දවසේ වේලාව මත පදනම්ව පරිමාණය කළ විට. එය පසුපස කාර්යාලයේ අය විසින් භාවිතා කරන ලද පසුපෙළ සේවාවක් විය. එනම්, ඔවුන් උදේ 9 ට වැඩට පැමිණ, පද්ධතියට ලොග් වීමට පටන් ගනී, ඒ අනුව, ඒ සියල්ල ක්‍රියාත්මක වන ක්ලවුඩ්නේටිව් පොකුර ඉදිමීමට පටන් ගනී, වැඩට එන සෑම කෙනෙකුටම යෙදුම සමඟ වැඩ කිරීමට හැකි වන පරිදි නව කරල් දියත් කරයි. ඔවුන් රාත්‍රී 8 ට හෝ සවස 6 ට රැකියාවෙන් පිටවන විට, කිසිවෙකු තවදුරටත් යෙදුම භාවිතා නොකරන බව Kubernetes පොකුරු දකින අතර හැකිලීමට පටන් ගනී. සියයට 30 දක්වා ඉතුරුම් සහතික කෙරේ. එකල ඇමේසන් වල එය ක්‍රියාත්මක විය; ඒ වන විට එය මෙතරම් හොඳින් කළ හැකි කිසිවෙකු රුසියාවේ සිටියේ නැත.

මම ඔබට කෙලින්ම කියන්නම්, ඉතිරිකිරීම් සියයට 30 ක් වන්නේ අපි Kubernetes භාවිතා කර වලාකුළේ හැකියාවන්ගෙන් ප්‍රයෝජන ගන්නා බැවිනි. දැන් මෙය රුසියාවේ කළ හැකිය. ඇත්ත වශයෙන්ම මම කිසිවෙකුට ප්‍රචාරය නොකරමි, නමුත් මෙය කළ හැකි සැපයුම්කරුවන් සිටින බව කියමු, එය බොත්තමක් සමඟ කොටුවෙන් පිටත ලබා දෙන්න.

මම ඔබේ අවධානය යොමු කිරීමට කැමති අවසාන කරුණක් ඇත. ඔබගේ යෙදුම, ඔබගේ යටිතල ව්‍යුහය Cloudnative වීම සඳහා, අවසාන වශයෙන් Infrastructure නම් ප්‍රවේශය කේතයක් ලෙස අනුවර්තනය කිරීම ආරම්භ කිරීම අර්ථවත් කරයි. එනම්, මෙයින් අදහස් කරන්නේ ඔබගේ යෙදුම හෝ ඒ වෙනුවට ඔබගේ යටිතල ව්‍යූහය හරියටම අවශ්‍ය වන බවයි. කේතය ඔබේ යෙදුම, ඔබේ ව්‍යාපාර තර්කය කේතය ආකාරයෙන් විස්තර කරන්න. එය කේතයක් ලෙස වැඩ කරන්න, එනම්, එය පරීක්ෂා කරන්න, එය රෝල් කරන්න, එය git තුළ ගබඩා කරන්න, එයට CICD යොදන්න.

මෙය හරියටම ඔබට ඉඩ සලසයි, පළමුව, සෑම විටම ඔබේ යටිතල ව්‍යුහය පාලනය කිරීමට, එය කුමන තත්වයක තිබේද යන්න සැමවිටම තේරුම් ගැනීමට. දෙවනුව, දෝෂ ඇති කරන අතින් මෙහෙයුම් වලින් වළකින්න. තෙවනුව, ඔබට නිරන්තරයෙන් එකම අතින් කාර්යයන් ඉටු කිරීමට අවශ්‍ය වූ විට, පිරිවැටුම ලෙස හඳුන්වන දෙය සරලව වළක්වා ගන්න. හතරවනුව, එය අසාර්ථක වූ විට වඩා වේගයෙන් යථා තත්ත්වයට පත් කිරීමට ඔබට ඉඩ සලසයි. රුසියාවේ, මම මේ ගැන කතා කරන සෑම අවස්ථාවකම, සෑම විටම විශාල පිරිසක් මෙසේ පවසනු ඇත: "ඔව්, එය පැහැදිලිය, නමුත් ඔබට ප්රවේශයන් තිබේ, කෙටියෙන් කිවහොත්, කිසිවක් නිවැරදි කිරීමට අවශ්ය නැත." ඒත් ඒක ඇත්ත. ඔබේ යටිතල ව්‍යූහය තුළ යම් දෙයක් කැඩී ඇත්නම්, ක්ලවුඩ්නේටිව් ප්‍රවේශයේ දෘෂ්ටි කෝණයෙන් සහ යටිතල පහසුකම් කේතයක් ලෙසින් බලන විට, එය සවි කිරීමට වඩා, සේවාදායකයට ගොස්, කැඩී ඇති දේ හඳුනාගෙන එය නිවැරදි කිරීම පහසුය. සේවාදායකය මකා දැමීමට සහ එය නැවත නිර්මාණය කිරීමට. මම මේ සියල්ල යථා තත්ත්වයට පත් කරමි.

මෙම සියලු ගැටළු වඩාත් විස්තරාත්මකව සාකච්ඡා කෙරේ Kubernetes වීඩියෝ පාඨමාලා: කනිෂ්ඨ, මූලික, මෙගා. සබැඳිය අනුගමනය කිරීමෙන් ඔබට වැඩසටහන සහ කොන්දේසි පිළිබඳව ඔබව හුරු කර ගත හැකිය. පහසුම දෙය නම්, ඔබට දිනකට පැය 1-2 ක් නිවසේ සිට හෝ වැඩ කිරීමෙන් පාඩම් කිරීමෙන් කුබර්නෙට්ස් ප්‍රගුණ කළ හැකිය.

මූලාශ්රය: www.habr.com