ഒമ്പത് കുബർനെറ്റസ് പെർഫോമൻസ് ടിപ്പുകൾ

എല്ലാവർക്കും ഹായ്! എന്റെ പേര് ഒലെഗ് സിഡോറെൻകോവ്, ഞാൻ ഒരു ഇൻഫ്രാസ്ട്രക്ചർ ടീം ലീഡറായി DomClick-ൽ ജോലി ചെയ്യുന്നു. ഞങ്ങൾ മൂന്ന് വർഷത്തിലേറെയായി ക്യൂബ് വിൽപ്പനയ്‌ക്കായി ഉപയോഗിക്കുന്നു, ഈ സമയത്ത് ഞങ്ങൾ അത് ഉപയോഗിച്ച് നിരവധി രസകരമായ നിമിഷങ്ങൾ അനുഭവിച്ചിട്ടുണ്ട്. ഇന്ന് ഞാൻ നിങ്ങളോട് പറയും, ശരിയായ സമീപനത്തിലൂടെ, നിങ്ങളുടെ ക്ലസ്റ്ററിനായി വാനില കുബെർനെറ്റസിൽ നിന്ന് കൂടുതൽ പ്രകടനം പുറത്തെടുക്കുന്നത് എങ്ങനെയെന്ന്. റെഡി സ്റ്റെഡി ഗോ!

കണ്ടെയ്‌നർ ഓർക്കസ്‌ട്രേഷനു വേണ്ടിയുള്ള സ്‌കേലബിൾ ഓപ്പൺ സോഴ്‌സ് സിസ്റ്റമാണ് കുബർനെറ്റസ് എന്ന് നിങ്ങൾക്കെല്ലാവർക്കും നന്നായി അറിയാം; നന്നായി, അല്ലെങ്കിൽ ഒരു സെർവർ പരിതസ്ഥിതിയിൽ നിങ്ങളുടെ മൈക്രോസർവീസുകളുടെ ജീവിതചക്രം കൈകാര്യം ചെയ്തുകൊണ്ട് മാജിക് ചെയ്യുന്ന 5 ബൈനറികൾ. കൂടാതെ, വ്യത്യസ്ത ജോലികൾക്കായുള്ള പരമാവധി ഇഷ്‌ടാനുസൃതമാക്കലിനായി ഒരു ലെഗോ കൺസ്ട്രക്‌ടർ പോലെ കൂട്ടിച്ചേർക്കാൻ കഴിയുന്ന തികച്ചും വഴക്കമുള്ള ഉപകരണമാണിത്.

എല്ലാം ശരിയാണെന്ന് തോന്നുന്നു: ഒരു ഫയർബോക്സിലേക്ക് വിറക് പോലെ സെർവറുകൾ ക്ലസ്റ്ററിലേക്ക് എറിയുക, സങ്കടം അറിയരുത്. എന്നാൽ നിങ്ങൾ പരിസ്ഥിതിക്ക് വേണ്ടിയാണെങ്കിൽ, നിങ്ങൾ ചിന്തിക്കും: "എനിക്ക് എങ്ങനെ അടുപ്പിൽ തീ സൂക്ഷിക്കാനും വനത്തെക്കുറിച്ച് പശ്ചാത്തപിക്കാനും കഴിയും?". മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, അടിസ്ഥാന സൗകര്യങ്ങൾ മെച്ചപ്പെടുത്തുന്നതിനും ചെലവ് കുറയ്ക്കുന്നതിനുമുള്ള വഴികൾ എങ്ങനെ കണ്ടെത്താം.

1. ടീമിന്റെയും ആപ്ലിക്കേഷൻ വിഭവങ്ങളുടെയും ട്രാക്ക് സൂക്ഷിക്കുക

അഭ്യർത്ഥനകൾ/പരിധികൾ അവതരിപ്പിക്കുക എന്നതാണ് ഏറ്റവും നിന്ദ്യമായതും എന്നാൽ ഫലപ്രദവുമായ മാർഗ്ഗങ്ങളിലൊന്ന്. നെയിംസ്‌പെയ്‌സുകളും നെയിംസ്‌പെയ്‌സുകളും ഡെവലപ്‌മെന്റ് ടീമുകൾ പ്രകാരം വേർതിരിക്കുക. പ്രോസസ്സർ സമയം, മെമ്മറി, എഫെമറൽ സ്റ്റോറേജ് എന്നിവയുടെ ഉപഭോഗത്തിനായി മൂല്യങ്ങൾ വിന്യസിക്കുന്നതിന് മുമ്പ് ആപ്ലിക്കേഷൻ സജ്ജമാക്കുക.

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

അനുഭവത്തിലൂടെ, ഞങ്ങൾ നിഗമനത്തിലെത്തി: പരിധിയിൽ നിന്നുള്ള അഭ്യർത്ഥനകൾ രണ്ടിൽ കൂടുതൽ തവണ വർദ്ധിപ്പിക്കുന്നത് വിലമതിക്കുന്നില്ല. അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കിയാണ് ക്ലസ്റ്റർ വലുപ്പം കണക്കാക്കുന്നത്, നിങ്ങൾ ആപ്ലിക്കേഷനെ ഉറവിടങ്ങളിലെ വ്യത്യാസത്തിലേക്ക് സജ്ജമാക്കുകയാണെങ്കിൽ, ഉദാഹരണത്തിന്, 5-10 മടങ്ങ്, നിങ്ങളുടെ നോഡിന് പോഡുകൾ നിറച്ച് പെട്ടെന്ന് ഒരു ലോഡ് ലഭിക്കുമ്പോൾ എന്ത് സംഭവിക്കുമെന്ന് സങ്കൽപ്പിക്കുക. ഒന്നും നല്ലതല്ല. ചുരുങ്ങിയത്, ത്രോട്ടിലിംഗ്, പരമാവധി, തൊഴിലാളിയോട് വിട പറയുകയും കായ്കൾ നീങ്ങാൻ തുടങ്ങിയതിന് ശേഷം ബാക്കിയുള്ള നോഡുകളിൽ ഒരു ചാക്രിക ലോഡ് നേടുകയും ചെയ്യുക.

