🥇Kubernetes Pod සම්පත් වෙත ප්‍රවේශ වන්නේ කෙසේද

තෝහාඩ්ගේ විපාකය

Kubernetes සමඟ ආරම්භ කරන විට, බහාලුම් සම්පත් සැකසීම අමතක කිරීම සාමාන්ය දෙයක්. මෙම අවස්ථාවේදී, ඩොකර් රූපය ක්‍රියා කරන බව සහතික කිරීම ප්‍රමාණවත් වන අතර එය Kubernetes පොකුරට යෙදවිය හැකිය.

නමුත් පසුව යෙදුම වෙනත් යෙදුම් සමඟ නිෂ්පාදන පොකුරක් තුළ යෙදවිය යුතුය. මෙය සිදු කිරීම සඳහා, ඔබ කන්ටේනරය සඳහා සම්පත් වෙන් කළ යුතු අතර, යෙදුම ක්රියාත්මක කිරීම සඳහා ප්රමාණවත් තරම් ඒවා ඇති බවට වග බලා ගත යුතු අතර, අනෙකුත් ධාවනය වන යෙදුම් ගැටළු වලට මුහුණ නොදෙනු ඇත.

කණ්ඩායම Mail.ru වෙතින් Kubernetes aaS බහාලුම් සම්පත් (CPU සහ MEM), ඉල්ලීම් සහ සම්පත් සීමාවන් පිළිබඳ ලිපියක් පරිවර්තනය කරන ලදී. ඔබ මෙම සැකසීම්වල ප්‍රතිලාභ සහ ඔබ ඒවා නොසකසා ඇත්නම් කුමක් සිදුවේද යන්න ඉගෙන ගනු ඇත.

සම්පත් ගණනය කිරීම

අපට පහත ඒකක සහිත සම්පත් වර්ග දෙකක් තිබේ:

මධ්යම සැකසුම් ඒකකය (CPU) - cores;
මතකය (MEM) - බයිට්.

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

ඉල්ලූ පොඩ් සම්පත් = සියලුම බහාලුම්වල ඉල්ලූ සම්පත් එකතුව;
Pod සම්පත් සීමාව = සියලුම Pod සම්පත් සීමාවන්ගේ එකතුව.

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

ඉල්ලුම් කළ සහ සීමිත සම්පත් සඳහා උදාහරණය

ක්ෂේත්රයේ resources.requested පිරිවිතරයෙන් Pod යනු අපේක්ෂිත නෝඩය සොයා ගැනීමට භාවිතා කරන මූලද්‍රව්‍ය වලින් එකකි. ඔබට දැනටමත් ඒ සඳහා Pod යෙදවීම සැලසුම් කළ හැක. සුදුසු නෝඩයක් සොයා ගන්නේ කෙසේද?

Kubernetes ප්‍රධාන නෝඩයක් හෝ ප්‍රධාන නෝඩයක් (Kubernetes Control Plane) ඇතුළු සංරචක කිහිපයකින් සමන්විත වේ. ප්‍රධාන නෝඩයට ක්‍රියාවලි කිහිපයක් ඇත: kube-apiserver, kube-controller-manager සහ kube-scheduler.

kube-scheduler ක්‍රියාවලිය අලුතින් සාදන ලද කරල් සමාලෝචනය කිරීම සහ ඉල්ලා ඇති සම්පත් සංඛ්‍යාව ඇතුළුව සියලුම පොඩ් ඉල්ලීම්වලට ගැළපෙන සේවක නෝඩ් සොයා ගැනීම සඳහා වගකීම දරයි. kube-scheduler විසින් සොයා ගන්නා ලද නෝඩ් ලැයිස්තුව ශ්‍රේණිගත කර ඇත. පොඩ් වැඩිම ලකුණු සහිත නෝඩය මත සැලසුම් කර ඇත.

දම් පාට පොඩ් එක කොහෙද තියන්නේ?

