કુબરનેટ્સ પોડ સંસાધનોને કેવી રીતે ઍક્સેસ કરવું

તોહાદ દ્વારા પુરસ્કાર

કુબરનેટ્સ સાથે પ્રારંભ કરતી વખતે, કન્ટેનર સંસાધનો સેટ કરવાનું ભૂલી જવાનું સામાન્ય છે. આ બિંદુએ, તે ખાતરી કરવા માટે પૂરતું છે કે ડોકર ઇમેજ કાર્ય કરે છે અને તેને કુબરનેટ્સ ક્લસ્ટરમાં જમાવી શકાય છે.

પરંતુ પાછળથી એપ્લિકેશનને અન્ય એપ્લિકેશનો સાથે પ્રોડક્શન ક્લસ્ટરમાં જમાવવાની જરૂર છે. આ કરવા માટે, તમારે કન્ટેનર માટે સંસાધનો ફાળવવાની જરૂર છે અને ખાતરી કરવાની જરૂર છે કે એપ્લિકેશનને ચાલુ કરવા અને ચલાવવા માટે તેમાંથી પૂરતા પ્રમાણમાં છે અને અન્ય ચાલી રહેલ એપ્લિકેશનો સમસ્યાઓનો અનુભવ કરશે નહીં.

ટીમ Mail.ru માંથી કુબરનેટ્સ એએએસ કન્ટેનર સંસાધનો (CPU અને MEM), વિનંતીઓ અને સંસાધન મર્યાદાઓ વિશેના લેખનો અનુવાદ કર્યો. તમે આ સેટિંગ્સના ફાયદા અને જો તમે તેને સેટ ન કરો તો શું થાય છે તે શીખી શકશો.

કમ્પ્યુટિંગ સંસાધનો

અમારી પાસે નીચેના એકમો સાથે બે પ્રકારના સંસાધનો છે:

• સેન્ટ્રલ પ્રોસેસિંગ યુનિટ (CPU) - કોરો;
• મેમરી (MEM) - બાઇટ્સ.

દરેક કન્ટેનર માટે સંસાધનો ઉલ્લેખિત છે. નીચેની Pod YAML ફાઇલમાં, તમે એક સંસાધન વિભાગ જોશો જેમાં વિનંતી કરેલ અને મર્યાદિત સંસાધનોનો સમાવેશ થાય છે:

• વિનંતી કરેલ પોડ સંસાધનો = તમામ કન્ટેનરના વિનંતી કરેલ સંસાધનોનો સરવાળો;
• પોડ રિસોર્સ લિમિટ = તમામ પોડ રિસોર્સ લિમિટનો સરવાળો.

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 સ્પષ્ટીકરણમાંથી પોડ એ ઘટકોમાંથી એક છે જેનો ઉપયોગ ઇચ્છિત નોડ શોધવા માટે થાય છે. તમે તેના માટે પહેલાથી જ પોડ ડિપ્લોયમેન્ટની યોજના બનાવી શકો છો. તમે યોગ્ય નોડ કેવી રીતે શોધી શકશો?

કુબરનેટ્સમાં માસ્ટર નોડ અથવા માસ્ટર નોડ (કુબરનેટ્સ કંટ્રોલ પ્લેન) સહિત અનેક ઘટકોનો સમાવેશ થાય છે. માસ્ટર નોડમાં ઘણી પ્રક્રિયાઓ છે: kube-apiserver, kube-controller-manager અને kube-scheduler.

ક્યુબ-શેડ્યુલર પ્રક્રિયા નવા બનાવેલા પોડ્સની સમીક્ષા કરવા અને વિનંતી કરાયેલા સંસાધનોની સંખ્યા સહિત તમામ પોડ વિનંતીઓ સાથે મેળ ખાતા સંભવિત કાર્યકર્તા નોડ્સ શોધવા માટે જવાબદાર છે. ક્યુબે-શેડ્યુલર દ્વારા મળેલ ગાંઠોની સૂચિને ક્રમ આપવામાં આવે છે. પોડ સૌથી વધુ સ્કોર સાથે નોડ પર સુનિશ્ચિત થયેલ છે.

