10 የተለመዱ የኩበርኔትስ ስህተቶች

ማስታወሻ. ትርጉምየዚህ ጽሑፍ አዘጋጆች ከትንሽ የቼክ ኩባንያ ፒፔይል መሐንዲሶች ናቸው። ከኩበርኔትስ ክላስተር አሠራር ጋር የተያያዙ [አንዳንዴ ባናል፣ነገር ግን አሁንም] በጣም አንገብጋቢ የሆኑ ችግሮችን እና የተሳሳቱ አመለካከቶችን አንድ ላይ ማሰባሰብ ችለዋል።

Kubernetes በተጠቀምንባቸው ዓመታት ከበርካታ ስብስቦች ጋር ሠርተናል (ሁለቱም የሚተዳደሩ እና የማይተዳደሩ - በGCP፣ AWS እና Azure)። ከጊዜ በኋላ አንዳንድ ስህተቶች ያለማቋረጥ እንደሚደጋገሙ ማስተዋል ጀመርን። ሆኖም ግን, በዚህ ውስጥ ምንም እፍረት የለም: አብዛኛዎቹን እኛ እራሳችን አድርገናል!

ጽሑፉ በጣም የተለመዱ ስህተቶችን የያዘ ሲሆን እንዴት እነሱን ማስተካከል እንደሚቻልም ይጠቅሳል.

1. መርጃዎች: ጥያቄዎች እና ገደቦች

ይህ ንጥል በእርግጠኝነት በዝርዝሩ ውስጥ በጣም የቅርብ ትኩረት እና የመጀመሪያ ቦታ ይገባዋል።

