Kubernetes Pod ஆதாரங்களை எவ்வாறு அணுகுவது

டோஹாட்டின் வெகுமதி

Kubernetes உடன் தொடங்கும் போது, ​​கொள்கலன் ஆதாரங்களை அமைப்பதை மறந்துவிடுவது பொதுவானது. இந்த கட்டத்தில், டோக்கர் படம் செயல்படுவதை உறுதிசெய்தால் போதுமானது மற்றும் குபெர்னெட்ஸ் கிளஸ்டருக்கு பயன்படுத்தப்படலாம்.

ஆனால் பின்னர் பயன்பாடு பிற பயன்பாடுகளுடன் ஒரு உற்பத்தி கிளஸ்டரில் பயன்படுத்தப்பட வேண்டும். இதைச் செய்ய, நீங்கள் கொள்கலனுக்கான ஆதாரங்களை ஒதுக்க வேண்டும் மற்றும் பயன்பாட்டைப் பெறுவதற்கும், இயங்குவதற்கும் போதுமான அளவு உள்ளன என்பதையும், மற்ற இயங்கும் பயன்பாடுகள் சிக்கல்களைச் சந்திக்காது என்பதையும் உறுதிப்படுத்த வேண்டும்.

அணி Mail.ru இலிருந்து Kubernetes aaS கொள்கலன் ஆதாரங்கள் (CPU & MEM), கோரிக்கைகள் மற்றும் வள வரம்புகள் பற்றிய கட்டுரையை மொழிபெயர்த்தது. இந்த அமைப்புகளின் நன்மைகள் மற்றும் அவற்றை அமைக்கவில்லை என்றால் என்ன நடக்கும் என்பதை நீங்கள் அறிந்து கொள்வீர்கள்.

வளங்களை கணக்கிடுதல்

பின்வரும் அலகுகளுடன் எங்களிடம் இரண்டு வகையான ஆதாரங்கள் உள்ளன:

• மத்திய செயலாக்க அலகு (CPU) - கோர்கள்;
• நினைவகம் (MEM) - பைட்டுகள்.

ஒவ்வொரு கொள்கலனுக்கும் ஆதாரங்கள் குறிப்பிடப்பட்டுள்ளன. பின்வரும் Pod YAML கோப்பில், கோரப்பட்ட மற்றும் வரம்பிடப்பட்ட ஆதாரங்களைக் கொண்ட ஒரு ஆதாரப் பகுதியைக் காண்பீர்கள்:

• கோரப்பட்ட பாட் வளங்கள் = அனைத்து கொள்கலன்களின் கோரப்பட்ட வளங்களின் கூட்டுத்தொகை;
• Pod Resource வரம்பு = அனைத்து Pod Resource வரம்புகளின் கூட்டுத்தொகை.

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 வரிசைப்படுத்தலை நீங்கள் ஏற்கனவே திட்டமிடலாம். பொருத்தமான முனையை எவ்வாறு கண்டுபிடிப்பது?

குபெர்னெட்ஸ் ஒரு முதன்மை முனை அல்லது முதன்மை முனை (குபெர்னெட்ஸ் கட்டுப்பாட்டு விமானம்) உட்பட பல கூறுகளைக் கொண்டுள்ளது. முதன்மை முனையில் பல செயல்முறைகள் உள்ளன: kube-apiserver, kube-controller-manager மற்றும் kube-scheduler.

புதிதாக உருவாக்கப்பட்ட காய்களை மதிப்பாய்வு செய்வதற்கும், கோரப்பட்ட ஆதாரங்களின் எண்ணிக்கை உட்பட அனைத்து பாட் கோரிக்கைகளுக்கும் பொருந்தக்கூடிய சாத்தியமான பணியாளர் முனைகளைக் கண்டறிவதற்கும் kube-scheduler செயல்முறை பொறுப்பாகும். kube-scheduler மூலம் கண்டறியப்பட்ட முனைகளின் பட்டியல் தரவரிசைப்படுத்தப்பட்டுள்ளது. அதிக மதிப்பெண்கள் கொண்ட முனையில் பாட் திட்டமிடப்பட்டுள்ளது.