පින්තූරයේ ඔබට පෙනෙන්නේ kube-scheduler විසින් නව දම් පාට Pod එකක් උපලේඛනගත කළ යුතු බවයි. Kubernetes පොකුරේ නෝඩ් දෙකක් අඩංගු වේ: A සහ B. ඔබට පෙනෙන පරිදි, kube-scheduler හට Node A මත Pod උපලේඛනගත කළ නොහැක - පවතින (ඉල්ලීම නොකළ) සම්පත් දම් පාට Pod හි ඉල්ලීම් සමඟ නොගැලපේ. එබැවින්, පවතින මතකය 1 GB වන බැවින්, දම් පාට Pod විසින් ඉල්ලා සිටින 0,5 GB මතකය node A මත නොගැලපේ. නමුත් නෝඩය B ප්රමාණවත් තරම් සම්පත් ඇත. එහි ප්‍රතිඵලයක් වශයෙන්, දම් පාට Pod හි ගමනාන්තය node B බව kube-scheduler තීරණය කරයි.

දැන් අපි දන්නවා ඉල්ලූ සම්පත් Pod ධාවනය කිරීමට node තේරීමට බලපාන්නේ කෙසේද කියා. නමුත් ආන්තික සම්පත් වල බලපෑම කුමක්ද?

සම්පත් සීමාව යනු CPU/MEM හට තරණය කළ නොහැකි සීමාවකි. කෙසේ වෙතත්, CPU සම්පත නම්‍යශීලී වේ, එබැවින් ඒවායේ CPU සීමාවට ළඟා වන බහාලුම් Pod පිටවීමට හේතු නොවේ. ඒ වෙනුවට, CPU තෙරපුම ආරම්භ වනු ඇත. MEM භාවිත සීමාවට ළඟා වී ඇත්නම්, OOM-Killer හේතුවෙන් බහාලුම නවත්වනු ලබන අතර RestartPolicy සැකසීමෙන් ඉඩ දෙන්නේ නම් නැවත ආරම්භ කෙරේ.

විස්තරාත්මකව ඉල්ලා ඇති සහ උපරිම සම්පත්

Docker සහ Kubernetes අතර සම්පත් සන්නිවේදනය

සම්පත් ඉල්ලීම් සහ සම්පත් සීමාවන් ක්‍රියා කරන ආකාරය පැහැදිලි කිරීමට හොඳම ක්‍රමය නම් Kubernetes සහ Docker අතර සම්බන්ධය හඳුන්වා දීමයි. ඉහත රූපයේ ඔබට Kubernetes ක්ෂේත්‍ර සහ ඩොකර් ආරම්භක කොඩි සම්බන්ධ වන ආකාරය දැක ගත හැක.

මතකය: ඉල්ලීම සහ සීමාව

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

ඉහත සඳහන් කළ පරිදි, මතකය බයිට් වලින් මනිනු ලැබේ. මත පදනම්ව Kubernetes ලියකියවිලි, අපට මතකය අංකයක් ලෙස දැක්විය හැක. සාමාන්යයෙන් එය නිඛිලයක්, උදාහරණයක් ලෙස 2678 - එනම් බයිට් 2678. ඔබට උපසර්ග ද භාවිතා කළ හැකිය G и Gi, ප්රධාන දෙය නම් ඔවුන් සමාන නොවන බව මතක තබා ගැනීමයි. පළමුවැන්න දශම වන අතර දෙවැන්න ද්විමය වේ. k8s ලේඛනයේ සඳහන් උදාහරණය මෙන්: 128974848, 129e6, 129M, 123Mi - ඒවා ප්රායෝගිකව සමාන වේ.

