Kubernetes ഉപയോഗിക്കുമ്പോൾ 10 സാധാരണ തെറ്റുകൾ

കുറിപ്പ്. വിവർത്തനം.: ഈ ലേഖനത്തിന്റെ രചയിതാക്കൾ ഒരു ചെറിയ ചെക്ക് കമ്പനിയായ പൈപ്പ്‌ടെയിലിൽ നിന്നുള്ള എഞ്ചിനീയർമാരാണ്. കുബെർനെറ്റസ് ക്ലസ്റ്ററുകളുടെ പ്രവർത്തനവുമായി ബന്ധപ്പെട്ട വളരെ ഗുരുതരമായ പ്രശ്‌നങ്ങളുടെയും തെറ്റിദ്ധാരണകളുടെയും [ചിലപ്പോൾ നിസാരവും എന്നാൽ ഇപ്പോഴും] ഒരു അത്ഭുതകരമായ പട്ടിക തയ്യാറാക്കാൻ അവർക്ക് കഴിഞ്ഞു.

കുബർനെറ്റസ് ഉപയോഗിക്കുന്ന വർഷങ്ങളിൽ, ഞങ്ങൾ ധാരാളം ക്ലസ്റ്ററുകളിൽ (നിയന്ത്രിതവും കൈകാര്യം ചെയ്യാത്തതും - GCP, AWS, Azure എന്നിവയിൽ) പ്രവർത്തിച്ചിട്ടുണ്ട്. കാലക്രമേണ, ചില തെറ്റുകൾ നിരന്തരം ആവർത്തിക്കുന്നത് ഞങ്ങൾ ശ്രദ്ധിക്കാൻ തുടങ്ങി. എന്നിരുന്നാലും, ഇതിൽ ലജ്ജയില്ല: അവയിൽ മിക്കതും ഞങ്ങൾ സ്വയം ചെയ്തു!

ലേഖനത്തിൽ ഏറ്റവും സാധാരണമായ പിശകുകൾ അടങ്ങിയിരിക്കുന്നു, അവ എങ്ങനെ ശരിയാക്കാമെന്നും പരാമർശിക്കുന്നു.

1. വിഭവങ്ങൾ: അഭ്യർത്ഥനകളും പരിധികളും

ഈ ഇനം തീർച്ചയായും ഏറ്റവും അടുത്ത ശ്രദ്ധയ്ക്കും പട്ടികയിലെ ഒന്നാം സ്ഥാനത്തിനും അർഹമാണ്.

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

നല്ല ശ്രമം (അങ്ങേയറ്റം അല്ല ശുപാർശ ചെയ്ത):

resources: {}

വളരെ കുറഞ്ഞ CPU അഭ്യർത്ഥന (അങ്ങേയറ്റം അല്ല ശുപാർശ ചെയ്ത):

   resources:
      Requests:
        cpu: "1m"

മറുവശത്ത്, ഒരു സിപിയു പരിധിയുടെ സാന്നിധ്യം, നോഡിന്റെ പ്രോസസർ പൂർണ്ണമായി ലോഡുചെയ്‌തിട്ടില്ലെങ്കിലും, പോഡുകൾ വഴി ക്ലോക്ക് സൈക്കിളുകൾ യുക്തിരഹിതമായി ഒഴിവാക്കുന്നതിന് ഇടയാക്കും. വീണ്ടും, ഇത് വർദ്ധിച്ച കാലതാമസത്തിന് ഇടയാക്കും. പരാമീറ്ററിനെ ചുറ്റിപ്പറ്റിയുള്ള തർക്കങ്ങൾ തുടരുന്നു CPU CFS ക്വാട്ട Linux കേർണലിലും CPU ത്രോട്ടിലിംഗിലും സെറ്റ് പരിധികളെ ആശ്രയിച്ച്, അതുപോലെ CFS ക്വാട്ട പ്രവർത്തനരഹിതമാക്കുന്നു... അയ്യോ, CPU പരിധികൾ പരിഹരിക്കാൻ കഴിയുന്നതിനേക്കാൾ കൂടുതൽ പ്രശ്നങ്ങൾ ഉണ്ടാക്കും. ഇതിനെക്കുറിച്ചുള്ള കൂടുതൽ വിവരങ്ങൾ ചുവടെയുള്ള ലിങ്കിൽ കാണാം.

അമിതമായ തിരഞ്ഞെടുപ്പ് (അമിതമായി പ്രവർത്തിക്കുന്ന) മെമ്മറി പ്രശ്നങ്ങൾ വലിയ പ്രശ്നങ്ങളിലേക്ക് നയിച്ചേക്കാം. CPU പരിധിയിലെത്തുന്നത് ക്ലോക്ക് സൈക്കിളുകൾ ഒഴിവാക്കുന്നു, അതേസമയം മെമ്മറി പരിധിയിലെത്തുന്നത് പോഡ് "കൊല്ലൽ" ആണ്. നിങ്ങൾ എപ്പോഴെങ്കിലും നിരീക്ഷിച്ചിട്ടുണ്ടോ OOMkill? അതെ, നമ്മൾ സംസാരിക്കുന്നത് അത് തന്നെയാണ്.

