ዘጠኝ የኩበርኔትስ የአፈጻጸም ምክሮች

ሰላም ሁላችሁም! ስሜ Oleg Sidorenkov እባላለሁ, DomClick ውስጥ እንደ የመሠረተ ልማት ቡድን መሪ እሰራለሁ. ከሶስት አመታት በላይ ለሽያጭ የ Cube ን እየተጠቀምን ነበር, እና በዚህ ጊዜ ውስጥ ብዙ የተለያዩ አስደሳች ጊዜዎችን አጋጥሞናል. ዛሬ እነግርዎታለሁ ፣ በትክክለኛው አቀራረብ ፣ ከቫኒላ ኩበርኔትስ ለክላስተርዎ የበለጠ አፈፃፀምን እንዴት እንደሚጭኑ። ዝግጁ ሁን!

ኩበርኔትስ ለኮንቴይነር ኦርኬስትራ ሊሰፋ የሚችል ክፍት ምንጭ ስርዓት መሆኑን ሁላችሁም በደንብ ታውቃላችሁ። ጥሩ፣ ወይም 5 የሁለትዮሽ አገልግሎት የማይክሮ ሰርቪስዎን የህይወት ኡደት በአገልጋይ አካባቢ በማስተዳደር አስማት የሚሰሩ። በተጨማሪም, ይህ ለተለያዩ ስራዎች ከፍተኛውን ለማበጀት እንደ Lego ገንቢ ሊገጣጠም የሚችል ተመጣጣኝ ተለዋዋጭ መሳሪያ ነው.

እና ሁሉም ነገር ጥሩ ይመስላል: አገልጋዮችን ወደ ክላስተር, እንደ ማገዶ ወደ ማገዶ ሳጥን ውስጥ ይጥሉ, እና ሀዘንን አያውቁም. ግን ለአካባቢው ከሆንክ ፣ “እሳትን በምድጃ ውስጥ እንዴት ማቆየት እና ጫካውን መጸጸት የምችለው እንዴት ነው?” ብለው ያስባሉ። በሌላ አነጋገር መሠረተ ልማትን ለማሻሻል እና ወጪዎችን ለመቀነስ መንገዶችን እንዴት መፈለግ እንደሚቻል።

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የኦፕስ ትዕዛዙ ሌላ 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. ምርጡን የፋይል ማከማቻ ይምረጡ

እዚህ የቋሚ ጥራዞች ርዕስ እና የ Kubernetes ሰራተኛ አንጓዎች የዲስክ ንዑስ ስርዓትን መንካት እፈልጋለሁ። ማንም ሰው "Cube" በ HDD ላይ በምርት ላይ እንደማይጠቀም ተስፋ አደርጋለሁ, ነገር ግን አንዳንድ ጊዜ መደበኛ ኤስኤስዲ እንኳን በቂ አይደለም. እኛ እንደዚህ ያለ ችግር አጋጥሞናል ምዝግብ ማስታወሻዎች ዲስኩን በ I / O ኦፕሬሽኖች እየገደሉት ነበር ፣ እና እዚህ ብዙ መፍትሄዎች የሉም

• ከፍተኛ አፈጻጸም ያላቸውን ኤስኤስዲዎች ተጠቀም ወይም ወደ NVMe ቀይር (የራስህን ሃርድዌር የምታስተዳድር ከሆነ)።

• የመግቢያ ደረጃን ይቀንሱ.

• ዲስኩን የሚደፍሩ ፖዶችን "ብልጥ" ማመጣጠን ያድርጉ (podAntiAffinity).

ከላይ ያለው ቅጽበታዊ ገጽ እይታ በ nginx-ingress-controller ስር የ access_logs ምዝግብ ማስታወሻ ሲነቃ ከዲስክ ጋር ምን እንደሚፈጠር ያሳያል (~12k logs/sec)። በእርግጥ እንዲህ ዓይነቱ ሁኔታ በዚህ መስቀለኛ መንገድ ላይ ያሉትን ሁሉንም አፕሊኬሽኖች ወደ መበስበስ ሊያመራ ይችላል.