Kubernetes විකල්පය limits.memory ධජයට ගැලපේ --memory ඩොකර් වෙතින්. අවස්ථාවක request.memory Docker මෙම ක්ෂේත්‍රය භාවිතා නොකරන නිසා Docker සඳහා ඊතලයක් නොමැත. ඔබ අසනු ඇත, මෙය පවා අවශ්යද? ඔව් අවශ්‍යයි. මම කලින් කිව්වා වගේ, කුබර්නෙටස් සඳහා ක්ෂේත්රය වැදගත් වේ. එහි ඇති තොරතුරු මත පදනම්ව, kube-scheduler Pod කාලසටහන්ගත කළ යුත්තේ කුමන නෝඩය මතද යන්න තීරණය කරයි.

ඔබ ඉල්ලීමක් සඳහා ප්‍රමාණවත් මතකයක් නොමැති නම් කුමක් සිදුවේද?

කන්ටේනරය ඉල්ලූ මතකයේ සීමාවට පැමිණ තිබේ නම්, නෝඩයේ ප්‍රමාණවත් මතකයක් නොමැති විට නතර වන පොඩ් සමූහයක Pod තබා ඇත.

ඔබ මතක සීමාව ඉතා අඩුවෙන් තැබුවහොත් කුමක් සිදුවේද?

කන්ටේනරය මතක සීමාව ඉක්මවා ගියහොත්, OOM-Killed හේතුවෙන් එය අවසන් වේ. පෙරනිමි අගය ඇති RestartPolicy මත පදනම්ව හැකි නම් නැවත ආරම්භ කරනු ඇත Always.

ඔබ ඉල්ලූ මතකය සඳහන් නොකළහොත් කුමක් සිදුවේද?

Kubernetes සීමාව අගය ගෙන එය පෙරනිමි අගය ලෙස සකසනු ඇත.

ඔබ මතක සීමාවක් සඳහන් නොකළහොත් කුමක් සිදුවිය හැකිද?

කන්ටේනරයට සීමාවන් නොමැත; එයට අවශ්‍ය තරම් මතකයක් භාවිතා කළ හැකිය. ඔහු නෝඩයේ පවතින සියලුම මතකය භාවිතා කිරීමට පටන් ගන්නේ නම්, OOM ඔහුව මරා දමයි. RestartPolicy මත පදනම්ව හැකි නම් කන්ටේනරය නැවත ආරම්භ කරනු ලැබේ.

ඔබ මතක සීමාවන් සඳහන් නොකළහොත් කුමක් සිදුවේද?

මෙය නරකම අවස්ථාවයි: කන්ටේනරයට කොපමණ සම්පත් අවශ්‍ය දැයි උපලේඛනකයා නොදනී, මෙය නෝඩයේ බරපතල ගැටළු ඇති කළ හැකිය. මෙම අවස්ථාවේදී, නාම අවකාශයේ පෙරනිමි සීමාවන් තිබීම සතුටක් වනු ඇත (LimitRange විසින් සකසා ඇත). පෙරනිමි සීමාවන් නොමැත - Pod හි සීමාවන් නොමැත, එයට අවශ්‍ය තරම් මතකයක් භාවිතා කළ හැකිය.

ඉල්ලූ මතකය නෝඩයට ලබා දිය හැකි ප්‍රමාණයට වඩා වැඩි නම්, Pod කාලසටහන්ගත නොවනු ඇත. එය මතක තබා ගැනීම වැදගත්ය Requests.memory - අවම අගය නොවේ. මෙය කන්ටේනරය අඛණ්ඩව ක්‍රියාත්මක වීමට ප්‍රමාණවත් මතක ප්‍රමාණය පිළිබඳ විස්තරයකි.

සඳහා සමාන අගයක් සැකසීමට සාමාන්යයෙන් නිර්දේශ කරනු ලැබේ request.memory и limit.memory. Pod ධාවනය කිරීමට ප්‍රමාණවත් මතකයක් ඇති නමුත් එය ක්‍රියාත්මක කිරීමට ප්‍රමාණවත් නොවන node එකක් මත Kubernetes Pod උපලේඛනගත නොකරන බව මෙය සහතික කරයි. මතක තබා ගන්න: Kubernetes Pod සැලසුම් කිරීම පමණක් සැලකිල්ලට ගනී requests.memoryහා limits.memory සැලකිල්ලට නොගනී.

