ისტიო და კუბერნეტები წარმოებაშია. ნაწილი 2. ტრასირება

Ბოლოს მუხლი ჩვენ გადავხედეთ Service Mesh Istio-ს ძირითად კომპონენტებს, გავეცანით სისტემას და ვუპასუხეთ მთავარ კითხვებს, რომლებიც ჩვეულებრივ ჩნდება Istio-სთან მუშაობის დაწყებისას. ამ ნაწილში ჩვენ განვიხილავთ, თუ როგორ უნდა მოაწყოთ ტრეკინგის ინფორმაციის შეგროვება ქსელში.

პირველი, რაც ბევრ დეველოპერსა და სისტემის ადმინისტრატორს ახსენდება, როდესაც ისმენენ სიტყვებს Service Mesh is tracing. მართლაც, ჩვენ ვამატებთ სპეციალურ პროქსი სერვერს თითოეულ ქსელის კვანძს, რომლის მეშვეობითაც გადის ყველა TCP ტრაფიკი. როგორც ჩანს, ახლა უკვე შესაძლებელია მარტივად გაგზავნოთ ინფორმაცია ქსელში არსებული ყველა ქსელის ურთიერთქმედების შესახებ. სამწუხაროდ, სინამდვილეში ბევრი ნიუანსია, რომელიც გასათვალისწინებელია. მოდით შევხედოთ მათ.

მცდარი მოსაზრება ნომერი პირველი: ჩვენ შეგვიძლია მივიღოთ ონლაინ ლაშქრობის მონაცემები უფასოდ.

სინამდვილეში, შედარებით უფასოდ, ჩვენ შეგვიძლია მივიღოთ მხოლოდ ჩვენი სისტემის კვანძები, რომლებიც დაკავშირებულია ისრებით და მონაცემთა სიჩქარით, რომელიც გადის სერვისებს შორის (ფაქტობრივად, მხოლოდ ბაიტების რაოდენობა დროის ერთეულზე). თუმცა, უმეტეს შემთხვევაში, ჩვენი სერვისები ურთიერთობენ რაიმე სახის აპლიკაციის ფენის პროტოკოლით, როგორიცაა HTTP, gRPC, Redis და ა.შ. და, რა თქმა უნდა, ჩვენ გვინდა ვიხილოთ მიკვლევის ინფორმაცია სპეციალურად ამ პროტოკოლებისთვის; ჩვენ გვინდა ვიხილოთ მოთხოვნის სიჩქარე და არა მონაცემთა სიჩქარე. ჩვენ გვინდა გავიგოთ მოთხოვნების შეყოვნება ჩვენი პროტოკოლის გამოყენებით. და ბოლოს, ჩვენ გვინდა ვნახოთ სრული გზა, რომელსაც მოთხოვნა გადის ჩვენს სისტემაში შესვლიდან მომხმარებლისგან პასუხის მიღებამდე. ამ პრობლემის გადაჭრა არც ისე ადვილია.

პირველ რიგში, მოდით შევხედოთ როგორ გამოიყურება გაგზავნის ტრასირების სპანები არქიტექტურული თვალსაზრისით ისტიოში. როგორც პირველი ნაწილიდან გვახსოვს, ისტიოს აქვს ცალკე კომპონენტი, რომელსაც ეწოდება Mixer ტელემეტრიის შეგროვებისთვის. თუმცა, მიმდინარე ვერსიაში 1.0.*, გაგზავნა ხდება უშუალოდ პროქსი სერვერებიდან, კერძოდ, envoy proxy-დან. Envoy proxy მხარს უჭერს მიკვლევის სპანების გაგზავნას zipkin პროტოკოლის გამოყენებით ყუთიდან. შესაძლებელია სხვა პროტოკოლების დაკავშირება, მაგრამ მხოლოდ დანამატის საშუალებით. Istio-სთან ერთად ჩვენ დაუყოვნებლივ ვიღებთ აწყობილ და კონფიგურირებულ დესპანის პროქსის, რომელიც მხარს უჭერს მხოლოდ zipkin პროტოკოლს. თუ გვსურს გამოვიყენოთ, მაგალითად, Jaeger პროტოკოლი და გავაგზავნოთ ტრასირების სპანები UDP-ის საშუალებით, მაშინ დაგვჭირდება საკუთარი istio-proxy სურათის შექმნა. არსებობს istio-proxy-ის მორგებული დანამატების მხარდაჭერა, მაგრამ ის ჯერ კიდევ ალფა ვერსიაშია. ამიტომ, თუ ჩვენ გვინდა გავაკეთოთ დიდი რაოდენობის მორგებული პარამეტრების გარეშე, მცირდება ტექნოლოგიების დიაპაზონი, რომლებიც გამოიყენება ტრასირების სპანების შესანახად და მისაღებად. ძირითადი სისტემებიდან, ფაქტობრივად, ახლა შეგიძლიათ გამოიყენოთ თავად Zipkin, ან Jaeger, მაგრამ გაგზავნოთ ყველაფერი იქ zipkin თავსებადი პროტოკოლის გამოყენებით (რაც გაცილებით ნაკლებად ეფექტურია). თავად zipkin პროტოკოლი გულისხმობს კოლექციონერებისთვის მიკვლევის ყველა ინფორმაციის გაგზავნას HTTP პროტოკოლის საშუალებით, რაც საკმაოდ ძვირია.

