"კუბერნეტებმა 10-ჯერ გაზარდა შეყოვნება": ვინ არის ამაში დამნაშავე?

Შენიშვნა. თარგმნა: ეს სტატია, დაწერილი გალო ნავაროს მიერ, რომელსაც უკავია მთავარი პროგრამული უზრუნველყოფის ინჟინრის თანამდებობა ევროპულ კომპანია Adevinta-ში, არის მომხიბლავი და ინსტრუქციული „გამოძიება“ ინფრასტრუქტურის ოპერაციების სფეროში. მისი ორიგინალური სათაური თარგმანში ოდნავ გაფართოვდა იმ მიზეზით, რასაც ავტორი თავიდანვე განმარტავს.

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

რამდენიმე კვირის წინ, ჩემმა გუნდმა გადაიტანა ერთი მიკროსერვისი ძირითად პლატფორმაზე, რომელიც მოიცავდა CI/CD, Kubernetes-ზე დაფუძნებულ გაშვებას, მეტრიკას და სხვა სიკეთეებს. ნაბიჯი საცდელი ხასიათის იყო: ჩვენ ვგეგმავდით მის საფუძვლად მიგვეღო და კიდევ დაახლოებით 150 სერვისის გადაცემა უახლოეს თვეებში. ყველა მათგანი პასუხისმგებელია ესპანეთის ზოგიერთი უმსხვილესი ონლაინ პლატფორმის ფუნქციონირებაზე (Infojobs, Fotocasa და ა.შ.).

მას შემდეგ, რაც აპლიკაცია განვათავსეთ Kubernetes-ზე და გადავიტანეთ გარკვეული ტრაფიკი მასზე, საგანგაშო სიურპრიზი გველოდა. დაგვიანებით (დაყოვნება) მოთხოვნა Kubernetes-ში 10-ჯერ მეტი იყო, ვიდრე EC2-ში. ზოგადად, საჭირო იყო ან ამ პრობლემის გადაწყვეტის პოვნა, ან მიკროსერვისის (და, შესაძლოა, მთელი პროექტის) მიგრაციის მიტოვება.

რატომ არის შეყოვნება ასე უფრო მაღალი Kubernetes-ში, ვიდრე EC2-ში?

შეფერხების საპოვნელად, ჩვენ შევაგროვეთ მეტრიკა მოთხოვნის მთელ გზაზე. ჩვენი არქიტექტურა მარტივია: API კარიბჭე (Zuul) ითხოვს მიკროსერვისის ინსტანციებს EC2 ან Kubernetes-ში. Kubernetes-ში ჩვენ ვიყენებთ NGINX Ingress Controller-ს, ხოლო backends არის ჩვეულებრივი ობიექტები, როგორიცაა განლაგება JVM აპლიკაციით Spring პლატფორმაზე.

                                  EC2
                            +---------------+
                            |  +---------+  |
                            |  |         |  |
                       +-------> BACKEND |  |
                       |    |  |         |  |
                       |    |  +---------+  |                   
                       |    +---------------+
             +------+  |
Public       |      |  |
      -------> ZUUL +--+
traffic      |      |  |              Kubernetes
             +------+  |    +-----------------------------+
                       |    |  +-------+      +---------+ |
                       |    |  |       |  xx  |         | |
                       +-------> NGINX +------> BACKEND | |
                            |  |       |  xx  |         | |
                            |  +-------+      +---------+ |
                            +-----------------------------+

პრობლემა, როგორც ჩანს, დაკავშირებული იყო თავდაპირველ შეყოვნებასთან ფონზე (მე აღვნიშნე დიაგრამაზე პრობლემის არე, როგორც "xx"). EC2-ზე განაცხადის პასუხს დაახლოებით 20 ms დასჭირდა. Kubernetes-ში შეყოვნება გაიზარდა 100-200 ms-მდე.

ჩვენ სწრაფად გავათავისუფლეთ სავარაუდო ეჭვმიტანილები, რომლებიც დაკავშირებულია გაშვების დროის ცვლილებასთან. JVM ვერსია იგივე რჩება. კონტეინერიზაციის პრობლემებს ასევე არაფერი ჰქონდა საერთო: აპლიკაცია უკვე წარმატებით მუშაობდა კონტეინერებში EC2-ზე. Ჩატვირთვა? მაგრამ ჩვენ დავაკვირდით მაღალ შეფერხებებს წამში 1 მოთხოვნითაც კი. ასევე შეიძლება უგულებელვყოთ ნაგვის შეგროვების პაუზები.

