በኩበርኔትስ ውስጥ የራስ-ስኬል እና የንብረት አስተዳደር (አጠቃላይ እይታ እና የቪዲዮ ዘገባ)

ኤፕሪል 27 በጉባኤው አድማ-2019, በ "DevOps" ክፍል ውስጥ "በኩበርኔትስ ውስጥ አውቶማቲክ እና የንብረት አያያዝ" ሪፖርት ቀርቧል. ከፍተኛ የአፕሊኬሽኖች መገኘትን ለማረጋገጥ እና ከፍተኛ አፈፃፀማቸውን ለማረጋገጥ K8s እንዴት እንደሚጠቀሙ ያብራራል።

በወጉ, በማቅረብ ደስ ይለናል ቪዲዮ ከሪፖርቱ ጋር (44 ደቂቃዎች፣ ከጽሑፉ የበለጠ መረጃ ሰጭ) እና ዋናው ማጠቃለያ በጽሁፍ መልክ። ሂድ!

የሪፖርቱን ርዕስ በቃላት እንመርምርና ከመጨረሻው እንጀምር።

ኩባንያቶች

በአስተናጋጁ ላይ Docker ኮንቴይነሮች አሉን እንበል። ለምንድነው? ተደጋጋሚነት እና ማግለል ለማረጋገጥ, ይህም በተራው ቀላል እና ጥሩ ማሰማራት, CI / ሲዲ. ብዙ እንዲህ ዓይነት የጭነት መኪናዎች ኮንቴይነሮች አለን።

በዚህ ጉዳይ ላይ Kubernetes ምን ይሰጣል?

1. ስለእነዚህ ማሽኖች ማሰብ አቁመን ከ "ደመና" ጋር መስራት እንጀምራለን. የእቃ መያዣዎች ስብስብ ወይም ፖድ (የመያዣዎች ቡድኖች).
2. በተጨማሪም ፣ ስለ ግለሰባዊ እንክብሎች እንኳን አናስብም ፣ ግን የበለጠ ያቀናብሩоትላልቅ ቡድኖች. እንደዚህ ከፍተኛ-ደረጃ primitives አንድን የተወሰነ የሥራ ጫና ለማስኬድ ስርዓተ-ጥለት እንዳለ እንድንናገር ፍቀድለት፣ ነገር ግን እሱን ለማስኬድ ትክክለኛው የአብነት ብዛት። በመቀጠል አብነቱን ከቀየርን ሁሉም ሁኔታዎች እንዲሁ ይለወጣሉ።
3. በ እገዛ ገላጭ ኤፒአይ የተወሰኑ ትዕዛዞችን ቅደም ተከተል ከማስፈፀም ይልቅ በኩበርኔትስ የተፈጠረውን "የአለምን መሳሪያ" (በ YAML) እንገልፃለን። እና እንደገና፡ መግለጫው ሲቀየር ትክክለኛው ማሳያውም ይለወጣል።

የሃብት አያያዝ

ሲፒዩ

በአገልጋዩ ላይ nginx፣ php-fpm እና mysql እናሄድ። እነዚህ አገልግሎቶች በእውነቱ የበለጠ ተጨማሪ የማስኬጃ ሂደቶች ይኖሯቸዋል፣ እያንዳንዳቸው የኮምፒዩተር ግብዓቶችን ይጠይቃሉ፡

(በስላይድ ላይ ያሉት ቁጥሮች "በቀቀኖች" ናቸው ፣ የእያንዳንዱ ሂደት የኮምፒዩተር ኃይል ረቂቅ ፍላጎት)

ከዚህ ጋር በተመጣጣኝ ሁኔታ ለመስራት, ሂደቶችን በቡድን ማዋሃድ ምክንያታዊ ነው (ለምሳሌ, ሁሉም የ nginx ሂደቶች ወደ አንድ "nginx" ቡድን). ይህንን ለማድረግ ቀላል እና ግልፅ መንገድ እያንዳንዱን ቡድን በእቃ መያዣ ውስጥ ማስገባት ነው-