ስለ PV ፣ ወዮ ፣ ሁሉንም ነገር አልሞከርኩም። ዝርያዎች የማያቋርጥ ጥራዞች. ለእርስዎ የሚስማማውን ምርጥ አማራጭ ይጠቀሙ. በአገራችን በታሪካዊ ሁኔታ ተከስቶ ነበር ትንሽ የአገልግሎቶች ክፍል RWX ጥራዞች ያስፈልገዋል, እና ከረጅም ጊዜ በፊት ለዚህ ተግባር የ NFS ማከማቻ መጠቀም ጀመሩ. ርካሽ እና ... በቂ። እርግጥ ነው, ከእሱ ጋር ሻይን በልተናል - ጤናማ ይሁኑ, ግን እሱን እንዴት ማስተካከል እንዳለብን ተምረናል, እና ጭንቅላቱ ከእንግዲህ አይጎዳም. እና ከተቻለ ወደ S3 ነገር ማከማቻ ይቀይሩ።

3. የተመቻቹ ምስሎችን ይገንቡ

ኩበርኔትስ በፍጥነት እንዲያመጣቸው እና በብቃት እንዲፈጽም በመያዣ የተመቻቹ ምስሎችን መጠቀም ጥሩ ነው። 

ማመቻቸት ማለት ምስሎች፡-

• አንድ መተግበሪያ ብቻ መያዝ ወይም አንድ ተግባር ብቻ ማከናወን;

• ትንሽ መጠን, ምክንያቱም ትላልቅ ምስሎች በአውታረ መረቡ ላይ የከፋ ስለሚተላለፉ;

• ለጤና እና ዝግጁነት ፍተሻዎች የመጨረሻ ነጥቦች አሏቸው ፣ በዚህም Kubernetes በእረፍት ጊዜ አንዳንድ እርምጃዎችን ሊወስድ ይችላል ፣

• የውቅረት ስህተቶችን የበለጠ የሚቋቋሙ ለመያዣ ተስማሚ ኦፕሬቲንግ ሲስተሞች (እንደ አልፓይን ወይም ኮርኦኤስ) ይጠቀሙ።

• የተቀናጁ አፕሊኬሽኖችን ብቻ እንጂ ተጓዳኝ ምንጮችን ማሰማራት እንድትችል ባለብዙ ደረጃ ግንባታዎችን ተጠቀም።

በበረራ ላይ ምስሎችን ለመፈተሽ እና ለማመቻቸት የሚያስችሉዎት ብዙ መሳሪያዎች እና አገልግሎቶች አሉ። ሁልጊዜ እነሱን ወቅታዊ እና ደህንነቱ የተጠበቀ ማድረግ አስፈላጊ ነው. በውጤቱም, የሚከተሉትን ያገኛሉ:

1. በጠቅላላው ዘለላ ላይ የአውታረ መረብ ጭነት ቀንሷል።

2. የመያዣ ጅምር ጊዜ ቀንሷል።

3. የመላው የዶክተር መዝገብህ ትንሽ መጠን።

4. የዲ ኤን ኤስ መሸጎጫ ይጠቀሙ

ስለ ከፍተኛ ጭነቶች ከተነጋገርን, የክላስተር ዲ ኤን ኤስ ስርዓትን ሳያስተካክሉ ህይወት በጣም ደካማ ነው. በአንድ ወቅት የኩበርኔትስ ገንቢዎች የ kube-dns መፍትሔያቸውን ደግፈዋል። በአገራችን ውስጥም ተተግብሯል, ነገር ግን ይህ ሶፍትዌር በተለየ ሁኔታ አልተቃኘም እና አስፈላጊውን አፈፃፀም አልሰጠም, ምንም እንኳን, ስራው ቀላል ቢሆንም. ከዚያም ኮረዶች ታዩ፣ ወደ እኛ ቀይረን ሀዘንን ሳናውቅ፣ በኋላ በ K8s ውስጥ ነባሪ የዲ ኤን ኤስ አገልግሎት ሆነ። በአንድ ወቅት, ወደ ዲ ኤን ኤስ ስርዓት እስከ 40 ሺህ ሮቤል ድረስ አደግን, እና ይህ መፍትሄ እንዲሁ በቂ አልነበረም. ግን፣ እንደ እድል ሆኖ፣ ኖዴሎካልድንስ ወጣ፣ aka node local cache፣ aka NodeLocal DNSCache.

