🥇 Tinder ወደ ኩበርኔትስ ማሸጋገር

ማስታወሻ. ትርጉምየዓለም ታዋቂው አገልግሎት ቲንደር ሰራተኞች በቅርቡ መሠረተ ልማታቸውን ወደ ኩበርኔትስ የማዛወር ቴክኒካዊ ዝርዝሮችን አካፍለዋል። ሂደቱ ወደ ሁለት ዓመታት ገደማ የፈጀ ሲሆን በK8s ላይ 200 አገልግሎቶችን ያካተተ በ48 ኮንቴይነሮች ላይ የተስተናገደውን በጣም ትልቅ መድረክን አስጀምሯል። የቲንደር መሐንዲሶች ምን አስደሳች ችግሮች አጋጥሟቸው እና ምን ውጤት እንዳመጡ - በዚህ ትርጉም ውስጥ ያንብቡ።

ለምን?

የዛሬ ሁለት አመት ገደማ ቲንደር መድረኩን ወደ ኩበርኔትስ ለመዛወር ወሰነ። ኩበርኔትስ የቲንደር ቡድን መያዣ እንዲይዝ እና በትንሹ ጥረት በማይለወጥ ማሰማራት እንዲቀጥል ይፈቅዳል (የማይለወጥ ማሰማራት). በዚህ ሁኔታ የመተግበሪያዎች ስብስብ, መዘርጋት እና መሠረተ ልማቱ እራሱ በኮዱ ልዩ በሆነ መልኩ ይገለጻል.

በተጨማሪም የመለጠጥ እና የመረጋጋት ችግር መፍትሄ እየፈለግን ነበር. ልኬቱ ወሳኝ በሚሆንበት ጊዜ፣ ብዙ ጊዜ አዲስ EC2 ጉዳዮችን ለመጀመር ብዙ ደቂቃዎችን መጠበቅ ነበረብን። ኮንቴይነሮችን ማስጀመር እና ከደቂቃዎች ይልቅ በሰከንዶች ውስጥ ትራፊክ ማገልገል መጀመር የሚለው ሀሳብ ለእኛ በጣም ማራኪ ሆኖልናል።

ሂደቱ አስቸጋሪ ሆነ። በ2019 መጀመሪያ ፍልሰት ወቅት፣ የኩበርኔትስ ክላስተር በጣም አሳሳቢ ደረጃ ላይ ደርሷል እና በትራፊክ ብዛት፣ በክላስተር መጠን እና በዲ ኤን ኤስ ምክንያት ወደ ተለያዩ ጉዳዮች መሮጥ ጀመርን። በመንገዳችን ላይ 200 አገልግሎቶችን ከመሰደድ እና 1000 ኖዶች ፣ 15000 ፖድ እና 48000 የሩጫ ኮንቴይነሮችን ያካተተ የኩበርኔትስ ክላስተርን ከመጠበቅ ጋር የተያያዙ ብዙ አስደሳች ችግሮችን ፈትተናል ።

እንዴት?

ከጥር 2018 ጀምሮ በተለያዩ የስደት ደረጃዎች ውስጥ አልፈናል። ሁሉንም አገልግሎቶቻችንን ኮንቴይነር በማድረግ እና የኩበርኔትስ ደመና አካባቢዎችን ለመፈተሽ በማሰማራት ጀመርን። ከጥቅምት ወር ጀምሮ ሁሉንም ነባር አገልግሎቶች ወደ ኩበርኔትስ በዘዴ ማዛወር ጀመርን። በሚቀጥለው ዓመት መጋቢት ወር ላይ "መዛወሪያውን" አጠናቅቀናል እና አሁን የቲንደር መድረክ በ Kubernetes ላይ ብቻ ይሰራል።

ለ Kubernetes ምስሎችን መገንባት