ለመቀጠል, መያዣ (በሊኑክስ ውስጥ) ምን እንደሆነ ማስታወስ ያስፈልግዎታል. የእነሱ ገጽታ ለረጅም ጊዜ ሲተገበሩ በነበሩት በከርነል ውስጥ ለሦስት ቁልፍ ባህሪዎች ምስጋና ይግባቸው ነበር። ችሎታዎች, የስም ቦታዎች и ቡድኖች. እና ሌሎች ቴክኖሎጂዎች ለቀጣይ እድገት አስተዋፅዖ አበርክተዋል (እንደ ዶከር ያሉ ምቹ “ዛጎሎች”ን ጨምሮ)

በሪፖርቱ አውድ ውስጥ, እኛ ብቻ ፍላጎት አለን ቡድኖች, ምክንያቱም የመያዣዎች ተግባራዊነት አካል የሆኑት የቁጥጥር ቡድኖች (ዶከር, ወዘተ) የንብረት አስተዳደርን ተግባራዊ ያደርጋሉ. እንደፈለግነው በቡድን የተዋሃዱ ሂደቶች የቁጥጥር ቡድኖች ናቸው.

ወደ እነዚህ ሂደቶች የሲፒዩ ፍላጎቶች እና አሁን ለሂደቶች ቡድኖች እንመለስ፡-

(ሁሉም ቁጥሮች የሀብት ፍላጎት ረቂቅ መግለጫ መሆናቸውን እደግመዋለሁ)

በተመሳሳይ ጊዜ, ሲፒዩ ራሱ የተወሰነ ገደብ ያለው ምንጭ አለው (በምሳሌው 1000 ነው), ሁሉም ሰው ሊጎድለው ይችላል (የሁሉም ቡድኖች ፍላጎት ድምር 150+850+460=1460 ነው). በዚህ ጉዳይ ላይ ምን ይሆናል?

ከርነል ሀብቶችን ማሰራጨት ይጀምራል እና "በፍትሃዊ" ያደርገዋል, ለእያንዳንዱ ቡድን ተመሳሳይ መጠን ያለው ሀብት ይሰጣል. ግን በመጀመሪያው ሁኔታ ከሚያስፈልገው በላይ (333>150) አሉ ፣ ስለሆነም ትርፍ (333-150 = 183) በመጠባበቂያ ውስጥ ይቆያል ፣ ይህም በሌሎቹ ሁለት ኮንቴይነሮች መካከል በእኩል ይሰራጫል ።

በውጤቱም-የመጀመሪያው ኮንቴይነር በቂ ሀብቶች ነበሩት, ሁለተኛው በቂ አልነበረም, ሶስተኛው በቂ አልነበረም. ይህ የተግባር ውጤት ነው። በሊኑክስ ውስጥ "ታማኝ" መርሐግብር - CFS. የእሱን አሠራር በመመደብ መቆጣጠር ይቻላል ክብደት እያንዳንዱ መያዣዎች. ለምሳሌ፣ እንደዚህ፡-

በሁለተኛው ኮንቴይነር (php-fpm) ውስጥ የግብዓት እጥረት ሁኔታን እንይ. ሁሉም የመያዣ ሃብቶች በሂደቶች መካከል እኩል ይሰራጫሉ. በውጤቱም ፣ የማስተር ሂደቱ በጥሩ ሁኔታ ይሰራል ፣ እና ሁሉም ሰራተኞች ከሚፈልጉት ከግማሽ በታች በመቀበል ፍጥነት ይቀንሳል።

የCFS መርሐግብር አዘጋጅ የሚሠራው በዚህ መንገድ ነው። ወደ ኮንቴይነሮች የምንመድበው ክብደቶች ይጠራሉ ጥያቄዎች. ይህ ለምን እንደሆነ - ተጨማሪ ይመልከቱ.

አጠቃላይ ሁኔታውን ከሌላኛው ወገን እንይ። እንደምታውቁት, ሁሉም መንገዶች ወደ ሮም, እና በኮምፒተር ውስጥ, ወደ ሲፒዩ ያመራሉ. አንድ ሲፒዩ፣ ብዙ ተግባራት - የትራፊክ መብራት ያስፈልግዎታል። ሀብቶችን ለማስተዳደር ቀላሉ መንገድ "የትራፊክ መብራት" ነው: ለአንድ ሂደት ወደ ሲፒዩ ለመድረስ የተወሰነ ጊዜ ሰጡ, ከዚያም ቀጣዩ, ወዘተ.