കൂടാതെ, സഹായത്തോടെ limitranges നിങ്ങൾക്ക് തുടക്കത്തിൽ തന്നെ കണ്ടെയ്‌നറിനായി ഉറവിട മൂല്യങ്ങൾ സജ്ജമാക്കാൻ കഴിയും - കുറഞ്ഞത്, പരമാവധി, സ്ഥിരസ്ഥിതി:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

നെയിംസ്പേസ് ഉറവിടങ്ങൾ പരിമിതപ്പെടുത്താൻ ഓർക്കുക, അങ്ങനെ ഒരു കമാൻഡിന് ക്ലസ്റ്ററിന്റെ എല്ലാ ഉറവിടങ്ങളും എടുക്കാൻ കഴിയില്ല:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

വിവരണത്തിൽ നിന്ന് നിങ്ങൾക്ക് കാണാനാകുന്നതുപോലെ resourcequotas, ops കമാൻഡിന് മറ്റൊരു 10 സിപിയു ഉപയോഗിക്കുന്ന പോഡുകൾ വിന്യസിക്കാൻ താൽപ്പര്യമുണ്ടെങ്കിൽ, ഷെഡ്യൂളർ അത് ചെയ്യാൻ അനുവദിക്കില്ല കൂടാതെ ഒരു പിശക് നൽകുകയും ചെയ്യും:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

സമാനമായ ഒരു പ്രശ്നം പരിഹരിക്കാൻ, നിങ്ങൾക്ക് ഒരു ഉപകരണം എഴുതാം, ഉദാഹരണത്തിന്, പോലെ ഇത്, കമാൻഡ് റിസോഴ്സുകളുടെ അവസ്ഥ സംഭരിക്കാനും പ്രതിജ്ഞാബദ്ധമാക്കാനും കഴിയും.

2. മികച്ച ഫയൽ സംഭരണം തിരഞ്ഞെടുക്കുക

പെർസിസ്റ്റന്റ് വോള്യങ്ങളുടെ വിഷയവും കുബർനെറ്റസ് വർക്കർ നോഡുകളുടെ ഡിസ്ക് സബ്സിസ്റ്റവും ഇവിടെ സ്പർശിക്കാൻ ഞാൻ ആഗ്രഹിക്കുന്നു. നിർമ്മാണത്തിൽ എച്ച്ഡിഡിയിൽ ആരും "ക്യൂബ്" ഉപയോഗിക്കുന്നില്ലെന്ന് ഞാൻ പ്രതീക്ഷിക്കുന്നു, പക്ഷേ ചിലപ്പോൾ ഒരു സാധാരണ എസ്എസ്ഡി പോലും മതിയാകില്ല. I / O ഓപ്പറേഷനുകൾ വഴി ലോഗുകൾ ഡിസ്കിനെ നശിപ്പിക്കുന്ന ഒരു പ്രശ്നം ഞങ്ങൾ അഭിമുഖീകരിച്ചു, കൂടാതെ ഇവിടെ വളരെയധികം പരിഹാരങ്ങളൊന്നുമില്ല:

• ഉയർന്ന പ്രകടനമുള്ള SSD-കൾ ഉപയോഗിക്കുക അല്ലെങ്കിൽ NVMe-ലേക്ക് മാറുക (നിങ്ങൾ നിങ്ങളുടെ സ്വന്തം ഹാർഡ്‌വെയർ കൈകാര്യം ചെയ്യുകയാണെങ്കിൽ).

• ലോഗിംഗ് ലെവൽ കുറയ്ക്കുക.

• ഡിസ്കിനെ ബലാത്സംഗം ചെയ്യുന്ന പോഡുകളുടെ "സ്മാർട്ട്" ബാലൻസ് ചെയ്യുക (podAntiAffinity).

ആക്‌സസ്_ലോഗുകൾ പ്രവർത്തനക്ഷമമാക്കുമ്പോൾ ഒരു ഡിസ്‌കിനൊപ്പം nginx-ingress-controller-ന് കീഴിൽ എന്താണ് സംഭവിക്കുന്നതെന്ന് മുകളിലുള്ള സ്‌ക്രീൻഷോട്ട് കാണിക്കുന്നു (~12k ലോഗുകൾ/സെക്കൻഡ്). അത്തരമൊരു അവസ്ഥ, തീർച്ചയായും, ഈ നോഡിലെ എല്ലാ ആപ്ലിക്കേഷനുകളുടെയും അപചയത്തിലേക്ക് നയിച്ചേക്കാം.

പിവിയെ സംബന്ധിച്ചിടത്തോളം, അയ്യോ, ഞാൻ എല്ലാം പരീക്ഷിച്ചിട്ടില്ല. തരത്തിലുള്ള സ്ഥിരമായ വോള്യങ്ങൾ. നിങ്ങൾക്ക് അനുയോജ്യമായ ഏറ്റവും മികച്ച ഓപ്ഷൻ ഉപയോഗിക്കുക. സേവനങ്ങളുടെ ഒരു ചെറിയ ഭാഗം RWX വോള്യങ്ങൾ ആവശ്യമാണെന്ന് ചരിത്രപരമായി നമ്മുടെ രാജ്യത്ത് സംഭവിച്ചു, വളരെക്കാലം മുമ്പ് അവർ ഈ ടാസ്ക്കിനായി NFS സംഭരണം ഉപയോഗിക്കാൻ തുടങ്ങി. വിലകുറഞ്ഞതും ... മതി. തീർച്ചയായും, ഞങ്ങൾ അവനോടൊപ്പം ചാണകം കഴിച്ചു - ആരോഗ്യവാനായിരിക്കുക, പക്ഷേ അവനെ എങ്ങനെ ട്യൂൺ ചെയ്യാമെന്ന് ഞങ്ങൾ പഠിച്ചു, അവന്റെ തല ഇനി വേദനിക്കുന്നില്ല. സാധ്യമെങ്കിൽ, S3 ഒബ്ജക്റ്റ് സ്റ്റോറേജിലേക്ക് മാറുക.

