Kubernetes හි පළමු යෙදුම යෙදවීමේදී පහක් මග හැරී ඇත

Aris Dreamer විසින් අසාර්ථකයි

බොහෝ අය සිතන්නේ යෙදුම Kubernetes වෙත මාරු කිරීම ප්‍රමාණවත් බවයි (හෙල්ම් භාවිතා කිරීම හෝ අතින්) - එවිට සතුටක් ලැබෙනු ඇත. නමුත් සෑම දෙයක්ම එතරම් සරල නැත.

කණ්ඩායම Mail.ru Cloud Solutions DevOps ඉංජිනේරු Julian Gindy විසින් ලිපියක් පරිවර්තනය කරන ලදී. සංක්‍රමණ ක්‍රියාවලියේදී ඔබ එකම පෝරකයට නොපැමිණීම සඳහා ඔහුගේ සමාගම මුහුණ දුන් අන්තරායන් මොනවාදැයි ඔහු කියයි.

පළමු පියවර: Pod ඉල්ලීම් සහ සීමාවන් සකසන්න

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

පොඩ් ඉල්ලීම් ‍පොඩ් එක ප්‍රශස්ත ලෙස තැබීමට උපලේඛකයා විසින් භාවිතා කරන ප්‍රධාන අගය වේ.

සිට Kubernetes ලියකියවිලි: පෙරහන පියවර මගින් Pod කාලසටහන්ගත කළ හැකි නෝඩ් කට්ටලයක් අර්ථ දක්වයි. උදාහරණයක් ලෙස, PodFitsResources ෆිල්ටරය පොඩ් එකකින් නිශ්චිත සම්පත් ඉල්ලීම් තෘප්තිමත් කිරීමට ප්‍රමාණවත් සම්පත් නෝඩයකට තිබේදැයි පරීක්ෂා කරයි.

අපි යෙදුම් ඉල්ලීම් භාවිතා කරන්නේ අපට සම්පත් කොපමණ ප්‍රමාණයක් තක්සේරු කළ හැකි ආකාරයටය ඇත්ත වශයෙන්ම යෙදුම නිවැරදිව ක්‍රියාත්මක වීමට එය අවශ්‍ය වේ. මේ ආකාරයෙන් උපලේඛකයාට නෝඩ් යථාර්ථවාදීව තැබිය හැකිය. මුලදී, එක් එක් Pod සඳහා ප්‍රමාණවත් සම්පත් සහතික කිරීම සඳහා ඉල්ලීම් වැඩිපුර කාලසටහන්ගත කිරීමට අපට අවශ්‍ය විය, නමුත් කාලසටහන්ගත කිරීමේ කාලය සැලකිය යුතු ලෙස වැඩි වී ඇති බව අපි දුටුවෙමු, සහ සමහර Pods සම්පූර්ණයෙන්ම කාලසටහන්ගත කර නොතිබුණි, ඒවා සඳහා සම්පත් ඉල්ලීම් නොමැත.

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

පොඩ් සීමාවන් කරල් සඳහා පැහැදිලි සීමාවකි. එය පොකුර විසින් බහාලුමට වෙන් කරන උපරිම සම්පත් ප්‍රමාණය නියෝජනය කරයි.

නැවතත්, සිට නිල ලියකියවිලි: කන්ටේනරයක මතක සීමාව 4 GiB නම්, kubelet (සහ බහාලුම් ධාවන කාලය) එය බලාත්මක කරයි. ධාවන කාලය මඟින් කන්ටේනරය නිශ්චිත සම්පත් සීමාවට වඩා භාවිතා කිරීම වළක්වයි. උදාහරණයක් ලෙස, කන්ටේනරයක ක්‍රියාවලියක් අවසර දී ඇති මතක ප්‍රමාණයට වඩා වැඩි ප්‍රමාණයක් භාවිතා කිරීමට උත්සාහ කරන විට, පද්ධති කර්නලය "මතකයෙන් බැහැර" (OOM) දෝෂයක් සමඟ ක්‍රියාවලිය අවසන් කරයි.