ይህ አካሄድ ሃርድ ጥቅስ ይባላል። (ጠንካራ ገደብ). እስቲ እናስታውሰው ገደቦች. ነገር ግን በሁሉም ኮንቴይነሮች ላይ ገደቦችን ብናከፋፍል ችግር ይፈጠራል፡ mysql በመንገድ ላይ እየነዳ ነበር እና በሆነ ጊዜ የሲፒዩ ፍላጎቱ አብቅቷል፣ ነገር ግን ሁሉም ሌሎች ሂደቶች ሲፒዩ እስኪጠብቁ ድረስ ይገደዳሉ። ስራ ፈት.

ወደ ሊኑክስ ከርነል እና ከሲፒዩ ጋር ያለውን መስተጋብር እንመለስ - አጠቃላይ ስዕሉ እንደሚከተለው ነው።

ግሩፕ ሁለት ቅንጅቶች አሉት - በእውነቱ ፣ እነዚህ ሁለት ቀላል “ጠማማዎች” ናቸው ፣ ይህም እንዲወስኑ ያስችልዎታል-

1. ለመያዣው ክብደት (ጥያቄዎች) ነው። ማጋራቶች;
2. በኮንቴይነር ተግባራት (ገደቦች) ላይ ለመስራት የሚያጠፋው የጠቅላላ ሲፒዩ ጊዜ መቶኛ ነው። ኮታ.

ሲፒዩ እንዴት እንደሚለካ?

የተለያዩ መንገዶች አሉ፡-

1. ምን በቀቀኖች, ማንም አያውቅም - በእያንዳንዱ ጊዜ መደራደር ያስፈልግዎታል.
2. ፍላጎት ይበልጥ ግልጽ፣ ግን አንጻራዊ፡ 50% አገልጋይ 4 ኮር እና 20 ኮር ሙሉ ለሙሉ የተለያዩ ነገሮች ናቸው።
3. ቀደም ሲል የተጠቀሰውን መጠቀም ይችላሉ ክብደትሊኑክስ የሚያውቀው ግን አንጻራዊ ናቸው።
4. በጣም በቂው አማራጭ የኮምፒተር ሀብቶችን በ ውስጥ መለካት ነው ሰከንዶች. እነዚያ። በሰከንዶች የአቀነባባሪ ጊዜ ከእውነተኛ ጊዜ ሴኮንድ ጋር በተያያዘ: በ 1 እውነተኛ ሰከንድ ውስጥ 1 ሰከንድ የአቀነባባሪ ጊዜ ሰጡ - ይህ አንድ ሙሉ ሲፒዩ ኮር ነው።

ለመናገር እንኳን ቀላል ለማድረግ በቀጥታ ወደ ውስጥ መለካት ጀመሩ ኒውክሊየስከእውነተኛው ጋር ተመሳሳይ የሆነ የሲፒዩ ጊዜ ማለት ነው. ሊኑክስ ክብደቶችን ስለሚረዳ እና እንደዚህ አይነት ሲፒዩ ጊዜ/ኮርን ስላልሆነ፣ ከአንዱ ወደ ሌላው ለመተርጎም ዘዴ አስፈለገ።

ቀለል ያለ የአገልጋይ ምሳሌ ከ3 ሲፒዩ ኮሮች ጋር እንመልከት፣ ሶስት ፖዶች ክብደቶች (500፣ 1000 እና 1500) በቀላሉ ወደተመደቡባቸው ኮሮች (0,5፣ 1 እና 1,5) ወደየየራሳቸው ክፍል የሚለወጡ።