როგორც უკვე ვთქვი, ჩვენ გვინდა დავაკვირდეთ აპლიკაციის დონის პროტოკოლებს. ეს ნიშნავს, რომ პროქსი სერვერებმა, რომლებიც დგანან თითოეული სერვისის გვერდით, უნდა გაიგონ, რა სახის ურთიერთქმედება ხდება ახლა. ნაგულისხმევად, Istio აკონფიგურირებს ყველა პორტს, რომ იყოს ჩვეულებრივი TCP, რაც ნიშნავს, რომ კვალი არ გაიგზავნება. იმისათვის, რომ კვალი გაიგზავნოს, პირველ რიგში, თქვენ უნდა ჩართოთ ეს პარამეტრი მთავარ ქსელის კონფიგურაციაში და, რაც ძალიან მნიშვნელოვანია, დაასახელოთ kubernetes სერვისის ერთეულების ყველა პორტი პროტოკოლის შესაბამისად, რომელიც გამოიყენება სერვისში. ეს არის, მაგალითად, ასეთი:

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

თქვენ ასევე შეგიძლიათ გამოიყენოთ რთული სახელები, როგორიცაა http-magic (Istio დაინახავს http და ამოიცნობს ამ პორტს, როგორც http ბოლო წერტილს). ფორმატი არის: პროტო-დამატებითი.

იმისათვის, რომ არ შეცვალოთ კონფიგურაციის დიდი რაოდენობა პროტოკოლის დასადგენად, შეგიძლიათ გამოიყენოთ ბინძური გამოსავალი: დააყენეთ Pilot კომპონენტი იმ მომენტში, როდესაც ის მხოლოდ ასრულებს პროტოკოლის განსაზღვრის ლოგიკას. საბოლოო ჯამში, რა თქმა უნდა, საჭირო იქნება ამ ლოგიკის შეცვლა სტანდარტზე და ყველა პორტის დასახელების კონვენციაზე გადასვლა.

იმისათვის, რომ გაიგოთ, არის თუ არა პროტოკოლი სწორად განსაზღვრული, თქვენ უნდა შეხვიდეთ რომელიმე გვერდითა კონტეინერში envoy proxy-ით და მიმართოთ envoy ინტერფეისის ადმინისტრაციულ პორტს მდებარეობით /config_dump. შედეგად კონფიგურაციაში, თქვენ უნდა დაათვალიეროთ სასურველი სერვისის მოქმედების ველი. ის გამოიყენება Istio-ში, როგორც იდენტიფიკატორი, სადაც მოთხოვნა ხდება. Istio-ში ამ პარამეტრის მნიშვნელობის მორგებისთვის (შემდეგ მას დავინახავთ ჩვენს ტრასინგის სისტემაში), აუცილებელია მიუთითოთ serviceCluster დროშა გვერდითი კარის კონტეინერის გაშვების ეტაპზე. მაგალითად, ის შეიძლება გამოითვალოს ქვევით kubernetes API-დან მიღებული ცვლადებიდან:

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

კარგი მაგალითია იმის გასაგებად, თუ როგორ მუშაობს მოკვლევა დესპანში აქ.

თავად საბოლოო წერტილი ტრასირების სპანების გაგზავნისთვის ასევე უნდა იყოს მითითებული ელჩის მარიონეტული გაშვების დროშებში, მაგალითად: --zipkinAddress tracing-collector.tracing:9411

