Kubernetes හි ස්වයං පරිමාණය සහ සම්පත් කළමනාකරණය (සමාලෝචන සහ වීඩියෝ වාර්තාව)

අප්රේල් 27 සමුළුවේදී වර්ජනය 2019, "DevOps" කොටසේ කොටසක් ලෙස, "කුබර්නෙට්ස් හි ස්වයංක්‍රීය පරිමාණය සහ සම්පත් කළමනාකරණය" වාර්තාව ලබා දෙන ලදී. ඔබගේ යෙදුම්වල ඉහළ ප්‍රතිලාභ සහතික කිරීමට සහ උපරිම කාර්ය සාධනය සහතික කිරීමට ඔබට K8s භාවිතා කළ හැකි ආකාරය ගැන එය කතා කරයි.

සම්ප්රදායට අනුව, අපි ඉදිරිපත් කිරීමට සතුටුයි වාර්තාවේ වීඩියෝව (විනාඩි 44, ලිපියට වඩා බොහෝ තොරතුරු) සහ ප්‍රධාන සාරාංශය පෙළ ආකාරයෙන්. යන්න!

වාර්තාවේ මාතෘකාව වචනයෙන් වචනය විශ්ලේෂණය කර අවසානයේ සිට ආරම්භ කරමු.

කුබර්නෙට්ස්

අපි හිතමු අපේ ධාරකයේ Docker කන්ටේනර් තියෙනවා කියලා. කුමක් සඳහා ද? පුනරාවර්තන හැකියාව සහ හුදකලා වීම සහතික කිරීම සඳහා, අනෙක් අතට සරල සහ හොඳ යෙදවීමට ඉඩ සලසයි, CI/CD. එවැනි කන්ටේනර් සහිත වාහන රාශියක් අප සතුව ඇත.

මෙම නඩුවේ Kubernetes සපයන්නේ කුමක්ද?

1. අපි මෙම යන්ත්‍ර ගැන සිතීම නවත්වා “වලාකුළු” සමඟ වැඩ කිරීමට පටන් ගනිමු. බහාලුම් පොකුරක් හෝ කරල් (කන්ටේනර් කණ්ඩායම්).
2. එපමණක්ද නොව, අපි තනි කරල් ගැන සිතන්නේවත් නැත, නමුත් තවත් කළමනාකරණය කරන්නоවිශාල කණ්ඩායම්. එබඳු ඉහළ මට්ටමේ ප්රාථමිකයන් යම් කාර්ය භාරයක් ක්‍රියාත්මක කිරීම සඳහා අච්චුවක් ඇති බව පැවසීමට අපට ඉඩ දෙන්න, එය ක්‍රියාත්මක කිරීමට අවශ්‍ය අවස්ථා සංඛ්‍යාව මෙන්න. අපි පසුව අච්චුව වෙනස් කළහොත්, සියලු අවස්ථා වෙනස් වනු ඇත.
3. සහාය ඇතිව ප්රකාශන API නිශ්චිත විධාන අනුපිළිවෙලක් ක්රියාත්මක කිරීම වෙනුවට, අපි Kubernetes විසින් නිර්මාණය කරන ලද "ලෝකයේ ව්යුහය" (YAML හි) විස්තර කරමු. නැවතත්: විස්තරය වෙනස් වූ විට, එහි සැබෑ සංදර්ශකය ද වෙනස් වනු ඇත.

සම්පත් කළමනාකරණය

CPU

අපි සේවාදායකයේ nginx, php-fpm සහ mysql ධාවනය කරමු. මෙම සේවාවන්ට ඇත්ත වශයෙන්ම ඊටත් වඩා ක්‍රියාවලි ක්‍රියාත්මක වනු ඇත, ඒ සෑම එකක්ම පරිගණක සම්පත් අවශ්‍ය වේ:

(විනිවිදකයේ ඇති සංඛ්‍යා “ගිරවුන්” වේ, පරිගණක බලය සඳහා එක් එක් ක්‍රියාවලියේ වියුක්ත අවශ්‍යතාවය)

මෙය සමඟ වැඩ කිරීම පහසු කිරීම සඳහා, ක්‍රියාවලි කණ්ඩායම් වලට ඒකාබද්ධ කිරීම තාර්කික ය (උදාහරණයක් ලෙස, සියලුම nginx ක්‍රියාවලි එක් කණ්ඩායමකට “nginx”). මෙය කිරීමට සරල සහ පැහැදිලි ක්රමයක් වන්නේ එක් එක් කණ්ඩායම කන්ටේනරයක තැබීමයි:

ඉදිරියට යාමට, ඔබ බහාලුමක් යනු කුමක්දැයි මතක තබා ගත යුතුය (ලිනක්ස් හි). බොහෝ කලකට පෙර ක්‍රියාත්මක කරන ලද කර්නලයේ ප්‍රධාන අංග තුනකට ස්තූතිවන්ත වන පරිදි ඔවුන්ගේ පෙනුම හැකි විය: හැකියාවන්, නාම අවකාශ и cgroups. වැඩිදුර සංවර්ධනය සඳහා වෙනත් තාක්ෂණයන් (ඩොකර් වැනි පහසු "ෂෙල් වෙඩි" ඇතුළුව) පහසුකම් සපයන ලදී:

වාර්තාවේ සන්දර්භය තුළ, අපි උනන්දු වන්නේ පමණි cgroups, පාලන කණ්ඩායම් සම්පත් කළමනාකරණය ක්රියාත්මක කරන බහාලුම් (Docker, ආදිය) ක්රියාකාරිත්වයේ කොටසක් වන බැවිනි. අපට අවශ්‍ය පරිදි කණ්ඩායම්වලට ඒකාබද්ධ වූ ක්‍රියාවලීන් පාලන කණ්ඩායම් වේ.

අපි මෙම ක්‍රියාවලි සඳහා CPU අවශ්‍යතා වෙත ආපසු යමු, සහ දැන් ක්‍රියාවලි කණ්ඩායම් සඳහා:

(සියලු සංඛ්‍යා සම්පත් අවශ්‍යතාවයේ වියුක්ත ප්‍රකාශනයක් බව මම නැවත කියමි)

ඒ අතරම, CPU සතුව යම් සීමිත සම්පතක් ඇත (උදාහරණයේ මෙය 1000), එය සෑම කෙනෙකුටම නොමැති විය හැක (සියලු කණ්ඩායම්වල අවශ්‍යතාවල එකතුව 150+850+460=1460). මෙම නඩුවේ කුමක් සිදුවේද?

කර්නලය සම්පත් බෙදා හැරීම ආරම්භ කරන අතර එය "සාධාරණව" කරයි, එක් එක් කණ්ඩායමට එකම සම්පත් ප්‍රමාණයක් ලබා දෙයි. නමුත් පළමු අවස්ථාවේ දී, ඒවායින් අවශ්‍ය ප්‍රමාණයට වඩා වැඩි ප්‍රමාණයක් ඇත (333>150), එබැවින් අතිරික්තය (333-150=183) සංචිතයේ පවතී, එය වෙනත් බහාලුම් දෙකක් අතර සමානව බෙදා හරිනු ලැබේ:

ප්රතිඵලයක් වශයෙන්: පළමු කන්ටේනරය ප්රමාණවත් තරම් සම්පත්, දෙවන - එය ප්රමාණවත් තරම් සම්පත් නොතිබුණි, තුන්වන - එය ප්රමාණවත් තරම් සම්පත් නොතිබුණි. මෙය ක්‍රියාවන්ගේ ප්‍රතිඵලයයි ලිනක්ස් හි "අවංක" උපලේඛකයා - CFS. පැවරුම භාවිතයෙන් එහි ක්රියාකාරිත්වය සකස් කළ හැකිය බර එක් එක් බහාලුම්. උදාහරණයක් ලෙස, මේ වගේ:

දෙවන කන්ටේනරයේ (php-fpm) සම්පත් නොමැතිකම පිළිබඳ කාරණය දෙස බලමු. සියලුම බහාලුම් සම්පත් ක්‍රියාවලි අතර සමානව බෙදා හරිනු ලැබේ. එහි ප්‍රතිඵලයක් වශයෙන්, ප්‍රධාන ක්‍රියාවලිය හොඳින් ක්‍රියාත්මක වේ, නමුත් සියලුම සේවකයින් මන්දගාමී වන අතර, ඔවුන්ට අවශ්‍ය ප්‍රමාණයෙන් අඩකට වඩා අඩු ප්‍රමාණයක් ලබා ගනී:

CFS උපලේඛනය ක්‍රියා කරන ආකාරය මෙයයි. අපි බහාලුම්වලට පවරන බර තවදුරටත් අපි හඳුන්වන්නෙමු ඉල්ලීම්. මෙය එසේ වන්නේ ඇයි - තවදුරටත් බලන්න.

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

මෙම ප්රවේශය දෘඪ කෝටා ලෙස හැඳින්වේ (දැඩි සීමා කිරීම). අපි එය සරලව මතක තබා ගනිමු සීමාවන්. කෙසේ වෙතත්, ඔබ සියලු බහාලුම් සඳහා සීමාවන් බෙදා හරින්නේ නම්, ගැටළුවක් පැන නගී: mysql පාර දිගේ ධාවනය වූ අතර යම් අවස්ථාවක එහි CPU සඳහා ඇති අවශ්‍යතාවය අවසන් විය, නමුත් අනෙක් සියලුම ක්‍රියාවලීන් CPU තෙක් රැඳී සිටීමට බල කෙරෙයි. නිෂ්ක්‍රීය.

අපි Linux කර්නලය වෙත ආපසු යමු සහ CPU සමඟ එහි අන්තර්ක්‍රියා - සමස්ත පින්තූරය පහත පරිදි වේ:

cgroup හි සැකසුම් දෙකක් ඇත - අත්‍යවශ්‍යයෙන්ම මේවා ඔබට තීරණය කිරීමට ඉඩ සලසන සරල “පෙරළි” දෙකකි:

1. බහාලුම් සඳහා බර (ඉල්ලීම්) වේ කොටස්;
2. බහාලුම් කාර්යයන් මත වැඩ කිරීම සඳහා මුළු CPU කාලයෙහි ප්‍රතිශතය (සීමාවන්) වේ කෝටාව.

CPU මැනිය හැක්කේ කෙසේද?

විවිධ ක්රම තිබේ:

1. කුමක්ද ගිරවුන්, කිසිවෙකු දන්නේ නැත - ඔබ සෑම අවස්ථාවකදීම සාකච්ඡා කිරීමට අවශ්ය වේ.
2. උනන්දුව වඩා පැහැදිලි, නමුත් සාපේක්ෂ: හරය 50ක් සහ මධ්‍ය 4ක් සහිත සේවාදායකයකින් 20% සම්පූර්ණයෙන්ම වෙනස් දේවල්.
3. ඔබට දැනටමත් සඳහන් කර ඇති ඒවා භාවිතා කළ හැකිය බර, ලිනක්ස් දන්නා නමුත් ඒවා ද සාපේක්ෂ ය.
4. වඩාත්ම ප්‍රමාණවත් විකල්පය වන්නේ පරිගණක සම්පත් මැනීමයි තත්පර. එම. තත්‍ය කාලීන තත්පර වලට සාපේක්ෂව ප්‍රොසෙසර කාලය තත්පර වලින්: ප්‍රොසෙසරයේ තත්පර 1ක කාලයක් නියම තත්පර 1කට ලබා දී ඇත - මෙය එක් සම්පූර්ණ CPU හරයකි.

කතා කිරීම වඩාත් පහසු කිරීම සඳහා, ඔවුන් කෙලින්ම මැනීමට පටන් ගත්හ කර්නල්, ඒවායින් අදහස් කරන්නේ සැබෑ එකට සාපේක්ෂව එකම CPU කාලයයි. Linux බර තේරුම් ගනී, නමුත් එතරම් CPU කාලය/cores නැති නිසා, එකකින් අනෙකට පරිවර්තනය කිරීමට යාන්ත්‍රණයක් අවශ්‍ය විය.

CPU මධ්‍ය 3 ක් සහිත සේවාදායකයක් සමඟ සරල උදාහරණයක් සලකා බලමු, එහිදී කරල් තුනකට බර (500, 1000 සහ 1500) ලබා දෙන අතර ඒවා ඒවාට වෙන් කර ඇති හරවල අනුරූප කොටස් (0,5, 1 සහ 1,5) වෙත පහසුවෙන් පරිවර්තනය කළ හැකිය.