කන්ටේනරයකට සෑම විටම සම්පත් ඉල්ලීමට වඩා වැඩි සම්පත් භාවිතා කළ හැක, නමුත් එය කිසිවිටක සීමාවට වඩා වැඩියෙන් භාවිතා කළ නොහැක. මෙම අගය නිවැරදිව සැකසීමට අපහසු නමුත් එය ඉතා වැදගත් වේ.

ඉතා මැනවින්, අපට අවශ්‍ය වන්නේ පද්ධතියේ අනෙකුත් ක්‍රියාවලීන්ට බාධා නොකර ක්‍රියාවලියක ජීවන චක්‍රය තුළදී පොඩ් එකක සම්පත් අවශ්‍යතා වෙනස් වීමයි - මෙය සීමාවන් සැකසීමේ අරමුණයි.

අවාසනාවකට මෙන්, කුමන අගයන් සැකසිය යුතුද යන්න පිළිබඳව මට නිශ්චිත උපදෙස් ලබා දිය නොහැක, නමුත් අපි පහත නීති රීති පිළිපදින්නෙමු:

1. බර පරීක්ෂා කිරීමේ මෙවලමක් භාවිතා කරමින්, අපි රථවාහන මූලික මට්ටමක් අනුකරණය කරන අතර පොඩ් සම්පත් (මතකය සහ ප්‍රොසෙසරය) භාවිතය නිරීක්ෂණය කරමු.
2. පොඩ් ඉල්ලීම් අත්තනෝමතික ලෙස අඩු අගයකට සකසන්න (ඉල්ලීම් අගය මෙන් 5 ගුණයක සම්පත් සීමාවක් සහිතව) සහ නිරීක්ෂණය කරන්න. ඉල්ලීම් ඉතා අඩු මට්ටමක පවතින විට, ක්‍රියාවලිය ආරම්භ කළ නොහැක, බොහෝ විට ගුප්ත Go ධාවන කාල දෝෂ ඇති කරයි.

ඉහළ සම්පත් සීමාවන් උපලේඛනගත කිරීම වඩාත් අපහසු කරන බව මම සටහන් කරමි, මන්ද පෝඩ්ට ප්‍රමාණවත් සම්පත් සහිත ඉලක්ක නෝඩයක් අවශ්‍ය වේ.

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

දෙවන පියවර: සජීවී බව සහ සූදානම පරීක්ෂා කරන්න

මෙය Kubernetes ප්‍රජාව තුළ නිතර සාකච්ඡා කෙරෙන තවත් සියුම් මාතෘකාවකි. මෘදුකාංගයේ ස්ථායී ක්‍රියාකාරිත්වය සඳහා යාන්ත්‍රණයක් සපයන අතර අක්‍රිය කාලය අවම කිරීම සඳහා සජීවී සහ සූදානම පරීක්ෂණ පිළිබඳ හොඳ අවබෝධයක් තිබීම වැදගත් වේ. කෙසේ වෙතත්, ඒවා නිවැරදිව වින්‍යාස කර නොමැති නම් ඔබේ යෙදුමේ ක්‍රියාකාරිත්වයට බරපතල ලෙස බලපෑ හැකිය. පහත දැක්වෙන්නේ සාම්පල දෙකම මොනවාද යන්න පිළිබඳ සාරාංශයකි.

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

සජීවී පරීක්ෂණ ලාභදායී විය යුතුය, එනම් සම්පත් විශාල ප්‍රමාණයක් පරිභෝජනය නොකළ යුතුය, මන්ද ඒවා නිතර ධාවනය වන අතර යෙදුම ක්‍රියාත්මක වන බව Kubernetes වෙත දැනුම් දිය යුතුය.