በኩበርኔትስ ክላስተር ላይ ለሚሰሩ ከ30 በላይ የሚሆኑ የጥቃቅን አገልግሎቶች የምንጭ ኮድ ማከማቻዎች አሉን። በእነዚህ ማከማቻዎች ውስጥ ያለው ኮድ በተለያዩ ቋንቋዎች (ለምሳሌ፣ Node.js፣ Java፣ Scala፣ Go) ለተመሳሳይ ቋንቋ ከበርካታ የሩጫ አካባቢዎች ጋር ተጽፏል።

የግንባታ ስርዓቱ ለእያንዳንዱ ማይክሮ አገልግሎት ሙሉ ለሙሉ ሊበጅ የሚችል "የግንባታ አውድ" ለማቅረብ የተነደፈ ነው። እሱ ብዙውን ጊዜ Dockerfile እና የሼል ትዕዛዞች ዝርዝርን ያካትታል። ይዘታቸው ሙሉ ለሙሉ ሊበጅ የሚችል ነው, እና በተመሳሳይ ጊዜ, እነዚህ ሁሉ የመሰብሰቢያ አውዶች የተጻፉት በመደበኛ ቅርጸት ነው. የግንባታ አውዶች ደረጃውን የጠበቀ አንድ ነጠላ የግንባታ ስርዓት ሁሉንም ጥቃቅን አገልግሎቶችን ለመቆጣጠር ያስችላል.

ምስል 1-1. ደረጃውን የጠበቀ የግንባታ ሂደት በገንቢ ኮንቴይነር በኩል

ለከፍተኛው ወጥነት በአሂድ ጊዜ አካባቢዎች (የአሂድ አከባቢዎች) በልማት እና በሙከራ ጊዜ ተመሳሳይ የግንባታ ሂደት ጥቅም ላይ ይውላል. በጣም አስደሳች ፈተና ገጥሞናል፡ በመላው መድረክ ላይ ወጥ የሆነ የግንባታ አካባቢን ለማረጋገጥ የሚያስችል መንገድ ማዘጋጀት ነበረብን። ይህንን ለማድረግ ሁሉም የመሰብሰቢያ ሂደቶች በልዩ መያዣ ውስጥ ይከናወናሉ. ቤት ሠሪ.

የእሱ ኮንቴይነር አተገባበር የላቀ የዶከር ዘዴዎችን ይፈልጋል። ግንበኛ የግል የTinder ማከማቻዎችን ለመድረስ የአካባቢውን የተጠቃሚ መታወቂያ እና ሚስጥሮችን (እንደ SSH ቁልፍ፣ AWS ምስክርነቶች፣ ወዘተ) ይወርሳል። በተፈጥሮ የግንባታ ቅርሶችን ለማከማቸት ምንጮችን የያዙ የአካባቢ ማውጫዎችን ይጭናል። ይህ አቀራረብ አፈፃፀሙን ያሻሽላል ምክንያቱም በግንባታ ኮንቴይነሩ እና በአስተናጋጁ መካከል የግንባታ ቅርሶችን መኮረጅ አስፈላጊነትን ያስወግዳል። የተከማቹ የግንባታ ቅርሶች ያለ ተጨማሪ ውቅር እንደገና ጥቅም ላይ ሊውሉ ይችላሉ።

ለአንዳንድ አገልግሎቶች የማጠናቀሪያውን አካባቢ ወደ ሩጫ ጊዜ ለማሳየት ሌላ ኮንቴይነር መፍጠር ነበረብን (ለምሳሌ፣ በመጫን ጊዜ Node.js bcrypt ቤተመፃህፍት በመድረክ ላይ የተመሰረቱ ሁለትዮሽ ቅርሶችን ይፈጥራል)። በማጠናቀር ጊዜ መስፈርቶቹ ለተለያዩ አገልግሎቶች ሊለያዩ ይችላሉ፣ እና የመጨረሻው Dockerfile በበረራ ላይ ተሰብስቧል።

የኩበርኔትስ ክላስተር አርክቴክቸር እና ፍልሰት

የክላስተር መጠን መቆጣጠሪያ

