በ Kubernetes ውስጥ የረጅም ጊዜ ግንኙነቶችን ማመጣጠን እና ማመጣጠን

ይህ መጣጥፍ በ Kubernetes ውስጥ የጭነት ማመጣጠን እንዴት እንደሚሰራ ፣ የረዥም ጊዜ ግንኙነቶችን በሚቀንሱበት ጊዜ ምን እንደሚፈጠር ፣ እና HTTP/2 ፣ gRPC ፣ RSockets ፣ AMQP ወይም ሌሎች ረጅም ጊዜ የሚቆዩ ፕሮቶኮሎችን ከተጠቀሙ የደንበኛ-ጎን ማመጣጠን ለምን ግምት ውስጥ ማስገባት እንዳለብዎ ለመረዳት ይረዳዎታል ። . 

በ Kubernetes ውስጥ ትራፊክ እንዴት እንደገና እንደሚከፋፈል ትንሽ 

ኩበርኔትስ አፕሊኬሽኖችን ለማሰማራት ሁለት ምቹ ማጠቃለያዎችን ይሰጣል፡ አገልግሎቶች እና ማሰማራት።

ማሰማራቶች በማንኛውም ጊዜ የማመልከቻዎ ምን ያህል እና ምን ያህል ቅጂዎች መሮጥ እንዳለባቸው ያብራራሉ። እያንዳንዱ መተግበሪያ እንደ ፖድ ነው የሚሰራው እና የአይፒ አድራሻ ይመደብለታል።

አገልግሎቶቹ ከሎድ ሚዛን ጋር ተመሳሳይ ናቸው። ትራፊክን በበርካታ ፖዶች ላይ ለማሰራጨት የተነደፉ ናቸው.

ምን እንደሚመስል እንይ.

1. ከዚህ በታች ባለው ስእል ውስጥ ሶስት ተመሳሳይ ትግበራዎችን እና የጭነት ሚዛንን ማየት ይችላሉ-

   

2. የጭነት ማመሳከሪያው አገልግሎት ተብሎ ይጠራል እና የአይፒ አድራሻ ይመደባል. ማንኛውም ገቢ ጥያቄ ወደ አንዱ ፖድ ይመራዋል፡-

   

3. የማሰማራቱ ሁኔታ የመተግበሪያውን ብዛት ብዛት ይወስናል። በሚከተሉት ስር በቀጥታ መስፋፋት በጭራሽ አይኖርብዎትም፦

   

4. እያንዳንዱ ፖድ የራሱ አይፒ አድራሻ ተሰጥቷል፡-

   

አገልግሎቶችን እንደ የአይፒ አድራሻዎች ስብስብ አድርጎ ማሰብ ጠቃሚ ነው። አገልግሎቱን በደረስክ ቁጥር ከአይፒ አድራሻዎቹ አንዱ ከዝርዝሩ ተመርጦ እንደ መድረሻ አድራሻ ይገለገላል::

ይህን ይመስላል.

1. የ curl 10.96.45.152 ጥያቄ ለአገልግሎቱ ደርሷል፡-

   

2. አገልግሎቱ ከሶስት አድራሻዎች አንዱን እንደ መድረሻ ይመርጣል፡-

   

3. ትራፊክ ወደ አንድ የተወሰነ ፖድ ይመራዋል፡-

   

ማመልከቻዎ የፊት ለፊት እና የኋለኛ ክፍልን ያካተተ ከሆነ ለእያንዳንዱ አገልግሎት እና ማሰማራት ይኖርዎታል።

የፊት ለፊቱ ለጀርባ ጥያቄ ሲያቀርብ፣ የጀርባው ክፍል ምን ያህል ፖድ እንደሚያገለግል በትክክል ማወቅ አያስፈልገውም፡ አንድ፣ አስር ወይም መቶ ሊኖር ይችላል።