3. ഒപ്റ്റിമൈസ് ചെയ്ത ചിത്രങ്ങൾ നിർമ്മിക്കുക

കണ്ടെയ്‌നർ ഒപ്റ്റിമൈസ് ചെയ്‌ത ചിത്രങ്ങൾ ഉപയോഗിക്കുന്നതാണ് നല്ലത്, അതുവഴി കുബർനെറ്റുകൾക്ക് അവ വേഗത്തിൽ ലഭ്യമാക്കാനും കൂടുതൽ കാര്യക്ഷമമായി നടപ്പിലാക്കാനും കഴിയും. 

ഒപ്റ്റിമൈസേഷൻ അർത്ഥമാക്കുന്നത് ചിത്രങ്ങൾ:

• ഒരു ആപ്ലിക്കേഷൻ മാത്രം ഉൾക്കൊള്ളുക അല്ലെങ്കിൽ ഒരു പ്രവർത്തനം മാത്രം ചെയ്യുക;

• ചെറിയ വലിപ്പം, കാരണം വലിയ ചിത്രങ്ങൾ നെറ്റ്‌വർക്കിലൂടെ മോശമായി കൈമാറ്റം ചെയ്യപ്പെടുന്നു;

• പ്രവർത്തനരഹിതമായ സാഹചര്യത്തിൽ നടപടിയെടുക്കാൻ കുബർനെറ്റുകൾക്ക് ഉപയോഗിക്കാവുന്ന ആരോഗ്യവും സന്നദ്ധതയും അവസാന പോയിന്റുകൾ ഉണ്ടായിരിക്കുക;

• കോൺഫിഗറേഷൻ പിശകുകളെ കൂടുതൽ പ്രതിരോധിക്കുന്ന കണ്ടെയ്നർ-ഫ്രണ്ട്ലി ഓപ്പറേറ്റിംഗ് സിസ്റ്റങ്ങൾ (ആൽപൈൻ അല്ലെങ്കിൽ CoreOS പോലുള്ളവ) ഉപയോഗിക്കുക;

• മൾട്ടി-സ്റ്റേജ് ബിൽഡുകൾ ഉപയോഗിക്കുന്നതിലൂടെ നിങ്ങൾക്ക് കംപൈൽ ചെയ്ത ആപ്ലിക്കേഷനുകൾ മാത്രമേ വിന്യസിക്കാൻ കഴിയൂ, അനുബന്ധ ഉറവിടങ്ങളല്ല.

ഫ്ലൈയിൽ ചിത്രങ്ങൾ പരിശോധിക്കാനും ഒപ്റ്റിമൈസ് ചെയ്യാനും നിങ്ങളെ അനുവദിക്കുന്ന നിരവധി ഉപകരണങ്ങളും സേവനങ്ങളും ഉണ്ട്. അവ എല്ലായ്പ്പോഴും കാലികമായും സുരക്ഷിതമായും സൂക്ഷിക്കേണ്ടത് പ്രധാനമാണ്. ഫലമായി, നിങ്ങൾക്ക് ലഭിക്കും:

1. മുഴുവൻ ക്ലസ്റ്ററിലും നെറ്റ്‌വർക്ക് ലോഡ് കുറച്ചു.

2. കണ്ടെയ്നർ സ്റ്റാർട്ടപ്പ് സമയം കുറച്ചു.

3. നിങ്ങളുടെ മുഴുവൻ ഡോക്കർ രജിസ്ട്രിയുടെയും ചെറിയ വലിപ്പം.

4. ഒരു DNS കാഷെ ഉപയോഗിക്കുക

നമ്മൾ ഉയർന്ന ലോഡുകളെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ, ക്ലസ്റ്ററിന്റെ DNS സിസ്റ്റം ട്യൂൺ ചെയ്യാതെ, ജീവിതം വളരെ മോശമാണ്. ഒരു കാലത്ത്, കുബർനെറ്റസ് ഡെവലപ്പർമാർ അവരുടെ kube-dns സൊല്യൂഷനെ പിന്തുണച്ചിരുന്നു. ഇത് നമ്മുടെ രാജ്യത്തും നടപ്പിലാക്കിയിട്ടുണ്ട്, എന്നാൽ ഈ സോഫ്റ്റ്വെയർ പ്രത്യേകിച്ച് ട്യൂൺ ചെയ്തില്ല, ആവശ്യമായ പ്രകടനം നൽകിയില്ല, എന്നിരുന്നാലും, ചുമതല ലളിതമാണെന്ന് തോന്നുന്നു. അപ്പോൾ coredns പ്രത്യക്ഷപ്പെട്ടു, അതിലേക്ക് ഞങ്ങൾ മാറി, സങ്കടം അറിഞ്ഞില്ല, പിന്നീട് അത് K8 കളിലെ സ്ഥിരസ്ഥിതി DNS സേവനമായി മാറി. ചില ഘട്ടങ്ങളിൽ, ഞങ്ങൾ ഡിഎൻഎസ് സിസ്റ്റത്തിലേക്ക് 40 ആയിരം ആർപിഎസ് വരെ വളർന്നു, ഈ പരിഹാരവും പര്യാപ്തമല്ല. പക്ഷേ, ഒരു ഭാഗ്യവശാൽ, Nodelocaldns പുറത്തുവന്നു, അല്ലെങ്കിൽ നോഡ് ലോക്കൽ കാഷെ നോഡ്ലോക്കൽ DNSCache.