ለምን እንጠቀማለን? በሊኑክስ ከርነል ውስጥ ብዙ ጊዜ በ NAT ከ UDP ጋር ሲገናኙ ፣ ወደ ኮንትራክተሩ ጠረጴዛዎች ለመፃፍ ወደ ውድድር ሁኔታ ይመራል ፣ እና በ NAT በኩል ያለው የትራፊክ ክፍል ይጠፋል (እያንዳንዱ በአገልግሎቱ ውስጥ NAT ነው)። Nodelocaldns NAT ን በማስወገድ እና ወደ TCP ግንኙነት ወደ ዲ ኤን ኤስ ወደላይ በማሻሻል እንዲሁም ወደላይ የዲ ኤን ኤስ መጠይቆችን በአገር ውስጥ በመሸጎጥ (አጭር የ 5 ሰከንድ አሉታዊ መሸጎጫ ጨምሮ) ችግሩን ይፈታል።

5. ቅርፊቶችን በአግድም እና በአቀባዊ በራስ-ሰር ይመዝኑ

ሁሉም ማይክሮ ሰርቪስዎ ከሁለት እስከ ሶስት እጥፍ ጭነት ለመጨመር ዝግጁ መሆናቸውን በእርግጠኝነት መናገር ይችላሉ? ለመተግበሪያዎችዎ ሀብቶችን እንዴት በትክክል መመደብ እንደሚቻል? ከስራው ብዛት በላይ ጥንድ ፖዶችን ማቆየት ብዙ ጊዜ ሊቀንስ ይችላል፣ እና እነሱን ወደ ኋላ ማቆየት በድንገት ወደ አገልግሎቱ ከሚመጣው የትራፊክ መጨመር የተነሳ የመዘግየት ጊዜን አደጋ ላይ ይጥላል። ወርቃማው አማካኝ የማባዛት ፊደል እንደዚህ ያሉ አገልግሎቶችን ለማግኘት ይረዳል አግድም Pod Autoscaler и አቀባዊ ፖድ አውቶማቲክ.

VPA በእውነተኛ አጠቃቀም ላይ በመመስረት የመያዣዎችዎን ጥያቄዎች/ገደቦች በፖድ ውስጥ በራስ-ሰር እንዲያነሱ ይፈቅድልዎታል። እንዴት ጠቃሚ ሊሆን ይችላል? በሆነ ምክንያት በአግድም ሊመዘኑ የማይችሉ (ሙሉ በሙሉ አስተማማኝ ያልሆኑ) ፖዶች ካሉዎት፣ ቪፒኤ ሀብቱን እንዲቀይር ለማመን መሞከር ይችላሉ። ባህሪው በታሪካዊ እና ወቅታዊ መረጃ ከሜትሪክ-ሰርቨር ላይ የተመሰረተ የምክር ስርዓት ነው ፣ ስለሆነም ጥያቄዎችን / ገደቦችን በራስ-ሰር መለወጥ ካልፈለጉ በቀላሉ ለኮንቴይነሮችዎ የሚመከሩ ሀብቶችን መከታተል እና ቅንጅቶችን ማመቻቸት ሲፒዩ እና ማህደረ ትውስታን መቆጠብ ይችላሉ ። በክላስተር ውስጥ.

ምስል ከ https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 የተወሰደ