ሁለተኛውን አገልጋይ ወስደን ሁለት እጥፍ ኮሮች (6) ያሉበትን ቦታ ወስደን ተመሳሳይ ፖዶችን እዚያ ላይ ካስቀመጥን የኮር ስርጭቱ በቀላሉ በ 2 (1, 2 እና 3, በቅደም ተከተል) በማባዛት በቀላሉ ማስላት ይቻላል. ነገር ግን አንድ አስፈላጊ ጊዜ አራተኛው ፖድ በዚህ አገልጋይ ላይ ሲታይ, ክብደቱ, ለምቾት, 3000 ይሆናል, አንዳንድ የሲፒዩ ሀብቶችን (ግማሹን ኮርሶች) ይወስዳል እና ከቀሪዎቹ እንክብሎች እንደገና ይሰላሉ. (ግማሽ)

Kubernetes እና ሲፒዩ መርጃዎች

በኩበርኔትስ፣ የሲፒዩ ሃብቶች ብዙውን ጊዜ የሚለኩት በ ውስጥ ነው። ሚሊድራች፣ ማለትም እ.ኤ.አ. 0,001 እንክብሎች እንደ መሰረታዊ ክብደት ይወሰዳሉ. (በተመሳሳይ ነገር በሊኑክስ/ቡድኖች የቃላት አገባብ ውስጥ የሲፒዩ ድርሻ ይባላል፣ ምንም እንኳን የበለጠ ትክክለኛ ቢሆንም፣ 1000 ሚሊኮርስ = 1024 ሲፒዩ ማጋራቶች።) K8s የሁሉም ፖድ ክብደት ድምር ሲፒዩ ሃብቶች ካሉት በላይ በአገልጋዩ ላይ ብዙ ፖድ አለማስቀመጥን ያረጋግጣል።

ይህ እንዴት ይሆናል? አገልጋይ ወደ ኩበርኔትስ ክላስተር ሲታከል ምን ያህል ሲፒዩ ኮርሶች እንዳሉት ይዘግባል። እና አዲስ ፖድ ሲፈጠር የኩበርኔትስ መርሐግብር አዘጋጅ ፖድ ምን ያህል ኮርሞች እንደሚያስፈልገው ያውቃል። ስለዚህ, ፖዱ በአገልጋዩ ላይ ይገለጻል, በቂ ኮርሶች ባሉበት.

ከሆነ ምን ይሆናል አይደለም ጥያቄው ይገለጻል (ማለትም የሚፈልገው የኮሮች ብዛት ለፖድ አልተገለጸም)? ኩበርኔትስ በአጠቃላይ ሀብቶችን እንዴት እንደሚቆጥር እንይ።

ፖድ ሁለቱንም ጥያቄዎች (CFS መርሐግብር አዘጋጅ) እና ገደቦች ሊኖሩት ይችላል (የትራፊክ መብራቱን ያስታውሱ?)

• እኩል ከሆኑ ፖዱ የQoS ክፍል ተመድቧል የተረጋገጠ. ለእሱ ሁልጊዜ የሚገኙ ይህ የኮሮች ቁጥር የተረጋገጠ ነው.
• ጥያቄው ከገደቡ ያነሰ ከሆነ - QoS ክፍል ሊፈነዳ የሚችል. እነዚያ። ፖድ ሁል ጊዜ 1 ኮር እንዲጠቀም እንጠብቃለን ነገርግን ይህ ዋጋ ለእሱ ገደብ አይደለም፡ አንዳንድ ጊዜ ፖድ የበለጠ መጠቀም ይችላል (አገልጋዩ ለዚህ ነፃ ሀብቶች ሲኖረው)።
• የQoS ክፍልም አለ። ምርጥ ጥረት - ጥያቄው ያልተገለፀባቸውን ፖዶች ያካትታል. ግብዓቶች ለመጨረሻ ጊዜ ተሰጥቷቸዋል.

አእምሮ

በማስታወስ, ሁኔታው ​​ተመሳሳይ ነው, ግን ትንሽ የተለየ ነው - ከሁሉም በላይ, የእነዚህ ሀብቶች ተፈጥሮ የተለየ ነው. በአጠቃላይ ምስሉ የሚከተለው ነው።

ጥያቄዎች በማህደረ ትውስታ ውስጥ እንዴት እንደሚተገበሩ እንይ። ፖድቹ የሚበሉትን የማህደረ ትውስታ መጠን በመለዋወጥ በአገልጋዩ ላይ እንዲኖሩ ያድርጉ፣ አንዳቸው በጣም ትልቅ እስኪሆን ድረስ ማህደረ ትውስታ እስኪያልቅ ድረስ። በዚህ አጋጣሚ የ OOM ገዳይ ብቅ አለ እና ትልቁን ሂደት ይገድላል፡

