కుబెర్నెట్స్ పాడ్ వనరులను ఎలా యాక్సెస్ చేయాలి

తోహాద్ ద్వారా రివార్డ్

కుబెర్నెట్స్‌తో ప్రారంభించినప్పుడు, కంటైనర్ వనరులను సెటప్ చేయడం గురించి మర్చిపోవడం సాధారణం. ఈ సమయంలో, డాకర్ ఇమేజ్ పని చేస్తుందని మరియు కుబెర్నెటెస్ క్లస్టర్‌కి అమర్చబడుతుందని నిర్ధారించుకోవడం సరిపోతుంది.

కానీ తర్వాత అప్లికేషన్‌ను ఇతర అప్లికేషన్‌లతో పాటు ప్రొడక్షన్ క్లస్టర్‌లో అమర్చాలి. దీన్ని చేయడానికి, మీరు కంటైనర్ కోసం వనరులను కేటాయించాలి మరియు అప్లికేషన్‌ను అప్ మరియు రన్ చేయడానికి వాటిలో తగినంతగా ఉన్నాయని మరియు ఇతర రన్నింగ్ అప్లికేషన్‌లు సమస్యలను ఎదుర్కోకుండా చూసుకోవాలి.

జట్టు Mail.ru నుండి Kubernetes aaS కంటైనర్ వనరులు (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.

కొత్తగా సృష్టించిన పాడ్‌లను సమీక్షించడం మరియు అభ్యర్థించిన వనరుల సంఖ్యతో సహా అన్ని పాడ్ అభ్యర్థనలకు సరిపోలే అవకాశం ఉన్న వర్కర్ నోడ్‌లను కనుగొనడం కోసం kube-షెడ్యూలర్ ప్రక్రియ బాధ్యత వహిస్తుంది. kube-షెడ్యూలర్ ద్వారా కనుగొనబడిన నోడ్‌ల జాబితా ర్యాంక్ చేయబడింది. పాడ్ అత్యధిక స్కోర్‌లతో నోడ్‌లో షెడ్యూల్ చేయబడింది.

పర్పుల్ పాడ్ ఎక్కడ ఉంచబడుతుంది?

kube-షెడ్యూలర్ కొత్త పర్పుల్ పాడ్‌ని షెడ్యూల్ చేయాలని చిత్రంలో మీరు చూడవచ్చు. కుబెర్నెటెస్ క్లస్టర్ రెండు నోడ్‌లను కలిగి ఉంది: A మరియు B. మీరు చూడగలిగినట్లుగా, kube-షెడ్యూలర్ నోడ్ Aలో పాడ్‌ని షెడ్యూల్ చేయలేరు - అందుబాటులో ఉన్న (అభ్యర్థించని) వనరులు పర్పుల్ పాడ్ అభ్యర్థనలతో సరిపోలడం లేదు. కాబట్టి, పర్పుల్ పాడ్ అభ్యర్థించిన 1 GB మెమరీ నోడ్ Aకి సరిపోదు, ఎందుకంటే అందుబాటులో ఉన్న మెమరీ 0,5 GB. కానీ నోడ్ B తగినంత వనరులను కలిగి ఉంది. ఫలితంగా, పర్పుల్ పాడ్ యొక్క గమ్యం నోడ్ B అని kube-షెడ్యూలర్ నిర్ణయిస్తాడు.

పాడ్‌ను అమలు చేయడానికి అభ్యర్థించిన వనరులు నోడ్ ఎంపికను ఎలా ప్రభావితం చేస్తాయో ఇప్పుడు మనకు తెలుసు. కానీ ఉపాంత వనరుల ప్రభావం ఏమిటి?

వనరుల పరిమితి అనేది CPU/MEM దాటలేని సరిహద్దు. అయినప్పటికీ, CPU వనరు అనువైనది, కాబట్టి వాటి CPU పరిమితులను చేరుకునే కంటైనర్లు పాడ్ నుండి నిష్క్రమించడానికి కారణం కాదు. బదులుగా, CPU థ్రోట్లింగ్ ప్రారంభమవుతుంది. MEM వినియోగ పరిమితిని చేరుకున్నట్లయితే, OOM-కిల్లర్ కారణంగా కంటైనర్ ఆపివేయబడుతుంది మరియు రీస్టార్ట్ పాలసీ సెట్టింగ్ ద్వారా అనుమతించబడితే పునఃప్రారంభించబడుతుంది.

అభ్యర్థించిన మరియు గరిష్ట వనరులు వివరంగా

డాకర్ మరియు కుబెర్నెట్స్ మధ్య వనరుల కమ్యూనికేషన్

వనరుల అభ్యర్థనలు మరియు వనరుల పరిమితులు ఎలా పని చేస్తాయో వివరించడానికి ఉత్తమ మార్గం కుబెర్నెట్స్ మరియు డాకర్ మధ్య సంబంధాన్ని పరిచయం చేయడం. పై చిత్రంలో మీరు కుబెర్నెట్స్ ఫీల్డ్‌లు మరియు డాకర్ స్టార్టప్ ఫ్లాగ్‌లు ఎలా సంబంధం కలిగి ఉన్నాయో చూడవచ్చు.

మెమరీ: అభ్యర్థన మరియు పరిమితి

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

పైన చెప్పినట్లుగా, మెమరీని బైట్‌లలో కొలుస్తారు. ఆధారంగా కుబెర్నెట్స్ డాక్యుమెంటేషన్, మనం మెమరీని సంఖ్యగా పేర్కొనవచ్చు. సాధారణంగా ఇది పూర్ణాంకం, ఉదాహరణకు 2678 - అంటే 2678 బైట్లు. మీరు ప్రత్యయాలను కూడా ఉపయోగించవచ్చు G и Gi, ప్రధాన విషయం వారు సమానం కాదని గుర్తుంచుకోవాలి. మొదటిది దశాంశం మరియు రెండవది బైనరీ. k8s డాక్యుమెంటేషన్‌లో పేర్కొన్న ఉదాహరణ వలె: 128974848, 129e6, 129M, 123Mi - అవి ఆచరణాత్మకంగా సమానంగా ఉంటాయి.

కుబెర్నెట్స్ ఎంపిక limits.memory జెండాతో సరిపోతుంది --memory డాకర్ నుండి. విషయంలో request.memory డాకర్ ఈ ఫీల్డ్‌ని ఉపయోగించనందున డాకర్ కోసం బాణం లేదు. మీరు అడగవచ్చు, ఇది కూడా అవసరమా? అవును కావాలి. నేను ఇంతకు ముందు చెప్పినట్లుగా, కుబెర్నెట్‌లకు ఫీల్డ్ ముఖ్యమైనది. దాని నుండి వచ్చిన సమాచారం ఆధారంగా, kube-షెడ్యూలర్ పాడ్‌ను ఏ నోడ్‌లో షెడ్యూల్ చేయాలో నిర్ణయిస్తుంది.

మీరు అభ్యర్థన కోసం తగినంత మెమరీని సెట్ చేస్తే ఏమి జరుగుతుంది?

కంటైనర్ అభ్యర్థించిన మెమరీ పరిమితులను చేరుకున్నట్లయితే, నోడ్‌లో తగినంత మెమరీ లేనప్పుడు ఆగిపోయే పాడ్‌ల సమూహంలో పాడ్ ఉంచబడుతుంది.

మీరు మెమరీ పరిమితిని చాలా తక్కువగా సెట్ చేస్తే ఏమి జరుగుతుంది?

కంటైనర్ మెమరీ పరిమితిని మించి ఉంటే, OOM-కిల్డ్ కారణంగా అది రద్దు చేయబడుతుంది. మరియు డిఫాల్ట్ విలువ ఉన్న రీస్టార్ట్ పాలసీ ఆధారంగా వీలైతే పునఃప్రారంభించబడుతుంది Always.

మీరు అభ్యర్థించిన మెమరీని పేర్కొనకపోతే ఏమి జరుగుతుంది?

Kubernetes పరిమితి విలువను తీసుకుంటుంది మరియు దానిని డిఫాల్ట్ విలువగా సెట్ చేస్తుంది.

మీరు మెమరీ పరిమితిని పేర్కొనకపోతే ఏమి జరుగుతుంది?

కంటైనర్‌కు ఎటువంటి పరిమితులు లేవు; అది కోరుకున్నంత మెమరీని ఉపయోగించవచ్చు. అతను నోడ్ యొక్క అందుబాటులో ఉన్న మొత్తం మెమరీని ఉపయోగించడం ప్రారంభిస్తే, OOM అతన్ని చంపుతుంది. RestartPolicy ఆధారంగా వీలైతే కంటైనర్ మళ్లీ ప్రారంభించబడుతుంది.

మీరు మెమరీ పరిమితులను పేర్కొనకపోతే ఏమి జరుగుతుంది?

ఇది చెత్త దృష్టాంతం: కంటైనర్‌కు ఎన్ని వనరులు అవసరమో షెడ్యూలర్‌కు తెలియదు మరియు ఇది నోడ్‌లో తీవ్రమైన సమస్యలను కలిగిస్తుంది. ఈ సందర్భంలో, నేమ్‌స్పేస్‌పై డిఫాల్ట్ పరిమితులను కలిగి ఉంటే బాగుంటుంది (LimitRange ద్వారా సెట్ చేయబడింది). డిఫాల్ట్ పరిమితులు లేవు - పాడ్‌కు పరిమితులు లేవు, అది ఎంత మెమొరీని కావాలంటే అంత వినియోగిస్తుంది.

అభ్యర్థించిన మెమరీ నోడ్ అందించే దానికంటే ఎక్కువగా ఉంటే, పాడ్ షెడ్యూల్ చేయబడదు. అది గుర్తుంచుకోవడం ముఖ్యం 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 అభ్యర్థన - సింగిల్ కోర్ సిస్టమ్

మీరు సింగిల్-కోర్ హోస్ట్ సిస్టమ్ రన్నింగ్ కంటైనర్‌లను కలిగి ఉన్నారని ఊహించండి. అమ్మ (కుబెర్నెటెస్) పై (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ని ఉపయోగిస్తుంది. నేమ్‌స్పేస్‌లో డిఫాల్ట్ CPU విధానం (LimitRange) నిర్వచించబడితే, ఈ పరిమితి కంటైనర్‌కు కూడా ఉపయోగించబడుతుంది.

మీరు అభ్యర్థన లేదా CPU పరిమితిని పేర్కొనకపోతే ఏమి జరుగుతుంది?

జ్ఞాపకశక్తి వలె, ఇది చెత్త దృష్టాంతం. మీ కంటైనర్‌కు ఎన్ని వనరులు అవసరమో షెడ్యూలర్‌కు తెలియదు మరియు ఇది నోడ్‌లో తీవ్రమైన సమస్యలను కలిగిస్తుంది. దీన్ని నివారించడానికి, మీరు నేమ్‌స్పేస్‌ల (లిమిట్‌రేంజ్) కోసం డిఫాల్ట్ పరిమితులను సెట్ చేయాలి.

గుర్తుంచుకోండి: మీరు నోడ్‌ల కంటే ఎక్కువ CPUని అభ్యర్థిస్తే, పాడ్ షెడ్యూల్ చేయబడదు. Requests.cpu - కనీస విలువ కాదు, కానీ పాడ్‌ను ప్రారంభించడానికి మరియు వైఫల్యాలు లేకుండా పని చేయడానికి సరిపోయే విలువ. అప్లికేషన్ సంక్లిష్ట గణనలను నిర్వహించకపోతే, ఉత్తమ ఎంపిక ఇన్స్టాల్ చేయడం request.cpu <= 1 మరియు అవసరమైనన్ని ప్రతిరూపాలను ప్రారంభించండి.

అభ్యర్థించిన వనరులు లేదా వనరుల పరిమితి యొక్క ఆదర్శ మొత్తం

కంప్యూటింగ్ వనరుల పరిమితి గురించి మేము తెలుసుకున్నాము. ఇప్పుడు ప్రశ్నకు సమాధానమివ్వాల్సిన సమయం వచ్చింది: “అప్లికేషన్‌ను ఎటువంటి సమస్యలు లేకుండా అమలు చేయడానికి నా పాడ్‌కి ఎన్ని వనరులు అవసరం? ఆదర్శ మొత్తం ఎంత?

దురదృష్టవశాత్తు, ఈ ప్రశ్నలకు స్పష్టమైన సమాధానాలు లేవు. మీ అప్లికేషన్ ఎలా పనిచేస్తుందో లేదా దానికి ఎంత CPU లేదా మెమరీ అవసరమో మీకు తెలియకపోతే, అప్లికేషన్‌కు చాలా మెమరీ మరియు CPUని అందించి, ఆపై పనితీరు పరీక్షలను అమలు చేయడం ఉత్తమ ఎంపిక.

పనితీరు పరీక్షలతో పాటు, ఒక వారం పాటు పర్యవేక్షణలో అప్లికేషన్ యొక్క ప్రవర్తనను పర్యవేక్షించండి. మీ అప్లికేషన్ మీరు అభ్యర్థించిన దాని కంటే తక్కువ వనరులను వినియోగిస్తోందని గ్రాఫ్‌లు సూచిస్తే, మీరు అభ్యర్థించిన CPU లేదా మెమరీ మొత్తాన్ని తగ్గించవచ్చు.

ఉదాహరణగా దీన్ని చూడండి గ్రాఫానా డాష్‌బోర్డ్. ఇది అభ్యర్థించిన వనరులు లేదా వనరుల పరిమితి మరియు ప్రస్తుత వనరుల వినియోగం మధ్య వ్యత్యాసాన్ని ప్రదర్శిస్తుంది.

తీర్మానం

వనరులను అభ్యర్థించడం మరియు పరిమితం చేయడం మీ కుబెర్నెట్స్ క్లస్టర్‌ను ఆరోగ్యంగా ఉంచడంలో సహాయపడుతుంది. సరైన పరిమితి కాన్ఫిగరేషన్ ఖర్చులను తగ్గిస్తుంది మరియు అప్లికేషన్‌లను అన్ని సమయాల్లో అమలులో ఉంచుతుంది.

సంక్షిప్తంగా, గుర్తుంచుకోవలసిన కొన్ని విషయాలు ఉన్నాయి:

1. అభ్యర్థించిన వనరులు ప్రారంభ సమయంలో (కుబెర్నెటెస్ అప్లికేషన్‌ను హోస్ట్ చేయాలని ప్లాన్ చేసినప్పుడు) పరిగణనలోకి తీసుకోబడే కాన్ఫిగరేషన్. దీనికి విరుద్ధంగా, రన్‌టైమ్‌లో వనరులను పరిమితం చేయడం ముఖ్యం-అప్లికేషన్ ఇప్పటికే నోడ్‌లో నడుస్తున్నప్పుడు.
2. మెమరీతో పోలిస్తే, CPU నియంత్రిత వనరు. తగినంత CPU లేకపోతే, మీ పాడ్ షట్ డౌన్ చేయబడదు మరియు థ్రోట్లింగ్ మెకానిజం ఆన్ అవుతుంది.
3. అభ్యర్థించిన వనరులు మరియు వనరుల పరిమితి కనిష్ట మరియు గరిష్ట విలువలు కాదు! అభ్యర్థించిన వనరులను నిర్వచించడం ద్వారా, అప్లికేషన్ సమస్యలు లేకుండా రన్ అవుతుందని మీరు నిర్ధారించుకోండి.
4. మెమొరీ అభ్యర్థనను మెమరీ పరిమితికి సమానంగా సెట్ చేయడం మంచి అభ్యాసం.
5. సరే ఇన్‌స్టాల్ చేయమని అభ్యర్థించారు CPU <=1, అప్లికేషన్ సంక్లిష్ట గణనలను నిర్వహించకపోతే.
6. మీరు నోడ్‌లో అందుబాటులో ఉన్న దానికంటే ఎక్కువ వనరులను అభ్యర్థిస్తే, పాడ్ ఆ నోడ్‌కు షెడ్యూల్ చేయబడదు.
7. అభ్యర్థించిన వనరులు/వనరుల పరిమితుల యొక్క సరైన మొత్తాన్ని నిర్ణయించడానికి, లోడ్ పరీక్ష మరియు పర్యవేక్షణను ఉపయోగించండి.

వనరుల పరిమితి యొక్క ప్రాథమిక భావనను అర్థం చేసుకోవడానికి ఈ వ్యాసం మీకు సహాయపడుతుందని నేను ఆశిస్తున్నాను. మరియు మీరు మీ పనిలో ఈ జ్ఞానాన్ని వర్తింపజేయగలరు.

గుడ్ లక్!

ఇంకా ఏమి చదవాలి:

1. SRE పరిశీలన: నేమ్‌స్పేస్‌లు మరియు మెట్రిక్ స్ట్రక్చర్.
2. Kubernetes కోసం 90+ ఉపయోగకరమైన సాధనాలు: విస్తరణ, నిర్వహణ, పర్యవేక్షణ, భద్రత మరియు మరిన్ని.
3. టెలిగ్రామ్‌లో కుబెర్నెట్స్ చుట్టూ ఉన్న మా ఛానెల్.

మూలం: www.habr.com