CPU: ඉල්ලීම සහ සීමාව

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

CPU එකකින් හැම දෙයක්ම ටිකක් සංකීර්ණයි. Kubernetes සහ Docker අතර සම්බන්ධතාවයේ පින්තූරය වෙත ආපසු යාම, ඔබට එය දැක ගත හැකිය request.cpu අනුරූප වේ --cpu-shares, නමුත් limit.cpu ධජයට ගැලපේ cpus Docker හි.

Kubernetes ඉල්ලා සිටින CPU CPU චක්‍රවල අනුපාතය වන 1024 න් ගුණ කරයි. ඔබට සම්පූර්ණ හරය 1ක් ඉල්ලීමට අවශ්‍ය නම්, ඔබ එක් කළ යුතුය cpu: 1ඉහත පෙන්වා ඇති පරිදි.

සම්පූර්ණ කර්නලයක් (අනුපාතය = 1024) ඉල්ලා සිටීමෙන් ඔබේ බහාලුමට එය ලැබෙනු ඇතැයි අදහස් නොවේ. ඔබගේ සත්කාරක යන්ත්‍රයට ඇත්තේ එක් හරයක් පමණක් නම් සහ ඔබ බහාලුම් එකකට වඩා ධාවනය කරන්නේ නම්, සියලුම බහාලුම් ඒවා අතර පවතින CPU බෙදා ගත යුතුය. මෙය සිදු වන්නේ කෙසේද? අපි පින්තූරය දෙස බලමු.

CPU ඉල්ලීම - Single Core System

ඔබ සතුව තනි-core ධාරක පද්ධතියක් ධාවනය වන බහාලුම් ඇති බව සිතමු. අම්මා (කුබර්නෙටේස්) පයි (CPU) පුළුස්සා එය දරුවන් (කන්ටේනර්) අතර බෙදීමට අවශ්යයි. දරුවන් තිදෙනෙකුට සම්පූර්ණ පයි එකක් අවශ්යයි (සමානුපාතිකය = 1024), තවත් දරුවෙකුට පයි භාගයක් අවශ්යයි (512). අම්මා සාධාරණ වීමට අවශ්ය වන අතර සරල ගණනය කිරීමක් සිදු කරයි.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

ගණනය කිරීම මත පදනම්ව, දරුවන් තිදෙනෙකුට හරයෙන් 28% ලැබෙනු ඇත, සහ සම්පූර්ණ හරය නොවේ. හතරවන දරුවාට සම්පූර්ණ කර්නලයෙන් 14% ක් ලැබෙනු ඇත, අඩක් නොවේ. නමුත් ඔබට බහු-core පද්ධතියක් තිබේ නම් දේවල් වෙනස් වනු ඇත.

CPU ඉල්ලීම - Multi-core (4) පද්ධතිය

ඉහත රූපයේ ඔබට පෙනෙන්නේ දරුවන් තිදෙනෙකුට සම්පූර්ණ පයි එකක් අවශ්‍ය බවත්, එක් අයෙකුට අඩක් අවශ්‍ය බවත්ය. අම්මා පයි හතරක් පුලුස්සන නිසා, ඇගේ සෑම දරුවෙකුටම ඔවුන්ට අවශ්‍ය තරම් ලැබේ. බහු-core පද්ධතියක් තුළ, ප්‍රොසෙසර සම්පත් පවතින සියලුම ප්‍රොසෙසර් කෝර් හරහා බෙදා හරිනු ලැබේ. කන්ටේනරයක් සම්පූර්ණ CPU හරයකට වඩා අඩු නම්, එය තවමත් 100% භාවිතා කළ හැක.