ይህ ሁልጊዜ አይስማማንም, ስለዚህ የትኞቹ ሂደቶች ለእኛ አስፈላጊ እንደሆኑ እና መገደል እንደሌለባቸው መቆጣጠር ይቻላል. ይህንን ለማድረግ መለኪያውን ይጠቀሙ oom_score_adj.

ወደ ሲፒዩ QoS ክፍሎች እንመለስ እና የማህደረ ትውስታ ፍጆታ ቅድሚያ የሚሰጣቸውን የ oom_score_adj እሴቶች ጋር ተመሳሳይነት እንሳል።

• ለፖድ ዝቅተኛው የ oom_score_adj ዋጋ -998 ነው፣ ይህ ማለት እንዲህ ያለው ፖድ በመጨረሻው ዙር መገደል አለበት ማለት ነው። የተረጋገጠ.
• ከፍተኛው 1000 ነው ምርጥ ጥረት, እንዲህ ያሉ እንክብሎች መጀመሪያ ይገደላሉ.
• የተቀሩትን ዋጋዎች ለማስላት (ሊፈነዳ የሚችል) ቀመር አለ፣ ዋናው ነገር ፖድ በጠየቀ ቁጥር የመገደሉ ዕድሉ ይቀንሳል።

ሁለተኛው "ማዞር" - በባይት_ውስጥ_ገደብ - ለገደብ. በእሱ አማካኝነት, ሁሉም ነገር ቀላል ነው: በቀላሉ የሚወጣውን ከፍተኛውን የማህደረ ትውስታ መጠን እንመድባለን, እና እዚህ (ከሲፒዩ በተለየ መልኩ) ምን (ማህደረ ትውስታ) መመዘን እንዳለበት ምንም ጥያቄ የለም.

ԸՆԴՀԱՆՈՒՐ ԳԻՆ

በኩበርኔትስ ውስጥ ያለው እያንዳንዱ ፖድ ተሰጥቷል requests и limits - ሁለቱም መለኪያዎች ለሲፒዩ እና ለማህደረ ትውስታ;

1. በጥያቄዎች ላይ በመመስረት የኩበርኔትስ መርሐግብር አዘጋጅ ይሠራል ፣ ይህም በአገልጋዮች መካከል ፓዶችን ያሰራጫል ፣
2. በሁሉም መመዘኛዎች ላይ በመመስረት, የፖድ QoS ክፍል ይወሰናል;
3. አንጻራዊ ክብደቶች በሲፒዩ ጥያቄዎች መሰረት ይሰላሉ;
4. በሲፒዩ ጥያቄዎች ላይ በመመስረት, የ CFS መርሐግብር አዘጋጅ ተዋቅሯል;
5. OOM ገዳይ በማህደረ ትውስታ ጥያቄዎች መሰረት ተዋቅሯል።
6. "የትራፊክ መብራት" በሲፒዩ ገደቦች መሰረት ተዋቅሯል;
7. የማህደረ ትውስታ ገደብ በ cgroup'u ላይ ያለው ገደብ ተስተካክሏል.

በአጠቃላይ ይህ ስዕል በኩበርኔትስ ውስጥ የንብረት አያያዝ ዋና አካል እንዴት እንደሚከሰት ሁሉንም ጥያቄዎች ይመልሳል.

አውቶማቲካሊንግ

K8s ክላስተር-autoscaler

ሙሉው ክላስተር ስራ በዝቶበታል እና አዲስ ፖድ መፈጠር እንዳለበት አስቡት። ፖድው እስኪታይ ድረስ በሁኔታው ላይ ይንጠለጠላል በመጠባበቅ ላይ. እንዲታይ ለማድረግ አዲስ አገልጋይን ከክላስተር ጋር ማገናኘት እንችላለን ወይም ... ክላስተር-አውቶስካለርን ጫንልን፡ ቨርቹዋል ማሽን ከዳመና አቅራቢው (በኤፒአይ ጥያቄ) በማዘዝ ያገናኘዋል። ወደ ክላስተር, ከዚያ በኋላ ፖድው ይጨመራል .