ඔබ සෑම තත්පරයකම ධාවනය කිරීමට විකල්පය සකසන්නේ නම්, මෙය තත්පරයකට ඉල්ලීම් 1ක් එක් කරයි, එබැවින් මෙම ගමනාගමනය සැකසීමට අමතර සම්පත් අවශ්‍ය වන බව මතක තබා ගන්න.

අපගේ සමාගමෙහි, දත්ත (උදාහරණයක් ලෙස, දුරස්ථ දත්ත ගබඩාවකින් හෝ හැඹිලියකින්) සම්පූර්ණයෙන් ලබා ගත නොහැකි වුවද, සජීවී පරීක්ෂණ මඟින් යෙදුමක මූලික කොටස් පරීක්ෂා කරයි.

අපි යෙදුම්වල "සෞඛ්‍ය" අන්ත ලක්ෂ්‍යයක් පිහිටුවා ඇති අතර එය හුදෙක් 200 ප්‍රතිචාර කේතයක් ලබා දෙයි. මෙය ක්‍රියාවලිය ක්‍රියාත්මක වන අතර ඉල්ලීම් හැසිරවීමට හැකියාව ඇති බවට ඇඟවීමකි (නමුත් තවමත් ගමනාගමනය නොවේ).

නියැදිය සූදානම කන්ටේනරය ඉල්ලීම් කිරීමට සූදානම්ද යන්න පෙන්නුම් කරයි. සූදානම පරීක්ෂාව අසාර්ථක වුවහොත්, අන්ත ලක්ෂ්‍ය පාලකය පොඩ් එකට ගැලපෙන සියලුම සේවාවල අන්ත ලක්ෂ්‍යවලින් පොඩ්ගේ IP ලිපිනය ඉවත් කරයි. මෙය Kubernetes ලේඛනවල ද සඳහන් වේ.

ඉල්ලීම් පිළිගැනීමට යෙදුම සුදානම් බව පෙන්වීමට ඒවා පසුපෙළට පහර දිය යුතු බැවින්, සූදානම පරීක්‍ෂණ වැඩි සම්පත් පරිභෝජනය කරයි.

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

ඔබගේ යෙදුමේ සූදානම පරීක්ෂා කිරීමට දත්ත සමුදාය විමසීමට ඔබ තීරණය කරන්නේ නම්, එය හැකි තරම් ලාභදායී බවට වග බලා ගන්න. අපි මෙම විමසුම ගනිමු:

SELECT small_item FROM table LIMIT 1

අපි Kubernetes හි මෙම අගයන් දෙක වින්‍යාස කරන ආකාරය පිළිබඳ උදාහරණයක් මෙන්න:

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

ඔබට අමතර සැකසුම් විකල්ප කිහිපයක් එකතු කළ හැකිය:

• initialDelaySeconds - කන්ටේනරය දියත් කිරීම සහ පරීක්ෂණ දියත් කිරීමේ ආරම්භය අතර තත්පර කීයක් ගත වේද.
• periodSeconds - නියැදි ධාවන අතර පොරොත්තු පරතරය.
• timeoutSeconds - පොඩ් එක හදිසි අවස්ථාවක් ලෙස සලකනු ලබන තත්පර ගණන. සාමාන්‍ය කල් ඉකුත්වීම.
• failureThreshold නැවත ආරම්භ කිරීමේ සංඥාවක් පොඩ් වෙත යැවීමට පෙර පරීක්ෂණ අසාර්ථක ගණන වේ.
• successThreshold පොඩ් සූදානම් තත්ත්වයට මාරු වීමට පෙර සාර්ථක අත්හදා බැලීම් ගණන වේ (අපොහොසත් වීමෙන් පසු පොඩ් එක ආරම්භ වූ විට හෝ යථා තත්ත්වයට පත් වූ විට).

තුන්වන පියවර: Pod හි පෙරනිමි ජාල ප්‍රතිපත්ති සැකසීම

