Kubernetes-ის რჩევები და ხრიკები: მოხდენილი გამორთვის მახასიათებლები NGINX-სა და PHP-FPM-ში

ტიპიური პირობა Kubernetes-ში CI/CD-ის დანერგვისას: აპლიკაციას უნდა შეეძლოს არ მიიღოს ახალი კლიენტის მოთხოვნები, სანამ მთლიანად შეწყვეტს და რაც მთავარია, წარმატებით დაასრულებს არსებულს.

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

თეორია. როგორ ცხოვრობს პოდი

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

ასევე უნდა გახსოვდეთ, რომ ნაგულისხმევი საშეღავათო პერიოდია 30 წამი: ამის შემდეგ, პოდი შეწყდება და განაცხადს უნდა ჰქონდეს დრო, რომ დამუშავდეს ყველა მოთხოვნა ამ ვადამდე. შენიშვნა: თუმცა ნებისმიერი მოთხოვნა, რომელსაც 5-10 წამზე მეტი სჭირდება, უკვე პრობლემურია და მოხდენილი გამორთვა მას აღარ უშველის...

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

A1, B1 - ცვლილებების მიღება კერის მდგომარეობის შესახებ
A2 - გამგზავრება SIGTERM
B2 - პოდის ამოღება ბოლო წერტილებიდან
B3 - ცვლილებების მიღება (ბოლო წერტილების სია შეიცვალა)
B4 - განაახლეთ iptables წესები

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

• კავშირის გაგზავნა: პასუხის სათაურების დახურვა (თუ ეს ეხება HTTP აპლიკაციას).
• თუ კოდში ცვლილებების შეტანა შეუძლებელია, მაშინ შემდეგი სტატია აღწერს გამოსავალს, რომელიც საშუალებას მოგცემთ დაამუშავოთ მოთხოვნები მოხდენილი პერიოდის დასრულებამდე.

თეორია. როგორ წყვეტენ NGINX და PHP-FPM პროცესებს

NGINX

დავიწყოთ NGINX-ით, ვინაიდან მასში ყველაფერი მეტ-ნაკლებად აშკარაა. თეორიაში ჩასვლით ვიგებთ, რომ NGINX-ს აქვს ერთი ძირითადი პროცესი და რამდენიმე „მუშაკი“ - ეს არის საბავშვო პროცესები, რომლებიც ამუშავებენ კლიენტის მოთხოვნებს. მოწოდებულია მოსახერხებელი ვარიანტი: ბრძანების გამოყენებით nginx -s <SIGNAL> პროცესების შეწყვეტა სწრაფი გამორთვის ან მოხდენილი გამორთვის რეჟიმში. ცხადია, ეს უკანასკნელი ვარიანტი გვაინტერესებს.

მაშინ ყველაფერი მარტივია: თქვენ უნდა დაამატოთ preStop-hook ბრძანება, რომელიც გამოსცემს მოხდენილი გამორთვის სიგნალს. ეს შეიძლება გაკეთდეს Deployment-ში, კონტეინერის ბლოკში:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

ახლა, როდესაც pod გამორთულია, ჩვენ ვნახავთ შემდეგს NGINX კონტეინერის ჟურნალებში:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

და ეს ნიშნავს იმას, რაც ჩვენ გვჭირდება: NGINX ელოდება მოთხოვნების დასრულებას და შემდეგ კლავს პროცესს. თუმცა, ქვემოთ განვიხილავთ ასევე გავრცელებულ პრობლემას, რომლის გამო, თუნდაც ბრძანებით nginx -s quit პროცესი არასწორად მთავრდება.

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

რა შუაშია PHP-FPM? როგორ უმკლავდება მოხდენილი გამორთვას? მოდი გავარკვიოთ.

PHP-FPM

PHP-FPM-ის შემთხვევაში ცოტა ნაკლები ინფორმაციაა. თუ თქვენ ყურადღებას გაამახვილებთ ოფიციალური სახელმძღვანელო PHP-FPM-ის მიხედვით, იტყვის, რომ მიღებულია შემდეგი POSIX სიგნალები:

1. SIGINT, SIGTERM - სწრაფი გამორთვა;
2. SIGQUIT - მოხდენილი გამორთვა (რაც გვჭირდება).

დარჩენილი სიგნალები არ არის საჭირო ამ ამოცანაში, ამიტომ ჩვენ გამოვტოვებთ მათ ანალიზს. პროცესის სწორად დასასრულებლად, თქვენ უნდა დაწეროთ შემდეგი preStop hook:

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

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

ივარჯიშე. შესაძლო პრობლემები მოხდენილი გამორთვით

NGINX