የሲፒዩ ጥያቄ ብዙውን ጊዜ ጨርሶ አልተገለጸም ወይም በጣም ዝቅተኛ ዋጋ አለው (በተቻለ መጠን በእያንዳንዱ መስቀለኛ መንገድ ላይ ብዙ እንክብሎችን ለማስቀመጥ). ስለዚህ, አንጓዎቹ ከመጠን በላይ ይጫናሉ. ከፍተኛ ጭነት በሚኖርበት ጊዜ የመስቀለኛ መንገድ የማቀነባበሪያ ኃይል ሙሉ በሙሉ ጥቅም ላይ ይውላል እና የተወሰነ የሥራ ጫና የሚቀበለው "የጠየቀውን" ብቻ ነው. ሲፒዩ ስሮትልንግ. ይህ ወደ ጨምሯል የመተግበሪያ መዘግየት, ጊዜ ማብቂያዎች እና ሌሎች ደስ የማይል መዘዞች ያስከትላል. (ስለዚህ በሌላኛው የቅርብ ጊዜ ትርጉማችን ላይ የበለጠ አንብብ፡ “በ Kubernetes ውስጥ የሲፒዩ ገደቦች እና ኃይለኛ ስሮትሊንግ"- በግምት. መተርጎም)

ምርጥ ጥረት (እጅግ አይደለም የሚመከር):

resources: {}

እጅግ በጣም ዝቅተኛ የሲፒዩ ጥያቄ (እጅግ አይደለም የሚመከር):

   resources:
      Requests:
        cpu: "1m"

በሌላ በኩል፣ የሲፒዩ ገደብ መኖሩ የመስቀለኛ መንገድ ፕሮሰሰር ሙሉ በሙሉ ባይጫንም እንኳ የሰዓት ዑደቶችን ያለምክንያት በፖድ መዝለልን ያስከትላል። በድጋሚ, ይህ ወደ መዘግየቶች መጨመር ሊያመራ ይችላል. በመለኪያው ዙሪያ ውዝግብ ቀጥሏል። ሲፒዩ CFS ኮታ በሊኑክስ ከርነል እና በሲፒዩ ስሮትሊንግ እንደተቀመጠው ገደብ፣ እንዲሁም የCFS ኮታውን ማሰናከል... ወዮ፣ የሲፒዩ ገደቦች ሊፈቱ ከሚችሉት በላይ ብዙ ችግሮችን ሊያስከትሉ ይችላሉ። ስለዚህ ጉዳይ ተጨማሪ መረጃ ከዚህ በታች ባለው ማገናኛ ማግኘት ይቻላል.

ከመጠን በላይ ምርጫ (ከመጠን ያለፈ) የማስታወስ ችግር ወደ ትላልቅ ችግሮች ሊመራ ይችላል. የሲፒዩ ገደብ ላይ መድረስ የሰዓት ዑደቶችን መዝለልን ይጨምራል፣ የማህደረ ትውስታ ገደቡ ላይ ሲደርስ ፖድውን መግደልን ይጠይቃል። ታዝበህ ታውቃለህ OOMkill? አዎ፣ በትክክል የምንናገረው ስለዚያ ነው።

ይህ የመከሰት እድልን መቀነስ ይፈልጋሉ? ማህደረ ትውስታን ከመጠን በላይ አይመድቡ እና የተረጋገጠ QoS (የአገልግሎት ጥራት) ይጠቀሙ የማህደረ ትውስታ ጥያቄውን ወደ ገደቡ በማቀናጀት (ከዚህ በታች ባለው ምሳሌ)። ስለዚህ ጉዳይ በ ውስጥ የበለጠ ያንብቡ Henning Jacobs አቀራረቦች (በዛላንዶ መሪ ኢንጂነር)።

ሊፈነዳ የሚችል (ኦኦኤም የመገደል ከፍተኛ ዕድል)

   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

ሆኖም፣ አሁን ያለውን አጠቃቀም ብቻ ያሳያሉ። የክብደቱን ቅደም ተከተል ግምታዊ ሀሳብ ሊሰጥዎት ይችላል ፣ ግን በመጨረሻ ያስፈልግዎታል በጊዜ ሂደት የመለኪያ ለውጦች ታሪክ (እንደ “የከፍተኛው የሲፒዩ ጭነት ምን ነበር?”፣ “ትላንት ጠዋት ጭነቱ ምን ነበር?” እና የመሳሰሉትን ጥያቄዎች ለመመለስ)። ለዚህም መጠቀም ይችላሉ ፕሮሚትየስ, DataDog እና ሌሎች መሳሪያዎች. በቀላሉ መለኪያዎችን ከመለኪያ-አገልጋይ ያገኙና ያከማቻሉ፣ እና ተጠቃሚው ሊጠይቃቸው እና በዚሁ መሰረት ሊያሴራቸው ይችላል።

VerticalPodAutoscaler ይህ ይፈቅዳል አውቶማቲክ ይህ ሂደት. የሲፒዩ እና የማህደረ ትውስታ አጠቃቀም ታሪክን ይከታተላል እና በዚህ መረጃ ላይ በመመስረት አዲስ ጥያቄዎችን እና ገደቦችን ያዘጋጃል።

የኮምፒዩተር ሃይልን በብቃት መጠቀም ቀላል ስራ አይደለም። ቴትሪስን ሁል ጊዜ መጫወት ነው። ለአነስተኛ አማካይ ፍጆታ (~10%) ስሌት ላለው ሃይል በጣም ብዙ እየከፈሉ ከሆነ፣ በAWS Fargate ወይም Virtual Kubelet ላይ የተመሰረቱ ምርቶችን እንዲመለከቱ እንመክራለን። እነሱ የተገነቡት አገልጋይ በሌለው/በአጠቃቀም ክፍያ የሚከፈል የሂሳብ አከፋፈል ሞዴል ላይ ነው፣ይህም በእንደዚህ አይነት ሁኔታዎች ርካሽ ሊሆን ይችላል።

2. መኖር እና ዝግጁነት ምርመራዎች

በነባሪ፣ የአኗኗር እና ዝግጁነት ማረጋገጫዎች በኩበርኔትስ ውስጥ አልነቁም። እና አንዳንድ ጊዜ እነሱን ማብራት ይረሳሉ ...

ነገር ግን ገዳይ ስህተት በሚፈጠርበት ጊዜ አገልግሎቱን እንደገና እንዴት ማስጀመር ይችላሉ? እና የጭነት ማመሳከሪያው አንድ ፖድ ትራፊክ ለመቀበል ዝግጁ መሆኑን እንዴት ያውቃል? ወይም ተጨማሪ ትራፊክን ማስተናገድ ይችላል?

እነዚህ ፈተናዎች ብዙውን ጊዜ እርስ በርስ ይደባለቃሉ-

• መኖር - "የመዳን" ቼክ, ፖድ ካልተሳካ እንደገና ያስጀምረዋል;
• ዝግጁነት - ዝግጁነት ማረጋገጫ ፣ ካልተሳካ ፣ ፖድውን ከ Kubernetes አገልግሎት ያላቅቃል (ይህን በመጠቀም ማረጋገጥ ይቻላል) kubectl get endpoints) እና ቀጣዩ ቼክ በተሳካ ሁኔታ እስኪጠናቀቅ ድረስ ትራፊክ ወደ እሱ አይደርስም።

