Kubernetes-ის საუკეთესო პრაქტიკა. პატარა კონტეინერების შექმნა

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

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

გარდა ამისა, Docker-ის სურათების უმეტესობა იყენებს Debian-ს ან Ubuntu-ს საბაზისო სურათისთვის, და მიუხედავად იმისა, რომ ეს უზრუნველყოფს შესანიშნავ თავსებადობას და მარტივ პერსონალიზაციას (Docker ფაილი იღებს მხოლოდ ორ ხაზს კოდს), საბაზისო სურათებს შეუძლიათ ასობით მეგაბაიტი დამატებითი დატვირთვის დამატება თქვენს კონტეინერში. მაგალითად, მარტივი node.js ფაილი Go "hello-world" აპლიკაციისთვის არის დაახლოებით 700 მეგაბაიტი, მაშინ როცა თქვენი რეალური აპლიკაცია მხოლოდ რამდენიმე მეგაბაიტია.

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

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

Docker-ში ნაგულისხმევად, node:8 საბაზისო სურათის ზომაა 670 მბ, ხოლო კვანძი: 8-ალპური გამოსახულების ზომა არის მხოლოდ 65 მბ, ანუ 10-ჯერ ნაკლები. ალპური ბაზის პატარა სურათის გამოყენებით, თქვენ მნიშვნელოვნად შეამცირებთ კონტეინერის ზომას. Alpine არის პატარა და მსუბუქი Linux დისტრიბუცია, რომელიც ძალიან პოპულარულია Docker-ის მომხმარებლებში, რადგან ის თავსებადია მრავალ აპლიკაციასთან, ხოლო კონტეინერები მცირეა. სტანდარტული Docker "node" სურათისგან განსხვავებით, "node:alpine" აშორებს უამრავ სერვისულ ფაილს და პროგრამას, ტოვებს მხოლოდ მათ, რაც საკმარისია თქვენი აპლიკაციის გასაშვებად.

უფრო პატარა საბაზისო სურათზე გადასასვლელად, უბრალოდ განაახლეთ Dockerfile, რომ დაიწყოთ მუშაობა ახალ საბაზისო სურათთან:

ახლა, ძველი onbuild სურათისგან განსხვავებით, თქვენ უნდა დააკოპიროთ თქვენი კოდი კონტეინერში და დააინსტალიროთ ნებისმიერი დამოკიდებულება. ახალ Dockerfile-ში კონტეინერი იწყება node:alpine სურათით, შემდეგ ქმნის დირექტორიას კოდისთვის, აინსტალირებს დამოკიდებულებებს NPM პაკეტის მენეჯერის გამოყენებით და ბოლოს აწარმოებს server.js.

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

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

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

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

თქვენ შეიძლება შეამჩნიოთ რაღაც უცნაური ამ Docker ფაილში: ის შეიცავს ორ FROM ხაზს. პირველი 4 სტრიქონიანი განყოფილება ზუსტად ისე გამოიყურება, როგორც წინა Dockerfile, გარდა იმისა, რომ ის იყენებს AS საკვანძო სიტყვას ამ ეტაპის დასასახელებლად. შემდეგ განყოფილებას აქვს ახალი FROM ხაზი ახალი სურათის დასაწყებად, სადაც golang:alpine გამოსახულების ნაცვლად გამოვიყენებთ Raw alpine-ს, როგორც საბაზისო სურათს.

Raw Alpine Linux-ს არ აქვს დაინსტალირებული SSL სერთიფიკატები, რაც გამოიწვევს HTTPS-ზე API ზარების უმეტესობის წარუმატებლობას, ამიტომ მოდით დავაინსტალიროთ რამდენიმე root CA სერთიფიკატი.

ახლა მოდის სახალისო ნაწილი: შედგენილი კოდის კოპირება პირველი კონტეინერიდან მეორეში, შეგიძლიათ უბრალოდ გამოიყენოთ COPY ბრძანება, რომელიც მდებარეობს მეორე განყოფილების მე-5 ხაზზე. ის დააკოპირებს მხოლოდ ერთ აპლიკაციის ფაილს და არ იმოქმედებს Go utility ინსტრუმენტებზე. ახალი მრავალსაფეხურიანი Docker ფაილი შეიცავს კონტეინერის სურათს, რომლის ზომაა მხოლოდ 12 მეგაბაიტი, ორიგინალური კონტეინერის სურათთან შედარებით, რომელიც იყო 700 მეგაბაიტი, რაც დიდი განსხვავებაა!
ასე რომ, მცირე საბაზისო სურათების და Builder Pattern-ის გამოყენება შესანიშნავი გზაა ბევრად უფრო პატარა კონტეინერების შესაქმნელად ბევრი სამუშაოს გარეშე.
შესაძლებელია, რომ აპლიკაციის დასტადან გამომდინარე, არსებობს გამოსახულების და კონტეინერის ზომის შემცირების დამატებითი გზები, მაგრამ აქვთ თუ არა პატარა კონტეინერებს ნამდვილად გაზომვადი სარგებელი? მოდით შევხედოთ ორ სფეროს, სადაც პატარა კონტეინერები ძალიან ეფექტურია - შესრულება და უსაფრთხოება.

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