CPU බහාලුම් අතර බෙදා හරින ආකාරය තේරුම් ගැනීමට ඉහත ගණනය කිරීම් සරල කර ඇත. ඇත්ත වශයෙන්ම, බහාලුම් වලට අමතරව, CPU සම්පත් භාවිතා කරන වෙනත් ක්‍රියාවලි තිබේ. එක් කන්ටේනරයක ක්‍රියාවලි අක්‍රිය වූ විට, අනෙක් අයට එහි සම්පත භාවිතා කළ හැකිය. CPU: "200m" අනුරූප වේ CPU: 0,2, එනම් එක් හරයකින් ආසන්න වශයෙන් 20% කි.

දැන් අපි කතා කරමු limit.cpu. Kubernetes සීමා කරන CPU 100 කින් ගුණ කරයි. ප්‍රතිඵලය වන්නේ බහාලුමට සෑම µs 100කටම භාවිතා කළ හැකි කාලයයි (cpu-period).

limit.cpu ඩොකර් ධජයට ගැලපේ --cpus. මෙය පැරණි නව සංයෝජනයකි --cpu-period и --cpu-quota. එය සැකසීමෙන්, ත්‍රොට්ල් කිරීම ආරම්භ කිරීමට පෙර කන්ටේනරයට උපරිම ලෙස භාවිත කළ හැකි CPU සම්පත් කීයක් අපි දක්වන්නෙමු:

cpus - සංයෝජනය cpu-period и cpu-quota. cpus = 1.5 සැකසීමට සමාන වේ cpu-period = 100000 и cpu-quota = 150000;
CPU-කාලසීමාව - කාලය CPU CFS උපලේඛනය, පෙරනිමි මයික්‍රො තත්පර 100;
cpu-කෝටාව - ඇතුළත මයික්‍රෝ තත්පර ගණන cpu-period, කන්ටේනරය මගින් බැඳී ඇත.

ඔබ ඉල්ලූ CPU ප්‍රමාණවත් නොවේ නම් කුමක් සිදුවේද?

කන්ටේනරයට එය ස්ථාපනය කර ඇති ප්‍රමාණයට වඩා අවශ්‍ය නම්, එය වෙනත් ක්‍රියාවලීන්ගෙන් CPU සොරකම් කරයි.

ඔබ CPU සීමාව ඉතා අඩුවෙන් සකසා ඇත්නම් කුමක් සිදුවේද?

CPU සම්පත වෙනස් කළ හැකි බැවින්, තෙරපුම ක්‍රියාත්මක වේ.

ඔබ CPU ඉල්ලීමක් සඳහන් නොකළහොත් කුමක් සිදුවේද?

මතකය සමඟ මෙන්, ඉල්ලීම් අගය සීමාවට සමාන වේ.

ඔබ CPU සීමාවක් සඳහන් නොකළහොත් කුමක් සිදුවේද?

කන්ටේනරය එයට අවශ්‍ය තරම් CPU භාවිතා කරයි. නාම අවකාශයේ පෙරනිමි CPU ප්‍රතිපත්තියක් (LimitRange) අර්ථ දක්වා තිබේ නම්, මෙම සීමාව බහාලුම සඳහා ද භාවිතා වේ.

ඔබ ඉල්ලීමක් හෝ CPU සීමාවක් සඳහන් නොකරන්නේ නම් කුමක් සිදුවේද?

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

මතක තබා ගන්න: ඔබ නෝඩ් වලට ලබා දිය හැකි ප්‍රමාණයට වඩා වැඩි CPU එකක් ඉල්ලා සිටියහොත්, Pod කාලසටහන්ගත නොවනු ඇත. Requests.cpu - අවම අගය නොව, Pod ආරම්භ කිරීමට සහ අසාර්ථක නොවී වැඩ කිරීමට ප්රමාණවත් අගයක්. යෙදුම සංකීර්ණ ගණනය කිරීම් සිදු නොකරන්නේ නම්, හොඳම විකල්පය වන්නේ ස්ථාපනය කිරීමයි request.cpu <= 1 සහ අවශ්‍ය තරම් අනුපිටපත් දියත් කරන්න.