እንዲሁም የፊት ለፊቱ የኋላ ክፍልን ስለሚያገለግሉ የፖዳዎች አድራሻዎች ምንም አያውቅም።

የፊት ግንባር ለኋለኛው ጥያቄ ሲያቀርብ የኋለኛውን አገልግሎት የአይፒ አድራሻ ይጠቀማል ፣ ይህ አይቀየርም።

ይህ ነው የሚመስለው.

1. ከ 1 በታች የውስጥ የኋላ ክፍልን ይጠይቃል። ለጀርባ አንድ የተወሰነ ከመምረጥ ይልቅ ለአገልግሎቱ ጥያቄ ያቀርባል፡-

   

2. አገልግሎቱ ከጀርባ ፖድዎች አንዱን እንደ መድረሻ አድራሻ ይመርጣል፡-

   

3. ትራፊክ ከፖድ 1 ወደ ፖድ 5 ይሄዳል፣ በአገልግሎቱ የተመረጠ፡-

   

4. ከ 1 አመት በታች ያሉ ከ 5 አመት በታች ያሉ ምን ያህል ፖዶች ከአገልግሎቱ በስተጀርባ እንደተደበቁ በትክክል አያውቅም።

   

ግን አገልግሎቱ በትክክል እንዴት ጥያቄዎችን ያሰራጫል? ክብ-ሮቢን ማመጣጠን ጥቅም ላይ የዋለ ይመስላል? እስቲ እንገምተው። 

በ Kubernetes አገልግሎቶች ውስጥ ማመጣጠን

የኩበርኔትስ አገልግሎቶች የሉም። አይፒ አድራሻ እና ወደብ ለተመደበው አገልግሎት ምንም ሂደት የለም።

በክላስተር ውስጥ ወዳለ ማንኛውም መስቀለኛ መንገድ በመግባት እና የ netstat -ntlp ትዕዛዝን በማሄድ ይህንን ማረጋገጥ ይችላሉ።

ለአገልግሎቱ የተመደበውን የአይፒ አድራሻ እንኳን ማግኘት አይችሉም።

የአገልግሎቱ አይፒ አድራሻ በመቆጣጠሪያው ውስጥ, በመቆጣጠሪያው ውስጥ እና በመረጃ ቋቱ ውስጥ ተመዝግቧል - ወዘተ. ተመሳሳይ አድራሻ በሌላ አካል ጥቅም ላይ ይውላል - kube-proxy.
Kube-proxy ለሁሉም አገልግሎቶች የአይ ፒ አድራሻዎችን ዝርዝር ይቀበላል እና በክላስተር ውስጥ በእያንዳንዱ መስቀለኛ መንገድ ላይ የ iptables ደንቦችን ያመነጫል።

እነዚህ ደንቦች "የአገልግሎቱን አይፒ አድራሻ ካየን, የጥያቄውን መድረሻ አድራሻ ማስተካከል እና ወደ አንዱ ፖድ መላክ አለብን."

የአገልግሎት አይፒ አድራሻው እንደ መግቢያ ነጥብ ብቻ ነው የሚያገለግለው እና ያንን አይ ፒ አድራሻ እና ወደብ በማዳመጥ በማንኛውም ሂደት አይቀርብም።

እስቲ ይህንን እንመልከት. 

1. የሶስት አንጓዎች ስብስብን አስቡበት። እያንዳንዱ መስቀለኛ መንገድ ፓድ አለው፡

   

2. የታሰሩ ፖድዎች በ beige ቀለም የተቀቡ የአገልግሎቱ አካል ናቸው። አገልግሎቱ እንደ ሂደት ስለማይኖር፣ በግራጫው ይታያል፡-

   

3. የመጀመሪያው ፖድ አገልግሎት ጠይቋል እና ከተያያዙት ፖድዎች ወደ አንዱ መሄድ አለበት፡

   

4. ግን አገልግሎቱ የለም, ሂደቱ የለም. እንዴት ነው የሚሰራው?

   