ஊதா நிற பாட் எங்கே வைக்கப்படும்?

குபே-திட்டமிடுபவர் ஒரு புதிய ஊதா நிறத்தை திட்டமிட வேண்டும் என்பதை படத்தில் காணலாம். குபெர்னெட்டஸ் கிளஸ்டரில் இரண்டு முனைகள் உள்ளன: A மற்றும் B. நீங்கள் பார்க்கிறபடி, kube-scheduler ஆனது முனை A இல் Pod-ஐ திட்டமிட முடியாது - கிடைக்கக்கூடிய (கோரப்படாத) ஆதாரங்கள் ஊதா நிற Podன் கோரிக்கைகளுடன் பொருந்தவில்லை. எனவே, பர்ப்பிள் பாட் கோரும் 1 ஜிபி நினைவகம் முனை A இல் பொருந்தாது, ஏனெனில் கிடைக்கும் நினைவகம் 0,5 ஜிபி. ஆனால் முனை B போதுமான ஆதாரங்களைக் கொண்டுள்ளது. இதன் விளைவாக, க்யூப்-திட்டமிடுபவர் ஊதா நிற பாட்டின் இலக்கு முனை பி என்று முடிவு செய்கிறார்.

பாட் ஐ இயக்குவதற்கான முனையின் தேர்வை கோரப்பட்ட ஆதாரங்கள் எவ்வாறு பாதிக்கின்றன என்பதை இப்போது நாம் அறிவோம். ஆனால் விளிம்பு வளங்களின் தாக்கம் என்ன?

ஆதார வரம்பு என்பது CPU/MEM கடக்க முடியாத எல்லையாகும். இருப்பினும், CPU ஆதாரம் நெகிழ்வானது, எனவே அவற்றின் CPU வரம்புகளை அடையும் கொள்கலன்கள் Pod ஐ வெளியேறச் செய்யாது. அதற்கு பதிலாக, CPU த்ரோட்லிங் தொடங்கும். MEM பயன்பாட்டு வரம்பை அடைந்துவிட்டால், OOM-கில்லர் காரணமாக கன்டெய்னர் நிறுத்தப்பட்டு, RestartPolicy அமைப்பு அனுமதித்தால் மீண்டும் தொடங்கப்படும்.

கோரப்பட்ட மற்றும் அதிகபட்ச ஆதாரங்கள் விரிவாக

Docker மற்றும் Kubernetes இடையே ஆதார தொடர்பு

ஆதார கோரிக்கைகள் மற்றும் ஆதார வரம்புகள் எவ்வாறு செயல்படுகின்றன என்பதை விளக்குவதற்கான சிறந்த வழி, குபெர்னெட்டஸுக்கும் டோக்கருக்கும் இடையிலான உறவை அறிமுகப்படுத்துவதாகும். மேலே உள்ள படத்தில் குபெர்னெட்டஸ் புலங்கள் மற்றும் டோக்கர் தொடக்கக் கொடிகள் எவ்வாறு தொடர்புடையவை என்பதை நீங்கள் பார்க்கலாம்.

நினைவகம்: கோரிக்கை மற்றும் வரம்பு

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

மேலே குறிப்பிட்டுள்ளபடி, நினைவகம் பைட்டுகளில் அளவிடப்படுகிறது. அடிப்படையில் குபெர்னெட்ஸ் ஆவணங்கள், நினைவகத்தை எண்ணாக குறிப்பிடலாம். பொதுவாக இது ஒரு முழு எண், எடுத்துக்காட்டாக 2678 - அதாவது 2678 பைட்டுகள். நீங்கள் பின்னொட்டுகளையும் பயன்படுத்தலாம் G и Gi, முக்கிய விஷயம் என்னவென்றால், அவை சமமானவை அல்ல என்பதை நினைவில் கொள்ள வேண்டும். முதல் தசமம் மற்றும் இரண்டாவது பைனரி. k8s ஆவணத்தில் குறிப்பிடப்பட்டுள்ள உதாரணத்தைப் போல: 128974848, 129e6, 129M, 123Mi - அவை நடைமுறையில் சமமானவை.