ለመጠቀም ወሰንን ኩቤ-አውስ በአማዞን EC2 አጋጣሚዎች ላይ በራስ ሰር ክላስተር ለማሰማራት። ገና መጀመሪያ ላይ ሁሉም ነገር በአንድ የጋራ የመስቀለኛ ክፍል ውስጥ ይሠራ ነበር. ሃብቶችን በብቃት ለመጠቀም የስራ ጫናዎችን በምሳሌነት በመጠን እና በአይነት የመለየት አስፈላጊነት በፍጥነት ተገንዝበናል። አመክንዮው ጥቂት የተጫኑ ባለብዙ-ክር ፖዶችን ማስኬድ በአፈፃፀም ውስጥ ከብዙ ነጠላ-ክር ፖድዎች ጋር አብሮ ከመኖር የበለጠ ሊተነበይ የሚችል ነበር።

በስተመጨረሻ፡ አበቃን።

m5.4x ትልቅ - ለክትትል (ፕሮሜቲየስ);
c5.4x ትልቅ - ለ Node.js የስራ ጫና (ነጠላ ክር የስራ ጫና)
c5.2x ትልቅ - ለጃቫ እና ሂድ (ባለብዙ ክር የስራ ጫና);
c5.4x ትልቅ - ለቁጥጥር ፓነል (3 አንጓዎች).

ፍልሰት

ከቀድሞው መሠረተ ልማት ወደ ኩበርኔትስ ለመሸጋገር ከቅድመ ዝግጅት እርምጃዎች አንዱ የነበረው በአገልግሎቶች መካከል ያለውን ቀጥተኛ መስተጋብር ወደ አዲሱ ላስቲክ ሎድ ባላንስ (ELBs) ማዞር ነው። እነሱ የተፈጠሩት በተወሰነ ምናባዊ የግል ደመና (VPC) ንዑስ መረብ ላይ ነው። ይህ ንዑስ መረብ ከ Kubernetes VPC ጋር ተገናኝቷል። ይህ ልዩ የአገልግሎት ጥገኞችን ቅደም ተከተል ከግምት ውስጥ ሳናስገባ ሞጁሎችን በእድገት እንድንሰደድ አስችሎናል።

እነዚህ የመጨረሻ ነጥቦች የተፈጠሩት በእያንዳንዱ አዲስ ELB ላይ በሚጠቁሙ CNAMEs የተመዘኑ የዲ ኤን ኤስ መዝገቦችን በመጠቀም ነው። ለመቀያየር ወደ አዲሱ የኩበርኔትስ አገልግሎት ELB በ0 ክብደት የሚያመለክት አዲስ ግቤት ጨምረናል።ከዚያም የመዝገቡን ጊዜ (TTL) ወደ 0 እናስቀምጠዋለን።ከዛ በኋላ አሮጌው እና አዲሱ ክብደቶች ቀስ ብለው ተስተካክለዋል እና በመጨረሻ 100% ጭነት ወደ አዲሱ አገልጋይ ተልኳል። ማብሪያው ከተጠናቀቀ በኋላ የቲቲኤል እሴት ወደ በቂ ደረጃ ተመልሷል.

የያዝናቸው የጃቫ ሞጁሎች ዝቅተኛውን የቲቲኤል ዲ ኤን ኤስ ይይዙ ነበር፣ ነገር ግን የመስቀለኛ መንገድ መተግበሪያዎች አልነበሩም። ከኢንጂነሮቹ አንዱ የግንኙነቱን ፑል ኮድ ከፊል ፃፈው እና ገንዳዎቹን በየ60 ሰከንድ በሚያዘምን ስራ አስኪያጅ ጠቅልለውታል። የተመረጠው አቀራረብ በጣም ጥሩ እና ጉልህ የሆነ የአፈፃፀም ውድቀት ሳይኖር ሰርቷል.

ትምህርቶቹ

የአውታረ መረብ ፋብሪካ ገደቦች

በጃንዋሪ 8፣ 2019 መጀመሪያ ላይ የቲንደር መድረክ በድንገት ወድቋል። በዚያው ቀን ጠዋት ላይ ከመድረክ መዘግየት ጋር ያልተገናኘ ጭማሪ ምላሽ ለመስጠት በክላስተር ውስጥ ያሉት የፖድ እና አንጓዎች ቁጥር ጨምሯል። ይህ የ ARP መሸጎጫ በሁሉም ኖዶቻችን ላይ እንዲሟጠጥ አድርጓል።