ഇത് സംഭവിക്കാനുള്ള സാധ്യത കുറയ്ക്കാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുണ്ടോ? മെമ്മറി അധികമായി അനുവദിക്കരുത്, മെമ്മറി അഭ്യർത്ഥന പരിധിയിലേക്ക് സജ്ജീകരിച്ചുകൊണ്ട് (ചുവടെയുള്ള ഉദാഹരണത്തിലെന്നപോലെ) ഗ്യാരണ്ടിഡ് QoS (സേവനത്തിന്റെ ഗുണനിലവാരം) ഉപയോഗിക്കുക. ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കുക ഹെന്നിംഗ് ജേക്കബ്സ് അവതരണങ്ങൾ (സലാൻഡോയിലെ ലീഡ് എഞ്ചിനീയർ).

പൊട്ടിത്തെറിക്കാവുന്ന (OOMkilled ലഭിക്കാനുള്ള ഉയർന്ന സാധ്യത):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ഗ്യാരണ്ടി:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

ഉറവിടങ്ങൾ സജ്ജീകരിക്കുമ്പോൾ എന്ത് സഹായിക്കും?

സഹായത്തോടെ മെട്രിക്സ്-സെർവർ നിങ്ങൾക്ക് നിലവിലെ സിപിയു റിസോഴ്‌സ് ഉപഭോഗവും പോഡ്‌സ് (അവയ്ക്കുള്ളിലെ കണ്ടെയ്‌നറുകളും) മെമ്മറി ഉപയോഗവും കാണാൻ കഴിയും. മിക്കവാറും, നിങ്ങൾ ഇതിനകം ഇത് ഉപയോഗിക്കുന്നു. ഇനിപ്പറയുന്ന കമാൻഡുകൾ പ്രവർത്തിപ്പിക്കുക:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

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

ലംബ പോഡ് ഓട്ടോസ്കെയിലർ ഇത് അനുവദിക്കുന്നു യാന്ത്രികമാക്കുക ഈ പ്രക്രിയ. ഇത് CPU, മെമ്മറി ഉപയോഗ ചരിത്രം എന്നിവ ട്രാക്ക് ചെയ്യുകയും ഈ വിവരങ്ങളെ അടിസ്ഥാനമാക്കി പുതിയ അഭ്യർത്ഥനകളും പരിധികളും സജ്ജമാക്കുകയും ചെയ്യുന്നു.

കമ്പ്യൂട്ടിംഗ് പവർ കാര്യക്ഷമമായി ഉപയോഗിക്കുന്നത് അത്ര എളുപ്പമുള്ള കാര്യമല്ല. എല്ലാ സമയത്തും ടെട്രിസ് കളിക്കുന്നത് പോലെയാണ് ഇത്. കുറഞ്ഞ ശരാശരി ഉപഭോഗമുള്ള (~10% എന്ന് പറയുക) കമ്പ്യൂട്ട് പവറിന് നിങ്ങൾ വളരെയധികം പണം നൽകുകയാണെങ്കിൽ, AWS Fargate അല്ലെങ്കിൽ Virtual Kubelet അടിസ്ഥാനമാക്കിയുള്ള ഉൽപ്പന്നങ്ങൾ നോക്കാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. അവ ഒരു സെർവർലെസ്സ്/പേ-ഓർ-ഉപയോഗ ബില്ലിംഗ് മോഡലിലാണ് നിർമ്മിച്ചിരിക്കുന്നത്, അത്തരം സാഹചര്യങ്ങളിൽ ഇത് വിലകുറഞ്ഞതായി മാറിയേക്കാം.

2. ലൈവ്നെസ് ആൻഡ് റെഡിനെസ് പ്രോബുകൾ

ഡിഫോൾട്ടായി, കുബെർനെറ്റസിൽ ലൈവ്‌നെസ്, റെഡിനസ് പരിശോധനകൾ പ്രവർത്തനക്ഷമമാക്കിയിട്ടില്ല. ചിലപ്പോൾ അവർ അത് ഓണാക്കാൻ മറക്കുന്നു ...

എന്നാൽ മാരകമായ ഒരു പിശക് സംഭവിച്ചാൽ നിങ്ങൾക്ക് മറ്റെങ്ങനെ ഒരു സേവനം പുനരാരംഭിക്കാൻ കഴിയും? ഒരു പോഡ് ട്രാഫിക് സ്വീകരിക്കാൻ തയ്യാറാണെന്ന് ലോഡ് ബാലൻസറിന് എങ്ങനെ അറിയാം? അതോ കൂടുതൽ ട്രാഫിക് കൈകാര്യം ചെയ്യാനാകുമോ?

ഈ പരിശോധനകൾ പലപ്പോഴും പരസ്പരം ആശയക്കുഴപ്പത്തിലാകുന്നു:

• സജീവത - "അതിജീവനം" പരിശോധന, അത് പരാജയപ്പെട്ടാൽ പോഡ് പുനരാരംഭിക്കുന്നു;
• സന്നദ്ധത - സന്നദ്ധത പരിശോധിക്കുക, അത് പരാജയപ്പെടുകയാണെങ്കിൽ, അത് കുബർനെറ്റസ് സേവനത്തിൽ നിന്ന് പോഡ് വിച്ഛേദിക്കുന്നു (ഇത് ഉപയോഗിച്ച് പരിശോധിക്കാവുന്നതാണ് kubectl get endpoints) കൂടാതെ അടുത്ത പരിശോധന വിജയകരമായി പൂർത്തിയാകുന്നതുവരെ ട്രാഫിക്കിൽ എത്തിച്ചേരില്ല.