குபெர்னெட்ஸ் விருப்பம் limits.memory கொடியுடன் பொருந்துகிறது --memory டோக்கரிடமிருந்து. ஒரு வேளை request.memory Docker இந்தப் புலத்தைப் பயன்படுத்தாததால், Dockerக்கு அம்புக்குறி எதுவும் இல்லை. நீங்கள் கேட்கலாம், இது கூட தேவையா? ஆம் தேவை. நான் முன்பு கூறியது போல், குபர்னெட்டஸுக்கு புலம் முக்கியமானது. அதிலிருந்து கிடைக்கும் தகவலின் அடிப்படையில், kube-scheduler எந்த முனையில் Podஐ திட்டமிட வேண்டும் என்பதை தீர்மானிக்கிறது.

கோரிக்கைக்கு போதுமான நினைவகத்தை அமைத்தால் என்ன நடக்கும்?

கன்டெய்னர் கோரப்பட்ட நினைவகத்தின் வரம்பை அடைந்துவிட்டால், முனையில் போதுமான நினைவகம் இல்லாதபோது நிறுத்தப்படும் பாட்களின் குழுவில் பாட் வைக்கப்படும்.

நினைவக வரம்பை மிகக் குறைவாக அமைத்தால் என்ன ஆகும்?

கன்டெய்னர் நினைவக வரம்பை மீறினால், OOM-Killed காரணமாக அது நிறுத்தப்படும். மற்றும் இயல்புநிலை மதிப்பு இருக்கும் RestartPolicy அடிப்படையில் முடிந்தால் மறுதொடக்கம் செய்யப்படும் Always.

கோரப்பட்ட நினைவகத்தை நீங்கள் குறிப்பிடவில்லை என்றால் என்ன நடக்கும்?

குபெர்னெட்ஸ் வரம்பு மதிப்பை எடுத்து இயல்புநிலை மதிப்பாக அமைக்கும்.

நினைவக வரம்பை நீங்கள் குறிப்பிடவில்லை என்றால் என்ன நடக்கும்?

கொள்கலனுக்கு எந்த கட்டுப்பாடுகளும் இல்லை; அது விரும்பும் அளவுக்கு நினைவகத்தைப் பயன்படுத்தலாம். அவர் கணுவின் அனைத்து நினைவகத்தையும் பயன்படுத்தத் தொடங்கினால், OOM அவரைக் கொன்றுவிடும். ரீஸ்டார்ட் பாலிசியின் அடிப்படையில் முடிந்தால் கொள்கலன் மறுதொடக்கம் செய்யப்படும்.

நினைவக வரம்புகளை நீங்கள் குறிப்பிடவில்லை என்றால் என்ன நடக்கும்?

இது மிக மோசமான சூழ்நிலை: கொள்கலனுக்கு எத்தனை ஆதாரங்கள் தேவை என்பதை திட்டமிடுபவருக்குத் தெரியாது, மேலும் இது முனையில் கடுமையான சிக்கல்களை ஏற்படுத்தும். இந்த வழக்கில், பெயர்வெளியில் இயல்புநிலை வரம்புகள் இருந்தால் நன்றாக இருக்கும் (லிமிட்ரேஞ்ச் அமைத்தது). இயல்புநிலை வரம்புகள் எதுவும் இல்லை - Pod க்கு வரம்புகள் இல்லை, அது விரும்பும் அளவுக்கு நினைவகத்தைப் பயன்படுத்தலாம்.

கோரப்பட்ட நினைவகம் முனை வழங்கக்கூடியதை விட அதிகமாக இருந்தால், Pod திட்டமிடப்படாது. என்பதை நினைவில் கொள்வது அவசியம் Requests.memory - குறைந்தபட்ச மதிப்பு அல்ல. இது கன்டெய்னரை தொடர்ந்து இயங்க வைக்க போதுமான நினைவகத்தின் அளவு பற்றிய விளக்கமாகும்.