നമ്മൾ എന്തിനാണ് അത് ഉപയോഗിക്കുന്നത്? ലിനക്‌സ് കേർണലിൽ ഒരു ബഗ് ഉണ്ട്, UDP വഴിയുള്ള കോൺട്രാക്ക് NAT വഴി ഒന്നിലധികം ആക്‌സസ്സ് ചെയ്യുമ്പോൾ, കോൺട്രാക്ക് ടേബിളുകളിലേക്ക് എഴുതുന്നതിനുള്ള ഒരു റേസ് അവസ്ഥയിലേക്ക് നയിക്കുകയും NAT വഴിയുള്ള ട്രാഫിക്കിന്റെ ഒരു ഭാഗം നഷ്ടപ്പെടുകയും ചെയ്യുന്നു (സേവനത്തിലൂടെയുള്ള ഓരോ യാത്രയും NAT ആണ്). NAT ഒഴിവാക്കി അപ്‌സ്ട്രീം DNS-ലേക്ക് TCP കണക്റ്റിവിറ്റിയിലേക്ക് അപ്‌ഗ്രേഡ് ചെയ്യുന്നതിലൂടെയും അപ്‌സ്ട്രീം DNS അന്വേഷണങ്ങൾ പ്രാദേശികമായി കാഷെ ചെയ്യുന്നതിലൂടെയും Nodelocaldns ഈ പ്രശ്നം പരിഹരിക്കുന്നു (ഒരു ചെറിയ 5 സെക്കൻഡ് നെഗറ്റീവ് കാഷെ ഉൾപ്പെടെ).

5. പോഡുകൾ തിരശ്ചീനമായും ലംബമായും യാന്ത്രികമായി സ്കെയിൽ ചെയ്യുക

നിങ്ങളുടെ എല്ലാ മൈക്രോസർവീസുകളും ലോഡിൽ രണ്ടോ മൂന്നോ മടങ്ങ് വർദ്ധനവിന് തയ്യാറാണെന്ന് നിങ്ങൾക്ക് ആത്മവിശ്വാസത്തോടെ പറയാൻ കഴിയുമോ? നിങ്ങളുടെ ആപ്ലിക്കേഷനുകളിലേക്ക് ഉറവിടങ്ങൾ എങ്ങനെ ശരിയായി വിനിയോഗിക്കാം? ജോലിഭാരത്തേക്കാൾ അധികമായി രണ്ട് പോഡുകൾ പ്രവർത്തിപ്പിക്കുന്നത് അനാവശ്യമാണ്, കൂടാതെ അവ തിരികെ സൂക്ഷിക്കുന്നത് സേവനത്തിലേക്കുള്ള തിരക്ക് പെട്ടെന്ന് വർദ്ധിക്കുന്നത് അപകടസമയത്തിന് കാരണമാകും. സുവർണ്ണ ശരാശരി ഗുണനത്തിന്റെ സ്പെൽ നേടാൻ സഹായിക്കുന്നു അത്തരം സേവനങ്ങൾ തിരശ്ചീന പോഡ് ഓട്ടോസ്കെയിലർ и ലംബ പോഡ് ഓട്ടോസ്കെയിലർ.

വി.പി.എ യഥാർത്ഥ ഉപയോഗത്തെ അടിസ്ഥാനമാക്കി ഒരു പോഡിൽ നിങ്ങളുടെ കണ്ടെയ്‌നറുകളുടെ അഭ്യർത്ഥനകൾ/പരിധികൾ സ്വയമേവ ഉയർത്താൻ നിങ്ങളെ അനുവദിക്കുന്നു. അത് എങ്ങനെ ഉപയോഗപ്രദമാകും? ചില കാരണങ്ങളാൽ തിരശ്ചീനമായി സ്കെയിൽ ചെയ്യാൻ കഴിയാത്ത പോഡുകൾ നിങ്ങളുടെ പക്കലുണ്ടെങ്കിൽ (അത് പൂർണ്ണമായും വിശ്വസനീയമല്ല), തുടർന്ന് അതിന്റെ ഉറവിടങ്ങൾ മാറ്റാൻ നിങ്ങൾക്ക് VPA-യെ വിശ്വസിക്കാൻ ശ്രമിക്കാം. മെട്രിക്-സെർവറിൽ നിന്നുള്ള ചരിത്രപരവും നിലവിലുള്ളതുമായ ഡാറ്റയെ അടിസ്ഥാനമാക്കിയുള്ള ഒരു ശുപാർശ സംവിധാനമാണ് ഇതിന്റെ സവിശേഷത, അതിനാൽ നിങ്ങൾക്ക് അഭ്യർത്ഥനകൾ/പരിധികൾ സ്വയമേവ മാറ്റാൻ താൽപ്പര്യമില്ലെങ്കിൽ, നിങ്ങളുടെ കണ്ടെയ്‌നറുകൾക്കായി ശുപാർശ ചെയ്‌ത ഉറവിടങ്ങൾ നിരീക്ഷിക്കാനും സിപിയുവും മെമ്മറിയും സംരക്ഷിക്കുന്നതിന് ക്രമീകരണങ്ങൾ ഒപ്റ്റിമൈസ് ചെയ്യാനും കഴിയും. ക്ലസ്റ്ററിൽ.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 എന്നതിൽ നിന്ന് എടുത്ത ചിത്രം

കുബർനെറ്റസിലെ ഷെഡ്യൂളർ എല്ലായ്പ്പോഴും അഭ്യർത്ഥനകളെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്. നിങ്ങൾ അവിടെ എന്ത് മൂല്യം നൽകിയാലും, ഷെഡ്യൂളർ അതിനെ അടിസ്ഥാനമാക്കി അനുയോജ്യമായ ഒരു നോഡിനായി നോക്കും. ഒരു പോഡ് എപ്പോൾ ത്രോട്ടിൽ ചെയ്യണം അല്ലെങ്കിൽ കൊല്ലണം എന്നറിയാൻ കുബ്ലെറ്റിന് പരിധി മൂല്യം ആവശ്യമാണ്. അഭ്യർത്ഥനകളുടെ മൂല്യം മാത്രമാണ് പ്രധാന പാരാമീറ്റർ എന്നതിനാൽ, VPA അതുമായി പ്രവർത്തിക്കും. നിങ്ങളുടെ ആപ്ലിക്കേഷൻ ലംബമായി സ്കെയിൽ ചെയ്യുമ്പോഴെല്ലാം, അഭ്യർത്ഥനകൾ എന്തായിരിക്കണമെന്ന് നിങ്ങൾ നിർവ്വചിക്കുന്നു. അപ്പോൾ പരിധികൾക്ക് എന്ത് സംഭവിക്കും? ഈ പരാമീറ്ററും ആനുപാതികമായി സ്കെയിൽ ചെയ്യപ്പെടും.