જાંબલી પોડ ક્યાં મૂકવામાં આવશે?

ચિત્રમાં તમે જોઈ શકો છો કે કુબે-શેડ્યૂલરને નવી જાંબલી પોડ શેડ્યૂલ કરવી જોઈએ. કુબરનેટસ ક્લસ્ટરમાં બે નોડ્સ છે: A અને B. તમે જોઈ શકો છો કે, ક્યુબ-શેડ્યુલર નોડ A પર પોડ શેડ્યૂલ કરી શકતું નથી - ઉપલબ્ધ (અનંનંતી) સ્ત્રોતો જાંબલી પોડની વિનંતીઓ સાથે મેળ ખાતા નથી. તેથી, જાંબલી પોડ દ્વારા વિનંતી કરાયેલ 1 GB મેમરી નોડ A પર ફિટ થશે નહીં, કારણ કે ઉપલબ્ધ મેમરી 0,5 GB છે. પરંતુ નોડ B પાસે પૂરતા સંસાધનો છે. પરિણામે, કુબે-શેડ્યુલર નક્કી કરે છે કે જાંબલી પોડનું ગંતવ્ય નોડ બી છે.

હવે આપણે જાણીએ છીએ કે કેવી રીતે વિનંતી કરેલ સંસાધનો પોડ ચલાવવા માટે નોડની પસંદગીને અસર કરે છે. પરંતુ સીમાંત સંસાધનોની અસર શું છે?

સંસાધન મર્યાદા એ સીમા છે જેને CPU/MEM ઓળંગી શકતા નથી. જો કે, CPU સંસાધન લવચીક છે, તેથી કન્ટેનર જે તેમની CPU મર્યાદા સુધી પહોંચે છે તે પોડને બહાર નીકળવાનું કારણ બનશે નહીં. તેના બદલે, CPU થ્રોટલિંગ શરૂ થશે. જો MEM વપરાશની મર્યાદા પહોંચી જાય, તો કન્ટેનર OOM-કિલરને કારણે બંધ થઈ જશે અને જો RestartPolicy સેટિંગ દ્વારા મંજૂરી આપવામાં આવશે તો તેને ફરીથી શરૂ કરવામાં આવશે.

વિનંતી કરેલ અને મહત્તમ સંસાધનો વિગતવાર

ડોકર અને કુબરનેટ્સ વચ્ચે સંસાધન સંચાર

સંસાધન વિનંતીઓ અને સંસાધન મર્યાદાઓ કેવી રીતે કાર્ય કરે છે તે સમજાવવાની શ્રેષ્ઠ રીત એ છે કે કુબરનેટ્સ અને ડોકર વચ્ચેના સંબંધનો પરિચય કરાવવો. ઉપરની છબીમાં તમે જોઈ શકો છો કે કુબરનેટ્સ ફીલ્ડ્સ અને ડોકર સ્ટાર્ટઅપ ફ્લેગ્સ કેવી રીતે સંબંધિત છે.

મેમરી: વિનંતી અને મર્યાદા

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

ઉપર જણાવ્યા મુજબ, મેમરીને બાઈટ્સમાં માપવામાં આવે છે. પર આધારિત છે કુબરનેટ્સ દસ્તાવેજીકરણ, આપણે મેમરીને સંખ્યા તરીકે સ્પષ્ટ કરી શકીએ છીએ. સામાન્ય રીતે તે પૂર્ણાંક છે, ઉદાહરણ તરીકે 2678 - એટલે કે, 2678 બાઇટ્સ. તમે પ્રત્યયનો પણ ઉપયોગ કરી શકો છો G и Gi, મુખ્ય વસ્તુ એ યાદ રાખવાની છે કે તેઓ સમકક્ષ નથી. પ્રથમ દશાંશ છે અને બીજું દ્વિસંગી છે. k8s દસ્તાવેજીકરણમાં દર્શાવેલ ઉદાહરણની જેમ: 128974848, 129e6, 129M, 123Mi - તેઓ વ્યવહારીક સમકક્ષ છે.