እነዚህ ሁለቱም ቼኮች በፖድ አጠቃላይ የህይወት ዑደት ውስጥ ተካሂዷል. በጣም አስፈላጊ ነው.

የተለመደው የተሳሳተ ግንዛቤ የዝግጁነት ምርመራዎች የሚከናወኑት በሚነሳበት ጊዜ ብቻ ነው ስለሆነም ሚዛኑ ፖዱ ዝግጁ መሆኑን ማወቅ ይችላል (Ready) እና ትራፊክን ማካሄድ ሊጀምር ይችላል። ሆኖም, ይህ ለአጠቃቀም አማራጮች አንዱ ብቻ ነው.

ሌላው በፖዳው ላይ ያለው ትራፊክ ከመጠን በላይ መሆኑን የማወቅ እድል እና ከመጠን በላይ ይጫናል (ወይም ፖድው በሀብት-ተኮር ስሌቶችን ያከናውናል). በዚህ ሁኔታ, ዝግጁነት ማረጋገጥ ይረዳል በፖዳው ላይ ያለውን ጭነት ይቀንሱ እና "ቀዝቃዛ" ያድርጉት. ለወደፊቱ ዝግጁነት ማረጋገጫ በተሳካ ሁኔታ ማጠናቀቅ ያስችላል በፖዳው ላይ ያለውን ጭነት እንደገና ይጨምሩ. በዚህ ሁኔታ (የዝግጁነት ፈተናው ካልተሳካ) የህይወት ፈተናው ውድቀት በጣም ተቃራኒ ይሆናል። ጤናማ እና ጠንክሮ የሚሰራ ፖድ ለምን እንደገና ያስጀምረዋል?

ስለዚህ, በአንዳንድ ሁኔታዎች, ምንም አይነት ቼኮች በተሳሳተ መንገድ የተዋቀሩ መለኪያዎችን ከማንቃት የተሻለ ነው. ከላይ እንደተገለፀው ከሆነ የአኗኗር ቼክ ቅጂዎች ዝግጁነት ማረጋገጫ, ከዚያም ትልቅ ችግር ውስጥ ነዎት. የሚቻለው አማራጭ ማዋቀር ነው። ዝግጁነት ፈተና ብቻና አደገኛ ኑሮ ወደ ጎን ተወው ።

ሁለቱም የቼኮች ዓይነቶች የተለመዱ ጥገኞች ሳይሳኩ ሲቀሩ መውደቅ የለባቸውም፣ አለበለዚያ ይህ ወደ ሁሉም የፖዳዎች ውድቀት (አቫላንሽ-መሰል) ውድቀትን ያስከትላል። በሌላ ቃል, እራስህን አትጎዳ.

3. ለእያንዳንዱ የኤችቲቲፒ አገልግሎት LoadBalancer

ምናልባትም፣ ወደ ውጭው ዓለም ማስተላለፍ የምትፈልጋቸው የኤችቲቲፒ አገልግሎቶች በክላስተርህ ውስጥ ሊኖርህ ይችላል።