ഈ രണ്ട് പരിശോധനകളും പോഡിന്റെ മുഴുവൻ ജീവിത ചക്രത്തിലും അവതരിപ്പിച്ചത്. ഇത് വളരെ പ്രധാനപെട്ടതാണ്.

റെഡിനെസ് പ്രോബുകൾ സ്റ്റാർട്ടപ്പിൽ മാത്രമേ പ്രവർത്തിപ്പിക്കുകയുള്ളൂ, അതിനാൽ പോഡ് തയ്യാറാണെന്ന് ബാലൻസർക്ക് അറിയാൻ കഴിയും എന്നതാണ് ഒരു പൊതു തെറ്റിദ്ധാരണ (Ready) കൂടാതെ ട്രാഫിക് പ്രോസസ്സ് ചെയ്യാൻ തുടങ്ങാം. എന്നിരുന്നാലും, ഇത് അവരുടെ ഉപയോഗത്തിനുള്ള ഓപ്ഷനുകളിൽ ഒന്ന് മാത്രമാണ്.

പോഡിലെ തിരക്ക് അധികമാണെന്ന് കണ്ടെത്താനുള്ള സാധ്യതയാണ് മറ്റൊന്ന് അത് ഓവർലോഡ് ചെയ്യുന്നു (അല്ലെങ്കിൽ പോഡ് റിസോഴ്സ്-ഇന്റൻസീവ് കണക്കുകൂട്ടലുകൾ നടത്തുന്നു). ഈ സാഹചര്യത്തിൽ, സന്നദ്ധത പരിശോധന സഹായിക്കുന്നു പോഡിലെ ലോഡ് കുറയ്ക്കുകയും "തണുക്കുക". ഭാവിയിൽ ഒരു തയ്യാറെടുപ്പ് പരിശോധന വിജയകരമായി പൂർത്തിയാക്കുന്നത് അനുവദിക്കുന്നു പോഡിലെ ലോഡ് വീണ്ടും വർദ്ധിപ്പിക്കുക. ഈ സാഹചര്യത്തിൽ (റെഡിനസ് ടെസ്റ്റ് പരാജയപ്പെട്ടാൽ), ലൈവ്നെസ് ടെസ്റ്റിന്റെ പരാജയം വളരെ പ്രതികൂലമായിരിക്കും. ആരോഗ്യകരവും കഠിനാധ്വാനവുമുള്ള ഒരു പോഡ് പുനരാരംഭിക്കുന്നത് എന്തുകൊണ്ട്?

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

സാധാരണ ഡിപൻഡൻസികൾ പരാജയപ്പെടുമ്പോൾ രണ്ട് തരത്തിലുള്ള പരിശോധനകളും പരാജയപ്പെടാൻ പാടില്ല, അല്ലാത്തപക്ഷം ഇത് എല്ലാ പോഡുകളുടെയും കാസ്കേഡിംഗ് (ഹിമപാതം പോലെയുള്ള) പരാജയത്തിലേക്ക് നയിക്കും. മറ്റൊരു വാക്കിൽ, സ്വയം ഉപദ്രവിക്കരുത്.

3. ഓരോ HTTP സേവനത്തിനും ലോഡ് ബാലൻസർ

മിക്കവാറും, പുറംലോകത്തേക്ക് കൈമാറാൻ ആഗ്രഹിക്കുന്ന HTTP സേവനങ്ങൾ നിങ്ങളുടെ ക്ലസ്റ്ററിൽ ഉണ്ടായിരിക്കും.

നിങ്ങൾ സേവനം തുറക്കുകയാണെങ്കിൽ type: LoadBalancer, അതിന്റെ കൺട്രോളർ (സേവന ദാതാവിനെ ആശ്രയിച്ച്) ഒരു ബാഹ്യ LoadBalancer നൽകുകയും ചർച്ച നടത്തുകയും ചെയ്യും (L7-ൽ പ്രവർത്തിക്കണമെന്നില്ല, പകരം L4-ൽ പോലും), ഇത് ചെലവിനെ ബാധിച്ചേക്കാം (ബാഹ്യ സ്റ്റാറ്റിക് IPv4 വിലാസം, കമ്പ്യൂട്ടിംഗ് പവർ, ഓരോ സെക്കൻഡ് ബില്ലിംഗ് ) അത്തരം ധാരാളം വിഭവങ്ങൾ സൃഷ്ടിക്കേണ്ടതിന്റെ ആവശ്യകത കാരണം.