ඔබ දෙවන සේවාදායකයක් ගෙන, එහි හරය මෙන් දෙගුණයක් (6) සහ එම කරල් එහි තබන්නේ නම්, හරය බෙදා හැරීම 2 (පිළිවෙලින් 1, 2 සහ 3) න් ගුණ කිරීමෙන් පහසුවෙන් ගණනය කළ හැකිය. නමුත් මෙම සේවාදායකයේ සිව්වන පොඩ් එකක් දිස්වන විට වැදගත් මොහොතක් සිදු වේ, එහි බර, පහසුව සඳහා, 3000 ක් වනු ඇත. එය CPU සම්පත් වලින් කොටසක් (හරය අඩක්) ඉවත් කරයි, සහ ඉතිරි කරල් සඳහා ඒවා නැවත ගණනය කරනු ලැබේ (අඩක්):

Kubernetes සහ CPU සම්පත්

Kubernetes හි, CPU සම්පත් සාමාන්‍යයෙන් මනිනු ලැබේ මිලිඩ්රැක්ස්, i.e. මූලික බර ලෙස 0,001 cores ගනු ලැබේ. (Linux/cgroups පාරිභාෂිතයේ එකම දෙය CPU කොටස ලෙස හැඳින්වේ, කෙසේ වෙතත්, වඩාත් නිවැරදිව, 1000 millicores = 1024 CPU කොටස්.) සියලුම කරල්වල බර එකතුව සඳහා CPU සම්පත් ඇති ප්‍රමාණයට වඩා වැඩි කරල් සේවාදායකය මත නොතබන බව K8s සහතික කරයි.

මෙය සිදු වන්නේ කෙසේද? ඔබ Kubernetes පොකුරකට සේවාදායකයක් එක් කළ විට, එහි CPU cores කීයක් තිබේද යන්න වාර්තා වේ. තවද නව පොඩ් එකක් සාදන විට, කුබර්නෙටස් උපලේඛකයා මෙම පොඩ් එකට කොපමණ හරයන් අවශ්‍ය දැයි දනී. මේ අනුව, ප්‍රමාණවත් හරයක් ඇති සේවාදායකයකට පොඩ් පවරනු ලැබේ.

එහෙම වුණොත් මොකද වෙන්නේ නෑ ඉල්ලීම නිශ්චිතව දක්වා ඇත (එනම් පොඩ් එකට අවශ්‍ය නිශ්චිත හර සංඛ්‍යාවක් නොමැත)? Kubernetes සාමාන්යයෙන් සම්පත් ගණනය කරන්නේ කෙසේදැයි සොයා බලමු.

පොඩ් එකක් සඳහා ඔබට ඉල්ලීම් (CFS උපලේඛනය) සහ සීමාවන් දෙකම සඳහන් කළ හැක (රථවාහන ආලෝකය මතකද?):

• ඒවා සමාන ලෙස දක්වා තිබේ නම්, එවිට පොඩ් එකට QoS පන්තියක් පවරනු ලැබේ සහතිකයි. එයට සැමවිටම ලබා ගත හැකි මෙම හර ගණන සහතික කෙරේ.
• ඉල්ලීම සීමාවට වඩා අඩු නම් - QoS පන්තිය පුපුරා යා හැකි. එම. උදාහරණයක් ලෙස, අපි පොඩ් එකක් සෑම විටම 1 හරයක් භාවිතා කිරීමට බලාපොරොත්තු වෙමු, නමුත් මෙම අගය එයට සීමාවක් නොවේ: සමහර විට pod වැඩිපුර භාවිතා කළ හැක (සේවාදායකයට මේ සඳහා නොමිලේ සම්පත් ඇති විට).
• QoS පන්තියක් ද ඇත හොඳම උත්සාහය - ඉල්ලීම නිශ්චිතව දක්වා නොමැති එම කරල් ඇතුළත් වේ. ඒ අයට අන්තිමට සම්පත් දෙනවා.

මතක

මතකය සමඟ, තත්වය සමාන ය, නමුත් තරමක් වෙනස් - සියල්ලට පසු, මෙම සම්පත් වල ස්වභාවය වෙනස් වේ. පොදුවේ ගත් කල, සමානතාවය පහත පරිදි වේ:

මතකයේ ඉල්ලීම් ක්‍රියාත්මක කරන්නේ කෙසේදැයි බලමු. ඒවායින් එකක් මතකය නැති වන තරමට විශාල වන තුරු, මතක පරිභෝජනය වෙනස් කරමින්, සර්වරය මත පොඩ්ඩ ජීවත් වීමට ඉඩ දෙන්න. මෙම අවස්ථාවේදී, OOM ඝාතකයා පෙනී සිටින අතර විශාලතම ක්රියාවලිය මරා දමයි:

මෙය සැමවිටම අපට ගැලපෙන්නේ නැත, එබැවින් අපට වැදගත් වන්නේ කුමන ක්‍රියාවලීන්ද සහ මරා දැමිය යුතුද යන්න නියාමනය කළ හැකිය. මෙය සිදු කිරීම සඳහා, පරාමිතිය භාවිතා කරන්න oom_score_adj.

අපි CPU හි QoS පන්ති වෙත ආපසු යමු සහ කරල් සඳහා මතක පරිභෝජන ප්‍රමුඛතා තීරණය කරන oom_score_adj අගයන් සමඟ ප්‍රතිසමයක් අඳින්න:

• Pod එකක් සඳහා ඇති අඩුම oom_score_adj අගය - -998 - එයින් අදහස් වන්නේ එවැනි කරලක් අවසන් වරට මරා දැමිය යුතු බවයි, මෙය සහතිකයි.
• ඉහළම - 1000 - වේ හොඳම උත්සාහය, එවැනි කරල් මුලින්ම මරා දමයි.
• ඉතිරි අගයන් ගණනය කිරීමට (පුපුරා යා හැකි) සූත්‍රයක් ඇත, එහි සාරය පොඩ්ඩෙක් වැඩි වැඩියෙන් සම්පත් ඉල්ලා ඇති තරමට එය මරා දැමීමේ සම්භාවිතාව අඩු වේ.

දෙවන "පෙරළිය" - සීමාව_බයිට් වලින් - සීමාවන් සඳහා. එය සමඟ, සෑම දෙයක්ම සරලයි: අපි නිකුත් කළ උපරිම මතක ප්රමාණය සරලව පවරමු, සහ මෙහි (CPU මෙන් නොව) එය (මතකය) මැනිය යුතු ආකාරය පිළිබඳ ප්රශ්නයක් නොමැත.

එකතුව

Kubernetes හි එක් එක් කරල් ලබා දී ඇත requests и limits - CPU සහ මතකය සඳහා පරාමිති දෙකම:

1. ඉල්ලීම් මත පදනම්ව, Kubernetes උපලේඛකයා ක්‍රියා කරයි, එය සේවාදායකයන් අතර කරල් බෙදා හරියි;
2. සියලු පරාමිති මත පදනම්ව, පොඩ්ගේ QoS පන්තිය තීරණය කරනු ලැබේ;
3. CPU ඉල්ලීම් මත පදනම්ව සාපේක්ෂ බර ගණනය කෙරේ;
4. CFS උපලේඛනය CPU ඉල්ලීම් මත පදනම්ව වින්‍යාස කර ඇත;
5. OOM ඝාතකයා මතක ඉල්ලීම් මත පදනම්ව වින්‍යාස කර ඇත;
6. CPU සීමාවන් මත පදනම්ව "රථවාහන ආලෝකය" වින්‍යාස කර ඇත;
7. මතක සීමාවන් මත පදනම්ව, cgroup සඳහා සීමාවක් වින්‍යාස කර ඇත.

පොදුවේ ගත් කල, මෙම පින්තූරය Kubernetes හි සම්පත් කළමනාකරණයේ ප්‍රධාන කොටස සිදුවන්නේ කෙසේද යන්න පිළිබඳ සියලු ප්‍රශ්නවලට පිළිතුරු සපයයි.

ස්වයං පරිමාණය

K8s cluster-autoscaler

අපි හිතමු සම්පූර්ණ පොකුර දැනටමත් වාඩිලාගෙන ඇති අතර නව පොඩ් එකක් සෑදිය යුතුය. කරල් දිස්විය නොහැකි අතර, එය තත්ත්‍වයේ එල්ලී ඇත විභාග. එය දිස්වීම සඳහා, අපට නව සේවාදායකයක් පොකුරට සම්බන්ධ කළ හැකිය, නැතහොත් ... cluster-autoscaler ස්ථාපනය කළ හැකිය, එය අප වෙනුවෙන් කරනු ඇත: වලාකුළු සපයන්නා වෙතින් අතථ්‍ය යන්ත්‍රයක් ඇණවුම් කර (API ඉල්ලීමක් භාවිතා කර) එය පොකුරට සම්බන්ධ කරන්න , ඉන් පසුව පොඩ් එක එකතු කරනු ලැබේ.