አገልግሎቱን ከከፈቱ type: LoadBalancerተቆጣጣሪው (በአገልግሎት አቅራቢው ላይ በመመስረት) የውጭ LoadBalancer (የግድ በ L7 ላይ ሳይሆን በ L4 ላይ ብቻ ሳይሆን) ያቀርባል እና ይደራደራል ፣ እና ይህ ወጪውን ሊጎዳ ይችላል (ውጫዊ የማይንቀሳቀስ IPv4 አድራሻ ፣ የኮምፒዩተር ኃይል ፣ በሰከንድ የሂሳብ አከፋፈል) ) ብዙ ቁጥር ያላቸው እንዲህ ያሉ ሀብቶችን መፍጠር አስፈላጊ በመሆኑ.

በዚህ ሁኔታ, አንድ የውጭ ጭነት ሚዛንን መጠቀም, አገልግሎቶችን እንደ መክፈት የበለጠ ምክንያታዊ ነው type: NodePort. ወይም የተሻለ ሆኖ፣ የሆነ ነገር አስፋፉ nginx-ingress-ተቆጣጣሪ (ወይም trafik) ማን ብቻ ይሆናል። መስቀለኛ መንገድ የመጨረሻ ነጥብ ከውጪው ሎድ ሚዛኑ ጋር የተያያዘ እና በክላስተር ውስጥ ያለውን ትራፊክ ተጠቅሞ ይመራል። እድገት-Kubernetes ሀብቶች.

እርስ በርስ የሚገናኙ ሌሎች የውስጠ-ክላስተር (ማይክሮ) አገልግሎቶች እንደ አገልግሎቶችን በመጠቀም "መገናኘት" ይችላሉ ክላስተርአይፒ እና አብሮ የተሰራ የአገልግሎት ማግኛ ዘዴ በዲ ኤን ኤስ በኩል። ይህ በመዘግየት ላይ ተጽዕኖ ስለሚያሳድር እና የደመና አገልግሎቶችን ዋጋ ሊጨምር ስለሚችል የእነሱን ይፋዊ ዲ ኤን ኤስ/አይፒ አይጠቀሙ።

4. ክላስተር ባህሪያቱን ከግምት ውስጥ ሳያስገቡ በራስ-ሰር መቁጠር

ኖዶችን ወደ ክላስተር ሲያስወግዷቸው እንደ ሲፒዩ አጠቃቀም ባሉ አንዳንድ መሰረታዊ መለኪያዎች ላይ መተማመን የለብዎትም። የፖድ እቅድ ብዙዎችን ግምት ውስጥ ማስገባት አለበት ገደቦችእንደ ፖድ/መስቀለኛ ቅርበት፣ ንክሻዎች እና መቻቻል፣ የንብረት ጥያቄዎች፣ QoS፣ ወዘተ። እነዚህን ጥቃቅን ነገሮች ግምት ውስጥ ያላስገባ ውጫዊ አውቶማቲክን መጠቀም ወደ ችግሮች ሊመራ ይችላል.

አንድ የተወሰነ ፖድ መርሐግብር ማስያዝ እንዳለበት አስቡት፣ ነገር ግን ሁሉም ያለው የሲፒዩ ኃይል ተጠየቀ/ተገነጠለ እና ፖድ ሁኔታ ውስጥ ይጣበቃል Pending. ውጫዊ አውቶማቲክ መለኪያ አማካይ የአሁኑን ሲፒዩ ጭነት (የተጠየቀውን ሳይሆን) ያያል እና መስፋፋትን አይጀምርም። (መለኪያ መውጣት) - ሌላ መስቀለኛ መንገድ አይጨምርም. በውጤቱም, ይህ ፖድ መርሃ ግብር አይደረግም.

