ኢስቲዮ እና ኩበርኔትስ በምርት ላይ። ክፍል 2. መከታተል

በመጨረሻው ጽሑፍ የሰርቪስ ሜሽ ኢስቲዮ መሰረታዊ ክፍሎችን ተመልክተናል ፣ ከስርአቱ ጋር መተዋወቅ እና ከኢስቲዮ ጋር መሥራት ስንጀምር ብዙውን ጊዜ የሚነሱትን ዋና ጥያቄዎች መለስን። በዚህ ክፍል የክትትል መረጃን በኔትወርክ እንዴት ማደራጀት እንደሚቻል እንመለከታለን።

ኢስቲዮ እና ኩበርኔትስ በምርት ላይ። ክፍል 2. መከታተል

ለብዙ ገንቢዎች እና የስርዓት አስተዳዳሪዎች ሰርቪስ ሜሽ የሚሉ ቃላትን ሲሰሙ ወደ አእምሮ የሚመጣው የመጀመሪያው ነገር። በእርግጥ ሁሉም የTCP ትራፊክ ወደሚያልፍበት እያንዳንዱ የአውታረ መረብ መስቀለኛ መንገድ ልዩ ተኪ አገልጋይ እንጨምራለን ። አሁን በአውታረ መረቡ ላይ ስላለው ሁሉም የአውታረ መረብ ግንኙነቶች መረጃን በቀላሉ መላክ የሚቻል ይመስላል። እንደ አለመታደል ሆኖ ፣ በእውነቱ ከግምት ውስጥ መግባት ያለባቸው ብዙ ልዩነቶች አሉ። እስቲ እንያቸው።

የተሳሳተ ቁጥር አንድ፡ የመስመር ላይ የእግር ጉዞ ዳታን በነጻ ማግኘት እንችላለን።

እንዲያውም በአንፃራዊነት በነፃ የስርዓታችንን አንጓዎች በቀስቶች እና በአገልግሎቶች መካከል የሚያልፍ የውሂብ መጠን ብቻ ነው ማግኘት የምንችለው (በእርግጥ የአንድ ጊዜ ባይት ብዛት ብቻ)። ነገር ግን፣ በአብዛኛዎቹ አጋጣሚዎች አገልግሎቶቻችን እንደ HTTP፣ gRPC፣ Redis፣ እና የመሳሰሉት ባሉ የመተግበሪያ ንብርብር ፕሮቶኮሎች ላይ ይገናኛሉ። እና፣ በእርግጥ፣ ለእነዚህ ፕሮቶኮሎች የመከታተያ መረጃን ማየት እንፈልጋለን፤ የምንፈልገው የውሂብ መጠን ሳይሆን የጥያቄ መጠን ነው። ፕሮቶኮላችንን በመጠቀም የጥያቄዎችን መዘግየት መረዳት እንፈልጋለን። በመጨረሻም፣ ጥያቄ ወደ ስርዓታችን ከመግባት ጀምሮ የተጠቃሚውን ምላሽ እስከመቀበል ድረስ የሚወስደውን ሙሉ መንገድ ማየት እንፈልጋለን። ይህ ችግር አሁን ለመፍታት በጣም ቀላል አይደለም.

በመጀመሪያ፣ በኢስቲዮ ውስጥ ካለው የስነ-ህንፃ እይታ አንጻር የመከታተያ ክፍተቶችን መላክ ምን እንደሚመስል እንመልከት። ከመጀመሪያው ክፍል እንደምናስታውሰው፣ ኢስቲዮ ቴሌሜትሪ ለመሰብሰብ ሚክስየር የሚባል የተለየ አካል አለው። ነገር ግን፣ አሁን ባለው ስሪት 1.0.*፣ መላክ የሚከናወነው በቀጥታ ከተኪ አገልጋዮች ማለትም ከተላላኪ ፕሮክሲ ነው። የመልእክት ተኪ ከሳጥኑ ውስጥ የዚፕኪን ፕሮቶኮልን በመጠቀም የመከታተያ ክፍተቶችን መላክን ይደግፋል። ሌሎች ፕሮቶኮሎችን ማገናኘት ይቻላል, ግን በፕለጊን ብቻ. ከኢስቲዮ ጋር ወዲያውኑ የዚፕኪን ፕሮቶኮልን ብቻ የሚደግፍ የተሰበሰበ እና የተዋቀረ የመልእክተኛ ፕሮክሲ እናገኛለን። ለምሳሌ የጃገር ፕሮቶኮልን ለመጠቀም እና በUDP በኩል የመከታተያ ቦታዎችን ለመላክ ከፈለግን የራሳችንን istio-proxy ምስል መገንባት አለብን። ለ istio-proxy ብጁ ተሰኪዎች ድጋፍ አለ፣ ግን አሁንም በአልፋ ስሪት ውስጥ ነው። ስለዚህ፣ ያለብዙ ብጁ ቅንጅቶች ማድረግ ከፈለግን የመከታተያ ቦታዎችን ለማከማቸት እና ለመቀበል የሚያገለግሉ ቴክኖሎጂዎች ብዛት ቀንሷል። ከዋና ዋናዎቹ ስርዓቶች, በእውነቱ, አሁን ዚፕኪን እራሱን ወይም ጄገርን መጠቀም ይችላሉ, ነገር ግን ሁሉንም ነገር በዚፕኪን ተኳሃኝ ፕሮቶኮል (ይህም በጣም ያነሰ ውጤታማ) በመጠቀም ይላኩ. የዚፕኪን ፕሮቶኮል ራሱ ሁሉንም የመከታተያ መረጃዎችን በኤችቲቲፒ ፕሮቶኮል ወደ ሰብሳቢዎች መላክን ያካትታል ይህም በጣም ውድ ነው።