በ Kubernetes ውስጥ ያለው መርሐግብር ሁልጊዜ በጥያቄዎች ላይ የተመሰረተ ነው. ምንም አይነት ዋጋ ቢያስቀምጡ, መርሐግብር አውጪው በእሱ ላይ የተመሰረተ ተስማሚ መስቀለኛ መንገድን ይፈልጋል. ፖድ መቼ እንደሚነድድ ወይም እንደሚገድል ለማወቅ የገደብ እሴቱ በ kublet ያስፈልጋል። እና ብቸኛው አስፈላጊ መለኪያ የጥያቄዎች ዋጋ ስለሆነ, ቪፒኤ ከእሱ ጋር ይሰራል. ማመልከቻዎን በአቀባዊ ሲመዘኑ፣ ምን ጥያቄዎች መሆን እንዳለባቸው ይገልፃሉ። እና ከዚያ ገደቦች ምን ይሆናሉ? ይህ ግቤት እንዲሁ በተመጣጣኝ መጠን ይሰፋል።

ለምሳሌ፣ የተለመዱ የፖድ ቅንጅቶች እዚህ አሉ

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

የምክር ሞተሩ መተግበሪያዎ በትክክል ለመስራት 300ሜ ሲፒዩ እና 500ሚ እንደሚያስፈልገው ይወስናል። እነዚህን ቅንብሮች ያገኛሉ፡-

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

ከላይ እንደተጠቀሰው፣ ይህ በአንጸባራቂው ውስጥ ባሉት የጥያቄዎች/ገደቦች ጥምርታ ላይ የተመሰረተ ተመጣጣኝ ልኬት ነው።

• ሲፒዩ፡ 200ሜ → 300ሜ፡ ሬሾ 1፡1.75;

• ማህደረ ትውስታ፡ 250ሚ → 500ሚ፡ 1፡2 ጥምርታ።

በ .. HPA, ከዚያም የአሠራር ዘዴው የበለጠ ግልጽ ነው. ገደቦች እንደ ፕሮሰሰር እና ማህደረ ትውስታ ላሉት መለኪያዎች ተቀናብረዋል፣ እና የሁሉም ቅጂዎች አማካኝ ከገደቡ ከበለጠ፣ ትግበራው በ+1 ፖድ እሴቱ ከገደቡ በታች እስኪወድቅ ድረስ ወይም ከፍተኛው የተባዛዎች ብዛት እስኪደርስ ድረስ ይመዘናል።

ምስል ከ https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 የተወሰደ

እንደ ሲፒዩ እና ሜሞሪ ካሉት የተለመዱ መለኪያዎች በተጨማሪ፣ በእርስዎ ብጁ የፕሮሜቲየስ ሜትሪክስ ላይ ገደቦችን ማዘጋጀት እና መተግበሪያዎን መቼ እንደሚያሳድጉ ለማወቅ ይህ በጣም ትክክለኛው መንገድ እንደሆነ ከተሰማዎት ከእነሱ ጋር መስራት ይችላሉ። አንዴ አፕሊኬሽኑ ከተጠቀሰው የሜትሪክ ገደብ በታች ካረጋጋ በኋላ፣ HPA ፖዶቹን ወደ ዝቅተኛው የቅጂዎች ብዛት ወይም ጭነቱ ጣራውን እስኪያሟላ ድረስ ማመጣጠን ይጀምራል።

6. ስለ መስቀለኛ ትስስር እና ስለ ፖድ አፊኒቲ አይርሱ

ሁሉም አንጓዎች በአንድ ሃርድዌር ላይ የሚሰሩ አይደሉም፣ እና ሁሉም ፖድዎች ስሌት-ተኮር መተግበሪያዎችን ማሄድ አያስፈልጋቸውም። Kubernetes በመጠቀም የአንጓዎችን እና የፖዳዎችን ልዩነት እንዲገልጹ ያስችልዎታል የመስቀለኛ መንገድ ትስስር и Pod Affinity.

ለኮምፒዩተር-ተኮር ስራዎች ተስማሚ የሆኑ አንጓዎች ካሉዎት, ለከፍተኛው ውጤታማነት, ማመልከቻዎችን ከተገቢው አንጓዎች ጋር ማሰር የተሻለ ነው. ይህንን ለማድረግ, ይጠቀሙ 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 ቀድሞውንም በዚያ መለያ ፖድ እያሄደ ካለው መስቀለኛ መንገድ ጋር ፖድቹን ያስራል።