በዚህ ሁኔታ, የተገላቢጦሽ ልኬት (ሚዛን-ውስጥ) - መስቀለኛ መንገድን ከጥቅል ውስጥ ማስወገድ ሁል ጊዜ ለመተግበር የበለጠ ከባድ ነው። ሁኔታዊ ፖድ (ከቋሚ ማከማቻ ጋር የተገናኘ) እንዳለህ አስብ። የማያቋርጥ ጥራዞች ብዙውን ጊዜ የ የተወሰነ ተገኝነት ዞን እና በክልሉ ውስጥ አይደገሙም. ስለዚህ, ውጫዊ አውቶማቲክ ማሽን ከዚህ ፖድ ጋር አንድ መስቀለኛ መንገድን ከሰረዘ, የጊዜ ሰሌዳው አውጪው ይህንን ፖድ በሌላ መስቀለኛ መንገድ ላይ ማቀድ አይችልም, ምክንያቱም ይህ ሊሠራ የሚችለው ዘላቂው ማከማቻ በሚገኝበት በተገኝነት ዞን ውስጥ ብቻ ነው. ፖድ በሁኔታ ውስጥ ተጣብቆ ይቆያል Pending.

በኩበርኔትስ ማህበረሰብ ውስጥ በጣም ታዋቂ ክላስተር-autoscaler. በክላስተር ይሰራል፣ ከዋና ዋና የደመና አቅራቢዎች ኤፒአይዎችን ይደግፋል፣ ሁሉንም ገደቦች ግምት ውስጥ ያስገባ እና ከላይ በተጠቀሱት ጉዳዮች ላይ መጠኑን ሊጨምር ይችላል። እንዲሁም ሁሉንም የተቀመጡ ገደቦችን እየጠበቀ ወደ ውስጥ መግባት ይችላል፣ በዚህም ገንዘብ ይቆጥባል (ይህ ካልሆነ ጥቅም ላይ ላልዋለ አቅም የሚውል)።

5. የIAM/RBAC ችሎታዎችን ችላ ማለት

የ IAM ተጠቃሚዎችን በቋሚ ሚስጥሮች ከመጠቀም ይጠንቀቁ ማሽኖች እና መተግበሪያዎች. ሚናዎችን እና የአገልግሎት መለያዎችን በመጠቀም ጊዜያዊ መዳረሻን ያደራጁ (የአገልግሎት መለያዎች).

ብዙ ጊዜ የመዳረሻ ቁልፎች (እና ሚስጥሮች) በመተግበሪያው ውቅረት ውስጥ ሃርድ ኮድ የተደረገባቸው እና እንዲሁም የ Cloud 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 K8s ውስጥ ለመተግበር ትንሽ የበለጠ ከባድ ነው፣ ነገር ግን በእርግጠኝነት ጥረቱን የሚያስቆጭ ነው።

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. የPodDisruption Budgets ችላ ማለት

በኩበርኔትስ ክላስተር ላይ የምርት ጭነት እንዳለህ አስብ። በየጊዜው፣ አንጓዎች እና ክላስተር ራሱ መዘመን (ወይም መቋረጥ) አለባቸው። PodDisruptionBudget (PDB) በክላስተር አስተዳዳሪዎች እና በተጠቃሚዎች መካከል እንደ የአገልግሎት ዋስትና ስምምነት ያለ ነገር ነው።

ፒዲቢ በአንጓዎች እጥረት ምክንያት የሚመጡ የአገልግሎት መቆራረጦችን እንዲያስወግዱ ይፈቅድልዎታል፡-

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

በዚህ ምሳሌ፣ አንተ፣ እንደ ክላስተር ተጠቃሚ፣ ለአስተዳዳሪዎች “ሄይ፣ የእንስሳት ጥበቃ አገልግሎት አለኝ፣ እና ምንም ብታደርግ፣ ሁልጊዜ የዚህ አገልግሎት ቢያንስ 2 ቅጂዎች እንዲኖሩኝ እፈልጋለሁ።”

ስለዚህ ጉዳይ የበለጠ ማንበብ ይችላሉ እዚህ.