5. ጥያቄው መስቀለኛ መንገድ ከመውጣቱ በፊት፣ በ iptables ደንቦች ውስጥ ያልፋል፡-

   

6. የ iptables ደንቦቹ አገልግሎቱ እንደሌለ ያውቃሉ እና የአይፒ አድራሻውን ከዛ አገልግሎት ጋር በተያያዙት ፖድዎች IP አድራሻ በአንዱ ይተካዋል፡

   

7. ጥያቄው ልክ የሆነ የአይፒ አድራሻ እንደ መድረሻ አድራሻ ይቀበላል እና በመደበኛነት ይከናወናል፡

   

8. በኔትወርኩ ቶፖሎጂ ላይ በመመስረት፣ ጥያቄው በመጨረሻ ወደ ፖድ ይደርሳል፡-

   

iptables ሚዛን መጫን ይችላል?

አይ፣ iptables ለማጣራት የሚያገለግሉ ሲሆን ለማመጣጠን የተነደፉ አይደሉም።

ሆኖም ግን, እንደ የሚሰሩ ደንቦች ስብስብ መጻፍ ይቻላል የውሸት-አመጣጣኝ.

እና በኩበርኔትስ ውስጥ በትክክል የሚተገበረው ይህ ነው።

ሶስት ፖዶች ካሉዎት, kube-proxy የሚከተሉትን ደንቦች ይጽፋል:

1. የ 33% ዕድል ያለው የመጀመሪያውን ንዑስ ይምረጡ, አለበለዚያ ወደ ቀጣዩ ህግ ይሂዱ.
2. የ 50% ዕድል ያለው ሁለተኛውን ይምረጡ, አለበለዚያ ወደ ቀጣዩ ህግ ይሂዱ.
3. ከስር ሶስተኛውን ይምረጡ።

ይህ ስርዓት እያንዳንዱ ፖድ በ 33% ዕድል እንዲመረጥ ያደርጋል.

እና ፖድ 2 ከፖድ 1 በኋላ እንደሚመረጥ ምንም ዋስትና የለም።

አመለከተ: iptables በዘፈቀደ ስርጭት ስታትስቲካዊ ሞጁል ይጠቀማል። ስለዚህ, የማመጣጠን ስልተ ቀመር በዘፈቀደ ምርጫ ላይ የተመሰረተ ነው.

አሁን አገልግሎቶች እንዴት እንደሚሠሩ ከተረዱ፣ የበለጠ አስደሳች የአገልግሎት ሁኔታዎችን እንመልከት።

በ Kubernetes ውስጥ ለረጅም ጊዜ የሚቆዩ ግንኙነቶች በነባሪነት አይመዘኑም።

እያንዳንዱ የኤችቲቲፒ ጥያቄ ከግንባር እስከ ኋለኛው ድረስ የሚቀርበው በተለየ የTCP ግንኙነት ነው፣ እሱም ይከፈታል እና ይዘጋል።

የፊት ለፊት ክፍል 100 ጥያቄዎችን በሰከንድ ወደ ኋላ ከላከ 100 የተለያዩ የTCP ግንኙነቶች ተከፍተው ይዘጋሉ።

አንድ TCP ግንኙነት በመክፈት እና ለሚቀጥሉት የኤችቲቲፒ ጥያቄዎች በመጠቀም የጥያቄ ሂደት ጊዜን መቀነስ እና መጫን ይችላሉ።

የኤችቲቲፒ ፕሮቶኮል HTTP keep-alive ወይም ግንኙነትን እንደገና መጠቀም የሚባል ባህሪ አለው። በዚህ አጋጣሚ፣ በርካታ የኤችቲቲፒ ጥያቄዎችን እና ምላሾችን ለመላክ እና ለመቀበል አንድ ነጠላ TCP ግንኙነት ስራ ላይ ይውላል፡-