ඉල්ලුම් කරන ලද සම්පත්වල ප්‍රශස්ත ප්‍රමාණය හෝ සම්පත් සීමාව

පරිගණක සම්පත් සීමා කිරීම ගැන අපි ඉගෙන ගත්තා. දැන් ප්‍රශ්නයට පිළිතුරු දීමට කාලයයි: “කිසිදු ගැටලුවකින් තොරව යෙදුම ක්‍රියාත්මක කිරීමට මගේ Pod වලට කොපමණ සම්පත් අවශ්‍යද? කදිම මුදල කුමක්ද?

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

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

උදාහරණයක් ලෙස මෙය බලන්න Grafana උපකරණ පුවරුව. එය ඉල්ලූ සම්පත් හෝ සම්පත් සීමාව සහ වත්මන් සම්පත් භාවිතය අතර වෙනස පෙන්වයි.

නිගමනය

සම්පත් ඉල්ලීම සහ සීමා කිරීම ඔබේ Kubernetes පොකුර නිරෝගීව තබා ගැනීමට උපකාරී වේ. නිසි සීමා වින්‍යාසය පිරිවැය අවම කරන අතර යෙදුම් සෑම විටම ක්‍රියාත්මක කරයි.

කෙටියෙන් කිවහොත්, මතක තබා ගත යුතු කරුණු කිහිපයක් තිබේ:

ඉල්ලූ සම්පත් යනු ආරම්භක වේලාවේදී (කුබර්නෙට්ස් යෙදුම සත්කාරකත්වය දැක්වීමට සැලසුම් කරන විට) සැලකිල්ලට ගන්නා වින්‍යාසයකි. ඊට ප්‍රතිවිරුද්ධව, ක්‍රියාත්මක වන විට සම්පත් සීමා කිරීම වැදගත් වේ - යෙදුම දැනටමත් නෝඩය මත ක්‍රියාත්මක වන විට.
මතකය හා සසඳන විට, CPU යනු නියාමනය කළ සම්පතකි. ප්‍රමාණවත් CPU නොමැති නම්, ඔබේ Pod වසා නොයන අතර තෙරපුම් යාන්ත්‍රණය ක්‍රියාත්මක වේ.
ඉල්ලූ සම්පත් සහ සම්පත් සීමාව අවම සහ උපරිම අගයන් නොවේ! ඉල්ලුම් කරන ලද සම්පත් නිර්වචනය කිරීමෙන්, යෙදුම ගැටළු නොමැතිව ධාවනය වන බව ඔබ සහතික කරයි.
හොඳ පරිචයක් නම් මතක ඉල්ලීම මතක සීමාවට සමාන ලෙස සැකසීමයි.
හරි ස්ථාපනය ඉල්ලා ඇත CPU <=1, යෙදුම සංකීර්ණ ගණනය කිරීම් සිදු නොකරන්නේ නම්.
ඔබ node එකක් මතම පවතින ප්‍රමාණයට වඩා වැඩි සම්පත් ඉල්ලන්නේ නම්, Pod කිසිවිටෙක එම node එකට කාලසටහන්ගත නොවනු ඇත.
ඉල්ලුම් කරන ලද සම්පත්/සම්පත් සීමාවන්ගේ නිවැරදි ප්‍රමාණය තීරණය කිරීම සඳහා, බර පරීක්ෂා කිරීම සහ අධීක්ෂණය භාවිතා කරන්න.

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

සුබ පැතුම්!

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

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

Kubernetes Pod සම්පත් වෙත ප්‍රවේශ වන්නේ කෙසේද