ከኤአርፒ መሸጎጫ ጋር የተያያዙ ሶስት የሊኑክስ አማራጮች አሉ፡

(ምንጩ)

gc_thresh3 ከባድ ገደብ ነው. በምዝግብ ማስታወሻው ውስጥ "የጎረቤት ጠረጴዛ ሞልቶ" መግባቱ ከተመሳሰለ የቆሻሻ ማጠራቀሚያ (ጂሲ) በኋላ እንኳን የጎረቤት ግቤትን ለማከማቸት በ ARP መሸጎጫ ውስጥ በቂ ቦታ አልነበረም. በዚህ ሁኔታ ከርነል በቀላሉ ፓኬጁን ሙሉ በሙሉ ጣለው.

እኛ እንጠቀማለን Flannel በኩበርኔትስ ውስጥ እንደ አውታር ጨርቅ. እሽጎች በVXLAN ላይ ይላካሉ። VXLAN በL2 አውታረመረብ ላይ የሚነሳ L3 ዋሻ ነው። ቴክኖሎጂው MAC-in-UDP (MAC Address-in-User Datagram Protocol) ማቀፊያን ይጠቀማል እና የንብርብሮች 2 ኔትወርክ ክፍሎችን ለማስፋት ያስችላል። በአካላዊ መረጃ ማእከል አውታረመረብ ላይ ያለው የትራንስፖርት ፕሮቶኮል IP እና UDP ነው።

ምስል 2-1. Flannel ገበታ (ምንጩ)

ምስል 2-2. VXLAN ጥቅል (ምንጩ)

እያንዳንዱ የኩበርኔትስ ሰራተኛ መስቀለኛ መንገድ ከትልቅ/24 ብሎክ ለ/9 ጭምብል የተሸፈነ ምናባዊ አድራሻ ቦታ ይመድባል። ለእያንዳንዱ አንጓ, ይህ መንገዶችን በማዞሪያ ሠንጠረዥ ውስጥ አንድ ግቤት፣ በ ARP ሠንጠረዥ ውስጥ አንድ ግቤት (በይነገጽ flannel.1) እና በመቀየሪያ ሠንጠረዥ ውስጥ አንድ ግቤት (ኤፍዲቢ)። ለመጀመሪያ ጊዜ የሰራተኛ መስቀለኛ መንገድ ሲጀመር ወይም እያንዳንዱ አዲስ መስቀለኛ መንገድ ሲገኝ ይታከላሉ።

በተጨማሪም, node-pod (ወይም pod-pod) መገናኛዎች በበይነገጹ ውስጥ ያልፋሉ eth0 (ከላይ ባለው የፍላኔል ገበታ ላይ እንደሚታየው)። ይህ ለእያንዳንዱ ተዛማጅ የአስተናጋጅ ምንጭ እና መድረሻ በ ARP ሰንጠረዥ ውስጥ ተጨማሪ ግቤትን ያስከትላል።

በአካባቢያችን ይህ ዓይነቱ ግንኙነት በጣም የተለመደ ነው. በኩበርኔትስ ላሉት የአገልግሎት ዕቃዎች ELB ተፈጠረ እና ኩበርኔትስ እያንዳንዱን መስቀለኛ መንገድ በኤልቢ ይመዘግባል። ELB ስለ ፖድ ምንም አያውቅም እና የተመረጠው መስቀለኛ መንገድ የፓኬቱ የመጨረሻ መድረሻ ላይሆን ይችላል። እውነታው ግን አንድ መስቀለኛ መንገድ ከኤልቢ (ELB) ፓኬት ሲቀበል, እንደ ደንቦቹ ግምት ውስጥ ያስገባል iptables ለአንድ የተወሰነ አገልግሎት እና በዘፈቀደ በሌላ መስቀለኛ መንገድ ላይ ፖድ ይመርጣል.