ይህ የኩበርኔትስ ክላስተር አውቶማቲክ ነው፣ እሱም በጣም ጥሩ ይሰራል (በእኛ ልምድ)። ሆኖም ፣ እንደሌላው ቦታ ፣ እዚህ አንዳንድ ልዩነቶች አሉ…

የክላስተር መጠኖችን በጨመርንበት ጊዜ ሁሉም ነገር ጥሩ ነበር፣ ግን ክላስተር ሲከሰት ምን ይከሰታል መልቀቅ ጀመረ? ችግሩ የሚፈልሰው ፖድ (ወደ ነጻ አስተናጋጆች) በቴክኒካል በጣም አስቸጋሪ እና ከሀብት አንፃር ውድ ነው። ኩበርኔትስ በጣም የተለየ አቀራረብ አለው.

ማሰማራት ያላቸውን የ3 አገልጋዮች ስብስብ አስቡበት። እሱ 6 ፓዶች አሉት: አሁን ለእያንዳንዱ አገልጋይ 2 ነው. በሆነ ምክንያት ከአገልጋዮቹ አንዱን መዝጋት እንፈልጋለን። ይህንን ለማድረግ, ትዕዛዙን እንጠቀማለን kubectl drainይህም፡-

• ወደዚህ አገልጋይ አዲስ ፖድ መላክን መከልከል;
• በአገልጋዩ ላይ ያሉትን ፖዶች ይሰርዛል።

ኩበርኔትስ የፖዳዎችን ቁጥር (6) ስለሚከታተል በቀላሉ እንደገና ይፈጥራል በሌሎች አንጓዎች ላይ፣ ነገር ግን በሚዘጋው ላይ አይደለም፣ ምክንያቱም አስቀድሞ አዲስ ፖድ ለማስተናገድ እንደማይቻል ምልክት ተደርጎበታል። ይህ ለኩበርኔትስ መሰረታዊ መካኒክ ነው።

ሆኖም ፣ እዚህም አንድ ልዩነት አለ። በተመሳሳይ ሁኔታ ለStatefulSet (ከማሰማራት ይልቅ) ድርጊቶቹ የተለዩ ይሆናሉ። አሁን ስቴት ያለው አፕሊኬሽን አለን - ለምሳሌ ከMongoDB ጋር ሶስት ፖዶች አንዱ የሆነ ችግር ነበረው (መረጃ ተበላሽቷል ወይም ፖዱ በትክክል እንዳይጀምር ያደረገ ሌላ ስህተት)። እና አንድ አገልጋይ ለመዝጋት እንደገና እንወስናለን. ምን ይሆናል?

MongODB ይችላል ምልአተ ጉባኤ ስለሚያስፈልገው ይሙት፡ ለሦስት ተከላዎች ክላስተር፣ ቢያንስ ሁለቱ ሥራ ላይ መዋል አለባቸው። ሆኖም, ይህ እየተከሰተ አይደለም - ይመስገን PodDisruption በጀት. ይህ ግቤት የሚፈለገውን አነስተኛውን የሩጫ ፖድ ቁጥር ይገልጻል። ከMongoDB ፖዶች አንዱ ከአሁን በኋላ እየሰራ እንዳልሆነ ማወቅ እና MongoDB PodDisruptionBudget እንዳለው ማየት minAvailable: 2, Kubernetes ፖድዎን እንዲሰርዙ አይፈቅድልዎትም.

የታችኛው መስመር፡ ክላስተር በሚለቀቅበት ጊዜ የፖዳዎች እንቅስቃሴ (እና በእውነቱ እንደገና መፈጠር) በትክክል እንዲሰራ የPodDisruptionBudget ን ማዋቀር ያስፈልግዎታል።

አግድም ልኬት