ይህ ባህሪ በነባሪነት አልነቃም፡ ሁለቱም አገልጋዩ እና ደንበኛው በዚሁ መሰረት መዋቀር አለባቸው።

ማዋቀሩ ራሱ ቀላል እና ለአብዛኛዎቹ የፕሮግራም አወጣጥ ቋንቋዎች እና አካባቢዎች ተደራሽ ነው።

በተለያዩ ቋንቋዎች ወደ ምሳሌዎች አንዳንድ አገናኞች እዚህ አሉ።

• በ Node.js ውስጥ በሕይወት ይኑርዎት
• በፀደይ ቡት ውስጥ በሕይወት ይኑርዎት
• በፓይዘን ውስጥ በሕይወት ይቆዩ
• በ NET ውስጥ በሕይወት ይኑርዎት

በ Kubernetes አገልግሎት ውስጥ ማቆየት የምንጠቀም ከሆነ ምን ይከሰታል?
ከፊት ለፊት እና ከኋላ ያሉት ሁለቱም በሕይወት እንዲቀጥሉ ይደግፋሉ ብለን እናስብ።

የፊት ለፊት ክፍል አንድ ቅጂ እና ሶስት የጀርባ ቅጂዎች አሉን. የፊት ግንባር የመጀመሪያውን ጥያቄ ያቀርባል እና ከጀርባው ጋር የ TCP ግንኙነትን ይከፍታል። ጥያቄው ወደ አገልግሎቱ ይደርሳል, ከጀርባ ፖድዎች አንዱ እንደ መድረሻ አድራሻ ይመረጣል. የኋለኛው ክፍል ምላሽ ይልካል, እና የፊት ግንባር ይቀበላል.

ምላሽ ከተቀበለ በኋላ የTCP ግንኙነት ከተዘጋበት የተለመደ ሁኔታ በተለየ፣ ለተጨማሪ የኤችቲቲፒ ጥያቄዎች አሁን ክፍት ሆኖ ይቆያል።

የፊት ግንባር ተጨማሪ ጥያቄዎችን ወደ ኋላ ከላከ ምን ይከሰታል?

እነዚህን ጥያቄዎች ለማስተላለፍ፣ የተከፈተ TCP ግንኙነት ስራ ላይ ይውላል፣ ሁሉም ጥያቄዎች የመጀመሪያው ጥያቄ ወደ ቀረበበት ተመሳሳይ የኋላ ክፍል ነው የሚሄደው።

iptables ትራፊኩን እንደገና ማሰራጨት የለበትም?

በዚህ ጉዳይ ላይ አይደለም.

የ TCP ግንኙነት ሲፈጠር፣ በ iptables ደንቦች ውስጥ ያልፋል፣ ይህም ትራፊክ የሚሄድበትን የተወሰነ የኋላ ክፍልን ይመርጣል።

ሁሉም ተከታይ ጥያቄዎች ቀድሞውኑ ክፍት በሆነው የTCP ግንኙነት ላይ ስለሆኑ፣ የ iptables ደንቦች ከአሁን በኋላ አይጠሩም።

ምን እንደሚመስል እንይ.

1. የመጀመሪያው ፖድ ለአገልግሎቱ ጥያቄ ይልካል፡-

   

2. ቀጥሎ ምን እንደሚሆን አስቀድመው ያውቁታል. አገልግሎቱ የለም፣ ግን ጥያቄውን የሚያስኬዱ የ iptables ህጎች አሉ፡

   

3. ከኋላ ያሉት ፖዶች አንዱ እንደ መድረሻ አድራሻ ይመረጣል፡-

   

4. ጥያቄው ወደ ፖድ ይደርሳል. በዚህ ጊዜ በሁለቱ ፖዶች መካከል የማያቋርጥ የTCP ግንኙነት ይመሰረታል፡

   