ഈ സാഹചര്യത്തിൽ, ഒരു ബാഹ്യ ലോഡ് ബാലൻസർ ഉപയോഗിക്കുന്നത് കൂടുതൽ യുക്തിസഹമാണ്, സേവനങ്ങൾ തുറക്കുന്നു type: NodePort. അല്ലെങ്കിൽ ഇതിലും മികച്ചത്, ഇതുപോലെ എന്തെങ്കിലും വികസിപ്പിക്കുക nginx-ingress-controller (അല്ലെങ്കിൽ ട്രാഫിക്), ആർ മാത്രമായിരിക്കും നോഡ്പോർട്ട് ഒരു എക്‌സ്‌റ്റേണൽ ലോഡ് ബാലൻസറുമായി ബന്ധപ്പെടുത്തിയിരിക്കുന്ന എൻഡ്‌പോയിന്റ്, ക്ലസ്റ്ററിലെ ട്രാഫിക്കിനെ ഇത് ഉപയോഗിച്ച് റൂട്ട് ചെയ്യും പ്രവേശിക്കുക-കുബെർനെറ്റസ് വിഭവങ്ങൾ.

പരസ്പരം ഇടപഴകുന്ന മറ്റ് ഇൻട്രാ-ക്ലസ്റ്റർ (മൈക്രോ) സേവനങ്ങൾക്ക് ഇതുപോലുള്ള സേവനങ്ങൾ ഉപയോഗിച്ച് "ആശയവിനിമയം" ചെയ്യാൻ കഴിയും ClusterIP കൂടാതെ ഡിഎൻഎസ് വഴിയുള്ള ബിൽറ്റ്-ഇൻ സർവീസ് ഡിസ്കവറി മെക്കാനിസവും. അവരുടെ പൊതു DNS/IP ഉപയോഗിക്കരുത്, കാരണം ഇത് ലേറ്റൻസിയെ ബാധിക്കുകയും ക്ലൗഡ് സേവനങ്ങളുടെ വില വർദ്ധിപ്പിക്കുകയും ചെയ്യും.

4. ഒരു ക്ലസ്റ്ററിന്റെ സവിശേഷതകൾ കണക്കിലെടുക്കാതെ ഓട്ടോസ്കെയിലിംഗ്

ഒരു ക്ലസ്റ്ററിലേക്ക് നോഡുകൾ ചേർക്കുകയും അവ നീക്കം ചെയ്യുകയും ചെയ്യുമ്പോൾ, ആ നോഡുകളിലെ സിപിയു ഉപയോഗം പോലുള്ള ചില അടിസ്ഥാന മെട്രിക്‌സിനെ നിങ്ങൾ ആശ്രയിക്കരുത്. പോഡ് ആസൂത്രണം പലതും കണക്കിലെടുക്കണം നിയന്ത്രണങ്ങൾ, പോഡ്‌സ്/നോഡുകളുടെ അഫിനിറ്റി, കളങ്കങ്ങളും ടോളറേഷനുകളും, റിസോഴ്‌സ് അഭ്യർത്ഥനകൾ, QoS മുതലായവ. ഈ സൂക്ഷ്മതകൾ കണക്കിലെടുക്കാത്ത ഒരു ബാഹ്യ ഓട്ടോസ്കെയിലർ ഉപയോഗിക്കുന്നത് പ്രശ്നങ്ങൾക്ക് ഇടയാക്കും.

ഒരു നിശ്ചിത പോഡ് ഷെഡ്യൂൾ ചെയ്യണമെന്ന് സങ്കൽപ്പിക്കുക, എന്നാൽ ലഭ്യമായ എല്ലാ സിപിയു പവറും അഭ്യർത്ഥിച്ചിരിക്കുന്നു/വിഘടിപ്പിക്കുകയും പോഡ് ഒരു അവസ്ഥയിൽ കുടുങ്ങി Pending. ബാഹ്യ ഓട്ടോസ്‌കെയിലർ ശരാശരി നിലവിലെ സിപിയു ലോഡ് കാണുന്നു (അഭ്യർത്ഥിച്ചതല്ല) മാത്രമല്ല വിപുലീകരണം ആരംഭിക്കുന്നില്ല (സ്കെയിൽ ഔട്ട്) - മറ്റൊരു നോഡ് ചേർക്കുന്നില്ല. തൽഫലമായി, ഈ പോഡ് ഷെഡ്യൂൾ ചെയ്യപ്പെടില്ല.

ഈ സാഹചര്യത്തിൽ, റിവേഴ്സ് സ്കെയിലിംഗ് (സ്കെയിൽ-ഇൻ) - ഒരു ക്ലസ്റ്ററിൽ നിന്ന് ഒരു നോഡ് നീക്കംചെയ്യുന്നത് എല്ലായ്പ്പോഴും നടപ്പിലാക്കാൻ കൂടുതൽ ബുദ്ധിമുട്ടാണ്. നിങ്ങൾക്ക് ഒരു സ്റ്റേറ്റ്ഫുൾ പോഡ് ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക (സ്ഥിരമായ സ്റ്റോറേജ് കണക്റ്റുചെയ്തത്). പെർസിസ്റ്റന്റ് വോള്യങ്ങൾ സാധാരണയായി ഉൾപ്പെടുന്നു നിർദ്ദിഷ്ട ലഭ്യത മേഖല കൂടാതെ മേഖലയിൽ ആവർത്തിക്കപ്പെടുന്നില്ല. അതിനാൽ, ഒരു ബാഹ്യ ഓട്ടോസ്‌കെയിലർ ഈ പോഡ് ഉപയോഗിച്ച് ഒരു നോഡ് ഇല്ലാതാക്കുകയാണെങ്കിൽ, ഷെഡ്യൂളറിന് ഈ പോഡ് മറ്റൊരു നോഡിൽ ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയില്ല, കാരണം ഇത് സ്ഥിരമായ സംഭരണം സ്ഥിതിചെയ്യുന്ന ലഭ്യത മേഖലയിൽ മാത്രമേ ഇത് ചെയ്യാൻ കഴിയൂ. പോഡ് സംസ്ഥാനത്ത് കുടുങ്ങിക്കിടക്കും Pending.