ሌላ ሁኔታን እንመልከት። በኩበርኔትስ ውስጥ እንደ ማሰማራት የሚሰራ መተግበሪያ አለ። የተጠቃሚ ትራፊክ ወደ ፖድፖቹ ይመጣል (ለምሳሌ ሦስቱ አሉ) እና በውስጣቸው የተወሰነ አመልካች እንለካለን (በሲፒዩ ላይ ያለውን ጭነት ይበሉ)። ጭነቱ ሲጨምር, እንደ መርሃግብሩ እናስተካክለዋለን እና ጥያቄዎችን ለማሰራጨት የፖዳዎች ብዛት እንጨምራለን.

ዛሬ ፣ በ Kubernetes ፣ ይህ በእጅ መከናወን አያስፈልገውም-በሚለካው የጭነት አመልካቾች ዋጋዎች ላይ በመመርኮዝ የፖዳዎች ብዛት በራስ-ሰር መጨመር / መቀነስ ተዋቅሯል።

ዋናዎቹ ጥያቄዎች እዚህ አሉ። ምን እንደሚለካ и እንዴት እንደሚተረጎም የተቀበሉት ዋጋዎች (የፖዳዎችን ቁጥር ለመቀየር ውሳኔ ለማድረግ) ብዙ ነገሮችን መለካት ይቻላል።

በቴክኒካዊ መንገድ እንዴት እንደሚደረግ - መለኪያዎችን ይሰብስቡ, ወዘተ. - በሪፖርቱ ውስጥ በዝርዝር ተናግሬያለሁ ክትትል እና Kubernetes. እና ምርጥ መለኪያዎችን ለመምረጥ ዋናው ምክር ነው ሙከራ!

አሉ የአጠቃቀም ዘዴ (የአጠቃቀም ሙሌት እና ስህተቶች) ትርጉሙም እንደሚከተለው ነው። ምን ላይ በመመስረት, ለምሳሌ, php-fpm መመዘን ትርጉም ያለው? ሰራተኞቹ እያለቀባቸው ነው በሚለው እውነታ መሰረት ይህ ነው። አጠቃቀም. እና ሰራተኞቹ ካለቁ እና አዲስ ግንኙነቶች ካልተቀበሉ, ይህ ቀድሞውኑ ነው ሙሌት. እነዚህ ሁለቱም መመዘኛዎች መለካት አለባቸው, እና በእሴቶቹ ላይ በመመስረት, መለካት መከናወን አለበት.

ከዚህ ይልቅ አንድ መደምደሚያ

ሪፖርቱ ቀጣይነት አለው፡ ስለ አቀባዊ ልኬት እና ትክክለኛ መገልገያዎችን እንዴት መምረጥ እንደሚቻል። ስለዚህ ጉዳይ ወደፊት በሚታዩ ቪዲዮዎች ውስጥ እናገራለሁ የእኛ ዩቲዩብ - እንዳያመልጥዎ ሰብስክራይብ ያድርጉ!

ቪዲዮዎች እና ስላይዶች

የአፈፃፀም ቪዲዮ (44 ደቂቃዎች)

የዝግጅት አቀራረብን ሪፖርት ያድርጉ፡

PS

በብሎጋችን ውስጥ ስለ ኩበርኔትስ ሌሎች ዘገባዎች፡-

• «Kubernetes ማራዘም እና ማሟያ» (አንድሬ ፖሎቮቭ፣ ኤፕሪል 8፣ 2019 በ Saint HighLoad++ ላይ);
• «የውሂብ ጎታዎች እና Kubernetes» (ዲሚትሪ ስቶልያሮቭ፣ ኖቬምበር 8፣ 2018 በሃይሎድ++ ላይ);
• «ክትትል እና Kubernetes» (ዲሚትሪ ስቶልያሮቭ፣ ሜይ 28፣ 2018 በRootConf);
• «CI/ሲዲ ከ Kubernetes እና GitLab ጋር ያሉ ምርጥ ልምዶች» (ዲሚትሪ ስቶልያሮቭ፣ ኖቬምበር 7፣ 2017 በሃይሎድ++ ላይ);
• «በትንሽ ፕሮጀክቶች ውስጥ ከ Kubernetes ጋር ያለን ልምድ» (ዲሚትሪ ስቶልያሮቭ፣ ሰኔ 6፣ 2017 በRootConf).

ምንጭ: hab.com