કુબરનેટ્સ વિકલ્પ limits.memory ધ્વજ સાથે મેળ ખાય છે --memory ડોકર તરફથી. એ પરિસ્થિતિ માં request.memory ડોકર માટે કોઈ તીર નથી કારણ કે ડોકર આ ક્ષેત્રનો ઉપયોગ કરતું નથી. તમે પૂછી શકો છો, શું આ જરૂરી પણ છે? હા જરૂર. મેં અગાઉ કહ્યું તેમ, કુબરનેટ્સ માટે ક્ષેત્ર મહત્ત્વપૂર્ણ છે. તેમાંથી મળેલી માહિતીના આધારે, કુબે-શેડ્યુલર નક્કી કરે છે કે કયા નોડ પર પોડ શેડ્યૂલ કરવું.

જો તમે વિનંતી માટે અપૂરતી મેમરી સેટ કરો તો શું થશે?

જો કન્ટેનર વિનંતી કરેલ મેમરીની મર્યાદા સુધી પહોંચી ગયું હોય, તો પોડને પોડ્સના જૂથમાં મૂકવામાં આવે છે જે જ્યારે નોડમાં પૂરતી મેમરી ન હોય ત્યારે બંધ થઈ જાય છે.

જો તમે મેમરી મર્યાદા ખૂબ ઓછી સેટ કરો તો શું થશે?

જો કન્ટેનર મેમરી મર્યાદાને ઓળંગે છે, તો તેને OOM-Killedને કારણે સમાપ્ત કરવામાં આવશે. અને જો શક્ય હોય તો રીસ્ટાર્ટ પોલિસીના આધારે પુનઃપ્રારંભ થશે જ્યાં ડિફોલ્ટ મૂલ્ય છે Always.

જો તમે વિનંતી કરેલ મેમરીનો ઉલ્લેખ ન કરો તો શું થશે?

Kubernetes મર્યાદા મૂલ્ય લેશે અને તેને ડિફોલ્ટ મૂલ્ય તરીકે સેટ કરશે.

જો તમે મેમરી મર્યાદાનો ઉલ્લેખ ન કરો તો શું થઈ શકે?

કન્ટેનર પર કોઈ નિયંત્રણો નથી; તે ઇચ્છે તેટલી મેમરીનો ઉપયોગ કરી શકે છે. જો તે નોડની બધી ઉપલબ્ધ મેમરીનો ઉપયોગ કરવાનું શરૂ કરે, તો OOM તેને મારી નાખશે. જો શક્ય હોય તો RestartPolicy ના આધારે કન્ટેનર ફરીથી શરૂ કરવામાં આવશે.

જો તમે મેમરી મર્યાદાનો ઉલ્લેખ ન કરો તો શું થશે?

આ સૌથી ખરાબ પરિસ્થિતિ છે: શેડ્યૂલરને ખબર નથી કે કન્ટેનરને કેટલા સંસાધનોની જરૂર છે, અને આ નોડ પર ગંભીર સમસ્યાઓનું કારણ બની શકે છે. આ કિસ્સામાં, નેમસ્પેસ (લિમિટરેન્જ દ્વારા સેટ) પર ડિફૉલ્ટ મર્યાદા હોય તો સારું રહેશે. ત્યાં કોઈ મૂળભૂત મર્યાદા નથી - પોડની કોઈ મર્યાદા નથી, તે ઇચ્છે તેટલી મેમરીનો ઉપયોગ કરી શકે છે.