አስቀድሜ እንዳልኩት፣ የመተግበሪያ ደረጃ ፕሮቶኮሎችን መፈለግ እንፈልጋለን። ይህ ማለት ከእያንዳንዱ አገልግሎት ቀጥሎ የሚቆሙት ፕሮክሲ ሰርቨሮች ምን አይነት መስተጋብር አሁን እየተፈጠረ እንዳለ መረዳት አለባቸው ማለት ነው። በነባሪ፣ ኢስቲዮ ሁሉንም ወደቦች ግልጽ TCP እንዲሆኑ ያዋቅራል፣ ይህ ማለት ምንም ዱካ አይላክም። ዱካዎች እንዲላኩ በመጀመሪያ ይህንን አማራጭ በዋናው ሜሽ ውቅረት ውስጥ ማንቃት እና በጣም አስፈላጊ የሆነው በአገልግሎቱ ውስጥ በአገልግሎት ላይ በሚውለው ፕሮቶኮል መሠረት ሁሉንም የኩበርኔትስ አገልግሎት ሰጪ አካላትን መሰየም አለብዎት ። ማለትም፣ ለምሳሌ፣ እንደዚህ፡-

apiVersion: v1
kind: Service
metadata:
  name: nginx
spec:
  ports:
  - port: 80
    targetPort: 80
    name: http
  selector:
    app: nginx

እንዲሁም እንደ http-magic ያሉ የተዋሃዱ ስሞችን መጠቀም ይችላሉ (ኢስቲዮ http ያያል እና ያንን ወደብ እንደ http የመጨረሻ ነጥብ ይገነዘባል)። ቅርጸቱ፡- proto-extra ነው።

ፕሮቶኮሉን ለመወሰን እጅግ በጣም ብዙ አወቃቀሮችን ላለማስተካከል፣ የቆሸሸ የአሰራር ዘዴን መጠቀም ይችላሉ፡ ልክ በሚሆንበት ጊዜ የፓይሎት ክፍሉን ያስተካክሉ። የፕሮቶኮል ፍቺ አመክንዮ ያከናውናል. በስተመጨረሻ፣ በእርግጥ፣ ይህንን አመክንዮ ወደ መደበኛው መለወጥ እና ለሁሉም ወደቦች ወደ ስም አሰጣጥ ስምምነት መቀየር አስፈላጊ ይሆናል።

ፕሮቶኮሉ በትክክል መገለጹን ለመረዳት ወደ የትኛውም የጎን መኪና ኮንቴይነሮች ከመልእክተኛ ፕሮክሲ ጋር ገብተህ የመልእክተኛውን በይነገጽ አስተዳዳሪ ወደብ ከቦታ/config_dump ጋር መጠየቅ አለብህ። በውጤቱ ውቅር ውስጥ የተፈለገውን አገልግሎት የስራ መስክ ማየት ያስፈልግዎታል. ጥያቄው የሚቀርብበትን ቦታ እንደ መለያ በኢስቲዮ ውስጥ ጥቅም ላይ ይውላል። በ Istio ውስጥ የዚህን ግቤት ዋጋ ለማበጀት (ከዚያም በክትትል ስርዓታችን ውስጥ እናየዋለን) የጎን መኪና መያዣውን በሚነሳበት ደረጃ ላይ የአገልግሎቱን ክላስተር ባንዲራ መግለጽ አስፈላጊ ነው። ለምሳሌ፣ ከቁልቁል kubernetes API ከተገኙት ተለዋዋጮች እንደዚህ ሊሰላ ይችላል።

--serviceCluster ${POD_NAMESPACE}.$(echo ${POD_NAME} | sed -e 's/-[a-z0-9]*-[a-z0-9]*$//g')

በመልእክተኛ ውስጥ መከታተል እንዴት እንደሚሰራ ለመረዳት ጥሩ ምሳሌ እዚህ.