ഉദാഹരണത്തിന്, സാധാരണ പോഡ് ക്രമീകരണങ്ങൾ ഇതാ:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

നിങ്ങളുടെ ആപ്ലിക്കേഷന് ശരിയായി പ്രവർത്തിക്കാൻ 300m CPU ഉം 500Mi ഉം ആവശ്യമാണെന്ന് ശുപാർശ എഞ്ചിൻ നിർണ്ണയിക്കുന്നു. നിങ്ങൾക്ക് ഈ ക്രമീകരണങ്ങൾ ലഭിക്കും:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, ഇത് മാനിഫെസ്റ്റിലെ അഭ്യർത്ഥനകൾ/പരിധി അനുപാതം അടിസ്ഥാനമാക്കിയുള്ള ആനുപാതിക സ്കെയിലിംഗ് ആണ്:

• CPU: 200m → 300m: അനുപാതം 1:1.75;

• മെമ്മറി: 250Mi → 500Mi: 1:2 അനുപാതം.

ഇതിനെ കുറിച്ച് HPA, അപ്പോൾ പ്രവർത്തനത്തിന്റെ സംവിധാനം കൂടുതൽ സുതാര്യമാണ്. പ്രോസസ്സറും മെമ്മറിയും പോലുള്ള മെട്രിക്‌സുകൾക്കായി ത്രെഷോൾഡുകൾ സജ്ജീകരിച്ചിരിക്കുന്നു, കൂടാതെ എല്ലാ പകർപ്പുകളുടെയും ശരാശരി ത്രെഷോൾഡ് കവിയുന്നുവെങ്കിൽ, മൂല്യം പരിധിക്ക് താഴെയാകുന്നതുവരെയോ അല്ലെങ്കിൽ പരമാവധി പകർപ്പുകളുടെ എണ്ണം എത്തുന്നതുവരെയോ ആപ്ലിക്കേഷൻ സ്കെയിലുകൾ +1 പോഡ് വഴി മാറുന്നു.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 എന്നതിൽ നിന്ന് എടുത്ത ചിത്രം

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

6. നോഡ് അഫിനിറ്റി, പോഡ് അഫിനിറ്റി എന്നിവയെക്കുറിച്ച് മറക്കരുത്

എല്ലാ നോഡുകളും ഒരേ ഹാർഡ്‌വെയറിൽ പ്രവർത്തിക്കുന്നില്ല, കൂടാതെ എല്ലാ പോഡുകൾക്കും കമ്പ്യൂട്ട്-ഇന്റൻസീവ് ആപ്ലിക്കേഷനുകൾ പ്രവർത്തിപ്പിക്കേണ്ടതില്ല. ഉപയോഗിക്കുന്ന നോഡുകളുടെയും പോഡുകളുടെയും സ്പെഷ്യലൈസേഷൻ വ്യക്തമാക്കാൻ Kubernetes നിങ്ങളെ അനുവദിക്കുന്നു നോഡ് അഫിനിറ്റി и പോഡ് അഫിനിറ്റി.

നിങ്ങൾക്ക് കമ്പ്യൂട്ട്-ഇന്റൻസീവ് പ്രവർത്തനങ്ങൾക്ക് അനുയോജ്യമായ നോഡുകൾ ഉണ്ടെങ്കിൽ, പരമാവധി കാര്യക്ഷമതയ്ക്കായി, ആപ്ലിക്കേഷനുകൾ ഉചിതമായ നോഡുകളിലേക്ക് ബന്ധിപ്പിക്കുന്നതാണ് നല്ലത്. ഇത് ചെയ്യുന്നതിന്, ഉപയോഗിക്കുക nodeSelector നോഡ് ലേബലിനൊപ്പം.

നിങ്ങൾക്ക് രണ്ട് നോഡുകൾ ഉണ്ടെന്ന് പറയാം: ഒന്ന് CPUType=HIGHFREQ ഒരു വലിയ സംഖ്യ ഫാസ്റ്റ് കോറുകൾ, മറ്റൊന്ന് MemoryType=HIGHMEMORY കൂടുതൽ മെമ്മറിയും വേഗത്തിലുള്ള പ്രകടനവും. ഒരു നോഡിലേക്ക് ഒരു പോഡ് വിന്യാസം അസൈൻ ചെയ്യുക എന്നതാണ് ഏറ്റവും എളുപ്പമുള്ള മാർഗം HIGHFREQവിഭാഗത്തിലേക്ക് ചേർത്തുകൊണ്ട് spec ഇതുപോലുള്ള ഒരു സെലക്ടർ:

…
nodeSelector:
	CPUType: HIGHFREQ

ഇത് ചെയ്യുന്നതിന് കൂടുതൽ ചെലവേറിയതും നിർദ്ദിഷ്ടവുമായ മാർഗ്ഗം ഉപയോഗിക്കുക എന്നതാണ് nodeAffinity വയലിൽ affinity എ spec. രണ്ട് ഓപ്ഷനുകൾ ഉണ്ട്:

• requiredDuringSchedulingIgnoredDuringExecution: ഹാർഡ് സെറ്റിംഗ് (ഷെഡ്യൂളർ നിർദ്ദിഷ്ട നോഡുകളിൽ മാത്രമേ പോഡുകൾ വിന്യസിക്കുകയുള്ളൂ (മറ്റൊരിടത്തും ഇല്ല));