ተጨማሪ Kubernetes መስክ ያቀርባል 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. የፖድ ማሰማራት ቅድሚያ ያዘጋጁ

ከፖድ-ወደ-መስቀለኛ መንገድ ማሰሪያዎችን ስላዋቀሩ ብቻ ሁሉም ፖድዎች በተመሳሳይ ቅድሚያ መታከም አለባቸው ማለት አይደለም። ለምሳሌ፣ አንዳንድ ፖዶችን ከሌሎች በፊት ማሰማራት ትፈልግ ይሆናል።

ኩበርኔትስ የፖድ ቅድሚያ እና ቅድመ ሁኔታን ለማዘጋጀት የተለያዩ መንገዶችን ያቀርባል። ቅንብሩ ብዙ ክፍሎችን ያቀፈ ነው: ነገር 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 የመላው ክላስተር አንጎል ተብሎ ሊጠራ ይችላል። በ "Cube" ውስጥ ያለው የሥራ ፍጥነት በእሱ ላይ ስለሚወሰን የዚህን የውሂብ ጎታ አሠራር በከፍተኛ ደረጃ ማቆየት በጣም አስፈላጊ ነው. ትክክለኛ ደረጃ እና በተመሳሳይ ጊዜ፣ ጥሩ መፍትሄ ለኩቤ-አፒሰርቨር ዝቅተኛ መዘግየት እንዲኖር የ ETCD ክላስተር በማስተር ኖዶች ላይ ማስቀመጥ ነው። ይህ የማይቻል ከሆነ ETCD ን በተቻለ መጠን በቅርብ ያስቀምጡ, በተሳታፊዎች መካከል ጥሩ የመተላለፊያ ይዘት ያለው. እንዲሁም ከ ETCD ስንት አንጓዎች በክላስተር ላይ ምንም ጉዳት ሳይደርስባቸው ሊወድቁ እንደሚችሉ ልብ ይበሉ።

በክላስተር ውስጥ ያሉ የተሳታፊዎች ብዛት ከመጠን በላይ መጨመር በአፈፃፀም ወጪዎች ላይ የስህተት መቻቻልን እንደሚጨምር ያስታውሱ ፣ ሁሉም ነገር በመጠን መሆን አለበት።

አገልግሎቱን ስለማዋቀር ከተነጋገርን ጥቂት ምክሮች አሉ-

1. በክላስተር መጠን መሰረት ጥሩ ሃርድዌር ይኑርዎት (ማንበብ ይችላሉ። እዚህ).

2. በዲሲ ጥንድ መካከል ክላስተር ካሰራጩ ወይም አውታረ መረብዎ እና ዲስኮችዎ የሚፈለጉትን የሚተዉ ከሆነ ጥቂት መለኪያዎችን ያስተካክሉ (ማንበብ ይችላሉ) እዚህ).

መደምደሚያ

ይህ ጽሑፍ ቡድናችን ለማክበር የሚሞክረውን ነጥቦች ይገልጻል። ይህ የእርምጃዎች ደረጃ በደረጃ መግለጫ አይደለም፣ ነገር ግን የክላስተርን የላይኛው ክፍል ለማመቻቸት ጠቃሚ ሊሆኑ የሚችሉ አማራጮች። እያንዳንዱ ክላስተር በራሱ መንገድ ልዩ እንደሆነ ግልጽ ነው፣ እና የመፍትሄ ሃሳቦችን ማስተካከል በእጅጉ ሊለያዩ ይችላሉ፣ ስለዚህ ከእርስዎ ግብረ መልስ ማግኘት አስደሳች ይሆናል-የ Kubernetes ክላስተርዎን እንዴት እንደሚቆጣጠሩ ፣ አፈፃፀሙን እንዴት እንደሚያሻሽሉ ። በአስተያየቶች ውስጥ የእርስዎን ተሞክሮ ያካፍሉ, እሱን ማወቅ አስደሳች ይሆናል.

ምንጭ: hab.com