የመከታተያ ክፍተቶችን ለመላክ የመጨረሻው ነጥብ እንዲሁ በመልእክተኛው ተኪ ማስጀመሪያ ባንዲራዎች ውስጥ መገለጽ አለበት፣ ለምሳሌ፡- --zipkinAddress tracing-collector.tracing:9411

የተሳሳተ ቁጥር ሁለት፡ ከሳጥኑ ውጪ በሲስተሙ በኩል የተሟሉ የጥያቄ ምልክቶችን በውድ ማግኘት እንችላለን

በሚያሳዝን ሁኔታ, አይደለም. የአተገባበሩ ውስብስብነት የአገልግሎቶች መስተጋብርን እንዴት እንደተተገበሩ ይወሰናል. ለምንድነው?

እውነታው ግን ኢስቲዮ ፕሮክሲ ከተመሳሳይ አገልግሎት ከሚወጡት ጋር ወደ አንድ አገልግሎት የሚመጡ ጥያቄዎችን ደብዳቤ ለመረዳት እንዲችል ሁሉንም ትራፊክ ለመጥለፍ ብቻ በቂ አይደለም። አንድ ዓይነት የግንኙነት መለያ ሊኖርዎት ይገባል። የኤችቲቲፒ መልእክተኛ ተኪ ልዩ ራስጌዎችን ይጠቀማል፣ በዚህም መልእክተኛው የትኛው የተለየ የአገልግሎቱ ጥያቄ ለሌሎች አገልግሎቶች የተለየ ጥያቄ እንደሚያመጣ ይገነዘባል። እንደዚህ ያሉ ራስጌዎች ዝርዝር:

  • x-ጥያቄ-መታወቂያ፣
  • x-b3-መከታተያ፣
  • x-b3-ስፓኒሽ፣
  • x-b3-የወላጆች ስፓኒድ፣
  • x-b3-ናሙና፣
  • x-b3-ባንዲራዎች፣
  • x-ot-span- አውድ።

አንድ ነጠላ ነጥብ ካለዎት, ለምሳሌ, መሰረታዊ ደንበኛ, እንደዚህ አይነት አመክንዮ መጨመር የሚችሉበት, ከዚያ ሁሉም ነገር ጥሩ ነው, ይህ ቤተ-መጽሐፍት ለሁሉም ደንበኞች እስኪዘመን ድረስ መጠበቅ አለብዎት. ነገር ግን በጣም የተለያየ ስርዓት ካለዎት እና ከአገልግሎት ወደ አገልግሎት በኔትወርኩ ውስጥ ምንም አይነት ውህደት ከሌለ ይህ ምናልባት ትልቅ ችግር ሊሆን ይችላል. እንደዚህ አይነት አመክንዮ ሳይጨምር ሁሉም የመከታተያ መረጃ "ነጠላ-ደረጃ" ብቻ ይሆናል. ያም ማለት ሁሉንም የኢንተር-አገልግሎት ግንኙነቶችን እንቀበላለን, ነገር ግን በኔትወርኩ ውስጥ ወደ ነጠላ የመተላለፊያ ሰንሰለቶች አይጣበቁም.

መደምደሚያ

ኢስቲዮ በአውታረመረብ ላይ መረጃን ለመሰብሰብ ምቹ መሣሪያን ይሰጣል ፣ ግን ለትግበራ ስርዓትዎን ማላመድ እና የኢስቲዮ አተገባበርን ባህሪዎች ከግምት ውስጥ ማስገባት እንደሚያስፈልግ መረዳት አለብዎት። በውጤቱም, ሁለት ዋና ዋና ነጥቦችን መፍታት ያስፈልጋል-የመተግበሪያ ደረጃ ፕሮቶኮልን መግለፅ (በመልእክተኛው ፕሮክሲው መደገፍ አለበት) እና ከአገልግሎቱ የሚቀርቡ ጥያቄዎችን ከአገልግሎቱ ጋር ያለውን ግንኙነት መረጃ ማስተላለፍ (ራስጌዎችን በመጠቀም) , በኤችቲቲፒ ፕሮቶኮል). እነዚህ ጉዳዮች ሲፈቱ በብዙ ቋንቋዎች እና ማዕቀፎች የተፃፉ በጣም የተለያዩ ስርዓቶች ውስጥ እንኳን ከአውታረ መረቡ ላይ መረጃን በግልፅ ለመሰብሰብ የሚያስችል ኃይለኛ መሳሪያ አለን።

ስለ ሰርቪስ ሜሽ በሚቀጥለው መጣጥፍ በኢስቲዮ ላይ ካሉት ትላልቅ ችግሮች አንዱን እንመለከታለን - በእያንዳንዱ የጎን መኪና ፕሮክሲ ኮንቴይነር ትልቅ የ RAM ፍጆታ እና እሱን እንዴት መቋቋም እንደሚችሉ እንነጋገራለን ።

ምንጭ: hab.com

አስተያየት ያክሉ