კუბერნეტი – ღრუბლის შერყევა

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

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

‘რეზისტენტული’ ნიშნავს, რომ თქვენი მომსახურება მოითმენს ინფრასტრუქტურაში ჩავარდნას. წარუმატებლობა შეიძლება იყოს სერვერის დისკის მაკონტროლებელი, რომელსაც აღარ შეუძლია წვდომა დისკებზე, რაც მონაცემებს მიუწვდომელია. ან მარცხი შეიძლება იყოს ქსელის შეცვლა, რომელიც აღარ აძლევს ორ ან მეტ სისტემას კომუნიკაციის საშუალებას. ამ კონტექსტში, ა “მარცხის ერთი წერტილი” ან SPOF არის მარცხი, რომელიც უარყოფითად მოქმედებს მომსახურების ხელმისაწვდომობაზე. მდგრადი ინფრასტრუქტურა არის ისეთი SPOF– ების გარეშე.

‘მასშტაბური’ აღწერს სისტემების უნარს, რომ მოხერხებულად გაუმკლავდეს მოთხოვნის spikes. ის ასევე კარნახობს, თუ რამდენად მარტივია ცვლილებები სისტემებში. მაგალითად, ახალი მომხმარებლის დამატება, შენახვისუნარიანობის გაზრდა ან ამაზონის ვებ – სერვისებიდან ინფრასტრუქტურის გადატანა Google Cloud– ზე – ან თუნდაც მისი შიდა გადატანა.

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

რომ გაიგოს რა’დღეს შესაძლებელია, ეს’სასარგებლოა თუ არა, თუ როგორ განიხილეს ტექნოლოგიური პროექტები ტრადიციულად. ძველ დღეებში – ანუ 10 წელზე მეტი ხნის წინ – ბიზნესი ყიდულობდა ან იჯარას აპარატს მათი პროგრამების ყველა კომპონენტის შესასრულებლად. შედარებით მარტივ პროგრამებსაც კი, მაგალითად WordPress ვებსაიტს, აქვს მრავალი კომპონენტი. WordPress- ის შემთხვევაში, საჭიროა MySQL მონაცემთა ბაზა, ვებ – სერვერთან ერთად, როგორიცაა Apache, და PHP კოდის მართვის გზა. Ასე რომ, ისინი’დ ააშენეთ სერვერი, დაამონტაჟეთ Apache, PHP და MySQL, დააინსტალირეთ WordPress და გამორთეთ ისინი’დ წადით.

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

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

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

აბსტრაქტული ღრუბლები

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

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

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

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

Slashdot ეფექტი

მასშტაბის პრობლემა ცოტა რთულია. დაე’თქვით, რომ თქვენი WordPress საიტი თვეში იღებს 1000 ვიზიტორს. ერთ დღეს, თქვენი საქმე ნახსენებია რადიო 4-ზე ან საუზმეზე. მოულოდნელად, თვეზე მეტ ხანს იღებთ’ვიზიტორების ღირს 20 წუთში. ჩვენ’ვებსაიტების ყველა მოსმენილი ამბავი ‘ავარიული’, და ეს’როგორც წესი, რატომ არის: მასშტაბურობის ნაკლებობა.

ორი სერვერი, რომლებმაც ხელი შეუწყო გამძლეობას, უფრო მაღალი დატვირთვის მართვა შეუძლია, ვიდრე მხოლოდ ერთ სერვერს შეეძლო, მაგრამ ეს’ისევ შეზღუდულია. შენ’დ იხდით ორი სერვერის გადახდა დროის 100 პროცენტს და უმეტეს დროს ორივე მშვენივრად მუშაობდა. ის’სავარაუდოდ, რომ მხოლოდ ერთს შეუძლია თქვენი საიტის გაშვება. შემდეგ ჯონ ჰამფრისი ახსენებს თქვენს საქმიანობას Today and you’დ დაჭირდება 10 სერვერი დატვირთვის შესასრულებლად – მაგრამ მხოლოდ რამდენიმე საათის განმავლობაში.

