ഓരോ ആഴ്ചയും ഞാൻ കാണുന്ന കുബർനെറ്റസ് പിശകുകളും അവ എങ്ങനെ പരിഹരിക്കാമെന്നതും
ക്രാഷ് ലൂപ്പ് ബാക്ക്ഓഫ്, ഇമേജ് പിൻ ഓഫ്, കാത്തിരിക്കുന്നു. ഒരു പ്രായോഗിക പരിഹാര പട്ടിക, ഒരു ചീറ്റ് ഷീറ്റിനൊപ്പം.
ക്രാഷ് ലൂപ്പ് ബാക്ക്ഓഫ്, ഇമേജ് പിൻ ഓഫ്, കാത്തിരിക്കുന്നു. ഒരു പ്രായോഗിക പരിഹാര പട്ടിക, ഒരു ചീറ്റ് ഷീറ്റിനൊപ്പം.

കുബർനെറ്റസ് പിശക് സന്ദേശങ്ങള് ക്ക് ഒരു പ്രത്യേക കഴിവുണ്ട്: എന്തെങ്കിലുമൊരു തെറ്റ് സംഭവിച്ചതായി അവർ വലിയ അക്ഷരങ്ങളില് പറയുന്നു, കാരണം പറയാതെ. CrashLoopBackOff. ImagePullBackOff. Pending. നിങ്ങൾ കുബർനെറ്റീസ് ഉപയോഗിച്ച് ജോലി ചെയ്യുന്നവരാണെങ്കിൽ, നിങ്ങൾ ഇത് എല്ലാ ആഴ്ചയും കാണും.
നല്ല വാർത്ത: ഈ പിശകുകൾക്ക് കാരണങ്ങൾ ഏതാനും കാരണങ്ങൾ തന്നെയാണ്. ഇവിടെ എന്റെ സാധാരണ ഡീബഗ്ഗിംഗ് പ്രക്രിയയും ഞാൻ ആദ്യം ശ്രമിക്കുന്ന പരിഹാരങ്ങളും ആണ്.
തെറ്റ് എന്തായിരുന്നാലും, ഞാന് തുടക്കത്തില് ഒരേ മൂന്ന് കമാന് ഡുകളാണ് ഉപയോഗിക്കുന്നത്:
kubectl get pods -n shop # what state is it in?
kubectl describe pod <pod> -n shop # events at the bottom tell the story
kubectl logs <pod> -n shop --previous # logs from the crashed container
സി. സംഭവങ്ങൾ താഴെ ഭാഗം kubectl describe കുബർനെറ്റസിലെ ഏറ്റവും വിലകുറഞ്ഞ ഡീബഗ്ഗിംഗ് ടൂളാണ്. പത്തിൽ ഒമ്പത് തവണ, ഉത്തരം അവിടെയുണ്ട്.
വലിയ ചിത്രത്തിന് വേണ്ടി:
kubectl get events -n shop --sort-by=.lastTimestamp
കണ്ടെയ്നർ ആരംഭിക്കുന്നു, ക്രാഷ് ചെയ്യുന്നു, കുബർനെറ്റ്സ് അത് പുനരാരംഭിക്കുന്നു, അത് വീണ്ടും ക്രാഷ് ചെയ്യപ്പെടുന്നു, ശ്രമങ്ങൾക്കിടയിൽ കുബർനെറ്റസ് കൂടുതൽ കൂടുതൽ കാത്തിരിക്കുന്നു.
സാധാരണ കാരണങ്ങൾ:
- ആപ്ലിക്കേഷൻ തന്നെ സ്റ്റാർട്ട് ചെയ്യുമ്പോൾ പരാജയപ്പെടുന്നു: കോൺഫിഗറേഷൻ നഷ്ടപ്പെട്ടു, തെറ്റായ പരിസ്ഥിതി വേരിയബിൾ, ഡാറ്റാബേസ് ആക്സസ് ചെയ്യാൻ കഴിയില്ല. - ഒരു രഹസ്യം കാണാതായതോ കോൺഫിഗ്മെപ് കീയോ. - ജീവൻ അന്വേഷണം തുടങ്ങുന്നതിനു മുമ്പ് കണ്ടെയ്നറിനെ നശിപ്പിക്കും. - സ്റ്റാർട്ട് അപ്പ് സമയത്ത് മെമ്മറിയിൽ നിന്ന് പുറത്തായി (ചെക്ക് ചെയ്യുക OOMKilled).
പരിഹാരം: kubectl logs --previous അവസാനത്തെ റൺ എന്തിന് മരിച്ചു എന്ന് കാണിക്കുന്നു. ലോഗ് ശൂന്യമാണെങ്കിൽ, എന്തെങ്കിലും ലോഗ് ചെയ്യുന്നതിനു മുമ്പ് പ്രക്രിയ ക്രാഷ് ആകും: കമാൻഡ്, എൻട്രി പോയിന്റ്, ഇമേജ് എന്നിവ പരിശോധിക്കുക.
കുബർനെറ്റിന് കണ്ടെയ്നര് ചിത്രം ഡൌണ് ലോഡ് ചെയ്യാൻ കഴിയില്ല.
സാധാരണ കാരണങ്ങൾ:
- ചിത്രത്തിന്റെ പേരോ ടാഗിലോ ഒരു അക്ഷര പിശക്. - ഈ ടാഗ് നിലവിലില്ല (ഇത് ഒരിക്കലും പുഷ് ചെയ്തിട്ടില്ല, അല്ലെങ്കിൽ ഇല്ലാതാക്കി). - ഒരു സ്വകാര്യ രജിസ്ട്രി ഇല്ലാതെ imagePullSecret, അല്ലെങ്കിൽ കാലഹരണപ്പെട്ടത്. - റജിസ്ട്രിയിൽ നിന്നും നിരക്ക് പരിധി. - നോഡിന് റെജിസ്ട്രി (നെറ്റ്വർക്ക്, പ്രോക്സി, ഫയർവാൾ) എത്താന് കഴിയില്ല.
പരിഹാരം: ഇവന്റ് സന്ദേശം സാധാരണയായി കൃത്യമായി ഏത് എന്ന് പറയുന്നുഃ "കണ്ടെത്തിയില്ല", "അനധികൃത", അല്ലെങ്കിൽ "മിക്ക അഭ്യർത്ഥനകളും".
ഈ പാഡ് സൃഷ്ടിക്കപ്പെട്ടിരിക്കുന്നു, പക്ഷെ ഒരു നോഡും അത് പ്രവർത്തിപ്പിക്കില്ല.
സാധാരണ കാരണങ്ങൾ: - ഒരു സിപിയുവിനും വേണ്ടത്ര മെമ്മറിയുമില്ല. അഭ്യർത്ഥനകൾ. - നോഡ് സെലക്ടർ, ആഫിനിറ്റി നിയമങ്ങൾ, നോഡ് പൊരുത്തപ്പെടാത്ത മാറ്റ്സ്. - ഒരു സ്ഥിരമായ വോള്യം ക്ലെയിം (തെറ്റായ സംഭരണ ക്ലാസ്, തെറ്റായ മേഖല) - ക്ലസ്റ്റര് ഓട്ടോ സ്കെയിലര് ഒരു നോഡ് കൂടി ചേര് ക്കാന് കഴിഞ്ഞിട്ടില്ല, അല്ലെങ്കിൽ പറ്റില്ല.
പരിഹാരം: kubectl describe pod "0/5 നോഡുകൾ ലഭ്യമാണ്: 3 മതിയായ മെമ്മറി ഇല്ല, 2 നോഡുകൾക്ക് അനുമതിയില്ല" എന്ന സന്ദേശം കാണിക്കുന്നു. അത് കൃത്യമായി എന്ത് മാറ്റം വരുത്തണമെന്ന് പറഞ്ഞു തരും.
കണ്ടെയ്നര് അതിന്റെ പരിധിക്കപ്പുറം മെമ്മറി ഉപയോഗിച്ചു, അത് നശിച്ചു. പുറപ്പെടൽ കോഡ് 137.
പരിഹാരം: യഥാർത്ഥ മെമ്മറി ഉപയോഗം പരിശോധിക്കുക, പിന്നെ പരിധി ഉയർത്തുക അല്ലെങ്കിൽ ചോർച്ച പരിഹരിക്കുക. ഭാഷാ റൺടൈം കണ്ടെയ്നറിന്റെ മെമ്മറി പരിധി അറിയുന്നുണ്ടോ എന്ന് ഉറപ്പുവരുത്തുക.
നോഡ് മെമ്മറി അല്ലെങ്കിൽ ഡിസ്കിൽ തീർന്നു, സ്വയം സംരക്ഷിക്കാനായി പാഡുകൾ നീക്കം ചെയ്തു.
പരിഹാരം: ശരിയായ മെമ്മറി അഭ്യർത്ഥനകൾ സജ്ജമാക്കുക, വലിയ ലോഗ് അല്ലെങ്കിൽ താൽക്കാലിക ഫയലുകൾ എഴുതുന്ന പോഡുകൾ പരിശോധിക്കുക, നോഡ് ഡിസ്ക് ഉപയോഗം നോക്കുക. പഴയ വീട് ഒഴിഞ്ഞ് കളഞ്ഞ കോപ്പികൾ വൃത്തിയാക്കുക kubectl delete pod --field-selector=status.phase=Failed.
സാധാരണയായി ഒരു രഹസ്യമോ കോൺഫിഗ്മാപ്പോ (അല്ലെങ്കിൽ അതിൽ ഒരു കീ) പരാമർശിച്ചിട്ടില്ല. സംഭവം തന്നെ അത് വിളിക്കുന്നു.
കണ്ടെയ്നര് പ്രവർത്തിക്കുന്നു, പക്ഷേ കുബർനെറ്റസ് അതിലേക്ക് ട്രാഫിക് അയയ്ക്കുന്നില്ല.
പരിഹാരം: അന്വേഷണ പാതയും തുറമുഖവും പരിശോധിച്ച്, അത് കപ്പലിന്റെ ഉള്ളിൽ നിന്നും പരിശോധിക്കുക. പരിശോധന ബാഹ്യ സേവനങ്ങളെ ആശ്രയിക്കുന്നില്ലെന്ന് ഉറപ്പുവരുത്തുക. അത് വളരെ വേഗത കുറഞ്ഞതായിരിക്കാം.
കുബർനെറ്റീസ് മിക്കവാറും എപ്പോഴും എന്താണ് കുഴപ്പം എന്ന് പറഞ്ഞു തരും. അത് ഉത്തരം താഴെ വയ്ക്കുന്നു
kubectl describe.
"ഇത് കപ്പലില് തന്നെ പ്രവർത്തിക്കുന്നു, പക്ഷേ സേവനത്തിലൂടെയല്ല".
# Does the Service have endpoints?
kubectl get endpointslices -n shop -l kubernetes.io/service-name=shop-api
# Test from inside the cluster
kubectl run tmp --rm -it --image=busybox:1.36 -- sh
# then: wget -qO- http://shop-api.shop.svc.cluster.local:8080/health
സാധാരണ കാരണങ്ങൾ:
- അവസാന പോയിന്റുകളില്ല: സേവന സെലക്ടർ പാഡ് ലേബലുകളുമായി പൊരുത്തപ്പെടുന്നില്ല. പേര് മാറ്റിയതിനു ശേഷം വളരെ സാധാരണമാണ്. - അതെ. തെറ്റായ പോർട്ട്: port എതിരാളികൾ targetPort ഒരു തെറ്റിദ്ധാരണ. - അതെ. നെറ്റ് വർക്ക് പോളിസി ട്രാഫിക് തടയുന്നു. ഏതെങ്കിലും നയം ഒരു പാഡ് തിരഞ്ഞെടുക്കുകയാണെങ്കില് , വ്യക്തമായി അനുവദിക്കാത്തതെല്ലാം നിഷേധിക്കപ്പെടും. - അതെ. ഡിഎൻഎസ്: കോർഡിഎൻഎസ് പാഡുകൾ ശരിയാണോ എന്ന് പരിശോധിക്കുക, നെയിംസ്പെയ്സുകളിലുടനീളം പൂർണ്ണ സേവന നാമം ഉപയോഗിക്കുക.
kubectl debug ഒരു റണ്ണിംഗ് പോഡിൽ ഒരു ദീർഘകാല ഡീബഗ് കണ്ടെയ്നർ ആരംഭിക്കുന്നു, ചിത്രത്തിന് ഷെൽ ഇല്ലെങ്കിലും. വിഭജിത ചിത്രങ്ങള് ക്ക് അത്യാവശ്യമാണ്.kubectl exec ഒരു ഷെൽ ഉള്ള ചിത്രങ്ങൾക്കായി.kubectl port-forward നിങ്ങളുടെ ലാപ്ടോപ്പില് നിന്നും ഒരു സേവനം പരിശോധിക്കാന് .| നില | ആദ്യം പരിശോധിക്കേണ്ട കാര്യം |
|---|---|
| ക്രാഷ് ലൂപ്പ് ബാക്ക്ഓഫ് | kubectl logs --previous |
| ചിത്രം പിൻവലിക്കുക | സംഭവ സന്ദേശം: പേര്, ടാഗ്, അംഗീകാരപത്രങ്ങൾ, നിരക്ക് പരിധി |
| കാത്തിരിക്കുന്നു | describe പരിപാടികൾ: വിഭവങ്ങൾ, മാലിന്യങ്ങൾ, പിവിസി |
| കൊലപാതകം | മെമ്മറി ഉപയോഗം vs പരിധി |
| പുറത്താക്കി | നോഡ് മെമ്മറി/ഡിസ്ക് സമ്മർദ്ദം, അഭ്യർത്ഥനകൾ നഷ്ടമായി |
| CreateContainerConfigError മാറ്റം വരുത്തുക | രഹസ്യം/കോൺഫിഗ്മാപ്പ് അല്ലെങ്കിൽ കീ നഷ്ടമായിരിക്കുന്നു |
| തയ്യാറായില്ല | സന്നദ്ധതയുടെ പാത, തുറമുഖം, ആശ്രിതത്വം |
| സേവനം ലഭ്യമല്ല | എൻഡ് പോയിന്റുകൾ, സെലക്ടർ ലേബലുകൾ, പോർട്ടുകൾ, നെറ്റ്വർക്ക് പോളിസി, ഡിഎൻഎസ് |
എന്റെ അഭിപ്രായം: സംഭവങ്ങളും മുൻകാല ലോഗുകളും വായിക്കാൻ പഠിക്കുക, മിക്ക കുബർനെറ്റസ് രഹസ്യങ്ങളും മിനിറ്റുകൾക്കുള്ളിൽ സ്വയം പരിഹരിക്കപ്പെടും.
ഡെസ്ലി