Kubernetes සතුව "පැතලි" ජාල භූ විෂමතාවයක් ඇත, පෙරනිමියෙන් සියලුම කරල් එකිනෙක සමග සෘජුව සන්නිවේදනය කරයි. සමහර අවස්ථාවලදී මෙය සුදුසු නොවේ.

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

උදාහරණයක් ලෙස, පහත දැක්වෙන්නේ යම් නාම අවකාශයක් සඳහා පැමිණෙන සියලුම මාර්ග තදබදය ප්‍රතික්ෂේප කරන සරල ප්‍රතිපත්තියකි:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

මෙම වින්‍යාසය දෘශ්‍යකරණය:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
වැඩි විස්තර මෙහි.

හතරවන පියවර: කොකු සහ Init බහාලුම් සමඟ අභිරුචි හැසිරීම

අපගේ එක් ප්‍රධාන ඉලක්කයක් වූයේ සංවර්ධකයින් සඳහා අක්‍රිය කාලයකින් තොරව Kubernetes හි යෙදවීම් සැපයීමයි. යෙදුම් වසා දැමීම සහ ඒවායේ භාවිතා කළ සම්පත් මුදා හැරීම සඳහා බොහෝ විකල්ප ඇති නිසා මෙය අපහසු වේ.

සමඟ විශේෂ දුෂ්කරතා මතු විය Nginx. මෙම Pods අනුපිළිවෙලින් යෙදවීමේදී, සාර්ථකව සම්පූර්ණ කිරීමට පෙර සක්‍රිය සම්බන්ධතාවලට බාධා ඇති වූ බව අපි දුටුවෙමු.

අන්තර්ජාලයේ පුළුල් පර්යේෂණයකින් පසුව, Kubernetes පොඩ් එක වසා දැමීමට පෙර Nginx සම්බන්ධතා අවසන් වන තෙක් බලා නොසිටින බව පෙනී ගියේය. පෙර-නැවතුම් හක්ක ආධාරයෙන්, අපි පහත ක්‍රියාකාරීත්වය ක්‍රියාත්මක කර අක්‍රිය කාලය සම්පූර්ණයෙන්ම ඉවත් කළෙමු:

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

ඒත් nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

තවත් පොදු යෝජනා ක්‍රමයක් වන්නේ ප්‍රධාන මොඩියුලයට මෙම අක්තපත්‍ර සපයන init කන්ටේනරය තුළ ඇති රහස් වෙත ප්‍රවේශ වීමයි, එමඟින් ප්‍රධාන යෙදුම් මොඩියුලයෙන්ම රහස් වෙත අනවසරයෙන් ප්‍රවේශ වීම වළක්වයි.

සුපුරුදු පරිදි, ලේඛනයෙන් උපුටා ගැනීමකි: init බහාලුම් ආරක්ෂිතව පරිශීලක කේතය හෝ යෙදුමේ බහාලුම් රූපයේ ආරක්ෂාවට බාධා කරන උපයෝගිතා ධාවනය කරයි. අනවශ්‍ය මෙවලම් වෙනම තබා ගැනීමෙන්, ඔබ යෙදුමේ බහාලුම් රූපයේ ප්‍රහාරක මතුපිට සීමා කරයි.

පස්වන පියවර: කර්නල් වින්‍යාසය

අවසාන වශයෙන්, අපි වඩාත් දියුණු තාක්ෂණයක් ගැන කතා කරමු.

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

කෙසේ වෙතත්, Kubernetes ඔබට විශේෂිත පොඩ් එකක් සඳහා කර්නල් පරාමිතීන් පමණක් වෙනස් කරන වරප්‍රසාදිත බහාලුමක් ධාවනය කිරීමට ඉඩ සලසයි. විවෘත සම්බන්ධතා උපරිම සංඛ්‍යාව වෙනස් කිරීමට අපි භාවිතා කළේ මෙන්න:

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

අවසාන වශයෙන්

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