უპირველეს ყოვლისა, სასარგებლოა გახსოვდეთ: ბრძანების შესრულების გარდა nginx -s quit არის კიდევ ერთი ეტაპი, რომელზეც ღირს ყურადღების მიქცევა. ჩვენ შევხვდით პრობლემას, როდესაც NGINX მაინც აგზავნის SIGTERM-ს SIGQUIT სიგნალის ნაცვლად, რაც იწვევს მოთხოვნების სწორად დასრულებას. მსგავსი შემთხვევები შეიძლება მოიძებნოს, მაგალითად, აქ. სამწუხაროდ, ჩვენ ვერ დავადგინეთ ამ ქცევის კონკრეტული მიზეზი: არსებობდა ეჭვი NGINX ვერსიაზე, მაგრამ ეს არ დადასტურდა. სიმპტომი იყო ის, რომ შეტყობინებები დაფიქსირდა NGINX კონტეინერის ჟურნალებში: "ღია სოკეტი #10 დარჩა კავშირში 5", რის შემდეგაც პოდი გაჩერდა.

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

სტატუსის კოდების ინდიკატორები განლაგების დროს

ამ შემთხვევაში, ჩვენ ვიღებთ მხოლოდ 503 შეცდომის კოდს თავად Ingress-ისგან: მას არ შეუძლია წვდომა NGINX კონტეინერზე, რადგან ის აღარ არის ხელმისაწვდომი. თუ გადავხედავთ კონტეინერების ჟურნალებს NGINX-ით, ისინი შეიცავს შემდეგს:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

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

თუ მსგავს პრობლემას წააწყდებით, აზრი აქვს გაერკვნენ, თუ რა გაჩერების სიგნალია გამოყენებული კონტეინერში და ზუსტად როგორ გამოიყურება preStop hook. სავსებით შესაძლებელია, რომ მიზეზი სწორედ ამაში მდგომარეობს.

PHP-FPM... და სხვა

PHP-FPM-ის პრობლემა ტრივიალურად არის აღწერილი: ის არ ელოდება ბავშვის პროცესების დასრულებას, ის წყვეტს მათ, რის გამოც 502 შეცდომა ხდება განლაგების და სხვა ოპერაციების დროს. 2005 წლიდან არის bugs.php.net-ზე რამდენიმე შეტყობინებები (მაგ აქ и აქ), რომელიც აღწერს ამ პრობლემას. მაგრამ თქვენ სავარაუდოდ ვერაფერს ნახავთ ჟურნალებში: PHP-FPM გამოაცხადებს პროცესის დასრულებას შეცდომის ან მესამე მხარის შეტყობინებების გარეშე.

უნდა განვმარტოთ, რომ თავად პრობლემა შეიძლება იყოს დამოკიდებული უფრო მცირე ან მეტწილად თავად აპლიკაციაზე და არ გამოვლინდეს, მაგალითად, მონიტორინგში. თუ შეგხვდებათ, უპირველეს ყოვლისა გახსენდებათ მარტივი გამოსავალი: დაამატეთ preStop hook ერთად sleep(30). ეს საშუალებას მოგცემთ შეასრულოთ ყველა მოთხოვნა, რომელიც ადრე იყო (და ჩვენ არ ვიღებთ ახალს, რადგან pod უკვე უნარი შესწევს შეწყვეტა), და 30 წამის შემდეგ თავად ღვეზელი დასრულდება სიგნალით SIGTERM.

გამოდის, რომ lifecycle კონტეინერი ასე გამოიყურება:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

თუმცა 30 წამის გამო sleep ჩვენ მკაცრად ჩვენ გავზრდით განლაგების დროს, რადგან ყოველი პოდი შეწყდება მინიმალური 30 წამი, რაც ცუდია. რა შეიძლება გაკეთდეს ამის შესახებ?

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

ამ ცოდნით, დავუბრუნდეთ ჩვენს ბოლო პრობლემას. როგორც აღვნიშნეთ, Kubernetes არ არის მონოლითური პლატფორმა: მის სხვადასხვა კომპონენტებს შორის კომუნიკაციას გარკვეული დრო სჭირდება. ეს განსაკუთრებით ეხება, როდესაც განვიხილავთ Ingresses-ის და სხვა დაკავშირებული კომპონენტების მუშაობას, რადგან ასეთი შეფერხების გამო განლაგების დროს ადვილია მიიღოთ 500 შეცდომის მატება. მაგალითად, შეცდომა შეიძლება მოხდეს მოთხოვნის ზემო დინებაში გაგზავნის ეტაპზე, მაგრამ კომპონენტებს შორის ურთიერთქმედების „დროის შუალედი“ საკმაოდ მოკლეა - წამზე ნაკლები.