ჩვენი Kubernetes-ის ერთ-ერთ ადმინისტრატორს აინტერესებდა, ჰქონდა თუ არა აპლიკაციას გარე დამოკიდებულებები, რადგან DNS მოთხოვნები წარსულში იწვევდა მსგავს პრობლემებს.

ჰიპოთეზა 1: DNS სახელის გარჩევადობა

თითოეული მოთხოვნისთვის, ჩვენი აპლიკაცია წვდება AWS Elasticsearch მაგალითს ერთიდან სამჯერ დომენში, როგორიცაა elastic.spain.adevinta.com. ჩვენს კონტეინერებში არის ჭურვი, ასე რომ, ჩვენ შეგვიძლია შევამოწმოთ დომენის ძიებას ნამდვილად დიდი დრო სჭირდება.

DNS მოთხოვნები კონტეინერიდან:

[root@be-851c76f696-alf8z /]# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 22 msec
;; Query time: 22 msec
;; Query time: 29 msec
;; Query time: 21 msec
;; Query time: 28 msec
;; Query time: 43 msec
;; Query time: 39 msec

მსგავსი მოთხოვნები EC2-ის ერთ-ერთი შემთხვევიდან, სადაც აპლიკაცია მუშაობს:

bash-4.4# while true; do dig "elastic.spain.adevinta.com" | grep time; sleep 2; done
;; Query time: 77 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec
;; Query time: 0 msec

იმის გათვალისწინებით, რომ ძიებას დაახლოებით 30 ms დასჭირდა, ცხადი გახდა, რომ DNS გარჩევადობა Elasticsearch-ზე წვდომისას მართლაც ხელს უწყობდა შეყოვნების ზრდას.

თუმცა, ეს უცნაური იყო ორი მიზეზის გამო:

1. ჩვენ უკვე გვაქვს ტონა Kubernetes აპლიკაცია, რომლებიც ურთიერთქმედებენ AWS რესურსებთან მაღალი შეყოვნების გარეშე. რაც არ უნდა იყოს მიზეზი, ის კონკრეტულად ამ საქმეს ეხება.
2. ჩვენ ვიცით, რომ JVM აკეთებს მეხსიერებაში DNS ქეშირებას. ჩვენს სურათებში TTL მნიშვნელობა იწერება $JAVA_HOME/jre/lib/security/java.security და დააყენეთ 10 წამზე: networkaddress.cache.ttl = 10. სხვა სიტყვებით რომ ვთქვათ, JVM-მა უნდა შეინახოს ყველა DNS მოთხოვნა 10 წამის განმავლობაში.

პირველი ჰიპოთეზის დასადასტურებლად, ჩვენ გადავწყვიტეთ შეგვეჩერებინა DNS-ის დარეკვა გარკვეული ხნით და ვნახოთ, გაქრა თუ არა პრობლემა. პირველ რიგში, ჩვენ გადავწყვიტეთ აპლიკაციის ხელახლა კონფიგურაცია ისე, რომ ის პირდაპირ დაუკავშირდეს Elasticsearch-ს IP მისამართით, ვიდრე დომენის სახელით. ამას დასჭირდება კოდის ცვლილებები და ახალი განლაგება, ამიტომ ჩვენ უბრალოდ დავაფიქსირეთ დომენი მის IP მისამართზე /etc/hosts:

34.55.5.111 elastic.spain.adevinta.com

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

დიაგნოსტიკა ქსელის საშუალებით

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

[root@be-851c76f696-alf8z /]# tcpdump -leni any -w capture.pcap

შემდეგ ჩვენ გავგზავნეთ რამდენიმე მოთხოვნა და გადმოვწერეთ მათი გადაღება (kubectl cp my-service:/capture.pcap capture.pcap) შემდგომი ანალიზისთვის Wireshark.

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

პაკეტის ნომრები ნაჩვენებია პირველ სვეტში. სიცხადისთვის, მე ფერადი კოდირებული მაქვს სხვადასხვა TCP ნაკადები.

მწვანე ნაკადი, რომელიც იწყება 328 პაკეტით, გვიჩვენებს, თუ როგორ დაამყარა კლიენტმა (172.17.22.150) TCP კავშირი კონტეინერთან (172.17.36.147). თავდაპირველი ხელის ჩამორთმევის შემდეგ (328-330), 331 პაკეტი მოიტანეს HTTP GET /v1/.. — შემომავალი მოთხოვნა ჩვენს სერვისზე. მთელ პროცესს 1 ms დასჭირდა.

ნაცრისფერი ნაკადი (პაკეტიდან 339) აჩვენებს, რომ ჩვენმა სერვისმა გაუგზავნა HTTP მოთხოვნა Elasticsearch ინსტანციას (არ არსებობს TCP ხელის ჩამორთმევა, რადგან ის იყენებს არსებულ კავშირს). ამას დასჭირდა 18 ms.