මෙය කුබර්නෙටස් පොකුරේ ස්වයංක්‍රීය පරිමාණය කිරීමකි, එය විශිෂ්ට ලෙස ක්‍රියා කරයි (අපගේ අත්දැකීම් අනුව). කෙසේ වෙතත්, වෙනත් තැන්වල මෙන්, මෙහි සමහර සූක්ෂ්මතා තිබේ ...

අපි පොකුරු ප්‍රමාණය වැඩි කරන තාක් කල්, සියල්ල හොඳයි, නමුත් පොකුරු විට සිදු වන්නේ කුමක්ද නිදහස් වීමට පටන් ගත්තේය? ගැටළුව වන්නේ පොඩ්ස් සංක්‍රමණය කිරීම (ධාරකයින් නිදහස් කිරීම සඳහා) සම්පත් අතින් ඉතා තාක්ෂණිකව දුෂ්කර සහ මිල අධික වීමයි. Kubernetes සම්පූර්ණයෙන්ම වෙනස් ප්රවේශයක් භාවිතා කරයි.

යෙදවීම ඇති සේවාදායක 3ක පොකුරක් සලකා බලන්න. එහි කරල් 6 ක් ඇත: දැන් සෑම සේවාදායකයක් සඳහාම 2 ක් ඇත. කිසියම් හේතුවක් නිසා අපට එක් සේවාදායකයක් ක්‍රියා විරහිත කිරීමට අවශ්‍ය විය. මෙය සිදු කිරීම සඳහා අපි විධානය භාවිතා කරමු kubectl drain, කුමන:

• මෙම සේවාදායකයට නව කරල් යැවීම තහනම් කරයි;
• සේවාදායකයේ පවතින පොඩ් මකා දමයි.

කරල් ගණන (6) නඩත්තු කිරීම සඳහා Kubernetes වගකිව යුතු බැවින්, එය සරලව නැවත නිර්මාණය කරනු ඇත ඒවා වෙනත් නෝඩ් වල, නමුත් අබල කර ඇති එක මත නොවේ, මන්ද එය දැනටමත් නව පොඩ් සත්කාරකත්වය සඳහා නොමැති ලෙස සලකුණු කර ඇත. මෙය Kubernetes සඳහා මූලික යාන්ත්‍රිකයෙකි.

කෙසේ වෙතත්, මෙහි ද සූක්ෂ්මතාවයක් තිබේ. ඒ හා සමාන තත්වයක් තුළ, StatefulSet සඳහා (Deployment වෙනුවට), ක්රියාවන් වෙනස් වනු ඇත. දැන් අපට දැනටමත් රාජ්‍ය යෙදුමක් ඇත - උදාහරණයක් ලෙස, MongoDB සමඟ කරල් තුනක්, ඉන් එකකට යම් ආකාරයක ගැටළුවක් ඇත (දත්ත දූෂිත වී ඇත හෝ පෝඩ් නිවැරදිව ආරම්භ වීම වළක්වන වෙනත් දෝෂයක්). අපි නැවතත් එක් සේවාදායකයක් අක්රිය කිරීමට තීරණය කරමු. කුමක් සිදුවේවිද?

MongoDB හැකි එයට ගණපූරණයක් අවශ්‍ය බැවින් මිය යන්න: ස්ථාපනයන් තුනක පොකුරක් සඳහා, අවම වශයෙන් දෙකක් ක්‍රියාත්මක විය යුතුය. කෙසේ වෙතත්, මෙම සිදු නොවේ - ස්තුති වන්නට PodDisruptionBudget. මෙම පරාමිතිය වැඩ කරන කරල්වල අවම අවශ්ය සංඛ්යාව තීරණය කරයි. MongoDB පොඩ් එකක් තවදුරටත් ක්‍රියා නොකරන බව දැනගෙන, PodDisruptionBudget MongoDB සඳහා සකසා ඇති බව දැකීම minAvailable: 2, Kubernetes ඔබට පොඩ් එකක් මැකීමට ඉඩ නොදේ.

පහළ පේළිය: පොකුර මුදා හරින විට කරල්වල චලනය (සහ ඇත්ත වශයෙන්ම, ප්‍රතිනිර්මාණය) නිවැරදිව ක්‍රියා කිරීම සඳහා, PodDisruptionBudget වින්‍යාස කිරීම අවශ්‍ය වේ.

තිරස් පරිමාණය