ამიტომ, Მთლიანობაში უკვე აღნიშნული დირექტივით process_control_timeout შეგიძლიათ გამოიყენოთ შემდეგი კონსტრუქცია lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

ამ შემთხვევაში დაგვიანებას ბრძანებით ავინაზღაურებთ sleep და დიდად არ გაზარდოთ განლაგების დრო: არის თუ არა შესამჩნევი განსხვავება 30 წამსა და ერთს შორის?.. სინამდვილეში, ეს არის process_control_timeoutხოლო lifecycle გამოიყენება მხოლოდ როგორც "უსაფრთხო ბადე" ჩამორჩენის შემთხვევაში.

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

ივარჯიშე. ჩატვირთეთ ტესტი, რათა შეამოწმოთ პოდის ფუნქციონირება

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

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

კიდევ ერთი ნიუანსია კონტეინერის მორების ნახვა მისი შეწყვეტის დროს. იქ არის დაფიქსირებული ინფორმაცია მოხდენილი გამორთვის შესახებ? არის თუ არა რაიმე შეცდომები ჟურნალებში სხვა რესურსებზე წვდომისას (მაგალითად, მეზობელ PHP-FPM კონტეინერში)? შეცდომები თავად აპლიკაციაში (როგორც ზემოთ აღწერილი NGINX-ის შემთხვევაში)? იმედი მაქვს, რომ ამ სტატიის შესავალი ინფორმაცია დაგეხმარებათ უკეთ გაიგოთ, რა ემართება კონტეინერს მისი შეწყვეტის დროს.

ასე რომ, პირველი სატესტო გაშვება ჩატარდა გარეშე lifecycle და დამატებითი დირექტივების გარეშე აპლიკაციის სერვერისთვის (process_control_timeout PHP-FPM-ში). ამ ტესტის მიზანი იყო შეცდომების სავარაუდო რაოდენობის დადგენა (და არის თუ არა). ასევე, დამატებითი ინფორმაციის მიხედვით, თქვენ უნდა იცოდეთ, რომ ყოველი პოდისთვის განლაგების საშუალო დრო იყო დაახლოებით 5-10 წამი, სანამ ის სრულად მზად იქნებოდა. შედეგები ასეთია:

Yandex.Tank საინფორმაციო პანელი აჩვენებს 502 შეცდომის მწვერვალს, რომელიც მოხდა განლაგების დროს და გაგრძელდა საშუალოდ 5 წამამდე. სავარაუდოდ, ეს იყო იმის გამო, რომ არსებული მოთხოვნები ძველ პოდზე წყდებოდა მისი შეწყვეტის დროს. ამის შემდეგ გაჩნდა 503 შეცდომა, რაც შეჩერებული NGINX კონტეინერის შედეგი იყო, რომელმაც ასევე გააუქმა კავშირები ბექენდის გამო (რაც ხელს უშლიდა Ingress-თან დაკავშირებას).

ვნახოთ როგორ process_control_timeout PHP-FPM-ში დაგვეხმარება დაველოდოთ ბავშვის პროცესების დასრულებას, ე.ი. შეასწორეთ ასეთი შეცდომები. ხელახლა განლაგება ამ დირექტივის გამოყენებით:

500-ე განლაგების დროს შეცდომები აღარ არის! განლაგება წარმატებულია, მოხდენილი გამორთვის სამუშაოები.

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

დასკვნა

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

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

თუმცა, ყველა აპლიკაციას არ შეუძლია ამ გზით მუშაობა. კუბერნეტის რეალობაში პრობლემის ერთ-ერთი გამოსავალია:

• წინასწარ გაჩერების კაკლის დამატება, რომელიც დაელოდება რამდენიმე წამს;
• ჩვენი backend-ის კონფიგურაციის ფაილის შესწავლა შესაბამისი პარამეტრებისთვის.

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

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

სტატიაზე გამოხმაურების საპასუხოდ: აღსანიშნავია, რომ პრობლემები და გადაწყვეტილებები აღწერილია აქ NGINX Ingress-თან მიმართებაში. სხვა შემთხვევებისთვის არის სხვა გადაწყვეტილებები, რომლებიც შეიძლება განვიხილოთ სერიის შემდეგ მასალებში.

PS

სხვა K8s რჩევებისა და ხრიკების სერიიდან:

• «მორგებული შეცდომის გვერდები NGINX Ingress-ში";
• «ვებ აპლიკაციაში კვანძების განაწილებისა და ჩატვირთვის შესახებ";
• «დეველოპერის საიტებზე წვდომა";
• «ჩატვირთვის დაჩქარება დიდი მონაცემთა ბაზებისთვის".

წყარო: www.habr.com