കുബർനെറ്റസ് കമ്മ്യൂണിറ്റിയിൽ വളരെ ജനപ്രിയമാണ് ക്ലസ്റ്റർ-ഓട്ടോസ്കെയിലർ. ഇത് ഒരു ക്ലസ്റ്ററിൽ പ്രവർത്തിക്കുന്നു, പ്രധാന ക്ലൗഡ് ദാതാക്കളിൽ നിന്നുള്ള API-കളെ പിന്തുണയ്ക്കുന്നു, എല്ലാ നിയന്ത്രണങ്ങളും കണക്കിലെടുക്കുന്നു, മുകളിൽ പറഞ്ഞ സന്ദർഭങ്ങളിൽ സ്കെയിൽ ചെയ്യാൻ കഴിയും. എല്ലാ സെറ്റ് പരിധികളും നിലനിർത്തിക്കൊണ്ടുതന്നെ ഇത് സ്കെയിൽ-ഇൻ ചെയ്യാനും അതുവഴി പണം ലാഭിക്കാനും കഴിയും (അല്ലെങ്കിൽ അത് ഉപയോഗിക്കാത്ത ശേഷിയിൽ ചെലവഴിക്കും).

5. IAM/RBAC കഴിവുകൾ അവഗണിക്കുന്നു

സ്ഥിരമായ രഹസ്യങ്ങളുള്ള IAM ഉപയോക്താക്കളെ ഉപയോഗിക്കുന്നത് സൂക്ഷിക്കുക മെഷീനുകളും ആപ്ലിക്കേഷനുകളും. റോളുകളും സേവന അക്കൗണ്ടുകളും ഉപയോഗിച്ച് താൽക്കാലിക ആക്‌സസ് സംഘടിപ്പിക്കുക (സേവന അക്കൗണ്ടുകൾ).

ആപ്ലിക്കേഷൻ കോൺഫിഗറേഷനിൽ ആക്‌സസ് കീകൾ (രഹസ്യങ്ങളും) ഹാർഡ്‌കോഡ് ചെയ്‌തിരിക്കുന്നതും ക്ലൗഡ് IAM-ലേക്ക് ആക്‌സസ് ഉണ്ടായിരുന്നിട്ടും രഹസ്യങ്ങളുടെ റൊട്ടേഷൻ അവഗണിക്കുന്നതും ഞങ്ങൾ പലപ്പോഴും അഭിമുഖീകരിക്കുന്നു. ഉചിതമായിടത്ത് ഉപയോക്താക്കൾക്ക് പകരം IAM റോളുകളും സേവന അക്കൗണ്ടുകളും ഉപയോഗിക്കുക.

kube2iam-നെ കുറിച്ച് മറന്ന്, സേവന അക്കൗണ്ടുകൾക്കായുള്ള IAM റോളുകളിലേക്ക് പോകുക (ഇതിൽ വിവരിച്ചിരിക്കുന്നത് പോലെ അതേ പേരിലുള്ള കുറിപ്പ് സ്റ്റെപാൻ വ്രാനി):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ഒരു വ്യാഖ്യാനം. അത്ര ബുദ്ധിമുട്ടുള്ള കാര്യമല്ല, അല്ലേ?

കൂടാതെ, സേവന അക്കൗണ്ടുകളും ഉദാഹരണ പ്രൊഫൈലുകളുടെ പ്രത്യേകാവകാശങ്ങളും അനുവദിക്കരുത് admin и cluster-adminഅവർക്ക് അത് ആവശ്യമില്ലെങ്കിൽ. ഇത് നടപ്പിലാക്കാൻ കുറച്ചുകൂടി ബുദ്ധിമുട്ടാണ്, പ്രത്യേകിച്ച് RBAC K8- കളിൽ, പക്ഷേ തീർച്ചയായും പരിശ്രമിക്കേണ്ടതാണ്.

6. പോഡുകൾക്ക് ഓട്ടോമാറ്റിക് ആന്റി-അഫിനിറ്റിയെ ആശ്രയിക്കരുത്

നിങ്ങൾക്ക് ഒരു നോഡിൽ ചില വിന്യാസത്തിന്റെ മൂന്ന് പകർപ്പുകൾ ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക. നോഡ് വീഴുന്നു, അതോടൊപ്പം എല്ലാ പകർപ്പുകളും. അസുഖകരമായ സാഹചര്യം, അല്ലേ? എന്നാൽ എന്തുകൊണ്ടാണ് എല്ലാ പകർപ്പുകളും ഒരേ നോഡിലുള്ളത്? കുബർനെറ്റസ് ഉയർന്ന ലഭ്യത (HA) നൽകേണ്ടതല്ലേ?!