• preferredDuringSchedulingIgnoredDuringExecution: സോഫ്റ്റ് ക്രമീകരണം (നിർദ്ദിഷ്‌ട നോഡുകളിലേക്ക് വിന്യസിക്കാൻ ഷെഡ്യൂളർ ശ്രമിക്കും, അത് പരാജയപ്പെട്ടാൽ, ലഭ്യമായ അടുത്ത നോഡിലേക്ക് വിന്യസിക്കാൻ ശ്രമിക്കും).

നോഡ് ലേബലുകൾ കൈകാര്യം ചെയ്യുന്നതിനായി നിങ്ങൾക്ക് ഒരു നിർദ്ദിഷ്ട വാക്യഘടന വ്യക്തമാക്കാൻ കഴിയും, ഉദാഹരണത്തിന്, In, NotIn, Exists, DoesNotExist, Gt അഥവാ Lt. എന്നിരുന്നാലും, ലേബലുകളുടെ നീണ്ട ലിസ്റ്റുകളിലെ സങ്കീർണ്ണമായ രീതികൾ നിർണായക സാഹചര്യങ്ങളിൽ തീരുമാനമെടുക്കുന്നത് മന്ദഗതിയിലാക്കുമെന്ന് ഓർക്കുക. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, കൂടുതൽ സങ്കീർണ്ണമാക്കരുത്.

മുകളിൽ സൂചിപ്പിച്ചതുപോലെ, നിലവിലെ പോഡുകളുടെ ബൈൻഡിംഗ് സജ്ജമാക്കാൻ Kubernetes നിങ്ങളെ അനുവദിക്കുന്നു. അതായത്, ഒരേ ലഭ്യത മേഖലയിൽ (മേഘങ്ങൾക്ക് പ്രസക്തമായത്) അല്ലെങ്കിൽ നോഡുകളിൽ ചില പോഡുകൾ മറ്റ് പോഡുകളുമായി ഒരുമിച്ച് പ്രവർത്തിക്കാൻ നിങ്ങൾക്ക് കഴിയും.

В podAffinity ഫീൽഡുകൾ affinity എ spec എന്നതിലെ അതേ ഫീൽഡുകൾ ലഭ്യമാണ് nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. വ്യത്യാസം അത് മാത്രമാണ് matchExpressions ആ ലേബൽ ഉള്ള ഒരു പോഡ് ഇതിനകം പ്രവർത്തിക്കുന്ന ഒരു നോഡിലേക്ക് പോഡുകൾ ബന്ധിപ്പിക്കും.

കൂടുതൽ കുബർനെറ്റസ് ഒരു ഫീൽഡ് വാഗ്ദാനം ചെയ്യുന്നു podAntiAffinity, വിപരീതമായി, ഒരു പോഡ് പ്രത്യേക പോഡുകളുള്ള ഒരു നോഡുമായി ബന്ധിപ്പിക്കുന്നില്ല.

ആവിഷ്കാരങ്ങളെ കുറിച്ച് nodeAffinity ഒരേ ഉപദേശം നൽകാം: നിയമങ്ങൾ ലളിതവും യുക്തിസഹവും നിലനിർത്താൻ ശ്രമിക്കുക, സങ്കീർണ്ണമായ നിയമങ്ങൾ ഉപയോഗിച്ച് പോഡ് സ്പെസിഫിക്കേഷൻ ഓവർലോഡ് ചെയ്യാൻ ശ്രമിക്കരുത്. ക്ലസ്റ്ററിന്റെ വ്യവസ്ഥകളുമായി പൊരുത്തപ്പെടാത്ത, ഷെഡ്യൂളറിൽ അധിക ലോഡ് ഇടുകയും മൊത്തത്തിലുള്ള പ്രകടനത്തെ തരംതാഴ്ത്തുകയും ചെയ്യുന്ന ഒരു നിയമം സൃഷ്ടിക്കുന്നത് വളരെ എളുപ്പമാണ്.

7. കളങ്കങ്ങളും സഹിഷ്ണുതകളും

ഷെഡ്യൂളർ നിയന്ത്രിക്കാൻ മറ്റൊരു മാർഗമുണ്ട്. നിങ്ങൾക്ക് നൂറുകണക്കിന് നോഡുകളും ആയിരക്കണക്കിന് മൈക്രോസർവീസുകളുമുള്ള ഒരു വലിയ ക്ലസ്റ്റർ ഉണ്ടെങ്കിൽ, ചില പോഡുകൾ ചില നോഡുകൾ ഹോസ്റ്റുചെയ്യുന്നത് തടയുന്നത് വളരെ ബുദ്ധിമുട്ടാണ്.

കളങ്കങ്ങളുടെ സംവിധാനം - നിരോധിക്കുന്ന നിയമങ്ങൾ - ഇത് സഹായിക്കുന്നു. ഉദാഹരണത്തിന്, ചില സാഹചര്യങ്ങളിൽ ചില നോഡുകൾ പ്രവർത്തിക്കുന്നതിൽ നിന്ന് നിങ്ങൾക്ക് തടയാനാകും. ഒരു നിർദ്ദിഷ്‌ട നോഡിൽ കളങ്കം പ്രയോഗിക്കുന്നതിന്, ഓപ്ഷൻ ഉപയോഗിക്കുക taint kubectl ൽ. കീയും മൂല്യവും വ്യക്തമാക്കുക, തുടർന്ന് ലൈക്ക് കളയുക NoSchedule അഥവാ NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

ടെയിൻറ് മെക്കാനിസം മൂന്ന് പ്രധാന ഇഫക്റ്റുകളെ പിന്തുണയ്ക്കുന്നുവെന്നതും ശ്രദ്ധിക്കേണ്ടതാണ്: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule പോഡ് സ്പെസിഫിക്കേഷനിൽ അനുബന്ധ എൻട്രി ഉണ്ടാകുന്നതുവരെ എന്നാണ് അർത്ഥമാക്കുന്നത് tolerations, ഇത് നോഡിലേക്ക് വിന്യസിക്കാൻ കഴിയില്ല (ഈ ഉദാഹരണത്തിൽ node10).

