Kubernetes Pod റിസോഴ്‌സുകൾ എങ്ങനെ ആക്‌സസ് ചെയ്യാം

തോഹദിന്റെ പ്രതിഫലം

Kubernetes-ൽ നിന്ന് ആരംഭിക്കുമ്പോൾ, കണ്ടെയ്നർ ഉറവിടങ്ങൾ സജ്ജീകരിക്കുന്നതിനെക്കുറിച്ച് മറക്കുന്നത് സാധാരണമാണ്. ഈ ഘട്ടത്തിൽ, ഡോക്കർ ഇമേജ് പ്രവർത്തിക്കുന്നുണ്ടെന്നും കുബർനെറ്റസ് ക്ലസ്റ്ററിലേക്ക് വിന്യസിക്കാൻ കഴിയുമെന്നും ഉറപ്പാക്കിയാൽ മതി.

എന്നാൽ പിന്നീട് ആപ്ലിക്കേഷൻ മറ്റ് ആപ്ലിക്കേഷനുകൾക്കൊപ്പം ഒരു പ്രൊഡക്ഷൻ ക്ലസ്റ്ററിൽ വിന്യസിക്കേണ്ടതുണ്ട്. ഇത് ചെയ്യുന്നതിന്, നിങ്ങൾ കണ്ടെയ്‌നറിനായി ഉറവിടങ്ങൾ അനുവദിക്കുകയും ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കുന്നതിന് അവയിൽ ആവശ്യത്തിന് ഉണ്ടെന്നും മറ്റ് പ്രവർത്തിക്കുന്ന ആപ്ലിക്കേഷനുകൾക്ക് പ്രശ്‌നങ്ങൾ ഉണ്ടാകില്ലെന്നും ഉറപ്പാക്കേണ്ടതുണ്ട്.

ടീം Mail.ru-ൽ നിന്ന് Kubernetes aaS കണ്ടെയ്‌നർ ഉറവിടങ്ങൾ (സിപിയു & എംഇഎം), അഭ്യർത്ഥനകൾ, വിഭവ പരിമിതികൾ എന്നിവയെക്കുറിച്ചുള്ള ഒരു ലേഖനം വിവർത്തനം ചെയ്തു. ഈ ക്രമീകരണങ്ങളുടെ പ്രയോജനങ്ങളെക്കുറിച്ചും അവ സജ്ജീകരിച്ചില്ലെങ്കിൽ എന്ത് സംഭവിക്കുമെന്നും നിങ്ങൾ മനസ്സിലാക്കും.

കമ്പ്യൂട്ടിംഗ് ഉറവിടങ്ങൾ

ഇനിപ്പറയുന്ന യൂണിറ്റുകളുള്ള ഞങ്ങൾക്ക് രണ്ട് തരം ഉറവിടങ്ങളുണ്ട്:

• സെൻട്രൽ പ്രോസസ്സിംഗ് യൂണിറ്റ് (സിപിയു) - കോറുകൾ;
• മെമ്മറി (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 സ്പെസിഫിക്കേഷനിൽ നിന്ന് ആവശ്യമുള്ള നോഡ് കണ്ടെത്താൻ ഉപയോഗിക്കുന്ന ഘടകങ്ങളിലൊന്നാണ് പോഡ്. അതിനായി നിങ്ങൾക്ക് ഇതിനകം തന്നെ Pod വിന്യാസം പ്ലാൻ ചെയ്യാം. അനുയോജ്യമായ ഒരു നോഡ് എങ്ങനെ കണ്ടെത്താം?

ഒരു മാസ്റ്റർ നോഡ് അല്ലെങ്കിൽ മാസ്റ്റർ നോഡ് (കുബർനെറ്റസ് കൺട്രോൾ പ്ലെയിൻ) ഉൾപ്പെടെ നിരവധി ഘടകങ്ങൾ കുബർനെറ്റസിൽ അടങ്ങിയിരിക്കുന്നു. മാസ്റ്റർ നോഡിന് നിരവധി പ്രക്രിയകൾ ഉണ്ട്: kube-apiserver, kube-controller-manager, kube-scheduler.

പുതുതായി സൃഷ്‌ടിച്ച പോഡുകൾ അവലോകനം ചെയ്യുന്നതിനും അഭ്യർത്ഥിച്ച വിഭവങ്ങളുടെ എണ്ണം ഉൾപ്പെടെ എല്ലാ പോഡ് അഭ്യർത്ഥനകളുമായി പൊരുത്തപ്പെടുന്ന സാധ്യമായ വർക്കർ നോഡുകൾ കണ്ടെത്തുന്നതിനും kube-ഷെഡ്യൂളർ പ്രക്രിയ ഉത്തരവാദിയാണ്. kube-scheduler കണ്ടെത്തിയ നോഡുകളുടെ ലിസ്റ്റ് റാങ്ക് ചെയ്‌തിരിക്കുന്നു. ഏറ്റവും ഉയർന്ന സ്കോറുകളുള്ള നോഡിലാണ് പോഡ് ഷെഡ്യൂൾ ചെയ്തിരിക്കുന്നത്.

പർപ്പിൾ പോഡ് എവിടെ സ്ഥാപിക്കും?

kube-scheduler ഒരു പുതിയ പർപ്പിൾ പോഡ് ഷെഡ്യൂൾ ചെയ്യേണ്ടത് ചിത്രത്തിൽ നിങ്ങൾക്ക് കാണാൻ കഴിയും. Kubernetes ക്ലസ്റ്ററിൽ രണ്ട് നോഡുകൾ അടങ്ങിയിരിക്കുന്നു: A, B. നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ, kube-scheduler-ന് നോഡ് A-ൽ ഒരു പോഡ് ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയില്ല - ലഭ്യമായ (അഭ്യർത്ഥിക്കാത്ത) ഉറവിടങ്ങൾ പർപ്പിൾ പോഡിന്റെ അഭ്യർത്ഥനകളുമായി പൊരുത്തപ്പെടുന്നില്ല. അതിനാൽ, ലഭ്യമായ മെമ്മറി 1 GB ആയതിനാൽ, പർപ്പിൾ പോഡ് അഭ്യർത്ഥിച്ച 0,5 GB മെമ്മറി നോഡ് A-യിൽ ചേരില്ല. എന്നാൽ നോഡ് ബി ആവശ്യത്തിന് വിഭവങ്ങൾ ഉണ്ട്. തൽഫലമായി, പർപ്പിൾ പോഡിന്റെ ലക്ഷ്യസ്ഥാനം നോഡ് ബി ആണെന്ന് ക്യൂബ്-ഷെഡ്യൂളർ തീരുമാനിക്കുന്നു.

അഭ്യർത്ഥിച്ച ഉറവിടങ്ങൾ പോഡ് പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള നോഡിന്റെ തിരഞ്ഞെടുപ്പിനെ എങ്ങനെ ബാധിക്കുന്നുവെന്ന് ഇപ്പോൾ നമുക്കറിയാം. എന്നാൽ നാമമാത്ര വിഭവങ്ങളുടെ സ്വാധീനം എന്താണ്?

CPU/MEM-ന് മറികടക്കാൻ കഴിയാത്ത ഒരു അതിരാണ് റിസോഴ്സ് പരിധി. എന്നിരുന്നാലും, സിപിയു റിസോഴ്‌സ് വഴക്കമുള്ളതാണ്, അതിനാൽ അവയുടെ സിപിയു പരിധിയിൽ എത്തുന്ന കണ്ടെയ്‌നറുകൾ പോഡ് പുറത്തുകടക്കാൻ കാരണമാകില്ല. പകരം, സിപിയു ത്രോട്ടിലിംഗ് ആരംഭിക്കും. 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 ഡോക്കർ ഈ ഫീൽഡ് ഉപയോഗിക്കാത്തതിനാൽ ഡോക്കറിന് അമ്പടയാളമില്ല. നിങ്ങൾ ചോദിച്ചേക്കാം, ഇത് പോലും ആവശ്യമാണോ? അതെ വേണം. ഞാൻ മുമ്പ് പറഞ്ഞതുപോലെ, കുബർനെറ്റസിന് ഫീൽഡ് പ്രധാനമാണ്. അതിൽ നിന്നുള്ള വിവരങ്ങളെ അടിസ്ഥാനമാക്കി, ഏത് നോഡിലാണ് പോഡ് ഷെഡ്യൂൾ ചെയ്യേണ്ടതെന്ന് kube-scheduler തീരുമാനിക്കുന്നു.

ഒരു അഭ്യർത്ഥനയ്ക്ക് വേണ്ടത്ര മെമ്മറി നിങ്ങൾ സജ്ജമാക്കിയാൽ എന്ത് സംഭവിക്കും?

അഭ്യർത്ഥിച്ച മെമ്മറിയുടെ പരിധിയിൽ കണ്ടെയ്നർ എത്തിയിട്ടുണ്ടെങ്കിൽ, നോഡിൽ മതിയായ മെമ്മറി ഇല്ലെങ്കിൽ നിർത്തുന്ന പോഡുകളുടെ ഒരു ഗ്രൂപ്പിൽ പോഡ് സ്ഥാപിക്കുന്നു.

നിങ്ങൾ മെമ്മറി പരിധി വളരെ കുറവായി സജ്ജമാക്കിയാൽ എന്ത് സംഭവിക്കും?

കണ്ടെയ്നർ മെമ്മറി പരിധി കവിയുന്നുവെങ്കിൽ, OOM-Killed കാരണം അത് അവസാനിപ്പിക്കും. സ്ഥിരസ്ഥിതി മൂല്യമുള്ള RestartPolicy അടിസ്ഥാനമാക്കി സാധ്യമെങ്കിൽ പുനരാരംഭിക്കും Always.

നിങ്ങൾ ആവശ്യപ്പെട്ട മെമ്മറി വ്യക്തമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

കുബർനെറ്റസ് പരിധി മൂല്യം എടുത്ത് സ്ഥിര മൂല്യമായി സജ്ജീകരിക്കും.

നിങ്ങൾ മെമ്മറി പരിധി വ്യക്തമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

കണ്ടെയ്നറിന് നിയന്ത്രണങ്ങളൊന്നുമില്ല; അതിന് ആവശ്യമുള്ളത്ര മെമ്മറി ഉപയോഗിക്കാം. അവൻ നോഡിന്റെ ലഭ്യമായ എല്ലാ മെമ്മറിയും ഉപയോഗിക്കാൻ തുടങ്ങിയാൽ, OOM അവനെ കൊല്ലും. റീസ്റ്റാർട്ട് പോളിസിയുടെ അടിസ്ഥാനത്തിൽ സാധ്യമെങ്കിൽ കണ്ടെയ്നർ പുനരാരംഭിക്കും.

നിങ്ങൾ മെമ്മറി പരിധികൾ വ്യക്തമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

ഇതാണ് ഏറ്റവും മോശം സാഹചര്യം: കണ്ടെയ്നറിന് എത്ര വിഭവങ്ങൾ ആവശ്യമാണെന്ന് ഷെഡ്യൂളർക്ക് അറിയില്ല, ഇത് നോഡിൽ ഗുരുതരമായ പ്രശ്നങ്ങൾ ഉണ്ടാക്കും. ഈ സാഹചര്യത്തിൽ, നെയിംസ്‌പെയ്‌സിൽ സ്ഥിരസ്ഥിതി പരിധികൾ ഉണ്ടായിരിക്കുന്നത് നന്നായിരിക്കും (ലിമിറ്റ്റേഞ്ച് സജ്ജമാക്കിയത്). സ്ഥിരസ്ഥിതി പരിധികളൊന്നുമില്ല - പോഡിന് പരിധികളില്ല, അതിന് ആവശ്യമുള്ളത്ര മെമ്മറി ഉപയോഗിക്കാം.

അഭ്യർത്ഥിച്ച മെമ്മറി നോഡിന് നൽകാൻ കഴിയുന്നതിനേക്കാൾ കൂടുതലാണെങ്കിൽ, പോഡ് ഷെഡ്യൂൾ ചെയ്യില്ല. അത് ഓർത്തിരിക്കേണ്ടത് പ്രധാനമാണ് Requests.memory - കുറഞ്ഞ മൂല്യമല്ല. കണ്ടെയ്‌നർ തുടർച്ചയായി പ്രവർത്തിക്കാൻ ആവശ്യമായ മെമ്മറിയുടെ അളവിന്റെ വിവരണമാണിത്.

സാധാരണയായി ഒരേ മൂല്യം സജ്ജമാക്കാൻ ശുപാർശ ചെയ്യുന്നു request.memory и limit.memory. പോഡ് പ്രവർത്തിപ്പിക്കാൻ മതിയായ മെമ്മറി ഉള്ളതും എന്നാൽ അത് പ്രവർത്തിപ്പിക്കാൻ പര്യാപ്തമല്ലാത്തതുമായ ഒരു നോഡിൽ Kubernetes ഒരു പോഡ് ഷെഡ്യൂൾ ചെയ്യില്ലെന്ന് ഇത് ഉറപ്പാക്കുന്നു. ഓർമ്മിക്കുക: Kubernetes Pod ആസൂത്രണം മാത്രമേ കണക്കിലെടുക്കൂ requests.memoryഒപ്പം limits.memory കണക്കിലെടുക്കുന്നില്ല.

സിപിയു: അഭ്യർത്ഥനയും പരിധിയും

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

ഒരു സിപിയു ഉപയോഗിച്ച് എല്ലാം കുറച്ചുകൂടി സങ്കീർണ്ണമാണ്. കുബർനെറ്റസും ഡോക്കറും തമ്മിലുള്ള ബന്ധത്തിന്റെ ചിത്രത്തിലേക്ക് മടങ്ങുമ്പോൾ, നിങ്ങൾക്ക് അത് കാണാൻ കഴിയും request.cpu എന്നതുമായി യോജിക്കുന്നു --cpu-shares, അതേസമയം limit.cpu പതാകയുമായി പൊരുത്തപ്പെടുന്നു cpus ഡോക്കറിൽ.

കുബെർനെറ്റസ് ആവശ്യപ്പെടുന്ന സിപിയു, സിപിയു സൈക്കിളുകളുടെ അനുപാതമായ 1024 കൊണ്ട് ഗുണിക്കുന്നു. നിങ്ങൾക്ക് ഒരു പൂർണ്ണ കോർ അഭ്യർത്ഥിക്കണമെങ്കിൽ, നിങ്ങൾ ചേർക്കണം cpu: 1മുകളിൽ കാണിച്ചിരിക്കുന്നതുപോലെ.

ഒരു പൂർണ്ണ കെർണൽ (അനുപാതം = 1024) അഭ്യർത്ഥിക്കുന്നത് നിങ്ങളുടെ കണ്ടെയ്‌നറിന് അത് ലഭിക്കുമെന്ന് അർത്ഥമാക്കുന്നില്ല. നിങ്ങളുടെ ഹോസ്റ്റ് മെഷീനിൽ ഒരു കോർ മാത്രമേ ഉള്ളൂവെങ്കിലും നിങ്ങൾ ഒന്നിലധികം കണ്ടെയ്‌നറുകൾ പ്രവർത്തിപ്പിക്കുന്നുണ്ടെങ്കിൽ, എല്ലാ കണ്ടെയ്‌നറുകളും അവയ്‌ക്കിടയിൽ ലഭ്യമായ സിപിയു പങ്കിടണം. ഇത് എങ്ങനെ സംഭവിക്കുന്നു? നമുക്ക് ചിത്രം നോക്കാം.

സിപിയു അഭ്യർത്ഥന - സിംഗിൾ കോർ സിസ്റ്റം

നിങ്ങൾക്ക് ഒരു സിംഗിൾ-കോർ ഹോസ്റ്റ് സിസ്റ്റം റണ്ണിംഗ് കണ്ടെയ്‌നറുകൾ ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക. അമ്മ (കുബെർനെറ്റസ്) ഒരു പൈ (സിപിയു) ചുട്ടു, കുട്ടികൾക്കിടയിൽ (കണ്ടെയ്നറുകൾ) വിഭജിക്കാൻ ആഗ്രഹിക്കുന്നു. മൂന്ന് കുട്ടികൾക്ക് മുഴുവൻ പൈ വേണം (അനുപാതം = 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% ലഭിക്കും, പകുതിയല്ല. എന്നാൽ നിങ്ങൾക്ക് ഒരു മൾട്ടി-കോർ സിസ്റ്റം ഉണ്ടെങ്കിൽ കാര്യങ്ങൾ വ്യത്യസ്തമായിരിക്കും.

സിപിയു അഭ്യർത്ഥന - മൾട്ടി-കോർ (4) സിസ്റ്റം

മുകളിലുള്ള ചിത്രത്തിൽ മൂന്ന് കുട്ടികൾക്ക് മുഴുവൻ പൈയും ഒരാൾക്ക് പകുതിയും വേണമെന്ന് നിങ്ങൾക്ക് കാണാൻ കഴിയും. അമ്മ നാല് പീസ് ചുട്ടതിനാൽ, അവളുടെ ഓരോ മക്കൾക്കും അവർ ആഗ്രഹിക്കുന്നത്രയും ലഭിക്കും. ഒരു മൾട്ടി-കോർ സിസ്റ്റത്തിൽ, ലഭ്യമായ എല്ലാ പ്രോസസർ കോറുകളിലും പ്രോസസ്സർ ഉറവിടങ്ങൾ വിതരണം ചെയ്യപ്പെടുന്നു. ഒരു കണ്ടെയ്‌നർ ഒന്നിൽ താഴെ മുഴുവൻ സിപിയു കോറിലേക്ക് പരിമിതപ്പെടുത്തിയിട്ടുണ്ടെങ്കിൽ, അതിന് അത് 100% ഉപയോഗിക്കാനാകും.

കണ്ടെയ്‌നറുകൾക്കിടയിൽ സിപിയു എങ്ങനെ വിതരണം ചെയ്യപ്പെടുന്നുവെന്ന് മനസിലാക്കാൻ മുകളിലുള്ള കണക്കുകൂട്ടലുകൾ ലളിതമാക്കിയിരിക്കുന്നു. തീർച്ചയായും, കണ്ടെയ്‌നറുകൾക്ക് പുറമേ, സിപിയു ഉറവിടങ്ങൾ ഉപയോഗിക്കുന്ന മറ്റ് പ്രക്രിയകളും ഉണ്ട്. ഒരു കണ്ടെയ്‌നറിലെ പ്രക്രിയകൾ നിഷ്‌ക്രിയമാകുമ്പോൾ, മറ്റുള്ളവർക്ക് അതിന്റെ ഉറവിടം ഉപയോഗിക്കാം. CPU: "200m" എന്നതുമായി യോജിക്കുന്നു CPU: 0,2, അതായത് ഒരു കോറിന്റെ ഏകദേശം 20%.

ഇനി നമുക്ക് സംസാരിക്കാം limit.cpu. കുബർനെറ്റസ് പരിമിതപ്പെടുത്തുന്ന സിപിയു 100 കൊണ്ട് ഗുണിക്കുന്നു. ഓരോ 100 µസെക്കിലും കണ്ടെയ്‌നറിന് ഉപയോഗിക്കാനാകുന്ന സമയമാണ് ഫലം.cpu-period).

limit.cpu ഡോക്കർ പതാകയുമായി പൊരുത്തപ്പെടുന്നു --cpus. ഇത് പഴയതിന്റെ പുതിയ സംയോജനമാണ് --cpu-period и --cpu-quota. ഇത് സജ്ജീകരിക്കുന്നതിലൂടെ, ത്രോട്ടിലിംഗ് ആരംഭിക്കുന്നതിന് മുമ്പ് കണ്ടെയ്‌നറിന് പരമാവധി ഉപയോഗിക്കാനാകുന്ന എത്ര സിപിയു ഉറവിടങ്ങൾ ഞങ്ങൾ സൂചിപ്പിക്കുന്നു:

• cpus - കോമ്പിനേഷൻ cpu-period и cpu-quota. cpus = 1.5 ക്രമീകരണത്തിന് തുല്യമാണ് cpu-period = 100000 и cpu-quota = 150000;
• സിപിയു-കാലയളവ് - കാലഘട്ടം CPU CFS ഷെഡ്യൂളർ, ഡിഫോൾട്ട് 100 മൈക്രോസെക്കൻഡ്;
• cpu-ക്വോട്ട - ഉള്ളിലെ മൈക്രോസെക്കൻഡുകളുടെ എണ്ണം cpu-period, ഏത് കണ്ടെയ്നർ ബന്ധിപ്പിച്ചിരിക്കുന്നു.

നിങ്ങൾ അഭ്യർത്ഥിച്ച CPU വേണ്ടത്ര ഇൻസ്റ്റാൾ ചെയ്തില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

കണ്ടെയ്‌നറിന് ഇൻസ്റ്റാൾ ചെയ്തതിനേക്കാൾ കൂടുതൽ ആവശ്യമുണ്ടെങ്കിൽ, അത് മറ്റ് പ്രോസസ്സുകളിൽ നിന്ന് സിപിയു മോഷ്ടിക്കും.

നിങ്ങൾ CPU പരിധി വളരെ കുറവായി സജ്ജമാക്കിയാൽ എന്ത് സംഭവിക്കും?

സിപിയു റിസോഴ്‌സ് ക്രമീകരിക്കാവുന്നതിനാൽ, ത്രോട്ടിലിംഗ് ഓണാകും.

നിങ്ങൾ ഒരു സിപിയു അഭ്യർത്ഥന വ്യക്തമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

മെമ്മറി പോലെ, അഭ്യർത്ഥന മൂല്യം പരിധിക്ക് തുല്യമാണ്.

നിങ്ങൾ ഒരു സിപിയു പരിധി വ്യക്തമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

കണ്ടെയ്‌നർ ആവശ്യമുള്ളത്ര സിപിയു ഉപയോഗിക്കും. നെയിംസ്‌പെയ്‌സിൽ ഒരു ഡിഫോൾട്ട് സിപിയു നയം (ലിമിറ്റ് റേഞ്ച്) നിർവചിച്ചിട്ടുണ്ടെങ്കിൽ, ഈ പരിധി കണ്ടെയ്‌നറിനും ഉപയോഗിക്കുന്നു.

നിങ്ങൾ ഒരു അഭ്യർത്ഥനയോ CPU പരിധിയോ വ്യക്തമാക്കിയില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

മെമ്മറി പോലെ, ഇത് ഏറ്റവും മോശം സാഹചര്യമാണ്. നിങ്ങളുടെ കണ്ടെയ്‌നറിന് എത്ര വിഭവങ്ങൾ ആവശ്യമാണെന്ന് ഷെഡ്യൂളർക്ക് അറിയില്ല, ഇത് നോഡിൽ ഗുരുതരമായ പ്രശ്‌നങ്ങൾക്ക് കാരണമാകും. ഇത് ഒഴിവാക്കാൻ, നിങ്ങൾ നെയിംസ്പേസുകൾക്കായി സ്ഥിരസ്ഥിതി പരിധികൾ സജ്ജമാക്കേണ്ടതുണ്ട് (ലിമിറ്റ്റേഞ്ച്).

ഓർക്കുക: നോഡുകൾക്ക് നൽകാൻ കഴിയുന്നതിനേക്കാൾ കൂടുതൽ സിപിയു നിങ്ങൾ അഭ്യർത്ഥിച്ചാൽ, പോഡ് ഷെഡ്യൂൾ ചെയ്യപ്പെടില്ല. Requests.cpu - ഏറ്റവും കുറഞ്ഞ മൂല്യമല്ല, പോഡ് ആരംഭിക്കുന്നതിനും പരാജയങ്ങളില്ലാതെ പ്രവർത്തിക്കുന്നതിനും മതിയായ മൂല്യം. ആപ്ലിക്കേഷൻ സങ്കീർണ്ണമായ കണക്കുകൂട്ടലുകൾ നടത്തുന്നില്ലെങ്കിൽ, മികച്ച ഓപ്ഷൻ ഇൻസ്റ്റാൾ ചെയ്യുക എന്നതാണ് request.cpu <= 1 ആവശ്യമുള്ളത്ര പകർപ്പുകൾ സമാരംഭിക്കുക.

അഭ്യർത്ഥിച്ച വിഭവങ്ങളുടെ അനുയോജ്യമായ തുക അല്ലെങ്കിൽ വിഭവ പരിധി

കമ്പ്യൂട്ടിംഗ് വിഭവങ്ങളുടെ പരിമിതിയെക്കുറിച്ച് ഞങ്ങൾ പഠിച്ചു. ഇപ്പോൾ ചോദ്യത്തിന് ഉത്തരം നൽകേണ്ട സമയമാണിത്: “ഒരു പ്രശ്നവുമില്ലാതെ ആപ്ലിക്കേഷൻ പ്രവർത്തിപ്പിക്കാൻ എന്റെ പോഡിന് എത്ര വിഭവങ്ങൾ ആവശ്യമാണ്? അനുയോജ്യമായ തുക എന്താണ്?

നിർഭാഗ്യവശാൽ, ഈ ചോദ്യങ്ങൾക്ക് വ്യക്തമായ ഉത്തരങ്ങളില്ല. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ എങ്ങനെ പ്രവർത്തിക്കുന്നുവെന്നോ അതിന് എത്ര സിപിയു അല്ലെങ്കിൽ മെമ്മറി ആവശ്യമാണെന്നോ നിങ്ങൾക്ക് അറിയില്ലെങ്കിൽ, ആപ്ലിക്കേഷന് ധാരാളം മെമ്മറിയും സിപിയുവും നൽകുകയും പ്രകടന പരിശോധനകൾ നടത്തുകയും ചെയ്യുക എന്നതാണ് ഏറ്റവും മികച്ച ഓപ്ഷൻ.

പ്രകടന പരിശോധനകൾക്ക് പുറമേ, ഒരാഴ്ചത്തേക്ക് നിരീക്ഷണത്തിൽ ആപ്ലിക്കേഷന്റെ പെരുമാറ്റം നിരീക്ഷിക്കുക. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ നിങ്ങൾ അഭ്യർത്ഥിച്ചതിനേക്കാൾ കുറച്ച് വിഭവങ്ങൾ ഉപയോഗിക്കുന്നുണ്ടെന്ന് ഗ്രാഫുകൾ സൂചിപ്പിക്കുന്നുവെങ്കിൽ, നിങ്ങൾക്ക് ആവശ്യപ്പെട്ട CPU അല്ലെങ്കിൽ മെമ്മറിയുടെ അളവ് കുറയ്ക്കാൻ കഴിയും.

ഉദാഹരണമായി ഇത് കാണുക ഗ്രാഫാന ഡാഷ്‌ബോർഡ്. അഭ്യർത്ഥിച്ച ഉറവിടങ്ങൾ അല്ലെങ്കിൽ റിസോഴ്സ് പരിധിയും നിലവിലെ റിസോഴ്സ് ഉപയോഗവും തമ്മിലുള്ള വ്യത്യാസം ഇത് പ്രദർശിപ്പിക്കുന്നു.

തീരുമാനം

വിഭവങ്ങൾ അഭ്യർത്ഥിക്കുകയും പരിമിതപ്പെടുത്തുകയും ചെയ്യുന്നത് നിങ്ങളുടെ കുബർനെറ്റസ് ക്ലസ്റ്ററിനെ ആരോഗ്യകരമായി നിലനിർത്താൻ സഹായിക്കുന്നു. ശരിയായ പരിധി കോൺഫിഗറേഷൻ ചെലവ് കുറയ്ക്കുകയും എല്ലാ സമയത്തും ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കുകയും ചെയ്യുന്നു.

ചുരുക്കത്തിൽ, മനസ്സിൽ സൂക്ഷിക്കേണ്ട ചില കാര്യങ്ങളുണ്ട്:

1. അഭ്യർത്ഥിച്ച ഉറവിടങ്ങൾ ഒരു കോൺഫിഗറേഷനാണ്, അത് ആരംഭിക്കുന്ന സമയത്ത് (കുബർനെറ്റസ് ആപ്ലിക്കേഷൻ ഹോസ്റ്റുചെയ്യാൻ പദ്ധതിയിടുമ്പോൾ) കണക്കിലെടുക്കുന്നു. ഇതിനു വിപരീതമായി, റൺടൈമിൽ ഉറവിടങ്ങൾ പരിമിതപ്പെടുത്തുന്നത് പ്രധാനമാണ് - ആപ്ലിക്കേഷൻ ഇതിനകം നോഡിൽ പ്രവർത്തിക്കുമ്പോൾ.
2. മെമ്മറിയുമായി താരതമ്യപ്പെടുത്തുമ്പോൾ, CPU ഒരു നിയന്ത്രിത വിഭവമാണ്. മതിയായ സിപിയു ഇല്ലെങ്കിൽ, നിങ്ങളുടെ പോഡ് ഷട്ട് ഡൗൺ ചെയ്യില്ല, ത്രോട്ടിലിംഗ് സംവിധാനം ഓണാകും.
3. അഭ്യർത്ഥിച്ച ഉറവിടങ്ങളും ഉറവിട പരിധിയും ഏറ്റവും കുറഞ്ഞതും കൂടിയതുമായ മൂല്യങ്ങളല്ല! അഭ്യർത്ഥിച്ച ഉറവിടങ്ങൾ നിർവചിക്കുന്നതിലൂടെ, ആപ്ലിക്കേഷൻ പ്രശ്നങ്ങളില്ലാതെ പ്രവർത്തിക്കുമെന്ന് നിങ്ങൾ ഉറപ്പാക്കുന്നു.
4. മെമ്മറി അഭ്യർത്ഥന മെമ്മറി പരിധിക്ക് തുല്യമായി സജ്ജീകരിക്കുന്നതാണ് നല്ല രീതി.
5. ശരി ഇൻസ്റ്റാൾ ചെയ്യാൻ അഭ്യർത്ഥിച്ചു CPU <=1, ആപ്ലിക്കേഷൻ സങ്കീർണ്ണമായ കണക്കുകൂട്ടലുകൾ നടത്തുന്നില്ലെങ്കിൽ.
6. ഒരു നോഡിൽ ലഭ്യമായതിനേക്കാൾ കൂടുതൽ ഉറവിടങ്ങൾ നിങ്ങൾ അഭ്യർത്ഥിക്കുകയാണെങ്കിൽ, Pod ഒരിക്കലും ആ നോഡിലേക്ക് ഷെഡ്യൂൾ ചെയ്യപ്പെടില്ല.
7. അഭ്യർത്ഥിച്ച ഉറവിടങ്ങളുടെ/വിഭവ പരിധികളുടെ ശരിയായ അളവ് നിർണ്ണയിക്കാൻ, ലോഡ് പരിശോധനയും നിരീക്ഷണവും ഉപയോഗിക്കുക.

വിഭവ പരിമിതി എന്ന അടിസ്ഥാന ആശയം മനസ്സിലാക്കാൻ ഈ ലേഖനം നിങ്ങളെ സഹായിക്കുമെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു. നിങ്ങളുടെ ജോലിയിൽ ഈ അറിവ് പ്രയോഗിക്കാൻ നിങ്ങൾക്ക് കഴിയും.

ഗുഡ് ലക്ക്!

മറ്റെന്താണ് വായിക്കേണ്ടത്:

1. എസ്ആർഇ നിരീക്ഷണക്ഷമത: നെയിംസ്പേസുകളും മെട്രിക് ഘടനയും.
2. 90+ കുബർനെറ്റുകൾക്കുള്ള ഉപയോഗപ്രദമായ ഉപകരണങ്ങൾ: വിന്യാസം, മാനേജ്മെന്റ്, നിരീക്ഷണം, സുരക്ഷ എന്നിവയും അതിലേറെയും.
3. ടെലിഗ്രാമിലെ ഞങ്ങളുടെ ചാനൽ കുബെർനെറ്റസിന് ചുറ്റും.

അവലംബം: www.habr.com