በመጥፋቱ ጊዜ በክላስተር ውስጥ 605 ኖዶች ነበሩ. ከላይ በተገለጹት ምክንያቶች ይህ ዋጋውን ለማሸነፍ በቂ ሆኖ ተገኝቷል gc_thresh3, በነባሪነት ተዘጋጅቷል. ይህ ሲሆን እሽጎች መጣል ብቻ ሳይሆን የፍላኔል ሙሉ/24 ምናባዊ አድራሻ ቦታ ከኤአርፒ ሠንጠረዥ ይጠፋል። የፖድ-ወደ-ፖድ ግንኙነት እና የዲኤንኤስ መጠይቆች ተሰብረዋል (ዲ ኤን ኤስ የሚስተናገደው በክላስተር ነው፤ ዝርዝሮችን በኋላ በዚህ ጽሑፍ ይመልከቱ)።

ይህንን ችግር ለመፍታት እሴቶቹን መጨመር ያስፈልግዎታል gc_thresh1, gc_thresh2 и gc_thresh3 እና የጎደሉትን አውታረ መረቦች እንደገና ለመመዝገብ Flannel ን እንደገና ያስጀምሩ።

ያልተጠበቀ የዲ ኤን ኤስ ልኬት

በስደት ሂደት፣ ትራፊክን ለመቆጣጠር እና አገልግሎቶችን ከድሮው መሠረተ ልማት ወደ ኩበርኔትስ ለማስተላለፍ በንቃት ዲ ኤን ኤስን ተጠቅመን ነበር። በ Route53 ውስጥ ለተያያዙ ሪከርዶች በአንጻራዊ ሁኔታ ዝቅተኛ የቲቲኤል እሴቶችን አዘጋጅተናል። የድሮው መሠረተ ልማት በEC2 አጋጣሚዎች ላይ ሲሰራ፣ የኛ ፈታኝ ውቅረት ወደ Amazon DNS አመልክቷል። እንደዋዛ ወስደነዋል እና ዝቅተኛ TTL በአገልግሎታችን እና በአማዞን አገልግሎቶች (ለምሳሌ ዳይናሞዲቢ) ላይ የሚያሳድረው ተጽዕኖ ሳይስተዋል ቀረ።

አገልግሎቶችን ወደ ኩበርኔትስ ስንሸጋገር ዲ ኤን ኤስ በሰከንድ 250ሺህ ጥያቄዎችን እያስተናገደ መሆኑን አግኝተናል። በዚህ ምክንያት አፕሊኬሽኖች በዲ ኤን ኤስ መጠይቆች ላይ የማያቋርጥ እና ከባድ የጊዜ ማብቂያዎችን ማየት ጀመሩ። የዲ ኤን ኤስ አቅራቢውን ወደ CoreDNS (በከፍተኛ ጭነት በ 1000 ኮሮች ላይ የሚሰሩ 120 ፖድዎች ደርሷል) ለማመቻቸት እና ለመቀየር አስደናቂ ጥረት ቢደረግም ይህ ተከሰተ።

ሌሎች ሊሆኑ የሚችሉ ምክንያቶችን እና መፍትሄዎችን ስንመረምር፣ አግኝተናል ጽሑፍየፓኬት ማጣሪያ ማዕቀፍ ላይ ተጽእኖ የሚያሳድሩትን የዘር ሁኔታዎችን የሚገልጽ netfilter በሊኑክስ ውስጥ. የምናስተውለው የጊዜ ማብቂያዎች፣ ከተጨማሪ ቆጣሪ ጋር ማስገባት_አልተሳካም። በ Flannel በይነገጽ ውስጥ ከጽሑፉ መደምደሚያ ጋር ይዛመዳል.