നിർഭാഗ്യവശാൽ, കുബർനെറ്റസ് ഷെഡ്യൂളർ, സ്വന്തം മുൻകൈയിൽ, പ്രത്യേക നിലനിൽപ്പിന്റെ നിയമങ്ങൾ പാലിക്കുന്നില്ല (ആന്റി അഫിനിറ്റി) കായ്കൾക്കായി. അവ വ്യക്തമായി പ്രസ്താവിക്കേണ്ടതാണ്:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

അത്രയേയുള്ളൂ. ഇപ്പോൾ പോഡുകൾ വ്യത്യസ്ത നോഡുകളിൽ ഷെഡ്യൂൾ ചെയ്യും (ഈ അവസ്ഥ ഷെഡ്യൂളിംഗ് സമയത്ത് മാത്രമേ പരിശോധിക്കൂ, പക്ഷേ അവയുടെ പ്രവർത്തന സമയത്ത് അല്ല - അതിനാൽ requiredDuringSchedulingIgnoredDuringExecution).

ഇവിടെ നമ്മൾ സംസാരിക്കുന്നത് podAntiAffinity വ്യത്യസ്ത നോഡുകളിൽ: topologyKey: "kubernetes.io/hostname", - വ്യത്യസ്ത ലഭ്യത മേഖലകളെ കുറിച്ചല്ല. ഒരു പൂർണ്ണമായ എച്ച്എ നടപ്പിലാക്കാൻ, നിങ്ങൾ ഈ വിഷയത്തിൽ കൂടുതൽ ആഴത്തിൽ കുഴിക്കേണ്ടതുണ്ട്.

7. PodDisruptionBdgets അവഗണിക്കുന്നു

ഒരു കുബർനെറ്റസ് ക്ലസ്റ്ററിൽ നിങ്ങൾക്ക് ഒരു പ്രൊഡക്ഷൻ ലോഡ് ഉണ്ടെന്ന് സങ്കൽപ്പിക്കുക. ആനുകാലികമായി, നോഡുകളും ക്ലസ്റ്ററും തന്നെ അപ്‌ഡേറ്റ് ചെയ്യേണ്ടതുണ്ട് (അല്ലെങ്കിൽ ഡീകമ്മീഷൻ ചെയ്യണം). PodDisruptionBudget (PDB) എന്നത് ക്ലസ്റ്റർ അഡ്മിനിസ്ട്രേറ്റർമാരും ഉപയോക്താക്കളും തമ്മിലുള്ള ഒരു സേവന ഗ്യാരണ്ടി കരാർ പോലെയാണ്.

നോഡുകളുടെ അഭാവം മൂലമുണ്ടാകുന്ന സേവന തടസ്സങ്ങൾ ഒഴിവാക്കാൻ PDB നിങ്ങളെ അനുവദിക്കുന്നു:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

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

നിങ്ങൾക്ക് ഇതിനെക്കുറിച്ച് കൂടുതൽ വായിക്കാം ഇവിടെ.

8. ഒരു പൊതു ക്ലസ്റ്ററിലെ ഒന്നിലധികം ഉപയോക്താക്കൾ അല്ലെങ്കിൽ പരിതസ്ഥിതികൾ

കുബെർനെറ്റസ് നെയിംസ്പേസുകൾ (നാമമേഖലകൾ) ശക്തമായ ഇൻസുലേഷൻ നൽകരുത്.

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

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

9. ബാഹ്യ ട്രാഫിക് പോളിസി: ക്ലസ്റ്റർ

ക്ലസ്റ്ററിനുള്ളിലെ എല്ലാ ട്രാഫിക്കും നോഡ്‌പോർട്ട് പോലെയുള്ള ഒരു സേവനത്തിലൂടെയാണ് വരുന്നത്, അതിനായി സ്ഥിരസ്ഥിതി നയം സജ്ജീകരിച്ചിരിക്കുന്നു. externalTrafficPolicy: Cluster... അതിനർത്ഥം അതാണ് നോഡ്പോർട്ട് ക്ലസ്റ്ററിലെ എല്ലാ നോഡിലും തുറന്നിരിക്കുന്നു, നിങ്ങൾക്ക് ആവശ്യമുള്ള സേവനവുമായി സംവദിക്കാൻ അവയിലേതെങ്കിലും ഉപയോഗിക്കാം (പോഡ്‌സിന്റെ സെറ്റ്).

അതേ സമയം, മുകളിൽ സൂചിപ്പിച്ച NodePort സേവനവുമായി ബന്ധപ്പെട്ട യഥാർത്ഥ പോഡുകൾ സാധാരണയായി ഒരു നിശ്ചിത സ്ഥലത്ത് മാത്രമേ ലഭ്യമാകൂ ഈ നോഡുകളുടെ ഉപവിഭാഗം. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, ആവശ്യമായ പോഡ് ഇല്ലാത്ത ഒരു നോഡിലേക്ക് ഞാൻ കണക്റ്റുചെയ്യുകയാണെങ്കിൽ, അത് മറ്റൊരു നോഡിലേക്ക് ട്രാഫിക്കിലേക്ക് കൈമാറും, ഒരു ഹോപ്പ് ചേർക്കുന്നു കൂടാതെ വർദ്ധിച്ചുവരുന്ന ലേറ്റൻസി (വ്യത്യസ്ത ലഭ്യത മേഖലകളിൽ/ഡാറ്റ സെന്ററുകളിൽ നോഡുകൾ സ്ഥിതിചെയ്യുന്നുണ്ടെങ്കിൽ, ലേറ്റൻസി വളരെ ഉയർന്നതായിരിക്കും; കൂടാതെ, എഗ്രസ് ട്രാഫിക് ചെലവുകൾ വർദ്ധിക്കും).