უკეთესი გამხსნელია როგორც გამძლეობის, ისე scalability პრობლემისათვის, cloud computing. დააყენეთ სერვერის მაგალითად ან ორი – პატარა სერვერები, რომლებიც თქვენს პროგრამებს მართავენ – ამაზონის ვებ სერვისებზე (AWS) ან Google Cloud– ზე, და თუ რომელიმე ინსტანცია რაიმე მიზეზის გამო ვერ მოხერხდა, ის ავტომატურად გადატვირთეთ. სწორად დააყენეთ ავტომატური მასშტაბები და როდესაც ბატონი ჰამფრისი იწვევს თქვენს ვებ სერვერზე ინსტაგრამის დატვირთვის დაჩქარებას, დამატებითი სერვერის ინსტაგრამები ავტომატურად იწყებენ სამუშაო დატვირთვის გაზიარებას. მოგვიანებით, როგორც ინტერესი იკლებს, ეს დამატებითი შემთხვევები შეჩერებულია და თქვენ იხდით მხოლოდ იმას, რასაც იყენებთ. სრულყოფილი… ან არის ეს?

მიუხედავად იმისა, რომ ღრუბლის გადაწყვეტა ბევრად უფრო მოქნილია, ვიდრე ტრადიციული დამოუკიდებელი სერვერი, ჯერ კიდევ არის პრობლემები. მიმდინარე ღრუბლოვანი შემთხვევების განახლება არ ხდება’t პირდაპირ. ღრუბლისთვის განვითარებას გამოწვევებიც აქვს: ლეპტოპი, რომელსაც იყენებენ თქვენი დეველოპერები, შეიძლება მსგავსი იყოს ღრუბლის მაგალითად, მაგრამ ეს’იგივე არ არის. თუ ვალდებულებას იღებთ AWS- ში, Google Cloud- ში გადასვლა რთული საქმეა. და, დავუშვათ, რაიმე მიზეზის გამო, შენ უბრალოდ დონ’გსურთ თქვენი კომპიუტერის გადაცემა Amazon- ზე, Google- ში ან Microsoft- ზე?

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

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

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

(გამოსახულების კრედიტი: მომავალი)

გახდი კუბერნე

Kubernetes (ku-ber-net-eez) წამყვანი კონტეინერის საორკესტრო იარაღია და იგი Google- დან გამოვიდა. თუ ვინმემ იცის თუ როგორ უნდა აწარმოოს უზარმაზარი მასშტაბის IT ინფრასტრუქტურა, Google აკეთებს ამას. Kubernetes- ის წარმოშობისაა Borg, Google- ის შიდა პროექტი’ისევ იყენებდნენ Google– ის უმეტესობას’პროგრამები, მათ შორის საძიებო სისტემის, Gmail, Google Maps და სხვათა ჩათვლით. ბორგი საიდუმლო იყო მანამ, სანამ გუგლიმ 2015 წელს გამოაქვეყნა სტატია ამის შესახებ, მაგრამ ამ სტატიამ ცხადი გახადა, რომ ბორგი იყო მთავარი ინსპირაცია კუბერნეტის უკან..

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

თავად კუბერნეტი დაიბადა Google- დან’საჩუქარი (‘Google’ინფრასტრუქტურა ყველასთვის’) ინიციატივა და შეიქმნა Borg- ის მეგობრული ვერსია, რომელიც შეიძლება სასარგებლო იყოს გუგლის მიღმა. იგი 2015 წელს გადაეცა ლინუქსის ფონდს, Cloud Native Computing Foundation (CNCF) ფორმირების გზით..

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

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

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

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

(გამოსახულების კრედიტი: მომავალი)

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

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

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

თითოეული კვანძი აწარმოებს Kubelet პროცესს, რომელიც კომუნიკაციას ახდენს API სერვერთან და მართავს კონტეინერებს – ზოგადად Docker- ის გამოყენებით – და Kube-Proxy, რომელიც ახდენს ქსელის პროქსიფიკაციას და დატვირთვის დაბალანსებას კლასტერში..

Etcd განაწილებული მონაცემთა ბაზის სისტემა თავის სახელს იღებს / ა.შ. საქაღალდე Linux სისტემებზე, რომელიც გამოიყენება სისტემის კონფიგურაციის ინფორმაციის შესანახად, დამატებით სუფიქსი ‘დ’, ხშირად იყენებდნენ დემონის პროცესის აღნიშვნას. Etcd– ის მიზნებია ძირითადი მნიშვნელობის მონაცემების შენახვა განაწილებული, თანმიმდევრული და შეცდომებისადმი ტოლერანტული გზით.

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

ეს ყველაფერი ერთად

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

პირველი ამოცანაა MySQL– ის პაროლის განსაზღვრა:

kubectl შექმნა საიდუმლო ზოგადი mysql- პასი –from-literal = პაროლი = YOUR_PASSWORD

kubectl ისაუბრებს API სერვერზე, რომელიც შეამოწმებს ბრძანებას და შემდეგ შეინახავს პაროლს და ა.შ. ჩვენი სერვისები განსაზღვრულია YAML ფაილებში და ახლა ჩვენ გვჭირდება გარკვეული მუდმივი შენახვა MySQL მონაცემთა ბაზაში.

apiVersion: v1kind: PersistentVolumeClaimmetadata: name: mysql-pv-pretendlabels: app: wordpress Spec: accessModes: – ReadWriteOnceresource: მოთხოვნები: შენახვა: 20Gi

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

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

ახლა ჩვენ სხვა კონტეინერი გვჭირდება WordPress- ის გასაშვებად. კონტეინერის განლაგების სპეციფიკაციის ნაწილია:

სახის: განლაგება მეტამონაცემები: სახელი: wordpresslabels: app: wordpress Spec: სტრატეგია: ტიპი: ხელახლა

სტრატეგიის ტიპი “ხელახლა” ეს ნიშნავს, რომ თუ რომელიმე კოდი, რომელიც მოიცავს განაცხადს, შეიცვლება, მაშინ მიმდინარე ინსტანციები წაიშლება და განახლდება. სხვა ვარიანტებში შედის ახალი ინსტალაციების ციკლირება და არსებული ინსტანციების ამოღება, სათითაოდ, საშუალებას აძლევს სამსახურის გაგრძელებას განაახლოს განახლების განლაგების დროს. დაბოლოს, ჩვენ ვაცხადებთ მომსახურებას თავად WordPress- ისთვის, რომელიც მოიცავს PHP კოდს და Apache- ს. YAML ფაილის ნაწილი, რომელიც აცხადებს ამას:

მეტამონაცემები: სახელი: wordpresslabels: app: wordpress Spec: პორტები: – პორტი: 80selector: app: wordpresstier: frontendtype: LoadBalancer

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

გამოიყენეთ გამგეობის ხედი, რომ მიიღოთ Kubernetes- ის ერთი შეხედვით მოკლე შინაარსი

(გამოსახულების საკრედიტო: Ditching)

ეს აუცილებელი იყო მხოლოდ კუბერნეზის მაღალი დონის მიმოხილვა და სისტემის მრავალი დეტალი და მახასიათებელი არ იქნა გამოტოვებული. ჩვენ’დაათვალიერეს ავტოკასტინგი (როგორც ბოძები, ასევე კვანძები, რომლებიც ქმნიან მტევანს), დატვირთვის სამუშაოებს (კონტეინერების დაწყებას გრაფიკის მიხედვით), Ingress (HTTP დატვირთვის დაბალანსება, გადაწერა და SSL გადატვირთვისას), RBAC (როლზე დაფუძნებული წვდომის კონტროლი), ქსელი პოლიტიკა (firewalling) და მრავალი სხვა. კუბერნეტი არის ძალზე მოქნილი და ძალზე ძლიერი: ნებისმიერი ახალი IT ინფრასტრუქტურისთვის, ის სერიოზული კონკურენტი უნდა იყოს.

რესურსები

Თუ შენ’აქ არ გაეცანით Docker– ს დაწყებას: https://docs.docker.com/get-started.

იქ’ინტერაქტიული, სამეურვეო პროგრამა პროგრამის განლაგების და მასშტაბის შესახებ: https://kubernetes.io/docs/tutorials/kubernetes-basics.

და იხილეთ https://kubernetes.io/docs/setup/scratch, თუ როგორ უნდა შექმნათ კლასტერი.

შეგიძლიათ უფასო Kubernetes- ის კლასტერთან თამაში შეგიძლიათ https://tryk8s.com.

დაბოლოს, შეგიძლიათ დაათვალიეროთ გრძელი, ტექნიკური ფურცელი, Google- ის შესანიშნავი მიმოხილვით’Borg– ის გამოყენებამ და რა გავლენა მოახდინა Kubernetes– ის დიზაინზე აქ: https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43438.pdf.

შეიტყვეთ მეტი Tiger Computing- ის შესახებ.

• 2019 წლის საუკეთესო ღრუბლოვანი შენახვა ინტერნეტით: უფასო, ფასიანი და ბიზნესის პარამეტრები