8. ብዙ ተጠቃሚዎች ወይም አካባቢዎች በጋራ ዘለላ

የኩበርኔትስ የስም ቦታዎች (ስም ቦታዎች) ጠንካራ መከላከያ አይስጡ.

የተለመደው የተሳሳተ ግንዛቤ ምርት ያልሆነ ጭነት ወደ አንድ የስም ቦታ እና የምርት ጭነት ወደ ሌላ ካሰማሩ እነሱ በምንም መልኩ አንዳቸው በሌላው ላይ ተጽዕኖ አይኖራቸውም።... ይሁን እንጂ የመርጃ ጥያቄዎችን/ገደቦችን፣ ኮታዎችን በማዘጋጀት እና ቅድሚያ ክፍሎችን በማዘጋጀት የተወሰነ ደረጃ ማግለል ይቻላል። በመረጃ አውሮፕላኑ ውስጥ አንዳንድ “አካላዊ” ማግለል በአፊኒቲስ ፣ መቻቻል ፣ ታይቶች (ወይም nodeselectors) ይሰጣል ፣ ግን እንዲህ ዓይነቱ መለያየት በጣም ጥሩ ነው ። አስቸጋሪ መተግበር።

ሁለቱንም የሥራ ጫናዎች በአንድ ክላስተር ውስጥ ማዋሃድ የሚያስፈልጋቸው ውስብስብ ነገሮችን መቋቋም አለባቸው. እንደዚህ አይነት ፍላጎት ከሌለ, እና አንድ እንዲኖርዎት ማድረግ ይችላሉ አንድ ተጨማሪ ዘለላ (ይበል, በአደባባይ ደመና), ከዚያ ይህን ማድረግ የተሻለ ነው. ይህ በጣም ከፍተኛ የሆነ የሙቀት መከላከያ ደረጃ ይደርሳል.

9. የውጭ የትራፊክ ፖሊሲ፡ ክላስተር

ብዙውን ጊዜ በክላስተር ውስጥ ያሉ ሁሉም ትራፊክ እንደ ኖድፖርት ባሉ አገልግሎት በኩል እንደሚመጡ እናስተውላለን፣ ለዚህም ነባሪው መመሪያ በተቀመጠለት externalTrafficPolicy: Cluster... ማለት ነው መስቀለኛ መንገድ በክላስተር ውስጥ በእያንዳንዱ መስቀለኛ መንገድ ላይ ክፍት ነው, እና ከተፈለገው አገልግሎት (የፖድ ስብስብ) ጋር ለመገናኘት ማንኛቸውንም መጠቀም ይችላሉ.

በተመሳሳይ ጊዜ፣ ከላይ ከተጠቀሰው የኖድፖርት አገልግሎት ጋር የተያያዙ እውነተኛ ፖድዎች አብዛኛውን ጊዜ የሚገኙት በተወሰነው ላይ ብቻ ነው። የእነዚህ አንጓዎች ንዑስ ክፍል. በሌላ አነጋገር፣ የሚፈለገው ፖድ ከሌለው መስቀለኛ መንገድ ጋር ከተገናኘሁ፣ ትራፊክን ወደ ሌላ መስቀለኛ መንገድ ያስተላልፋል፣ ሆፕ መጨመር እና መዘግየትን መጨመር (አንጓዎች በተለያዩ የመገኛ ዞኖች/መረጃ ማዕከሎች ውስጥ የሚገኙ ከሆነ, መዘግየት በጣም ከፍተኛ ሊሆን ይችላል, በተጨማሪም, የመውጣት የትራፊክ ወጪዎች ይጨምራሉ).