മറുവശത്ത്, ഒരു നിശ്ചിത കുബർനെറ്റസ് സേവനത്തിന് ഒരു പോളിസി സെറ്റ് ഉണ്ടെങ്കിൽ externalTrafficPolicy: Local, അപ്പോൾ ആവശ്യമുള്ള പോഡുകൾ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്ന നോഡുകളിൽ മാത്രമേ NodePort തുറക്കുകയുള്ളൂ. സംസ്ഥാനം പരിശോധിക്കുന്ന ഒരു ബാഹ്യ ലോഡ് ബാലൻസർ ഉപയോഗിക്കുമ്പോൾ (ആരോഗ്യ പരിശോധന) അവസാന പോയിന്റുകൾ (അത് എങ്ങനെ ചെയ്യുന്നു AWS ELB), അവൻ ആവശ്യമായ നോഡുകളിലേക്ക് മാത്രം ട്രാഫിക് അയയ്ക്കും, ഇത് കാലതാമസം, കമ്പ്യൂട്ടിംഗ് ആവശ്യങ്ങൾ, എഗ്രസ് ബില്ലുകൾ എന്നിവയിൽ ഗുണം ചെയ്യും (സാമാന്യബുദ്ധിയും ഇത് തന്നെയാണ് നിർദ്ദേശിക്കുന്നത്).

നിങ്ങൾ ഇതിനകം ഇതുപോലുള്ള എന്തെങ്കിലും ഉപയോഗിക്കാനുള്ള ഉയർന്ന സാധ്യതയുണ്ട് ട്രാഫിക് അഥവാ nginx-ingress-controller ഒരു NodePort എൻഡ്‌പോയിന്റ് (അല്ലെങ്കിൽ LoadBalancer, NodePort ഉപയോഗിക്കുകയും ചെയ്യുന്നു) ആയി HTTP ഇൻഗ്രെസ്സ് ട്രാഫിക്ക് റൂട്ട് ചെയ്യാൻ, ഈ ഓപ്ഷൻ സജ്ജീകരിക്കുന്നത് അത്തരം അഭ്യർത്ഥനകളുടെ ലേറ്റൻസി ഗണ്യമായി കുറയ്ക്കും.

В ഈ പ്രസിദ്ധീകരണം നിങ്ങൾക്ക് എക്‌സ്‌റ്റേണൽ ട്രാഫിക് പോളിസി, അതിന്റെ ഗുണങ്ങളെയും ദോഷങ്ങളെയും കുറിച്ച് കൂടുതലറിയാൻ കഴിയും.

10. ക്ലസ്റ്ററുകളുമായി ബന്ധിപ്പിക്കരുത്, നിയന്ത്രണ തലം ദുരുപയോഗം ചെയ്യരുത്

മുമ്പ്, സെർവറുകളെ ശരിയായ പേരുകളിൽ വിളിക്കുന്നത് പതിവായിരുന്നു: ആന്റൺ, HAL9000, Colossus... ഇന്ന് അവ ക്രമരഹിതമായി സൃഷ്ടിച്ച ഐഡന്റിഫയറുകൾ ഉപയോഗിച്ച് മാറ്റിസ്ഥാപിച്ചു. എന്നിരുന്നാലും, ശീലം തുടർന്നു, ഇപ്പോൾ ശരിയായ പേരുകൾ ക്ലസ്റ്ററുകളിലേക്ക് പോകുന്നു.

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

കൂട്ടങ്ങൾ വളർത്തുമൃഗങ്ങളായി മാറുന്നതിൽ രസകരമൊന്നുമില്ല, അതിനാൽ പരിശീലിക്കുമ്പോൾ ഇടയ്ക്കിടെ അവയെ നീക്കം ചെയ്യാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു ദുരിത മോചനം (ഇത് സഹായിക്കും കുഴപ്പം എഞ്ചിനീയറിംഗ് - ഏകദേശം. പരിഭാഷ.). കൂടാതെ, നിയന്ത്രണ പാളിയിൽ പ്രവർത്തിക്കുന്നത് ഉപദ്രവിക്കില്ല (നിയന്ത്രണ തലം). അവനെ തൊടാൻ ഭയപ്പെടുന്നത് നല്ല ലക്ഷണമല്ല. തുടങ്ങിയവ. മരിച്ചോ? സുഹൃത്തുക്കളേ, നിങ്ങൾ ശരിക്കും കുഴപ്പത്തിലാണ്!