பொதுவாக அதே மதிப்பை அமைக்க பரிந்துரைக்கப்படுகிறது request.memory и limit.memory. Pod ஐ இயக்குவதற்கு போதுமான நினைவகம் உள்ளது ஆனால் அதை இயக்க போதுமானதாக இல்லாத ஒரு முனையில் Kubernetes ஒரு Pod ஐ திட்டமிடாது என்பதை இது உறுதி செய்கிறது. நினைவில் கொள்ளுங்கள்: Kubernetes Pod திட்டமிடல் மட்டுமே கணக்கில் எடுத்துக்கொள்ளப்படும் requests.memoryமற்றும் limits.memory கணக்கில் எடுத்துக்கொள்வதில்லை.

CPU: கோரிக்கை மற்றும் வரம்பு

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

ஒரு CPU உடன் எல்லாம் கொஞ்சம் சிக்கலானது. குபெர்னெட்டஸுக்கும் டோக்கருக்கும் இடையிலான உறவின் படத்திற்குத் திரும்புகையில், நீங்கள் அதைப் பார்க்கலாம் request.cpu ஒத்துள்ளது --cpu-shares, அதேசமயம் limit.cpu கொடியுடன் பொருந்துகிறது cpus டோக்கரில்.

குபெர்னெட்ஸ் கோரும் CPU ஆனது CPU சுழற்சிகளின் விகிதமான 1024 ஆல் பெருக்கப்படுகிறது. 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 கொள்கை (லிமிட்ரேஞ்ச்) வரையறுக்கப்பட்டால், இந்த வரம்பு கொள்கலனுக்கும் பயன்படுத்தப்படும்.

கோரிக்கை அல்லது CPU வரம்பை நீங்கள் குறிப்பிடவில்லை என்றால் என்ன நடக்கும்?

நினைவகத்தைப் போலவே, இது மிக மோசமான சூழ்நிலை. உங்கள் கன்டெய்னருக்கு எத்தனை ஆதாரங்கள் தேவை என்று திட்டமிடுபவருக்குத் தெரியாது, மேலும் இது முனையில் கடுமையான சிக்கல்களை ஏற்படுத்தலாம். இதைத் தவிர்க்க, பெயர்வெளிகளுக்கு (லிமிட்ரேஞ்ச்) இயல்புநிலை வரம்புகளை அமைக்க வேண்டும்.

நினைவில் கொள்ளுங்கள்: முனைகள் வழங்குவதை விட அதிகமான CPU ஐ நீங்கள் கோரினால், Pod திட்டமிடப்படாது. Requests.cpu - குறைந்தபட்ச மதிப்பு அல்ல, ஆனால் Pod ஐத் தொடங்க மற்றும் தோல்விகள் இல்லாமல் வேலை செய்ய போதுமான மதிப்பு. பயன்பாடு சிக்கலான கணக்கீடுகளைச் செய்யவில்லை என்றால், சிறந்த விருப்பம் நிறுவுவதாகும் request.cpu <= 1 மற்றும் தேவையான பல பிரதிகளை துவக்கவும்.

கோரப்பட்ட வளங்களின் சிறந்த அளவு அல்லது வள வரம்பு

கணினி வளங்களின் வரம்பு பற்றி அறிந்து கொண்டோம். இப்போது கேள்விக்கு பதிலளிக்க வேண்டிய நேரம் இது: "எந்த பிரச்சனையும் இல்லாமல் பயன்பாட்டை இயக்க எனது Podக்கு எத்தனை ஆதாரங்கள் தேவை? உகந்த தொகை என்ன?

துரதிர்ஷ்டவசமாக, இந்தக் கேள்விகளுக்கு தெளிவான பதில்கள் இல்லை. உங்கள் பயன்பாடு எவ்வாறு இயங்குகிறது அல்லது அதற்கு எவ்வளவு CPU அல்லது நினைவகம் தேவை என்று உங்களுக்குத் தெரியாவிட்டால், பயன்பாட்டிற்கு அதிக நினைவகம் மற்றும் CPU ஐக் கொடுத்து பின்னர் செயல்திறன் சோதனைகளை இயக்குவதே சிறந்த வழி.

செயல்திறன் சோதனைகள் கூடுதலாக, ஒரு வாரத்திற்கு கண்காணிப்பில் பயன்பாட்டின் நடத்தையை கண்காணிக்கவும். உங்கள் பயன்பாடு நீங்கள் கோரியதை விட குறைவான ஆதாரங்களை பயன்படுத்துகிறது என்று வரைபடங்கள் சுட்டிக்காட்டினால், கோரப்பட்ட CPU அல்லது நினைவகத்தின் அளவைக் குறைக்கலாம்.