Kubernetes වෙත සංක්‍රමණය පුරාවට, "බර පරීක්ෂා කිරීමේ චක්‍රය" අනුගමනය කිරීම වැදගත් වේ: යෙදුම ධාවනය කරන්න, බර යටතේ එය පරීක්ෂා කරන්න, ප්‍රමිතික සහ පරිමාණ හැසිරීම් නිරීක්ෂණය කරන්න, මෙම දත්ත මත පදනම්ව වින්‍යාසය සකස් කරන්න, ඉන්පසු මෙම චක්‍රය නැවත නැවත කරන්න.

අපේක්ෂිත ගමනාගමනය පිළිබඳ යථාර්ථවාදී වන්න සහ පළමුව බිඳ වැටෙන්නේ කුමන සංරචකදැයි බැලීමට ඉන් ඔබ්බට යාමට උත්සාහ කරන්න. මෙම පුනරාවර්තන ප්රවේශය සමඟින්, සාර්ථකත්වය ළඟා කර ගැනීම සඳහා ලැයිස්තුගත නිර්දේශ කිහිපයක් පමණක් ප්රමාණවත් විය හැකිය. නැතහොත් එය වඩාත් ගැඹුරු අභිරුචිකරණයක් අවශ්‍ය විය හැකිය.

සෑම විටම මෙම ප්‍රශ්න ඔබෙන්ම අසන්න:

1. යෙදුම් කොපමණ සම්පත් පරිභෝජනය කරන්නේද සහ මෙම මුදල වෙනස් වන්නේ කෙසේද?
2. සැබෑ පරිමාණ අවශ්‍යතා මොනවාද? යෙදුම සාමාන්‍යයෙන් කොපමණ තදබදයක් හසුරුවයිද? උපරිම තදබදය ගැන කුමක් කිව හැකිද?
3. සේවාව කොපමණ වාරයක් පරිමාණය කිරීමට අවශ්‍ය වේද? ගමනාගමනය ලබා ගැනීම සඳහා නව කරල් කෙතරම් ඉක්මනින් ක්‍රියාත්මක විය යුතුද?
4. කරල් කෙතරම් අලංකාර ලෙස වසා දමන්නේද? එය කිසිසේත්ම අවශ්‍යද? අක්‍රීය කාලයකින් තොරව යෙදවීම ලබා ගත හැකිද?
5. ආරක්‍ෂක අවදානම් අවම කර ගැනීම සහ කිසියම් සම්මුතියකට ලක් වූ කරල්වලින් සිදුවන හානිය සීමා කරන්නේ කෙසේද? කිසියම් සේවාවකට අවශ්‍ය නොවන අවසර හෝ ප්‍රවේශයන් තිබේද?

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

වාසනාවකට මෙන්, Kubernetes සියලු තාක්ෂණික අරමුණු සාක්ෂාත් කර ගැනීම සඳහා අවශ්ය සැකසුම් සපයයි. සම්පත් ඉල්ලීම් සහ සීමාවන්, Liveness සහ Readiness probes, init බහාලුම්, ජාල ප්‍රතිපත්ති සහ අභිරුචි කර්නල් සුසර කිරීමේ සංයෝජනයක් භාවිතා කිරීමෙන්, ඔබට දෝෂ ඉවසීම සහ වේගවත් පරිමාණය සමඟ ඉහළ කාර්ය සාධනයක් ලබා ගත හැකිය.

තවත් කියවිය යුතු දේ:

1. නිෂ්පාදන පරිසරයන්හි බහාලුම් සහ කුබර්නෙට් ධාවනය සඳහා හොඳම භාවිතයන් සහ හොඳම භාවිතයන්.
2. Kubernetes සඳහා 90+ ප්‍රයෝජනවත් මෙවලම්: යෙදවීම, කළමනාකරණය, අධීක්ෂණය, ආරක්ෂාව සහ තවත්.
3. Telegram හි Kubernetes අවට අපගේ නාලිකාව.

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