જો વિનંતી કરેલ મેમરી નોડ ઓફર કરી શકે છે તેના કરતા વધુ છે, તો પોડ શેડ્યૂલ કરવામાં આવશે નહીં. તે યાદ રાખવું અગત્યનું છે Requests.memory - ન્યૂનતમ મૂલ્ય નથી. કન્ટેનરને સતત ચાલુ રાખવા માટે પૂરતી મેમરીની માત્રાનું આ વર્ણન છે.

તે સામાન્ય રીતે માટે સમાન મૂલ્ય સેટ કરવાની ભલામણ કરવામાં આવે છે request.memory и limit.memory. આ સુનિશ્ચિત કરે છે કે કુબરનેટ્સ એવા નોડ પર પોડ શેડ્યૂલ કરશે નહીં કે જે પોડ ચલાવવા માટે પૂરતી મેમરી ધરાવે છે પરંતુ તેને ચલાવવા માટે પૂરતી નથી. ધ્યાનમાં રાખો: કુબરનેટ્સ પોડ પ્લાનિંગ માત્ર ધ્યાનમાં લે છે requests.memoryઅને limits.memory ધ્યાનમાં લેતા નથી.

CPU: વિનંતી અને મર્યાદા

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

CPU સાથે બધું થોડું વધુ જટિલ છે. કુબરનેટ્સ અને ડોકર વચ્ચેના સંબંધના ચિત્ર પર પાછા ફરતા, તમે તે જોઈ શકો છો request.cpu соответствует --cpu-shares, જ્યારે limit.cpu ધ્વજ સાથે મેળ ખાય છે cpus ડોકર માં.

કુબરનેટેસ જે CPU વિનંતી કરે છે તેને 1024 વડે ગુણાકાર કરવામાં આવે છે, જે CPU ચક્રનું પ્રમાણ છે. જો તમે 1 સંપૂર્ણ કોર માટે વિનંતી કરવા માંગતા હો, તો તમારે ઉમેરવું આવશ્યક છે cpu: 1ઉપર બતાવ્યા પ્રમાણે.

સંપૂર્ણ કર્નલ (પ્રમાણ = 1024)ની વિનંતી કરવાનો અર્થ એ નથી કે તમારું કન્ટેનર તેને પ્રાપ્ત કરશે. જો તમારા યજમાન મશીનમાં માત્ર એક કોર હોય અને તમે એક કરતા વધુ કન્ટેનર ચલાવી રહ્યા હોવ, તો બધા કન્ટેનર તેમની વચ્ચે ઉપલબ્ધ CPU શેર કરવા આવશ્યક છે. આ કેવી રીતે થાય છે? ચાલો ચિત્ર જોઈએ.

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% મળશે, અડધો નહીં. પરંતુ જો તમારી પાસે મલ્ટી-કોર સિસ્ટમ હોય તો વસ્તુઓ અલગ હશે.

CPU વિનંતી - મલ્ટી-કોર (4) સિસ્ટમ

ઉપરની છબીમાં તમે જોઈ શકો છો કે ત્રણ બાળકોને આખી પાઈ જોઈએ છે, અને એકને અડધી જોઈએ છે. મમ્મીએ ચાર પાઈ શેક્યા હોવાથી, તેના દરેક બાળકને તેઓ જોઈએ તેટલા મળશે. મલ્ટિ-કોર સિસ્ટમમાં, પ્રોસેસર સંસાધનો તમામ ઉપલબ્ધ પ્રોસેસર કોરોમાં વિતરિત કરવામાં આવે છે. જો કન્ટેનર એક કરતાં ઓછા સંપૂર્ણ CPU કોર સુધી મર્યાદિત હોય, તો પણ તે તેનો ઉપયોગ 100% પર કરી શકે છે.