Docker ქეშირებს ფენებს, ასე რომ შემდგომი კონსტრუქციები იქნება ძალიან სწრაფი. თუმცა, ბევრი CI სისტემა, რომელიც გამოიყენება კონტეინერების ასაგებად და შესამოწმებლად, არ ინახავს ფენების ქეშირებას, ამიტომ არის მნიშვნელოვანი დროის დაზოგვა. როგორც ხედავთ, დიდი კონტეინერის აშენების დრო, თქვენი აპარატის სიმძლავრედან გამომდინარე, არის 34-დან 54 წამამდე, ხოლო კონტეინერის გამოყენებისას მცირდება Builder Pattern-ის გამოყენებით - 23-დან 28 წამამდე. ამ ტიპის ოპერაციებისთვის პროდუქტიულობის ზრდა იქნება 40-50%. ასე რომ, უბრალოდ დაფიქრდით, რამდენჯერ შექმნით და შეამოწმებთ თქვენს კოდს.

კონტეინერის აშენების შემდეგ, თქვენ უნდა შეიყვანოთ მისი სურათი (push კონტეინერის სურათი) კონტეინერის რეესტრში, რათა შემდეგ შეძლოთ მისი გამოყენება თქვენს Kubernetes კლასტერში. გირჩევთ გამოიყენოთ Google Container Registry.

Google Container Registry-ით (GCR) იხდით მხოლოდ ნედლეული შენახვისა და ქსელის საფასურს და არ არის კონტეინერის მართვის დამატებითი გადასახადი. ეს არის პირადი, უსაფრთხო და ძალიან სწრაფი. GCR იყენებს ბევრ ხრიკს, რათა დააჩქაროს გაყვანის ოპერაცია. როგორც ხედავთ, Go:onbuild-ის გამოყენებით Docker Container Image კონტეინერის ჩასმა დასჭირდება 15-დან 48 წამამდე, რაც დამოკიდებულია კომპიუტერის მუშაობაზე, ხოლო იგივე ოპერაცია უფრო პატარა კონტეინერთან ერთად დასჭირდება 14-დან 16 წამამდე, ხოლო ნაკლებად პროდუქტიული მანქანებისთვის. უპირატესობა მუშაობის სიჩქარეში იზრდება 3-ჯერ. უფრო დიდი მანქანებისთვის, დრო დაახლოებით იგივეა, რადგან GCR იყენებს გლობალურ ქეშს სურათების საერთო მონაცემთა ბაზისთვის, რაც იმას ნიშნავს, რომ თქვენ საერთოდ არ გჭირდებათ მათი ჩატვირთვა. დაბალი სიმძლავრის კომპიუტერში CPU არის ბოსტნეული, ამიტომ მცირე კონტეინერების გამოყენების უპირატესობა აქ ბევრად მეტია.

თუ იყენებთ GCR-ს, გირჩევთ გამოიყენოთ Google Container Builder (GCB), როგორც თქვენი build სისტემის ნაწილი.

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

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

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

შეხედეთ ამ შედარებას: პატარა კონტეინერებზე გაყვანის ოპერაციას 4-9-ჯერ ნაკლები დრო სჭირდება, რაც დამოკიდებულია მანქანის სიმძლავრეზე, ვიდრე იგივე ოპერაცია go:onbuild-ის გამოყენებით. საზიარო, პატარა კონტეინერების საბაზისო სურათების გამოყენება მნიშვნელოვნად აჩქარებს დროსა და სიჩქარეს, რომლითაც შესაძლებელია ახალი Kubernetes კვანძების განლაგება და ონლაინ გამოსვლა.

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

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

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

Kubernetes-ის საუკეთესო პრაქტიკა. Kubernetes-ის ორგანიზაცია სახელთა სივრცით

რამდენიმე რეკლამა 🙂

გმადლობთ, რომ დარჩით ჩვენთან. მოგწონთ ჩვენი სტატიები? გსურთ ნახოთ უფრო საინტერესო შინაარსი? მხარი დაგვიჭირეთ შეკვეთის განთავსებით ან მეგობრებისთვის რეკომენდაციით, ღრუბელი VPS დეველოპერებისთვის 4.99 დოლარიდან, საწყისი დონის სერვერების უნიკალური ანალოგი, რომელიც ჩვენ მიერ გამოგონილია თქვენთვის: მთელი სიმართლე VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps 19$-დან ან როგორ გავაზიარო სერვერი? (ხელმისაწვდომია RAID1 და RAID10-ით, 24 ბირთვამდე და 40 გბ-მდე DDR4).

Dell R730xd 2-ჯერ იაფია Equinix Tier IV მონაცემთა ცენტრში ამსტერდამში? Მხოლოდ აქ 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 ტელევიზორი $199-დან ნიდერლანდებში! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99-დან! Წაიკითხო რაღაცის შესახებ როგორ ავაშენოთ ინფრასტრუქტურის კორპუსი. კლასი Dell R730xd E5-2650 v4 სერვერების გამოყენებით 9000 ევროს ღირებულების პენი?

წყარო: www.habr.com