ჯერჯერობით ყველაფერი კარგადაა და დრო უხეშად შეესაბამება მოსალოდნელ შეფერხებებს (კლიენტისგან გაზომვისას 20-30 ms).

თუმცა, ლურჯი განყოფილება იღებს 86 ms. რა ხდება მასში? 333 პაკეტით, ჩვენმა სერვისმა გაგზავნა HTTP GET მოთხოვნა /latest/meta-data/iam/security-credentialsდა ამის შემდეგ, იმავე TCP კავშირის საშუალებით, კიდევ ერთი GET მოთხოვნა /latest/meta-data/iam/security-credentials/arn:...

ჩვენ აღმოვაჩინეთ, რომ ეს მეორდებოდა ყოველი თხოვნით მთელი კვალის განმავლობაში. DNS რეზოლუცია მართლაც ცოტა ნელია ჩვენს კონტეინერებში (ამ ფენომენის ახსნა საკმაოდ საინტერესოა, მაგრამ ცალკე სტატიისთვის შევინახავ). აღმოჩნდა, რომ ხანგრძლივი შეფერხების მიზეზი იყო ზარები AWS Instance Metadata სერვისზე ყოველი მოთხოვნით.

ჰიპოთეზა 2: არასაჭირო ზარები AWS-ზე

ორივე ბოლო წერტილი ეკუთვნის AWS Instance Metadata API. ჩვენი მიკროსერვისი იყენებს ამ სერვისს Elasticsearch-ის გაშვებისას. ორივე ზარი არის ავტორიზაციის ძირითადი პროცესის ნაწილი. საბოლოო წერტილი, რომელზეც წვდომა ხდება პირველ მოთხოვნაზე, გასცემს IAM როლს, რომელიც ასოცირდება ინსტანციასთან.

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/
arn:aws:iam::<account_id>:role/some_role

მეორე მოთხოვნა ითხოვს მეორე საბოლოო პუნქტს დროებითი ნებართვებისთვის ამ მაგალითისთვის:

/ # curl http://169.254.169.254/latest/meta-data/iam/security-credentials/arn:aws:iam::<account_id>:role/some_role`
{
    "Code" : "Success",
    "LastUpdated" : "2012-04-26T16:39:16Z",
    "Type" : "AWS-HMAC",
    "AccessKeyId" : "ASIAIOSFODNN7EXAMPLE",
    "SecretAccessKey" : "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "Token" : "token",
    "Expiration" : "2017-05-17T15:09:54Z"
}

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

AWS Java SDK უნდა აიღოს პასუხისმგებლობა ამ პროცესის ორგანიზებაზე, მაგრამ რატომღაც ეს არ ხდება.

GitHub-ზე პრობლემების ძიების შემდეგ, პრობლემას წავაწყდით # 1921. ის დაგვეხმარა განვსაზღვროთ მიმართულება, რომლითაც შემდგომში „გათხრა“.

AWS SDK განაახლებს სერთიფიკატებს, როდესაც ხდება ერთ-ერთი შემდეგი პირობა:

• Ვადის გასვლის თარიღი (Expiration) ჩავარდა EXPIRATION_THRESHOLD, მყარი კოდირებულია 15 წუთამდე.
• სერთიფიკატების განახლების ბოლო მცდელობიდან უფრო მეტი დრო გავიდა, ვიდრე REFRESH_THRESHOLD, მყარი კოდირებული 60 წუთის განმავლობაში.

ჩვენ მიერ მიღებული სერთიფიკატების ვადის გასვლის თარიღის სანახავად, ჩვენ გავუშვით ზემოთ მოცემული cURL ბრძანებები როგორც კონტეინერიდან, ასევე EC2 ინსტანციიდან. კონტეინერიდან მიღებული სერთიფიკატის მოქმედების ვადა გაცილებით მოკლე აღმოჩნდა: ზუსტად 15 წუთი.

ახლა ყველაფერი ნათელი გახდა: პირველი მოთხოვნისთვის ჩვენმა სამსახურმა მიიღო დროებითი სერთიფიკატები. ვინაიდან ისინი არ იყო მოქმედი 15 წუთზე მეტი ხნის განმავლობაში, AWS SDK გადაწყვეტს მათ განახლებას შემდგომი მოთხოვნით. და ეს ხდებოდა ყოველი თხოვნით.

რატომ შემცირდა სერტიფიკატების მოქმედების ვადა?