අපි තවත් තත්වයක් සලකා බලමු. Kubernetes හි Deployment ලෙස ධාවනය වන යෙදුමක් ඇත. පරිශීලක ගමනාගමනය එහි කරල් වෙත පැමිණේ (උදාහරණයක් ලෙස, ඒවායින් තුනක් ඇත), සහ අපි ඒවායේ යම් දර්ශකයක් මනිමු (කියන්න, CPU භාරය). ලෝඩ් එක වැඩි උනාම කාලසටහනකට රෙකෝඩ් කරලා රික්වෙස්ට් ඩිස්ට් රිබියුට් කරන්න පොඩ් ගාන වැඩි කරනවා.

අද Kubernetes හි මෙය අතින් සිදු කිරීම අවශ්‍ය නොවේ: මනින ලද භාර දර්ශකවල අගයන් මත පදනම්ව කරල් සංඛ්‍යාවේ ස්වයංක්‍රීය වැඩිවීමක් / අඩුවීමක් වින්‍යාස කර ඇත.

මෙහි ඇති ප්‍රධාන ප්‍රශ්න නම්: හරියටම මැනිය යුතු දේ и අර්ථකථනය කරන ආකාරය ලබාගත් අගයන් (කරල් ගණන වෙනස් කිරීම පිළිබඳ තීරණයක් ගැනීම සඳහා). ඔබට බොහෝ දේ මැනිය හැකිය:

මෙය තාක්ෂණික වශයෙන් කරන්නේ කෙසේද - ප්‍රමිතික එකතු කිරීම ආදිය. - ගැන මම වාර්තාවේ විස්තරාත්මකව කතා කළා අධීක්ෂණය සහ කුබර්නෙටස්. සහ ප්රශස්ත පරාමිතීන් තෝරා ගැනීම සඳහා ප්රධාන උපදෙස් වේ අත්හදා බැලීම!

ඇත භාවිතා කිරීමේ ක්රමය (භාවිත සන්තෘප්තිය සහ දෝෂ), එහි තේරුම පහත පරිදි වේ. උදාහරණයක් ලෙස, php-fpm පරිමාණය කිරීම අර්ථවත් කරන්නේ කුමන පදනමක් මතද? කම්කරුවන් ඉවරයි යන කාරණය මත පදනම්ව, මෙයයි පරිභෝජනය. කම්කරුවන් අවසන් වී නව සම්බන්ධතා පිළි නොගන්නේ නම්, මෙය දැනටමත් ය සන්තෘප්තිය. මෙම පරාමිතීන් දෙකම මැනිය යුතු අතර, අගයන් මත පදනම්ව, පරිමාණය සිදු කළ යුතුය.

ඒ වෙනුවට අවසාන කාල පරිච්ඡේදය

වාර්තාවේ අඛණ්ඩ පැවැත්මක් ඇත: සිරස් පරිමාණය සහ නිවැරදි සම්පත් තෝරා ගන්නේ කෙසේද යන්න ගැන. මම මේ ගැන ඉදිරි වීඩියෝ වලදී කතා කරන්නම් අපේ YouTube - ඔබ අතපසු නොකිරීමට දායක වන්න!

වීඩියෝ සහ විනිවිදක

කාර්ය සාධනයෙන් වීඩියෝව (මිනිත්තු 44):

වාර්තාව ඉදිරිපත් කිරීම:

ප්රාදේශීය සභා

අපගේ බ්ලොග් අඩවියේ Kubernetes පිළිබඳ වෙනත් වාර්තා:

• «Kubernetes දිගු කිරීම සහ සම්පූර්ණ කිරීම» (Andrey Polovov; 8 අප්‍රේල් 2019 Saint HighLoad++ හි);
• «දත්ත සමුදායන් සහ Kubernetes» (Dmitry Stolyarov; නොවැම්බර් 8, 2018 HighLoad++ මත);
• «අධීක්ෂණය සහ කුබර්නෙටස්» (Dmitry Stolyarov; මැයි 28, 2018 RootConf හිදී);
• «Kubernetes සහ GitLab සමඟ CI/CD හොඳම භාවිතයන්» (Dmitry Stolyarov; නොවැම්බර් 7, 2017 HighLoad++ මත);
• «කුඩා ව්යාපෘති වල Kubernetes සමඟ අපගේ අත්දැකීම්» (Dmitry Stolyarov; ජූනි 6, 2017 RootConf හිදී).

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