உதாரணமாக இதைப் பாருங்கள் கிராஃபானா டாஷ்போர்டு. இது கோரப்பட்ட வளங்கள் அல்லது வள வரம்பு மற்றும் தற்போதைய வள பயன்பாடு ஆகியவற்றுக்கு இடையேயான வேறுபாட்டைக் காட்டுகிறது.

முடிவுக்கு

ஆதாரங்களைக் கோருவதும் வரம்பிடுவதும் உங்கள் குபெர்னெட்ஸ் கிளஸ்டரை ஆரோக்கியமாக வைத்திருக்க உதவுகிறது. சரியான வரம்பு உள்ளமைவு செலவுகளைக் குறைக்கிறது மற்றும் எல்லா நேரங்களிலும் பயன்பாடுகளை இயங்க வைக்கிறது.

சுருக்கமாக, மனதில் கொள்ள வேண்டிய சில விஷயங்கள் உள்ளன:

1. கோரப்பட்ட ஆதாரங்கள் என்பது தொடக்க நேரத்தில் (குபெர்னெட்ஸ் பயன்பாட்டை ஹோஸ்ட் செய்யத் திட்டமிடும் போது) கணக்கில் எடுத்துக்கொள்ளப்படும் உள்ளமைவாகும். இதற்கு நேர்மாறாக, இயக்க நேரத்தில், பயன்பாடு ஏற்கனவே முனையில் இயங்கும் போது வளங்களை கட்டுப்படுத்துவது முக்கியம்.
2. நினைவகத்துடன் ஒப்பிடும்போது, ​​CPU ஒரு ஒழுங்குபடுத்தப்பட்ட வளமாகும். போதுமான CPU இல்லாவிட்டால், உங்கள் Pod மூடப்படாது மற்றும் த்ரோட்லிங் மெக்கானிசம் இயக்கப்படும்.
3. கோரப்பட்ட ஆதாரங்கள் மற்றும் வள வரம்பு குறைந்தபட்ச மற்றும் அதிகபட்ச மதிப்புகள் அல்ல! கோரப்பட்ட ஆதாரங்களை வரையறுப்பதன் மூலம், பயன்பாடு சிக்கல்கள் இல்லாமல் இயங்கும் என்பதை உறுதிசெய்கிறீர்கள்.
4. நினைவக கோரிக்கையை நினைவக வரம்பிற்கு சமமாக அமைப்பது ஒரு நல்ல நடைமுறை.
5. சரி நிறுவல் கோரப்பட்டது CPU <=1, பயன்பாடு சிக்கலான கணக்கீடுகளைச் செய்யவில்லை என்றால்.
6. ஒரு முனையில் இருப்பதை விட அதிகமான ஆதாரங்களை நீங்கள் கோரினால், அந்த முனைக்கு Pod ஒருபோதும் திட்டமிடப்படாது.
7. கோரப்பட்ட வளங்கள்/வள வரம்புகளின் சரியான அளவைத் தீர்மானிக்க, சுமை சோதனை மற்றும் கண்காணிப்பைப் பயன்படுத்தவும்.

வள வரம்பு பற்றிய அடிப்படைக் கருத்தைப் புரிந்துகொள்ள இந்தக் கட்டுரை உதவும் என்று நம்புகிறேன். இந்த அறிவை உங்கள் வேலையில் நீங்கள் பயன்படுத்த முடியும்.

நல்ல அதிர்ஷ்டம்!

வேறு என்ன படிக்க வேண்டும்:

1. SRE கவனிப்பு: பெயர்வெளிகள் மற்றும் மெட்ரிக் அமைப்பு.
2. 90+ குபெர்னெட்களுக்கான பயனுள்ள கருவிகள்: வரிசைப்படுத்தல், மேலாண்மை, கண்காணிப்பு, பாதுகாப்பு மற்றும் பல.
3. Telegram இல் Kubernetes சுற்றி எங்கள் சேனல்.

ஆதாரம்: www.habr.com