5. ከመጀመሪያው ፖድ ማንኛውም ቀጣይ ጥያቄ አስቀድሞ በተመሰረተው ግንኙነት ውስጥ ያልፋል፡-

   

ውጤቱ ፈጣን የምላሽ ጊዜ እና ከፍተኛ የውጤት መጠን ነው፣ ነገር ግን የጀርባውን የመመዘን ችሎታ ያጣሉ።

ምንም እንኳን በኋለኛው ውስጥ ሁለት ፖዶች ቢኖሩዎትም ፣ በቋሚ ግንኙነት ፣ ትራፊክ ሁል ጊዜ ወደ አንዱ ይሄዳል።

ይህ ሊስተካከል ይችላል?

ኩበርኔትስ ቋሚ ግንኙነቶችን እንዴት ማመጣጠን እንዳለበት ስለማያውቅ ይህ ተግባር በእርስዎ ላይ ይወድቃል።

አገልግሎቶች የመጨረሻ ነጥብ የሚባሉ የአይፒ አድራሻዎች እና ወደቦች ስብስብ ናቸው።

ማመልከቻዎ ከአገልግሎቱ የመጨረሻ ነጥቦችን ዝርዝር ማግኘት እና በመካከላቸው ጥያቄዎችን እንዴት ማሰራጨት እንደሚቻል መወሰን ይችላል። ክብ-ሮቢን በመጠቀም ከእያንዳንዱ ፖድ ጋር የማያቋርጥ ግንኙነት መክፈት እና በእነዚህ ግንኙነቶች መካከል ጥያቄዎችን ማመጣጠን ይችላሉ።

ወይም ተጨማሪ ያመልክቱ ውስብስብ ማመጣጠን ስልተ ቀመሮች.

ለማመጣጠን ኃላፊነት ያለው የደንበኛ-ጎን ኮድ ይህንን አመክንዮ መከተል አለበት፡-

1. ከአገልግሎቱ የመጨረሻ ነጥቦችን ዝርዝር ያግኙ።
2. ለእያንዳንዱ የመጨረሻ ነጥብ የማያቋርጥ ግንኙነት ይክፈቱ።
3. ጥያቄ መቅረብ ሲያስፈልግ፣ ክፍት ከሆኑ ግንኙነቶች አንዱን ይጠቀሙ።
4. የማጠቃለያ ነጥቦችን ዝርዝር በመደበኛነት ያዘምኑ፣ አዳዲሶችን ይፍጠሩ ወይም ዝርዝሩ ከተቀየረ የቆዩ ቋሚ ግንኙነቶችን ይዝጉ።

ይህ ነው የሚመስለው.

1. ከመጀመሪያው ፖድ ጥያቄውን ወደ አገልግሎቱ ከመላክ ይልቅ በደንበኛው በኩል ጥያቄዎችን ማመጣጠን ይችላሉ-

   

2. የትኞቹ ፖዶች የአገልግሎቱ አካል እንደሆኑ የሚጠይቅ ኮድ መጻፍ ያስፈልግዎታል።

   

3. አንዴ ዝርዝሩን ካገኙ በኋላ በደንበኛው በኩል ያስቀምጡት እና ከፖድ ጋር ለመገናኘት ይጠቀሙበት፡

   

4. ለጭነት ማመጣጠን ስልተ-ቀመር ኃላፊነት አለብዎት፡-

   

አሁን ጥያቄው የሚነሳው ይህ ችግር በ HTTP keep-alive ላይ ብቻ ነው?

የደንበኛ-ጎን ጭነት ማመጣጠን

ኤችቲቲፒ ቀጣይነት ያለው የTCP ግንኙነቶችን መጠቀም የሚችል ፕሮቶኮል ብቻ አይደለም።

አፕሊኬሽን ዳታቤዝ የሚጠቀም ከሆነ ጥያቄ ባቀረቡ ቁጥር ወይም ከመረጃ ቋቱ ሰነድ ባወጡ ቁጥር የTCP ግንኙነት አይከፈትም። 

