🥇7 საუკეთესო პრაქტიკა კონტეინერების მუშაობისთვის Google-ის მიხედვით

Შენიშვნა. თარგმნა: ორიგინალური სტატიის ავტორია თეო ჩამლი, Google Cloud Solutions Architect. Google Cloud ბლოგის ამ პოსტში ის გთავაზობთ მისი კომპანიის უფრო დეტალური სახელმძღვანელოს შეჯამებას, სახელწოდებით "კონტეინერების ექსპლუატაციის საუკეთესო პრაქტიკა" მასში Google-ის ექსპერტებმა შეაგროვეს კონტეინერების მუშაობის საუკეთესო პრაქტიკა Google Kubernetes Engine-ის გამოყენების კონტექსტში და სხვა, შეეხოთ თემების ფართო სპექტრს: უსაფრთხოებიდან მონიტორინგამდე და ლოგირებამდე. რა არის კონტეინერის ყველაზე მნიშვნელოვანი პრაქტიკა Google-ის მიხედვით?

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

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

1. გამოიყენეთ კონტეინერების ჭრის მექანიზმები

თუ აპლიკაცია მუშაობს Kubernetes კლასტერზე, ბევრი არ არის საჭირო ჟურნალებისთვის. ცენტრალიზებული შესვლის სისტემა, სავარაუდოდ, უკვე ჩაშენებულია კლასტერში, რომელსაც იყენებთ. Kubernetes Engine-ის გამოყენების შემთხვევაში, ეს პასუხისმგებელია Stackdriver Logging. (Შენიშვნა. თარგმნა: და თუ იყენებთ საკუთარ Kubernetes-ის ინსტალაციას, გირჩევთ უფრო ახლოს გაეცნოთ ჩვენს ღია კოდის გადაწყვეტას - ხის სახლი.) შეინახეთ თქვენი ცხოვრება მარტივი და გამოიყენეთ კონტეინერების ჭრის მექანიზმები. ჩაწერეთ ჟურნალები stdout-ში და stderr-ში - ისინი ავტომატურად მიიღება, შეინახება და ინდექსირებული იქნება.

თუ სასურველია, ასევე შეგიძლიათ დაწეროთ ჟურნალები JSON ფორმატი. ეს მიდგომა გაადვილებს მათში მეტამონაცემების დამატებას. და მათთან ერთად, Stackdriver Logging-ს ექნება შესაძლებლობა მოძებნოს ჟურნალებში ამ მეტამონაცემების გამოყენებით.

2. დარწმუნდით, რომ კონტეინერები არის მოქალაქეობის არმქონე და უცვლელი

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

მოქალაქეობის არმქონე ნიშნავს, რომ ნებისმიერი მდგომარეობა (ნებისმიერი სახის მუდმივი მონაცემები) ინახება კონტეინერის გარეთ. ამისათვის, საჭიროებიდან გამომდინარე, შეიძლება გამოყენებულ იქნას სხვადასხვა ტიპის გარე მეხსიერება: Cloud Storage, მუდმივი დისკები, Redis, ღრუბლოვანი SQL ან სხვა მართული მონაცემთა ბაზები. (Შენიშვნა. თარგმნა: დაწვრილებით ამის შესახებ ჩვენს სტატიაში ”ოპერატორები Kubernetes-ისთვის: როგორ გავუშვათ სახელმწიფო აპლიკაციები".)

უცვლელი ნიშნავს, რომ კონტეინერი არ შეიცვლება მისი სიცოცხლის განმავლობაში: არ არის განახლებები, პატჩები, კონფიგურაციის ცვლილებები. თუ გჭირდებათ თქვენი აპლიკაციის კოდის განახლება ან პატჩის გამოყენება, შექმენით ახალი სურათი და განათავსეთ იგი. რეკომენდებულია კონტეინერის კონფიგურაციის (მოსმენის პორტი, გაშვების გარემოს პარამეტრები და ა.შ.) გარედან გადატანა - Secrets и ConfigMaps. მათი განახლება შესაძლებელია კონტეინერის ახალი სურათის შექმნის გარეშე. გამოსახულების შეკრებით მილსადენების ადვილად შესაქმნელად, შეგიძლიათ გამოიყენოთ Cloud Build. (Შენიშვნა. თარგმნა: ჩვენ ვიყენებთ ღია კოდის ინსტრუმენტს ამ მიზნებისათვის დაპ.)

განლაგების კონფიგურაციის განახლების მაგალითი Kubernetes-ში კონფიგურაციის სახით ჩამონტაჟებული კონფიგურაციის კონფიგურაციის გამოყენებით

3. მოერიდეთ პრივილეგირებულ კონტეინერებს

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

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

4. მოერიდეთ გაშვებას როგორც root

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

ამის თავიდან აცილების საუკეთესო გზაა თავიდანვე არ გაუშვათ არაფერი როგორც root. ამისათვის შეგიძლიათ გამოიყენოთ დირექტივა USER в Dockerfile ან runAsUser კუბერნეტეში. კლასტერის ადმინისტრატორს ასევე შეუძლია აღსრულების ქცევის კონფიგურაცია გამოყენებით პოდის უსაფრთხოების პოლიტიკა.

5. გააადვილეთ აპლიკაციის მონიტორინგი

ჟურნალის მსგავსად, მონიტორინგი აპლიკაციის მართვის განუყოფელი ნაწილია. პოპულარული მონიტორინგის გადაწყვეტა Kubernetes საზოგადოებაში არის პრომეთე - სისტემა, რომელიც ავტომატურად ამოიცნობს პოდებსა და სერვისებს, რომლებიც საჭიროებენ მონიტორინგს. (Შენიშვნა. თარგმნა: აგრეთვე ჩვენი დეტალური ანგარიში პრომეთეს და კუბერნეტესის გამოყენებით მონიტორინგის თემაზე.) სტეკდრაივერი შეუძლია Kubernetes კლასტერების მონიტორინგი და მოიცავს Prometheus-ის საკუთარ ვერსიას აპლიკაციის მონიტორინგისთვის.

Kubernetes Dashboard Stackdriver-ზე

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

6. ხელმისაწვდომი გახადეთ აპლიკაციის ჯანმრთელობის მდგომარეობა

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

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

ამის შესახებ მეტი შეგიძლიათ წაიკითხოთ სტატიაში Sandeep Dinesh-ისგან, Developer Advocate Google-ისგან: “Kubernetes-ის საუკეთესო პრაქტიკა: ჯანმრთელობის შემოწმებების დაყენება მზადყოფნისა და სიცოცხლისუნარიანობის გამოკვლევებით".

7. აირჩიეთ თქვენი სურათის ვერსია ყურადღებით

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

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