മറുവശത്ത്, അത് കൈകാര്യം ചെയ്യുന്നതിൽ നിങ്ങൾ അകന്നുപോകരുത്. സമയം കൊണ്ട് നിയന്ത്രണ പാളി മന്ദഗതിയിലായേക്കാം. മിക്കവാറും, ഭ്രമണം കൂടാതെ ധാരാളം ഒബ്‌ജക്‌റ്റുകൾ സൃഷ്‌ടിക്കപ്പെട്ടതാണ് ഇതിന് കാരണം (സ്ഥിരസ്ഥിതി ക്രമീകരണങ്ങളുള്ള ഹെൽം ഉപയോഗിക്കുമ്പോൾ ഒരു സാധാരണ സാഹചര്യം, അതിനാലാണ് കോൺഫിഗ്‌മാപ്പുകളിൽ/രഹസ്യങ്ങളിൽ അതിന്റെ അവസ്ഥ അപ്‌ഡേറ്റ് ചെയ്യാത്തത് - ഫലമായി, ആയിരക്കണക്കിന് ഒബ്‌ജക്റ്റുകൾ അടിഞ്ഞുകൂടുന്നു. നിയന്ത്രണ പാളി) അല്ലെങ്കിൽ kube-api ഒബ്‌ജക്‌റ്റുകളുടെ നിരന്തരമായ എഡിറ്റിംഗ് (ഓട്ടോമാറ്റിക് സ്‌കെയിലിംഗിന്, CI/CD-യ്‌ക്ക്, നിരീക്ഷണത്തിനായി, ഇവന്റ് ലോഗുകൾ, കൺട്രോളറുകൾ മുതലായവ).

കൂടാതെ, നിയന്ത്രിത കുബർനെറ്റ്സ് ദാതാവുമായുള്ള SLA/SLO കരാറുകൾ പരിശോധിക്കാനും ഗ്യാരന്റികളിൽ ശ്രദ്ധ ചെലുത്താനും ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു. വിൽപ്പനക്കാരന് ഉറപ്പ് നൽകാൻ കഴിയും നിയന്ത്രണ പാളി ലഭ്യത (അല്ലെങ്കിൽ അതിന്റെ ഉപഘടകങ്ങൾ), എന്നാൽ നിങ്ങൾ ഇതിലേക്ക് അയയ്‌ക്കുന്ന അഭ്യർത്ഥനകളുടെ p99 കാലതാമസം അല്ല. മറ്റൊരു വിധത്തിൽ പറഞ്ഞാൽ, നിങ്ങൾക്ക് പ്രവേശിക്കാം kubectl get nodes10 മിനിറ്റിനുശേഷം മാത്രമേ ഉത്തരം ലഭിക്കൂ, ഇത് സേവന കരാറിന്റെ നിബന്ധനകളുടെ ലംഘനമാകില്ല.

11. ബോണസ്: ഏറ്റവും പുതിയ ടാഗ് ഉപയോഗിച്ച്

എന്നാൽ ഇത് ഇതിനകം ഒരു ക്ലാസിക് ആണ്. കയ്പേറിയ അനുഭവങ്ങളിൽ നിന്ന് പഠിച്ച് പലരും ടാഗ് ഉപയോഗിക്കുന്നത് നിർത്തിയതിനാൽ ഈയിടെയായി ഞങ്ങൾ ഈ സാങ്കേതികത വളരെ കുറച്ച് മാത്രമേ കണ്ടിട്ടുള്ളൂ. :latest പതിപ്പുകൾ പിൻ ചെയ്യാൻ തുടങ്ങി. ഹൂറേ!

ECR ഇമേജ് ടാഗുകളുടെ മാറ്റമില്ലാത്തത് നിലനിർത്തുന്നു; ഈ ശ്രദ്ധേയമായ സവിശേഷതയെക്കുറിച്ച് നിങ്ങൾ സ്വയം പരിചയപ്പെടാൻ ഞങ്ങൾ ശുപാർശ ചെയ്യുന്നു.

സംഗ്രഹം

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

വിവിധ ടീമുകളുടെ വിജയിക്കാത്ത അനുഭവങ്ങൾ നിങ്ങൾക്ക് പരിചയപ്പെടാം ഈ കഥാസമാഹാരം ഹെന്നിംഗ് ജേക്കബ്സ്.

ഈ ലേഖനത്തിൽ നൽകിയിരിക്കുന്ന പിശകുകളുടെ പട്ടികയിൽ ചേർക്കാൻ ആഗ്രഹിക്കുന്നവർക്ക് Twitter-ൽ ഞങ്ങളെ ബന്ധപ്പെടാം (@MarekBartik, @MstrsObserver).

വിവർത്തകനിൽ നിന്ന് പി.എസ്

ഞങ്ങളുടെ ബ്ലോഗിലും വായിക്കുക:

• «കുബർനെറ്റസ് ക്ലസ്റ്ററുകൾ രൂപകൽപ്പന ചെയ്യുന്നു: എത്ര എണ്ണം ഉണ്ടായിരിക്കണം?";
• «കുബർനെറ്റസിലെ എബിസി ഓഫ് സെക്യൂരിറ്റി: ആധികാരികത, അംഗീകാരം, ഓഡിറ്റിംഗ്";
• «കുബർനെറ്റസിലെ ഓട്ടോസ്‌കേലിംഗും റിസോഴ്‌സ് മാനേജ്‌മെന്റും"(അവലോകനവും വീഡിയോ റിപ്പോർട്ടും);
• «കുബെർനെറ്റസിലെ കോൺഫിഗ്മാപ്പുകൾ: അറിയേണ്ട സൂക്ഷ്മതകൾ".

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