• PreferNoSchedule - ലളിതമാക്കിയ പതിപ്പ് NoSchedule. ഈ സാഹചര്യത്തിൽ, പൊരുത്തപ്പെടുന്ന എൻട്രി ഇല്ലാത്ത പോഡുകൾ അനുവദിക്കാതിരിക്കാൻ ഷെഡ്യൂളർ ശ്രമിക്കും. tolerations ഓരോ നോഡിനും, എന്നാൽ ഇത് ഒരു ഹാർഡ് പരിധിയല്ല. ക്ലസ്റ്ററിൽ ഉറവിടങ്ങളൊന്നും ഇല്ലെങ്കിൽ, ഈ നോഡിൽ പോഡുകൾ വിന്യസിക്കാൻ തുടങ്ങും.

• NoExecute - ഈ പ്രഭാവം പൊരുത്തപ്പെടുന്ന എൻട്രി ഇല്ലാത്ത പോഡുകളുടെ ഉടനടി ഒഴിപ്പിക്കാൻ പ്രേരിപ്പിക്കുന്നു tolerations.

കൗതുകകരമെന്നു പറയട്ടെ, ടോളറേഷൻസ് മെക്കാനിസം ഉപയോഗിച്ച് ഈ സ്വഭാവം പഴയപടിയാക്കാനാകും. ഒരു "വിലക്കപ്പെട്ട" നോഡ് ഉള്ളപ്പോൾ ഇത് സൗകര്യപ്രദമാണ്, നിങ്ങൾ അതിൽ ഇൻഫ്രാസ്ട്രക്ചർ സേവനങ്ങൾ മാത്രം സ്ഥാപിക്കേണ്ടതുണ്ട്. ഇത് എങ്ങനെ ചെയ്യാം? അനുയോജ്യമായ ടോളറൻസ് ഉള്ള കായ്കൾ മാത്രം അനുവദിക്കുക.

പോഡ് സ്പെക് എങ്ങനെയായിരിക്കുമെന്ന് ഇതാ:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

അടുത്ത പുനർവിന്യാസ സമയത്ത്, പോഡ് ഈ നോഡിൽ കൃത്യമായി അടിക്കുമെന്ന് ഇതിനർത്ഥമില്ല, ഇത് നോഡ് അഫിനിറ്റി മെക്കാനിസമല്ല. nodeSelector. എന്നാൽ നിരവധി സവിശേഷതകൾ സംയോജിപ്പിക്കുന്നതിലൂടെ, നിങ്ങൾക്ക് വളരെ ഫ്ലെക്സിബിൾ ഷെഡ്യൂളർ സജ്ജീകരണം നേടാനാകും.

8. പോഡ് വിന്യാസ മുൻഗണന സജ്ജമാക്കുക

നിങ്ങൾ പോഡ്-ടു-നോഡ് ബൈൻഡിംഗുകൾ കോൺഫിഗർ ചെയ്‌തതിനാൽ എല്ലാ പോഡുകളും ഒരേ മുൻഗണനയോടെ പരിഗണിക്കണമെന്ന് അർത്ഥമാക്കുന്നില്ല. ഉദാഹരണത്തിന്, മറ്റുള്ളവയ്ക്ക് മുമ്പായി ചില പോഡുകൾ വിന്യസിക്കാൻ നിങ്ങൾ ആഗ്രഹിച്ചേക്കാം.

Pod Priority ഉം Preemption ഉം സജ്ജമാക്കാൻ Kubernetes വ്യത്യസ്ത വഴികൾ വാഗ്ദാനം ചെയ്യുന്നു. ക്രമീകരണം നിരവധി ഭാഗങ്ങൾ ഉൾക്കൊള്ളുന്നു: ഒബ്ജക്റ്റ് PriorityClass ഫീൽഡ് വിവരണങ്ങളും priorityClassName പോഡ് സ്പെസിഫിക്കേഷനിൽ. ഒരു ഉദാഹരണം പരിഗണിക്കുക:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

ഞങ്ങൾ സൃഷ്ടിക്കുന്നു PriorityClass, അതിന് ഒരു പേരും വിവരണവും മൂല്യവും നൽകുക. ഉയർന്നത് value, ഉയർന്ന മുൻഗണന. മൂല്യം 32-നേക്കാൾ കുറവോ തുല്യമോ ആയ ഏതെങ്കിലും 1-ബിറ്റ് പൂർണ്ണസംഖ്യയായിരിക്കാം. ഉയർന്ന മൂല്യങ്ങൾ മിഷൻ-ക്രിട്ടിക്കൽ സിസ്റ്റം പോഡുകൾക്കായി നീക്കിവച്ചിരിക്കുന്നു, അത് സാധാരണഗതിയിൽ മുൻകൈയെടുക്കാൻ കഴിയില്ല. ഉയർന്ന മുൻഗണനയുള്ള പോഡിന് തിരിയാൻ ഒരിടവുമില്ലെങ്കിൽ മാത്രമേ ഒഴിപ്പിക്കൽ സംഭവിക്കൂ, തുടർന്ന് ഒരു പ്രത്യേക നോഡിൽ നിന്നുള്ള ചില പോഡുകൾ ഒഴിപ്പിക്കപ്പെടും. ഈ സംവിധാനം നിങ്ങൾക്ക് വളരെ കർക്കശമാണെങ്കിൽ, നിങ്ങൾക്ക് ഓപ്ഷൻ ചേർക്കാവുന്നതാണ് preemptionPolicy: Never, തുടർന്ന് മുൻകരുതൽ ഉണ്ടാകില്ല, പോഡ് ക്യൂവിൽ ഒന്നാമനാകുകയും ഷെഡ്യൂളർ അതിനായി സൗജന്യ ഉറവിടങ്ങൾ കണ്ടെത്തുന്നതിനായി കാത്തിരിക്കുകയും ചെയ്യും.

അടുത്തതായി, ഞങ്ങൾ ഒരു പോഡ് സൃഷ്ടിക്കുന്നു, അതിൽ ഞങ്ങൾ പേര് വ്യക്തമാക്കുന്നു priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