በሌላ በኩል፣ የተወሰነ የኩበርኔት አገልግሎት የፖሊሲ ቅንብር ካለው externalTrafficPolicy: Local, ከዚያ NodePort የሚከፈቱት አስፈላጊዎቹ ፖዶች በትክክል በሚሰሩባቸው አንጓዎች ላይ ብቻ ነው. ሁኔታውን የሚፈትሽ የውጭ ጭነት ሚዛን ሲጠቀሙ (የጤና ቁጥጥር) የመጨረሻ ነጥቦች (እንዴት እንደሚሰራ AWS ELB), እሱ ትራፊክ ወደ አስፈላጊ አንጓዎች ብቻ ይልካል, ይህም በመዘግየቶች ላይ ጠቃሚ ተጽእኖ ይኖረዋል, የኮምፒዩተር ፍላጎቶችን, የፍጆታ ሂሳቦችን (እና የጋራ አስተሳሰብ ተመሳሳይ ነው).

እንደዚህ ያለ ነገር ቀድሞውኑ እየተጠቀሙበት የመሆን እድሉ ከፍተኛ ነው። trafik ወይም nginx-ingress-ተቆጣጣሪ እንደ NodePort የመጨረሻ ነጥብ (ወይም LoadBalancer፣ እሱም NodePort የሚጠቀመው) የኤችቲቲፒ መግቢያ ትራፊክን ለመምራት እና ይህን አማራጭ ማዘጋጀት ለእንደዚህ አይነት ጥያቄዎች መዘግየትን በእጅጉ ይቀንሳል።

В ይህ እትም ስለ ውጫዊ የትራፊክ ፖሊሲ፣ ጥቅሞቹ እና ጉዳቶቹ የበለጠ ማወቅ ይችላሉ።

10. ከስብስብ ጋር አይጣመሩ እና የመቆጣጠሪያውን አውሮፕላን አላግባብ አይጠቀሙ

ከዚህ ቀደም አገልጋዮችን በትክክለኛ ስሞች መጥራት የተለመደ ነበር፡- አንቶን፣ HAL9000 እና ኮሎሰስ... ዛሬ በዘፈቀደ በተፈጠሩ መለያዎች ተተክተዋል። ሆኖም፣ ልማዱ ቀረ፣ እና አሁን ትክክለኛ ስሞች ወደ ዘለላዎች ይሄዳሉ።

የተለመደ ታሪክ (በእውነተኛ ክስተቶች ላይ የተመሰረተ)፡ ሁሉም የተጀመረው በፅንሰ-ሃሳብ ማረጋገጫ ነው፣ ስለዚህ ክላስተር የሚያኮራ ስም ነበረው። ሙከራ… ዓመታት አለፉ እና አሁንም ለምርት ስራ ላይ ይውላል፣ እና ሁሉም ሰው ለመንካት ይፈራል።

ክላስተሮች ወደ የቤት እንስሳት ሲቀየሩ ምንም የሚያስደስት ነገር የለም፣ ስለዚህ በሚለማመዱበት ጊዜ በየጊዜው እንዲያስወግዷቸው እንመክራለን የአደጋ ማገገም (ይህ ይረዳል ትርምስ ምህንድስና - በግምት. መተርጎም). በተጨማሪም, በመቆጣጠሪያው ንብርብር ላይ መስራት አይጎዳውም (የመቆጣጠሪያ አውሮፕላን). እሱን ለመንካት መፍራት ጥሩ ምልክት አይደለም. ወዘተ ሞቷል? ወንዶች ፣ በእርግጥ ችግር ውስጥ ናችሁ!

በአንጻሩ ደግሞ እሱን በማጭበርበር መወሰድ የለብህም። ከጊዜ ጋር የመቆጣጠሪያው ንብርብር ቀርፋፋ ሊሆን ይችላል. ምናልባትም ይህ የሆነበት ምክንያት ብዙ ቁጥር ያላቸው ነገሮች ሳይዞሩ በመፈጠሩ ነው (ሄልምን ከነባሪ ቅንጅቶች ጋር ሲጠቀሙበት የተለመደ ሁኔታ ነው ፣ ለዚህም ነው በውቅሮች / ምስጢሮች ውስጥ ያለው ሁኔታ ያልዘመነው - በውጤቱም ፣ በሺዎች የሚቆጠሩ ነገሮች ይከማቻሉ። የመቆጣጠሪያው ንብርብር) ወይም የ kube-api ዕቃዎችን በቋሚነት በማስተካከል (ለራስ-ሰር ልኬት, ለ CI / ሲዲ, ለክትትል, የክስተት ምዝግቦች, ተቆጣጣሪዎች, ወዘተ.).