ችግሩ የሚከሰተው የምንጭ እና መድረሻ አውታረ መረብ አድራሻ ትርጉም (SNAT እና ዲኤንኤቲ) እና ከዚያ በኋላ ወደ ጠረጴዛው መግባት ደረጃ ላይ ነው. ኮንትራት. በውስጥ በኩል ውይይት ከተደረገባቸው እና በህብረተሰቡ ከተጠቆሙት መፍትሄዎች አንዱ ዲ ኤን ኤስ ወደ ሰራተኛ መስቀለኛ መንገድ ማዛወር ነው። በዚህ ሁኔታ፡-

ትራፊኩ በአስተናጋጁ ውስጥ ስለሚቆይ SNAT አያስፈልግም። በይነገጹ ውስጥ ማለፍ አያስፈልግም eth0.
ዲኤንኤቲ አያስፈልግም፣ ምክንያቱም የመድረሻ አይፒ ወደ መስቀለኛ መንገድ አካባቢ ስለሆነ እና እንደ ደንቡ በዘፈቀደ በፖድ አልተመረጠም iptables.

ይህንን አካሄድ ለመውሰድ ወሰንን. CoreDNS እንደ DaemonSet በኩበርኔትስ ውስጥ ተሰማርቷል እና በ ውስጥ የአካባቢ አስተናጋጅ ዲ ኤን ኤስ አገልጋይን ተግባራዊ አድርገናል መፍትሄ. ኮን ባንዲራ በማዘጋጀት እያንዳንዱ ፖድአ --ክላስተር-ዲኤን ትዕዛዞች kubelet . ይህ መፍትሔ ለዲኤንኤስ ጊዜ ማብቂያዎች ውጤታማ ሆኖ ተገኝቷል።

ሆኖም፣ አሁንም የፓኬት መጥፋት እና የቆጣሪ ጭማሪ አይተናል። ማስገባት_አልተሳካም። በ Flannel በይነገጽ ውስጥ. SNAT እና/ወይም DNATን ለዲኤንኤስ ትራፊክ ብቻ ማጥፋት ስለቻልን ይህ መፍትሄው ተግባራዊ ከሆነ በኋላም ቀጥሏል። ለሌሎች የትራፊክ ዓይነቶች የውድድር ሁኔታዎች ተጠብቀዋል። እንደ እድል ሆኖ፣ እኛ ያለን አብዛኛዎቹ እሽጎች TCP ናቸው፣ እና ችግር ከተፈጠረ በቀላሉ እንደገና ይተላለፋሉ። አሁንም ለሁሉም የትራፊክ ዓይነቶች ተስማሚ መፍትሄ ለማግኘት እየሞከርን ነው።

ለተሻለ ጭነት ማመጣጠን መልእክተኛን መጠቀም

የኋላ አገልግሎት ወደ ኩበርኔትስ ሲሰደድ፣ በፖድ መካከል ሚዛናዊ ባልሆነ ጭነት መሰቃየት ጀመርን። ኤችቲቲፒ Keepalive በእያንዳንዱ የታጠቀ ማሰማራቱ የመጀመሪያ ዝግጁ ፖድ ላይ የኤልቢ ግንኙነቶች እንዲሰቀሉ እያደረገ መሆኑን ደርሰንበታል። ስለዚህ፣ አብዛኛው የትራፊክ ፍሰት በጥቂቱ ከተገኙት ፖድዎች ውስጥ አልፏል። እኛ የሞከርነው የመጀመሪያው መፍትሄ MaxSurgeን ለከፋ ጉዳዮች በአዲስ ማሰማራት ላይ 100% ማዋቀር ነው። በትልልቅ ማሰማራት ረገድ ውጤቱ እዚህ ግባ የማይባል እና ተስፋ ሰጪ ሆኖ ተገኝቷል።

ሌላው የተጠቀምንበት መፍትሔ ለወሳኝ አገልግሎቶች የግብዓት ጥያቄዎችን በሰው ሰራሽ መንገድ መጨመር ነው። በዚህ ሁኔታ, በአቅራቢያ ያሉ ፖድዎች ከሌሎች ከባድ ምሰሶዎች ጋር ሲነፃፀሩ የበለጠ የሚወዛወዝ ክፍል ይኖራቸዋል. በረዥም ጊዜ፣ በንብረት ብክነትም ምክንያት አይሰራም። በተጨማሪም፣ የእኛ የመስቀለኛ መንገድ አፕሊኬሽኖች ነጠላ-ክር ነበሩ እና፣ በዚህ መሰረት፣ አንድ ኮር ብቻ መጠቀም ይችላሉ። ብቸኛው ትክክለኛ መፍትሔ የተሻለ ጭነት ማመጣጠን መጠቀም ነበር።