በምትኩ፣ ከመረጃ ቋቱ ጋር የማያቋርጥ የTCP ግንኙነት ተከፍቷል እና ጥቅም ላይ ይውላል።

የውሂብ ጎታዎ በ Kubernetes ላይ ከተዘረጋ እና መዳረሻ እንደ አገልግሎት ከተሰጠ, በቀደመው ክፍል ውስጥ የተገለጹትን ተመሳሳይ ችግሮች ያጋጥሙዎታል.

አንድ የውሂብ ጎታ ቅጂ ከሌሎቹ በበለጠ ይጫናል. Kube-proxy እና Kubernetes ግንኙነቶችን ሚዛናዊ ለማድረግ አይረዱም። መጠይቆችን ወደ የውሂብ ጎታዎ ለማመጣጠን መጠንቀቅ አለብዎት።

ከመረጃ ቋቱ ጋር ለማገናኘት በየትኛው ቤተ-መጽሐፍት ላይ በመመስረት ይህንን ችግር ለመፍታት የተለያዩ አማራጮች ሊኖሩዎት ይችላሉ።

ከዚህ በታች የ MySQL ዳታቤዝ ስብስብን ከ Node.js የመድረስ ምሳሌ ነው፡-

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

ቀጣይነት ያለው የTCP ግንኙነቶችን የሚጠቀሙ ብዙ ሌሎች ፕሮቶኮሎች አሉ፡

• WebSockets እና ደህንነቱ የተጠበቀ WebSockets
• HTTP / 2
• ጂአርፒሲ
• RSockets
• AMQP

ከእነዚህ ፕሮቶኮሎች ውስጥ አብዛኛዎቹን አስቀድመው ማወቅ አለብዎት።

ግን እነዚህ ፕሮቶኮሎች በጣም ተወዳጅ ከሆኑ ለምንድነው ደረጃውን የጠበቀ ሚዛናዊ መፍትሄ የለም? የደንበኛው አመክንዮ ለምን መለወጥ አለበት? የኩበርኔትስ ቤተኛ መፍትሄ አለ?

Kube-proxy እና iptables ወደ ኩበርኔትስ በሚሰማሩበት ጊዜ በጣም የተለመዱ የአጠቃቀም ጉዳዮችን ለመሸፈን የተነደፉ ናቸው። ይህ ለመመቻቸት ነው።

የ REST ኤፒአይን የሚያጋልጥ የድር አገልግሎት እየተጠቀሙ ከሆነ እድለኞች ኖት - በዚህ አጋጣሚ ቋሚ የ TCP ግንኙነቶች ጥቅም ላይ አይውሉም, ማንኛውንም የ Kubernetes አገልግሎት መጠቀም ይችላሉ.

ነገር ግን ቋሚ የTCP ግንኙነቶችን መጠቀም ከጀመርክ በኋላ ሸክሙን በጀርባው ላይ እንዴት በእኩል ማከፋፈል እንደምትችል ማወቅ አለብህ። Kubernetes ለዚህ ጉዳይ ዝግጁ የሆኑ መፍትሄዎችን አልያዘም.

ሆኖም ግን, በእርግጠኝነት ሊረዱ የሚችሉ አማራጮች አሉ.

በ Kubernetes ውስጥ የረጅም ጊዜ ግንኙነቶችን ማመጣጠን

በኩበርኔትስ ውስጥ አራት አይነት አገልግሎቶች አሉ፡-

1. ክላስተርአይፒ
2. መስቀለኛ መንገድ
3. LoadBalancer
4. ጭንቅላት የለውም

የመጀመሪያዎቹ ሦስቱ አገልግሎቶች የሚሠሩት በቨርቹዋል አይፒ አድራሻ ነው፣ እሱም በ kube-proxy የiptables ደንቦችን ለመገንባት ይጠቅማል። ነገር ግን የሁሉም አገልግሎቶች መሰረታዊ መሰረት ጭንቅላት የሌለው አገልግሎት ነው።