მცდარი მოსაზრება ნომერი ორი: ჩვენ შეგვიძლია იაფად მივიღოთ მოთხოვნების სრული კვალი სისტემის მეშვეობით ყუთიდან

სამწუხაროდ, ეს ასე არ არის. განხორციელების სირთულე დამოკიდებულია იმაზე, თუ როგორ უკვე განახორციელეთ სერვისების ურთიერთქმედება. Რატომ არის, რომ?

ფაქტია, რომ იმისთვის, რომ istio-proxy-ს შეეძლოს გაიგოს სერვისზე შემოსული მოთხოვნების შესაბამისობა იმავე სერვისის მიტოვებასთან, საკმარისი არ არის უბრალოდ მთელი ტრაფიკის ჩარევა. თქვენ უნდა გქონდეთ რაიმე სახის საკომუნიკაციო იდენტიფიკატორი. HTTP envoy proxy იყენებს სპეციალურ სათაურებს, რომლითაც დესპანი ესმის, რომელი კონკრეტული მოთხოვნა სერვისის მიმართ წარმოქმნის კონკრეტულ მოთხოვნებს სხვა სერვისებზე. ასეთი სათაურების სია:

• x-მოთხოვნის ID,
• x-b3-traceid,
• x-b3-სპანიდი,
• x-b3-parentspanid,
• x-b3-ნიმუში,
• x-b3-დროშები,
• x-ot-span-context.

თუ თქვენ გაქვთ ერთი წერტილი, მაგალითად, ძირითადი კლიენტი, რომელშიც შეგიძლიათ დაამატოთ ასეთი ლოგიკა, მაშინ ყველაფერი კარგადაა, თქვენ უბრალოდ უნდა დაელოდოთ ამ ბიბლიოთეკის განახლებას ყველა კლიენტისთვის. მაგრამ თუ თქვენ გაქვთ ძალიან ჰეტეროგენული სისტემა და არ არის გაერთიანება სერვისიდან სერვისზე ქსელში გადასვლისას, მაშინ ეს, სავარაუდოდ, დიდი პრობლემა იქნება. ასეთი ლოგიკის დამატების გარეშე, ყველა მოკვლევის ინფორმაცია იქნება მხოლოდ "ერთ დონის". ანუ, ჩვენ მივიღებთ ყველა სერვისთაშორისი ურთიერთქმედებას, მაგრამ ისინი არ იქნება მიბმული ქსელის გავლის ერთ ჯაჭვში.

დასკვნა

Istio უზრუნველყოფს მოსახერხებელ ინსტრუმენტს ქსელის საშუალებით მიკვლევის ინფორმაციის შესაგროვებლად, მაგრამ თქვენ უნდა გესმოდეთ, რომ განხორციელებისთვის დაგჭირდებათ თქვენი სისტემის ადაპტირება და Istio-ს განხორციელების მახასიათებლების გათვალისწინება. შედეგად, ორი ძირითადი პუნქტი უნდა გადაწყდეს: აპლიკაციის დონის პროტოკოლის განსაზღვრა (რომელიც მხარდაჭერილი უნდა იყოს ელჩის პროქსის მიერ) და სერვისთან მოთხოვნის კავშირის შესახებ ინფორმაციის გადაგზავნა სერვისის მოთხოვნიდან (სათაურების გამოყენებით). , HTTP პროტოკოლის შემთხვევაში). როდესაც ეს საკითხები მოგვარდება, ჩვენ გვაქვს მძლავრი ინსტრუმენტი, რომელიც საშუალებას გვაძლევს გამჭვირვალედ შევაგროვოთ ინფორმაცია ქსელიდან, თუნდაც ძალიან ჰეტეროგენულ სისტემებში, რომლებიც დაწერილია მრავალ სხვადასხვა ენაზე და ჩარჩოებში.

შემდეგ სტატიაში Service Mesh-ის შესახებ, ჩვენ გადავხედავთ Istio-ს ერთ-ერთ ყველაზე დიდ პრობლემას - RAM-ის დიდ მოხმარებას თითოეული sidecar proxy კონტეინერის მიერ და განვიხილავთ, თუ როგორ შეგიძლიათ გაუმკლავდეთ მას.

წყარო: www.habr.com