በተጨማሪም፣ የ SLA/SLO ስምምነቶችን ከሚተዳደረው Kubernetes አቅራቢ ጋር መፈተሽ እና ለዋስትናዎቹ ትኩረት መስጠትን እንመክራለን። ሻጩ ዋስትና መስጠት ይችላል የመቆጣጠሪያ ንብርብር መገኘት (ወይም ንዑስ ክፍሎቹ)፣ ነገር ግን ወደ እሱ የላኩት የ p99 ጥያቄዎች መዘግየት አይደለም። በሌላ አነጋገር መግባት ትችላለህ kubectl get nodes, እና ከ 10 ደቂቃዎች በኋላ ብቻ መልስ ይቀበሉ, እና ይህ የአገልግሎት ውሉን መጣስ አይሆንም.

11. ጉርሻ: የቅርብ መለያ በመጠቀም

ግን ይህ ቀድሞውኑ ክላሲክ ነው። ከቅርብ ጊዜ ወዲህ ይህን ዘዴ ያገኘነው ብዙ ጊዜ ነው፣ ብዙዎች፣ ከመራራ ልምድ በመማር መለያውን መጠቀም ስላቆሙ ነው። :latest እና ስሪቶችን መሰካት ጀመረ። ሆራይ!

ECR የምስል መለያዎች የማይለወጡ ናቸው; በዚህ አስደናቂ ባህሪ እራስዎን በደንብ እንዲያውቁ እንመክርዎታለን።

ማጠቃለያ

ሁሉም ነገር በአንድ ጀንበር እንደሚሰራ አትጠብቅ፡ ኩበርኔትስ መድኃኒት አይደለም። መጥፎ መተግበሪያ በ Kubernetes ውስጥ እንኳን በዚህ መንገድ ይቆያል (እና ምናልባት የከፋ ይሆናል). ግድየለሽነት ከመጠን በላይ ውስብስብነት ፣ ቀርፋፋ እና አስጨናቂ የቁጥጥር ንብርብር ስራን ያስከትላል። በተጨማሪም፣ ያለአደጋ ማገገሚያ ስትራቴጂ የመተው አደጋ ሊያጋጥምዎት ይችላል። ኩበርኔትስ ከሳጥኑ ውጭ መገለልን እና ከፍተኛ አቅርቦትን ይሰጣል ብለው አይጠብቁ። መተግበሪያዎን በእውነት የደመና ቤተኛ ለማድረግ የተወሰነ ጊዜ ይውሰዱ።

በ ውስጥ ካሉ የተለያዩ ቡድኖች ያልተሳኩ ተሞክሮዎች ጋር መተዋወቅ ይችላሉ። ይህ የታሪክ ስብስብ በሄኒንግ ጃኮብስ.

በዚህ ጽሑፍ ውስጥ በተሰጡት ስህተቶች ዝርዝር ውስጥ ለመጨመር የሚፈልጉ ሰዎች በ Twitter ላይ ሊያገኙን ይችላሉ (@MarekBartik, @Mstrs ታዛቢ).

PS ከተርጓሚ

በብሎጋችን ላይ ያንብቡ፡-

• «የኩበርኔትስ ስብስቦችን መንደፍ፡ ስንት መሆን አለበት?";
• «የ ABC ደህንነት በኩበርኔትስ፡ ማረጋገጫ፣ ፍቃድ፣ ኦዲት";
• «በኩበርኔትስ ውስጥ የራስ-ስኬል እና የንብረት አስተዳደር"(የግምገማ እና የቪዲዮ ዘገባ);
• «ConfigMaps በ Kubernetes ውስጥ፡ ማወቅ የሚገባቸው ልዩነቶች».

ምንጭ: hab.com