നിങ്ങൾക്ക് ഇഷ്‌ടമുള്ളത്ര മുൻഗണനാ ക്ലാസുകൾ സൃഷ്‌ടിക്കാൻ കഴിയും, എന്നിരുന്നാലും ഇത് ഒഴിവാക്കരുതെന്ന് ശുപാർശ ചെയ്‌തിരിക്കുന്നു (പറയുക, താഴ്ന്നതും ഇടത്തരവും ഉയർന്നതുമായ മുൻഗണനയിലേക്ക് സ്വയം പരിമിതപ്പെടുത്തുക).

അതിനാൽ, ആവശ്യമെങ്കിൽ, നിങ്ങൾക്ക് nginx-ingress-controller, coredns മുതലായ നിർണായക സേവനങ്ങൾ വിന്യസിക്കുന്നതിന്റെ കാര്യക്ഷമത വർദ്ധിപ്പിക്കാൻ കഴിയും.

9. നിങ്ങളുടെ ETCD ക്ലസ്റ്റർ ഒപ്റ്റിമൈസ് ചെയ്യുക

ETCDയെ മുഴുവൻ ക്ലസ്റ്ററിന്റെയും തലച്ചോറ് എന്ന് വിളിക്കാം. ഈ ഡാറ്റാബേസിന്റെ പ്രവർത്തനം ഉയർന്ന തലത്തിൽ നിലനിർത്തേണ്ടത് വളരെ പ്രധാനമാണ്, കാരണം "ക്യൂബിലെ" പ്രവർത്തനങ്ങളുടെ വേഗത അതിനെ ആശ്രയിച്ചിരിക്കുന്നു. ക്യൂബ്-അപിസർവറിന് ഏറ്റവും കുറഞ്ഞ കാലതാമസം ലഭിക്കുന്നതിന്, മാസ്റ്റർ നോഡുകളിൽ ഒരു ETCD ക്ലസ്റ്റർ സൂക്ഷിക്കുക എന്നതാണ് സാമാന്യം നിലവാരമുള്ളതും അതേ സമയം ഒരു നല്ല പരിഹാരം. ഇത് സാധ്യമല്ലെങ്കിൽ, പങ്കെടുക്കുന്നവർക്കിടയിൽ നല്ല ബാൻഡ്‌വിഡ്ത്ത് ഉപയോഗിച്ച് ETCD കഴിയുന്നത്ര അടുത്ത് വയ്ക്കുക. ക്ലസ്റ്ററിന് ദോഷം വരുത്താതെ ETCD-യിൽ നിന്ന് എത്ര നോഡുകൾ വീഴുമെന്നതും ശ്രദ്ധിക്കുക.

ക്ലസ്റ്ററിലെ പങ്കാളികളുടെ എണ്ണത്തിൽ അമിതമായ വർദ്ധനവ് പ്രകടനത്തിന്റെ ചെലവിൽ തെറ്റ് സഹിഷ്ണുത വർദ്ധിപ്പിക്കുമെന്ന് ഓർമ്മിക്കുക, എല്ലാം മോഡറേഷനിൽ ആയിരിക്കണം.

ഞങ്ങൾ സേവനം സജ്ജീകരിക്കുന്നതിനെക്കുറിച്ച് സംസാരിക്കുകയാണെങ്കിൽ, കുറച്ച് ശുപാർശകൾ ഉണ്ട്:

1. ക്ലസ്റ്ററിന്റെ വലുപ്പത്തെ അടിസ്ഥാനമാക്കി നല്ല ഹാർഡ്‌വെയർ ഉണ്ടായിരിക്കുക (നിങ്ങൾക്ക് വായിക്കാൻ കഴിയും ഇവിടെ).

2. നിങ്ങൾ ഒരു ജോടി DC-കൾ അല്ലെങ്കിൽ നിങ്ങളുടെ നെറ്റ്‌വർക്കുകൾക്കിടയിൽ ഒരു ക്ലസ്റ്റർ സ്‌പ്രെഡ് ചെയ്‌തിട്ടുണ്ടെങ്കിൽ, കുറച്ച് പാരാമീറ്ററുകൾ മാറ്റുക, കൂടാതെ ഡിസ്‌കുകൾ ആവശ്യമുള്ളത് വളരെ അവശേഷിക്കുന്നു (നിങ്ങൾക്ക് വായിക്കാൻ കഴിയും ഇവിടെ).

തീരുമാനം

ഈ ലേഖനം ഞങ്ങളുടെ ടീം പാലിക്കാൻ ശ്രമിക്കുന്ന പോയിന്റുകൾ വിവരിക്കുന്നു. ഇത് പ്രവർത്തനങ്ങളുടെ ഘട്ടം ഘട്ടമായുള്ള വിവരണമല്ല, ഒരു ക്ലസ്റ്ററിന്റെ ഓവർഹെഡ് ഒപ്റ്റിമൈസ് ചെയ്യാൻ ഉപയോഗപ്രദമാകുന്ന ഓപ്ഷനുകൾ. ഓരോ ക്ലസ്റ്ററും അതിന്റേതായ രീതിയിൽ അദ്വിതീയമാണെന്ന് വ്യക്തമാണ്, ട്യൂണിംഗ് പരിഹാരങ്ങൾ വളരെയധികം വ്യത്യാസപ്പെടാം, അതിനാൽ നിങ്ങളിൽ നിന്ന് ഫീഡ്‌ബാക്ക് ലഭിക്കുന്നത് രസകരമായിരിക്കും: നിങ്ങളുടെ കുബർനെറ്റസ് ക്ലസ്റ്ററിനെ നിങ്ങൾ എങ്ങനെ നിരീക്ഷിക്കുന്നു, അതിന്റെ പ്രകടനം എങ്ങനെ മെച്ചപ്പെടുത്താം. അഭിപ്രായങ്ങളിൽ നിങ്ങളുടെ അനുഭവം പങ്കിടുക, അത് അറിയുന്നത് രസകരമായിരിക്കും.

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