ራስ-አልባ አገልግሎቱ ከእሱ ጋር የተገናኘ ምንም አይነት የአይፒ አድራሻ የለውም እና ከእሱ ጋር የተያያዙ የአይፒ አድራሻዎችን እና የፖድስ (የመጨረሻ ነጥቦችን) ወደቦች ዝርዝር ለማውጣት ዘዴን ብቻ ይሰጣል።

ሁሉም አገልግሎቶች ጭንቅላት በሌለው አገልግሎት ላይ የተመሰረቱ ናቸው።

የClusterIP አገልግሎት አንዳንድ ተጨማሪዎች ያሉት ራስ-አልባ አገልግሎት ነው፡- 

1. የአስተዳደር ንብርብር የአይፒ አድራሻ ይመድባል።
2. Kube-proxy አስፈላጊ የሆኑትን የ iptables ደንቦች ያመነጫል.

በዚህ መንገድ የ kube-proxyን ችላ ማለት እና ማመልከቻዎን ሚዛን ለመጫን ከራስ-አልባ አገልግሎት የተገኙትን የመጨረሻ ነጥቦችን በቀጥታ መጠቀም ይችላሉ።

ነገር ግን በክላስተር ውስጥ ለተሰማሩ ሁሉም መተግበሪያዎች ተመሳሳይ አመክንዮ እንዴት ማከል እንችላለን?

ማመልከቻዎ አስቀድሞ ከተሰራ፣ ይህ ተግባር የማይቻል ሊመስል ይችላል። ይሁን እንጂ አንድ አማራጭ አማራጭ አለ.

የአገልግሎት ሜሽ ይረዳዎታል

የደንበኛ-ጎን ጭነት ማመጣጠን ስልት በጣም ደረጃውን የጠበቀ መሆኑን አስቀድመህ አስተውለህ ይሆናል።

ማመልከቻው ሲጀምር፡-

1. ከአገልግሎቱ የአይፒ አድራሻዎችን ዝርዝር ያገኛል።
2. የግንኙነት ገንዳ ይከፍታል እና ይጠብቃል።
3. የማብቂያ ነጥቦችን በመጨመር ወይም በማስወገድ ገንዳውን በየጊዜው ያሻሽላል።

ማመልከቻው አንዴ ጥያቄ ማቅረብ ከፈለገ፡-

1. አንዳንድ አመክንዮዎችን (ለምሳሌ ክብ-ሮቢን) በመጠቀም የሚገኝ ግንኙነትን ይመርጣል።
2. ጥያቄውን ያስፈጽማል።

እነዚህ እርምጃዎች ለሁለቱም WebSockets፣ gRPC እና AMQP ግንኙነቶች ይሰራሉ።

ይህንን አመክንዮ ወደ የተለየ ቤተ-መጽሐፍት ለይተው በመተግበሪያዎችዎ ውስጥ ሊጠቀሙበት ይችላሉ።

ሆኖም፣ በምትኩ እንደ Istio ወይም Linkerd ያሉ የአገልግሎት መረቦችን መጠቀም ትችላለህ።

የአገልግሎት Mesh ማመልከቻዎን በሚከተለው ሂደት ይጨምራል፦

1. የአገልግሎት አይፒ አድራሻዎችን በራስ-ሰር ይፈልጋል።
2. እንደ WebSockets እና gRPC ያሉ ግንኙነቶችን ይፈትሻል።
3. ትክክለኛውን ፕሮቶኮል በመጠቀም ጥያቄዎችን ያመዛዝናል።