AWS Instance Metadata შექმნილია EC2 ეგზემპლარებთან მუშაობისთვის და არა Kubernetes-თან. მეორეს მხრივ, ჩვენ არ გვინდოდა აპლიკაციის ინტერფეისის შეცვლა. ამისთვის გამოვიყენეთ კიამ - ინსტრუმენტი, რომელიც იყენებს აგენტებს Kubernetes-ის თითოეულ კვანძზე, საშუალებას აძლევს მომხმარებლებს (ინჟინრები, რომლებიც განათავსებენ აპლიკაციებს კლასტერში) დაავალონ IAM როლები კონტეინერებს პოდებში, თითქოს ისინი EC2 ინსტანციები იყვნენ. KIAM წყვეტს ზარებს AWS Instance მეტამონაცემების სერვისზე და ამუშავებს მათ მისი ქეშიდან, მანამდე რომ მიიღო ისინი AWS-დან. განაცხადის თვალსაზრისით, არაფერი იცვლება.

KIAM აწვდის მოკლევადიან სერთიფიკატებს პოდებს. ეს ლოგიკურია იმის გათვალისწინებით, რომ პოდის საშუალო სიცოცხლის ხანგრძლივობა უფრო მოკლეა, ვიდრე EC2 მაგალითზე. სერთიფიკატების მოქმედების ნაგულისხმევი პერიოდი იგივე 15 წუთის ტოლია.

შედეგად, თუ თქვენ გადააფარებთ ორივე ნაგულისხმევ მნიშვნელობას ერთმანეთზე, პრობლემა წარმოიქმნება. განაცხადისთვის მიწოდებულ თითოეულ სერტიფიკატს ვადა ეწურება 15 წუთის შემდეგ. თუმცა, AWS Java SDK აიძულებს განაახლოს ნებისმიერი სერტიფიკატი, რომელსაც ვადის გასვლის თარიღამდე დარჩა 15 წუთზე ნაკლები.

შედეგად, დროებითი სერტიფიკატი იძულებულია განახლდეს ყოველი მოთხოვნით, რაც იწვევს რამდენიმე ზარს AWS API-ზე და იწვევს შეყოვნების მნიშვნელოვან ზრდას. AWS Java SDK-ში აღმოვაჩინეთ ფუნქციის მოთხოვნა, რომელიც მსგავს პრობლემას აღნიშნავს.

გამოსავალი მარტივი აღმოჩნდა. ჩვენ უბრალოდ ხელახლა დავაკონფიგურირეთ KIAM, რომ მოითხოვოთ სერტიფიკატები უფრო გრძელი მოქმედების ვადით. როგორც კი ეს მოხდა, მოთხოვნები დაიწყო AWS მეტამონაცემების სერვისის მონაწილეობის გარეშე და შეყოვნება დაეცა კიდევ უფრო დაბალ დონემდე, ვიდრე EC2-ში.

დასკვნები

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

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

ჩვენს შემთხვევაში, მაღალი შეყოვნება არ იყო შეცდომების ან ცუდი გადაწყვეტილებების შედეგი Kubernetes-ში, KIAM-ში, AWS Java SDK-ში ან ჩვენს მიკროსერვისში. ეს იყო ორი დამოუკიდებელი ნაგულისხმევი პარამეტრის გაერთიანების შედეგი: ერთი KIAM-ში, მეორე AWS Java SDK-ში. ცალკე აღებული ორივე პარამეტრს აქვს აზრი: აქტიური სერტიფიკატის განახლების პოლიტიკა AWS Java SDK-ში და სერთიფიკატების ხანმოკლე მოქმედების პერიოდი KAIM-ში. მაგრამ როცა მათ აერთიანებთ, შედეგები არაპროგნოზირებადი ხდება. ორი დამოუკიდებელი და ლოგიკური გადაწყვეტა არ უნდა იყოს გონივრული კომბინაციისას.

PS მთარგმნელისგან

შეგიძლიათ მეტი შეიტყოთ KIAM კომუნალური პროგრამის არქიტექტურის შესახებ AWS IAM-ის Kubernetes-თან ინტეგრირებისთვის აქ ეს მუხლი მისი შემქმნელებისგან.

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «კუბერნეტესის წარუმატებლობის 3 ისტორია წარმოებაში: ანტი-აფინურობა, მოხდენილი გამორთვა, ვებჰუკი";
• «როგორ გამოიწვია პოდ პრიორიტეტებმა Kubernetes-ში Grafana Labs-ის შეფერხება";
• «6 გასართობი სისტემის შეცდომა Kubernetes-ის მუშაობაში [და მათი გადაწყვეტა]";
• «6 პრაქტიკული ამბავი ჩვენი SRE ყოველდღიური ცხოვრებიდან".

წყარო: www.habr.com