እኛ ሙሉ በሙሉ ለማድነቅ ለረጅም ጊዜ እንፈልጋለን መልእክተኛ. አሁን ያለው ሁኔታ በጣም ውስን በሆነ መንገድ አሰማርተን ፈጣን ውጤት እንድናገኝ አስችሎናል። መልእክተኛ ለትልቅ SOA አፕሊኬሽኖች የተነደፈ ክፍት ምንጭ ባለከፍተኛ አፈጻጸም Layer XNUMX ፕሮክሲ ነው። አውቶማቲክ ሙከራዎችን፣ ሰርክ መግቻዎችን እና የአለምአቀፍ ደረጃን መገደብን ጨምሮ የላቀ ጭነት ማመጣጠን ቴክኒኮችን እንዴት እንደሚተገብር ያውቃል። (ማስታወሻ. ትርጉም: ስለዚህ ጉዳይ በ ውስጥ የበለጠ ማንበብ ይችላሉ ይህ ጽሑፍ ስለ ኢስቲዮ፣ እሱም በመልእክተኛ ላይ የተመሰረተ።)

የሚከተለውን አወቃቀሩን ይዘን መጥተናል፡ ለእያንዳንዱ ፖድ እና ነጠላ መንገድ የEnvoy sidecar እንዲኖረን እና ክላስተር ከኮንቴይነር ጋር በአገር ውስጥ በወደብ እንዲገናኝ። እምቅ መወርወርን ለመቀነስ እና የመግደል ራዲየስን ትንሽ ለማድረግ፣ ለእያንዳንዱ አገልግሎት በእያንዳንዱ የAvailability Zone (AZ) አንድ የEnvoy front-proxy pods ተጠቀምን። በየእኛ መሐንዲሶች የተፃፈውን ቀላል የአገልግሎት ማግኛ ዘዴ ተጠቅመው ለእያንዳንዱ AZ ውስጥ ያሉ የፖዳዎች ዝርዝር ለተወሰነ አገልግሎት በቀላሉ ይመልሱ ነበር።

የአገልግሎቱ የፊት መልእክተኞች ይህንን የአገልግሎት ማግኛ ዘዴ ከአንድ ወደላይ ክላስተር እና መስመር ተጠቅመዋል። በቂ የጊዜ ማብቂያዎችን አዘጋጅተናል፣ ሁሉንም የወረዳ የሚላተም ቅንጅቶችን ጨምረናል፣ እና ነጠላ አለመሳካቶችን ለማገዝ እና ለስለስ ያለ መሰማራትን ለማረጋገጥ አነስተኛ ድጋሚ የመሞከር ውቅር አክለናል። ከእነዚህ የአገልግሎት የፊት መልእክተኞች በእያንዳንዱ ፊት፣ TCP ELB አደረግን። ምንም እንኳን ከዋናው የተኪ ንብርብሩ ላይ ያለው ህይወት በአንዳንድ የመልእክተኛ ፖድፖች ላይ ቢሰቀልም ጭነቱን በተሻለ ሁኔታ መቋቋም ይችሉ ነበር እና በኋለኛው ውስጥ በትንሹ_ጥያቄ በኩል እንዲመጣጠን ተዋቅረዋል።

ለማሰማራት፣ በሁለቱም የአፕሊኬሽን ፓዶች እና የጎን መኪና ፓዶች ላይ የቅድመ ማቆሚያ መንጠቆን ተጠቀምን። መንጠቆው በጎን መኪና መያዣው ላይ በሚገኘው የአስተዳዳሪው የመጨረሻ ነጥብ ላይ የሁኔታ ፍተሻ ስህተት አስነስቷል እና ንቁ ግንኙነቶች እንዲጠናቀቁ ለትንሽ ጊዜ ተኛ።