ሰርቪስ ሜሽ በክላስተር ውስጥ ያለውን ትራፊክ ለመቆጣጠር ይረዳል፣ ነገር ግን ብዙ ሀብትን የሚጠይቅ ነው። ሌሎች አማራጮች እንደ ኔትፍሊክስ ሪባን ያሉ የሶስተኛ ወገን ቤተ-ፍርግሞችን ወይም እንደ መልእክተኛ ያሉ ፕሮግራማዊ ፕሮክሲዎችን እየተጠቀሙ ነው።

የማመጣጠን ጉዳዮችን ችላ ካልክ ምን ይከሰታል?

የጭነት ማመጣጠን ላለመጠቀም መምረጥ ይችላሉ እና አሁንም ምንም ለውጦችን አያስተውሉም። ጥቂት የስራ ሁኔታዎችን እንመልከት።

ከአገልጋይ በላይ ብዙ ደንበኞች ካሉዎት፣ ይህ ትልቅ ችግር አይደለም።

ከሁለት አገልጋዮች ጋር የሚገናኙ አምስት ደንበኞች አሉ እንበል። ምንም እንኳን ማመጣጠን ባይኖርም፣ ሁለቱም አገልጋዮች ጥቅም ላይ ይውላሉ፡-

ግንኙነቶች በእኩልነት ላይሰራጩ ይችላሉ፡ ምናልባት አራት ደንበኞች ከተመሳሳይ አገልጋይ ጋር የተገናኙ ናቸው፣ ነገር ግን ሁለቱም አገልጋዮች የመጠቀም እድላቸው ሰፊ ነው።

የበለጠ ችግር ያለበት ግን ተቃራኒው ሁኔታ ነው።

ያነሱ ደንበኞች እና ብዙ አገልጋዮች ካሉዎት ሃብቶችዎ ብዙም ጥቅም ላይ ያልዋሉ እና ማነቆዎች ሊኖሩ ይችላሉ።

ሁለት ደንበኞች እና አምስት አገልጋዮች አሉ እንበል። በጣም ጥሩ በሆነ ሁኔታ ከአምስት ውስጥ ከሁለት አገልጋዮች ጋር ሁለት ቋሚ ግንኙነቶች ይኖራሉ.

የተቀሩት አገልጋዮች ስራ ፈት ይሆናሉ፡-

እነዚህ ሁለት አገልጋዮች የደንበኛ ጥያቄዎችን ማስተናገድ ካልቻሉ፣ አግድም ልኬት ማድረግ አይረዳም።

መደምደሚያ

የኩበርኔትስ አገልግሎቶች በአብዛኛዎቹ መደበኛ የድር መተግበሪያ ሁኔታዎች ውስጥ ለመስራት የተነደፉ ናቸው።

ሆኖም ግን፣ እንደ ዳታቤዝ፣ gRPC ወይም WebSockets ያሉ የማያቋርጥ የTCP ግንኙነቶችን ከሚጠቀሙ የመተግበሪያ ፕሮቶኮሎች ጋር መስራት ከጀመሩ አገልግሎቶች ከአሁን በኋላ ተስማሚ አይደሉም። Kubernetes የማያቋርጥ የTCP ግንኙነቶችን ለማመጣጠን ውስጣዊ ዘዴዎችን አይሰጥም።

ይህ ማለት የደንበኛ-ጎን ሚዛንን ግምት ውስጥ በማስገባት ማመልከቻዎችን መጻፍ አለብዎት.

ትርጉም በቡድኑ ተዘጋጅቷል። Kubernetes aaS ከ Mail.ru.

በርዕሱ ላይ ሌላ ምን ማንበብ:

1. በ Kubernetes ውስጥ ሶስት ደረጃዎች አውቶማቲክ እና እንዴት እነሱን በብቃት እንደሚጠቀሙባቸው. 
2. ኩበርኔትስ በስርቆት መንፈስ ለትግበራ አብነት.
3. የቴሌግራም ቻናላችን ስለ ዲጂታል ትራንስፎርሜሽን.

ምንጭ: hab.com