કન્ટેનર વચ્ચે CPU કેવી રીતે વિતરિત થાય છે તે સમજવા માટે ઉપરોક્ત ગણતરીઓ સરળ બનાવવામાં આવી છે. અલબત્ત, કન્ટેનર ઉપરાંત, અન્ય પ્રક્રિયાઓ પણ છે જે CPU સંસાધનોનો ઉપયોગ કરે છે. જ્યારે એક કન્ટેનરમાં પ્રક્રિયાઓ નિષ્ક્રિય હોય, ત્યારે અન્ય તેના સંસાધનનો ઉપયોગ કરી શકે છે. CPU: "200m" соответствует CPU: 0,2, જેનો અર્થ એક કોરનો આશરે 20% છે.

હવે વાત કરીએ limit.cpu. CPU કે જે કુબરનેટ્સની મર્યાદા છે તેને 100 વડે ગુણાકાર કરવામાં આવે છે. પરિણામ એ છે કે કન્ટેનર દર 100 µs (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 પોલિસી (LimitRange) વ્યાખ્યાયિત કરવામાં આવી હોય, તો આ મર્યાદા કન્ટેનર માટે પણ વપરાય છે.

જો તમે વિનંતી અથવા CPU મર્યાદાનો ઉલ્લેખ ન કરો તો શું થશે?

મેમરીની જેમ, આ સૌથી ખરાબ પરિસ્થિતિ છે. શેડ્યૂલરને ખબર નથી કે તમારા કન્ટેનરને કેટલા સંસાધનોની જરૂર છે, અને આ નોડ પર ગંભીર સમસ્યાઓનું કારણ બની શકે છે. આને અવગણવા માટે, તમારે નેમસ્પેસ (લિમિટરેન્જ) માટે ડિફોલ્ટ મર્યાદા સેટ કરવાની જરૂર છે.

યાદ રાખો: જો તમે નોડ્સ પ્રદાન કરી શકે તે કરતાં વધુ CPU માટે વિનંતી કરો છો, તો Pod શેડ્યૂલ કરવામાં આવશે નહીં. Requests.cpu - ન્યૂનતમ મૂલ્ય નહીં, પરંતુ પોડ શરૂ કરવા અને નિષ્ફળતા વિના કાર્ય કરવા માટે પૂરતું મૂલ્ય. જો એપ્લિકેશન જટિલ ગણતરીઓ કરતી નથી, તો શ્રેષ્ઠ વિકલ્પ ઇન્સ્ટોલ કરવાનો છે request.cpu <= 1 અને જરૂરી હોય તેટલી પ્રતિકૃતિઓ લોંચ કરો.

વિનંતી કરેલ સંસાધનોની આદર્શ રકમ અથવા સંસાધન મર્યાદા

અમે કમ્પ્યુટિંગ સંસાધનોની મર્યાદા વિશે શીખ્યા. હવે આ પ્રશ્નનો જવાબ આપવાનો સમય છે: “મારા પોડને કોઈપણ સમસ્યા વિના એપ્લિકેશન ચલાવવા માટે કેટલા સંસાધનોની જરૂર છે? આદર્શ રકમ શું છે?

કમનસીબે, આ પ્રશ્નોના કોઈ સ્પષ્ટ જવાબો નથી. જો તમને ખબર ન હોય કે તમારી એપ્લિકેશન કેવી રીતે કાર્ય કરે છે અથવા તેને કેટલી CPU અથવા મેમરીની જરૂર છે, તો શ્રેષ્ઠ વિકલ્પ એ છે કે એપ્લિકેશનને ઘણી બધી મેમરી અને CPU આપો અને પછી પ્રદર્શન પરીક્ષણો ચલાવો.

પ્રદર્શન પરીક્ષણો ઉપરાંત, એક અઠવાડિયા માટે મોનિટરિંગમાં એપ્લિકેશનના વર્તનનું નિરીક્ષણ કરો. જો આલેખ સૂચવે છે કે તમારી એપ્લિકેશન તમારી વિનંતી કરતા ઓછા સંસાધનોનો ઉપયોગ કરી રહી છે, તો તમે વિનંતી કરેલ CPU અથવા મેમરીની માત્રા ઘટાડી શકો છો.

ઉદાહરણ તરીકે આ જુઓ ગ્રાફના ડેશબોર્ડ. તે વિનંતી કરેલ સંસાધનો અથવા સંસાધન મર્યાદા અને વર્તમાન સંસાધન વપરાશ વચ્ચેનો તફાવત દર્શાવે છે.

નિષ્કર્ષ

સંસાધનોની વિનંતી અને મર્યાદા તમારા કુબરનેટ્સ ક્લસ્ટરને સ્વસ્થ રાખવામાં મદદ કરે છે. યોગ્ય મર્યાદા રૂપરેખાંકન ખર્ચ ઘટાડે છે અને એપ્લિકેશનને હંમેશા ચાલુ રાખે છે.

ટૂંકમાં, ધ્યાનમાં રાખવાની કેટલીક બાબતો છે:

1. વિનંતી કરેલ સંસાધનો એ એક રૂપરેખાંકન છે જે સ્ટાર્ટઅપ સમયે ધ્યાનમાં લેવામાં આવે છે (જ્યારે કુબરનેટ્સ એપ્લિકેશનને હોસ્ટ કરવાની યોજના ધરાવે છે). તેનાથી વિપરિત, રનટાઇમ પર સંસાધનોને મર્યાદિત કરવું મહત્વપૂર્ણ છે-જ્યારે એપ્લિકેશન નોડ પર પહેલેથી જ ચાલી રહી હોય.
2. મેમરીની તુલનામાં, CPU એ એક નિયમન કરેલ સંસાધન છે. જો ત્યાં પૂરતું CPU ન હોય, તો તમારું Pod બંધ થશે નહીં અને થ્રોટલિંગ મિકેનિઝમ ચાલુ થશે.
3. વિનંતી કરેલ સંસાધનો અને સંસાધન મર્યાદા લઘુત્તમ અને મહત્તમ મૂલ્યો નથી! વિનંતી કરેલ સંસાધનોને વ્યાખ્યાયિત કરીને, તમે ખાતરી કરો કે એપ્લિકેશન સમસ્યાઓ વિના ચાલશે.
4. સારી પ્રથા એ છે કે મેમરી વિનંતિને મેમરી મર્યાદા જેટલી સેટ કરવી.
5. ઓકે ઇન્સ્ટોલ કરવાની વિનંતી કરી CPU <=1, જો એપ્લિકેશન જટિલ ગણતરીઓ કરતી નથી.
6. જો તમે નોડ પર ઉપલબ્ધ હોય તેના કરતાં વધુ સંસાધનોની વિનંતી કરો છો, તો પોડ ક્યારેય તે નોડ પર સુનિશ્ચિત કરવામાં આવશે નહીં.
7. વિનંતી કરેલ સંસાધનો/સંસાધન મર્યાદાઓની સાચી રકમ નક્કી કરવા માટે, લોડ પરીક્ષણ અને દેખરેખનો ઉપયોગ કરો.

મને આશા છે કે આ લેખ તમને સંસાધન મર્યાદાના મૂળભૂત ખ્યાલને સમજવામાં મદદ કરશે. અને તમે આ જ્ઞાનને તમારા કાર્યમાં લાગુ કરી શકશો.

સફળતા!

બીજું શું વાંચવું:

1. SRE અવલોકનક્ષમતા: નેમસ્પેસ અને મેટ્રિક સ્ટ્રક્ચર.
2. કુબરનેટ્સ માટે 90+ ઉપયોગી સાધનો: જમાવટ, સંચાલન, દેખરેખ, સુરક્ષા અને વધુ.
3. ટેલિગ્રામમાં કુબરનેટ્સની આસપાસ અમારી ચેનલ.

સોર્સ: www.habr.com