በፍጥነት መሻሻል ከቻልንባቸው ምክንያቶች አንዱ በተለመደው የፕሮሜቲየስ ተከላ ውስጥ በቀላሉ ለማዋሃድ በቻልናቸው ዝርዝር መለኪያዎች ምክንያት ነው። ይህ የማዋቀር አማራጮችን ስናስተካክል እና ትራፊኩን እንደገና ስናከፋፍል ምን እየተካሄደ እንዳለ በትክክል እንድናይ አስችሎናል።

ውጤቶቹ ወዲያውኑ እና ግልጽ ነበሩ. እኛ በጣም ሚዛናዊ ባልሆኑ አገልግሎቶች ጀመርን ፣ እና በአሁኑ ጊዜ በክላስተር ውስጥ ካሉት 12 በጣም አስፈላጊ አገልግሎቶች ፊት ለፊት እየሰራ ነው። በዚህ አመት በላቀ የአገልግሎት ግኝት፣ የወረዳ መሰባበር፣ የውጭ ማወቂያ፣ የፍጥነት ገደብ እና ክትትል ወደ ሙሉ አገልግሎት ጥልፍልፍ ለመሄድ አቅደናል።

ምስል 3-1. ወደ መልእክተኛ በሚሸጋገርበት ጊዜ ነጠላ አገልግሎት የሲፒዩ ውህደት

የመጨረሻ ውጤት

ባገኘነው ልምድ እና ተጨማሪ ምርምር፣ ትላልቅ የኩበርኔትስ ክላስተርዎችን በመንደፍ፣ በማሰማራት እና በመስራት ረገድ ጠንካራ ክህሎት ያለው ጠንካራ የመሰረተ ልማት ቡድን ገንብተናል። አሁን ሁሉም የቲንደር መሐንዲሶች ኮንቴይነሮችን እንዴት ማሸግ እና በ Kubernetes ላይ መተግበሪያዎችን ማሰማራት እንደሚችሉ ዕውቀት እና ልምድ አላቸው።

የድሮው መሠረተ ልማት ተጨማሪ አቅም ሲፈልግ፣ አዲስ EC2 ጉዳዮችን ለመጀመር ብዙ ደቂቃዎችን መጠበቅ ነበረብን። አሁን ኮንቴይነሮች ተጀምረዋል እና ከደቂቃዎች ይልቅ በሰከንዶች ውስጥ ትራፊክ ማካሄድ ይጀምራሉ። በአንድ EC2 አብነት ላይ ብዙ ኮንቴይነሮችን መርሐግብር ማስያዝ የተሻሻለ አግድም ትኩረትን ይሰጣል። በውጤቱም፣ በ2019 የEC2 ወጪዎች ካለፈው ዓመት ጋር ሲነጻጸር በከፍተኛ ሁኔታ እንደሚቀንስ ተንብየናል።

ፍልሰቱ ወደ ሁለት ዓመታት ገደማ ፈጅቷል፣ ግን በመጋቢት 2019 ጨርሰናል። የቲንደር መድረክ በአሁኑ ጊዜ በ200 አገልግሎቶች፣ 1000 ኖዶች፣ 15 ፖዶች እና 000 የሩጫ ኮንቴይነሮች በ Kubernetes ክላስተር ላይ ብቻ ይሰራል። መሠረተ ልማት ከአሁን በኋላ ልዩ የክዋኔ ቡድኖች ጎራ አይደለም። ሁሉም መሐንዲሶቻችን ይህንን ሃላፊነት ይጋራሉ እና ማመልከቻዎቻቸውን በኮድ ብቻ የመገንባት እና የማሰማራት ሂደት ይቆጣጠራሉ።

PS ከተርጓሚ

በብሎጋችን ውስጥ ተከታታይ መጣጥፎችን ያንብቡ፡-

ምንጭ: hab.com

የቲንደር ሽግግር ወደ ኩበርኔትስ