DEVOXX დიდი ბრიტანეთის კონფერენცია. აირჩიეთ ჩარჩო: Docker Swarm, Kubernetes ან Mesos. ნაწილი 3

Docker Swarm, Kubernetes და Mesos არის ყველაზე პოპულარული კონტეინერის ორკესტრირების ჩარჩოები. თავის მოხსენებაში არუნ გუპტა ადარებს Docker-ის, Swarm-ისა და Kubernetes-ის შემდეგ ასპექტებს:

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

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

არუნ გუპტა არის Amazon Web Services-ის ღია კოდის პროდუქტების მთავარი ტექნოლოგი, რომელიც ავითარებს Sun, Oracle, Red Hat და Couchbase დეველოპერთა საზოგადოებებს 10 წელზე მეტი ხნის განმავლობაში. აქვს წამყვან ჯვარედინი ფუნქციურ გუნდებში მუშაობის დიდი გამოცდილება მარკეტინგული კამპანიებისა და პროგრამების სტრატეგიის შემუშავებისა და განხორციელების მიზნით. ის ხელმძღვანელობდა Sun ინჟინრების გუნდებს, არის Java EE გუნდის ერთ-ერთი დამფუძნებელი და Devoxx4Kids-ის აშშ ფილიალის შემქმნელი. არუნ გუპტა არის 2 ათასზე მეტი პოსტის ავტორი IT ბლოგებში და მოხსენებები აქვს 40-ზე მეტ ქვეყანაში.

DEVOXX დიდი ბრიტანეთის კონფერენცია. აირჩიეთ ჩარჩო: Docker Swarm, Kubernetes ან Mesos. ნაწილი 1
DEVOXX დიდი ბრიტანეთის კონფერენცია. აირჩიეთ ჩარჩო: Docker Swarm, Kubernetes ან Mesos. ნაწილი 2

ხაზი 55 შეიცავს COUCHBASE_URI-ს, რომელიც მიუთითებს მონაცემთა ბაზის ამ სერვისზე, რომელიც ასევე შეიქმნა Kubernetes-ის კონფიგურაციის ფაილის გამოყენებით. თუ დააკვირდებით მე-2 ხაზს, ხედავთ: სერვისი არის სერვისი, რომელსაც მე ვქმნი, სახელწოდებით couchbase-service, და იგივე სახელია ჩამოთვლილი მე-4 ხაზზე. ქვემოთ მოცემულია რამდენიმე პორტი.

საკვანძო ხაზები არის 6 და 7. სერვისში მე ვამბობ: „ჰეი, ეს არის ეტიკეტები, რომლებსაც ვეძებ!“ და ეს ეტიკეტები სხვა არაფერია, თუ არა ცვლადი წყვილის სახელები და ხაზი 7 მიუთითებს ჩემს couchbase-rs-pod-ზე. განაცხადი. ქვემოთ მოცემულია პორტები, რომლებიც უზრუნველყოფენ წვდომას იმავე ეტიკეტებზე.

მე-19 სტრიქონზე მე ვქმნი ახალი ტიპის ReplicaSet, სტრიქონი 31 შეიცავს სურათის სახელს და 24-27 სტრიქონები მიუთითებს მეტამონაცემებზე, რომლებიც დაკავშირებულია ჩემს პოდთან. ეს არის ზუსტად ის, რასაც სერვისი ეძებს და რასთან უნდა მოხდეს კავშირი. ფაილის ბოლოს არის გარკვეული კავშირი 55-56 და 4 სტრიქონებს შორის, სადაც ნათქვამია: "გამოიყენე ეს სერვისი!"

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

შედეგად, მე მაქვს WildFly pod, რომელიც აკავშირებს მონაცემთა ბაზას Couchbase სერვისის საშუალებით. მე შემიძლია გამოვიყენო ფრონტენტი რამდენიმე WildFly pods-ით, რომელიც ასევე აკავშირებს couchbase-ის საყრდენს couchbase სერვისის მეშვეობით.

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

ასე რომ, მოქალაქეობის არმქონე კონტეინერები შესანიშნავია, მაგრამ რამდენად კარგია სახელმწიფო კონტეინერების გამოყენება? მოდით შევხედოთ სისტემის პარამეტრებს სტაჟიანი ან მუდმივი კონტეინერებისთვის. Docker-ში არსებობს 4 განსხვავებული მიდგომა მონაცემთა შენახვის განლაგების მიმართ, რომელსაც ყურადღება უნდა მიაქციოთ. პირველი არის Implicit Per-Container, რაც ნიშნავს, რომ couchbase, MySQL ან MyDB satateful კონტეინერების გამოყენებისას ისინი ყველა იწყება ნაგულისხმევი Sandbox-ით. ანუ ყველაფერი, რაც ინახება მონაცემთა ბაზაში, ინახება თავად კონტეინერში. თუ კონტეინერი ქრება, მონაცემებიც ქრება მასთან ერთად.

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

თითოეული ეს მეთოდი იყენებს სპეციფიკურ შენახვის ადგილს. Implicit და Explicit Per-Container ინახავს მონაცემებს ჰოსტზე /var/lib/docker/volumes-ზე. Per-Host მეთოდის გამოყენებისას, საცავი დამონტაჟებულია კონტეინერის შიგნით, ხოლო თავად კონტეინერი დამონტაჟებულია ჰოსტზე. მულტიჰოსტებისთვის შეიძლება გამოყენებულ იქნას ისეთი გადაწყვეტილებები, როგორიცაა Ceph, ClusterFS, NFS და ა.შ.

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

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

ეს უნდა იყოს გათვალისწინებული სახელმწიფო კონტეინერების შექმნისას. კიდევ ერთი სასარგებლო Docker ინსტრუმენტი არის მოცულობის მოდული, რომელიც მუშაობს პრინციპით "ბატარეები იმყოფება, მაგრამ უნდა შეიცვალოს". როდესაც Docker კონტეინერს იწყებთ, ის ამბობს: "ჰეი, როგორც კი დაიწყებთ კონტეინერს მონაცემთა ბაზით, შეგიძლიათ შეინახოთ თქვენი მონაცემები ამ კონტეინერში!" ეს არის ნაგულისხმევი ფუნქცია, მაგრამ თქვენ შეგიძლიათ შეცვალოთ იგი. ეს მოდული საშუალებას გაძლევთ გამოიყენოთ ქსელის დისკი ან მსგავსი რამ კონტეინერის მონაცემთა ბაზის ნაცვლად. იგი მოიცავს ნაგულისხმევ დრაივერს ჰოსტზე დაფუძნებული შენახვისთვის და საშუალებას აძლევს კონტეინერის ინტეგრაციას გარე შენახვის სისტემებთან, როგორიცაა Amazon EBS, Azure Storage და GCE Persistent დისკები.

შემდეგი სლაიდი აჩვენებს Docker Volume მოდულის არქიტექტურას.

ლურჯი ფერი წარმოადგენს Docker კლიენტს, რომელიც ასოცირდება ლურჯ Docker ჰოსტთან, რომელსაც აქვს ადგილობრივი შენახვის ძრავა, რომელიც გაძლევთ კონტეინერებს მონაცემების შესანახად. მწვანე მიუთითებს Plugin Client და Plugin Daemon, რომლებიც ასევე დაკავშირებულია ჰოსტთან. ისინი საშუალებას გაძლევთ შეინახოთ მონაცემები ქსელურ საცავში იმ ტიპის Storage Backend, რომელიც გჭირდებათ.

Docker Volume მოდული შეიძლება გამოყენებულ იქნას Portworx საცავთან ერთად. PX-Dev მოდული რეალურად არის კონტეინერი, რომელსაც თქვენ მართავთ, რომელიც უკავშირდება თქვენს Docker ჰოსტს და საშუალებას გაძლევთ მარტივად შეინახოთ მონაცემები Amazon EBS-ზე.

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

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

პირველი არის ის, რომ ვინმე ქსელის მხარეს, ჩვეულებრივ ადმინისტრატორი, გაძლევთ მუდმივ საცავს. ამისათვის არის შესაბამისი PersistentVolume კონფიგურაციის ფაილი. შემდეგი, აპლიკაციის დეველოპერი წერს კონფიგურაციის ფაილს სახელად PersistentVolumeClaim, ან PVC შენახვის მოთხოვნას, რომელშიც ნათქვამია: „მე მაქვს 50 GB განაწილებული საცავი, მაგრამ იმისათვის, რომ სხვა ადამიანებმაც გამოიყენონ მისი სიმძლავრე, მე ვეუბნები ამ PVC-ს, რომ მე ამჟამად საჭიროა მხოლოდ 10 GB". დაბოლოს, მესამე ნაბიჯი არის ის, რომ თქვენი მოთხოვნა დამონტაჟდება როგორც საცავი და აპლიკაცია, რომელსაც აქვს pod, ან replica set, ან მსგავსი რამ, იწყებს მის გამოყენებას. მნიშვნელოვანია გვახსოვდეს, რომ ეს პროცესი შედგება აღნიშნული 3 საფეხურისგან და მასშტაბირებადია.

შემდეგი სლაიდი აჩვენებს AWS არქიტექტურის Kubernetes Persistence Container-ს.

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

ისევე, როგორც Docker-თან ერთად, შეგიძლიათ გამოიყენოთ მუდმივი Kubernetes კონტეინერები Portworx-ით.

ეს არის ის, რასაც Kubernetes 1.6-ის ამჟამინდელ ტერმინოლოგიაში ეწოდება "StatefulSet" - Stateful აპლიკაციებთან მუშაობის გზა, რომელიც ამუშავებს მოვლენებს Pod-ის გაჩერებისა და Graceful Shutdown-ის შესრულების შესახებ. ჩვენს შემთხვევაში, ასეთი აპლიკაციები არის მონაცემთა ბაზები. ჩემს ბლოგზე შეგიძლიათ წაიკითხოთ, თუ როგორ უნდა შექმნათ StatefulSet Kubernetes-ში Portworx-ის გამოყენებით.
მოდით ვისაუბროთ განვითარების ასპექტზე. როგორც ვთქვი, Docker-ს აქვს 2 ვერსია - CE და EE, პირველ შემთხვევაში საუბარია Community Edition-ის სტაბილურ ვერსიაზე, რომელიც ახლდება 3 თვეში ერთხელ, განსხვავებით EE-ის ყოველთვიური განახლებული ვერსიისგან. შეგიძლიათ ჩამოტვირთოთ Docker Mac-ისთვის, Linux-ისთვის ან Windows-ისთვის. ინსტალაციის შემდეგ, Docker ავტომატურად განახლდება და მისი დაწყება ძალიან მარტივია.

Kubernetes-ისთვის მე მირჩევნია Minikube ვერსია - ეს კარგი გზაა პლატფორმის დასაწყებად ერთ კვანძზე კლასტერის შექმნით. რამდენიმე კვანძის კლასტერების შესაქმნელად, ვერსიების არჩევანი უფრო ფართოა: ეს არის kops, kube-aws (CoreOS+AWS), kube-up (მოძველებული). თუ გსურთ გამოიყენოთ AWS-ზე დაფუძნებული Kubernetes, გირჩევთ შეუერთდეთ AWS SIG-ს, რომელიც იკრიბება ონლაინ ყოველ პარასკევს და აქვეყნებს მრავალფეროვან საინტერესო მასალებს AWS Kubernetes-თან მუშაობის შესახებ.

მოდით შევხედოთ როგორ ხდება Rolling Update ამ პლატფორმებზე. თუ არსებობს რამდენიმე კვანძის კლასტერი, მაშინ ის იყენებს გამოსახულების კონკრეტულ ვერსიას, მაგალითად, WildFly:1. მოძრავი განახლება ნიშნავს, რომ გამოსახულების ვერსია თანმიმდევრულად იცვლება ახლით თითოეულ კვანძზე, ერთმანეთის მიყოლებით.

ამისთვის ვიყენებ დოკერ სერვისის განახლებას (სერვისის სახელს) ბრძანებას, რომელშიც ვაზუსტებ WildFly:2 სურათის ახალ ვერსიას და განახლების მეთოდს განახლება-პარალელიზმი 2. ნომერი 2 ნიშნავს, რომ სისტემა განაახლებს აპლიკაციის 2 სურათს. ამავდროულად, შემდეგ განახლების 10 წამის დაგვიანებით 10s, რის შემდეგაც მომდევნო 2 სურათი განახლდება კიდევ 2 კვანძზე და ა.შ. ეს მარტივი მოძრავი განახლების მექანიზმი მოგეწოდებათ როგორც Docker-ის ნაწილი.

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

ამ შემთხვევაში, ჩვენ გვაქვს 3 პოდი Replication კონტროლერში, რომელიც მუშაობს WildFly ვერსიის 1 აპლიკაციაში. ფონზე განახლებისას იქმნება სხვა რეპლიკაციის კონტროლერი იმავე სახელით და ბოლოში - - xxxxx, სადაც x არის შემთხვევითი რიცხვები და იგივე ეტიკეტებით. ახლა Application Service-ს აქვს სამი განყოფილება აპლიკაციის ძველი ვერსიით და სამი პოდი ახალი ვერსიით ახალ Replication კონტროლერში. ამის შემდეგ იშლება ძველი ჯირკვლები, რეპლიკაციის კონტროლერი ახალ პოდებთან ერთად სახელდება და ამოქმედდება.

მოდით გადავიდეთ მონიტორინგზე. Docker-ს აქვს მრავალი ჩაშენებული მონიტორინგის ბრძანება. მაგალითად, დოკერის კონტეინერის სტატისტიკის ბრძანების ხაზის ინტერფეისი საშუალებას გაძლევთ ყოველ წამს აჩვენოთ ინფორმაცია კონსოლში კონტეინერების მდგომარეობის შესახებ - პროცესორის გამოყენება, დისკის გამოყენება, ქსელის დატვირთვა. Docker Remote API ინსტრუმენტი გვაწვდის მონაცემებს იმის შესახებ, თუ როგორ ურთიერთობს კლიენტი სერვერთან. ის იყენებს მარტივ ბრძანებებს, მაგრამ დაფუძნებულია Docker REST API-ზე. ამ შემთხვევაში, სიტყვები REST, Flash, Remote ნიშნავს იგივეს. როდესაც თქვენ დაუკავშირდებით მასპინძელს, ეს არის REST API. Docker Remote API გაძლევთ საშუალებას მიიღოთ მეტი ინფორმაცია გაშვებული კონტეინერების შესახებ. ჩემი ბლოგი ასახავს ამ მონიტორინგის Windows Server-ით გამოყენების დეტალებს.

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

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

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

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

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

თითოეული სამუშაო კვანძი შეიცავს ავტომატურად გაშვებულ cAdvisor-ს. გარდა ამისა, არსებობს Heapster, შესრულების მონიტორინგისა და მეტრიკის შეგროვების სისტემა, რომელიც თავსებადია Kubernetes 1.0.6 და უფრო მაღალ ვერსიასთან. Heapster საშუალებას გაძლევთ შეაგროვოთ არა მხოლოდ სამუშაო დატვირთვის, პოდებისა და კონტეინერების შესრულების მეტრიკა, არამედ მთელი კლასტერის მიერ წარმოქმნილი მოვლენები და სხვა სიგნალები. მონაცემების შესაგროვებლად, ის ესაუბრება თითოეული პოდის Kubelet-ს, ავტომატურად ინახავს ინფორმაციას InfluxDB მონაცემთა ბაზაში და გამოაქვს მას მეტრიკის სახით Grafana-ს დაფაზე. თუმცა, გაითვალისწინეთ, რომ თუ იყენებთ miniKube-ს, ეს ფუნქცია ნაგულისხმევად მიუწვდომელია, ამიტომ მონიტორინგისთვის მოგიწევთ დამატებების გამოყენება. ასე რომ, ეს ყველაფერი დამოკიდებულია იმაზე, თუ სად მართავთ კონტეინერებს და რომელი მონიტორინგის ინსტრუმენტები შეგიძლიათ გამოიყენოთ ნაგულისხმევად და რომელთა დაყენება გჭირდებათ ცალკე დანამატებად.

შემდეგი სლაიდი აჩვენებს Grafana-ს დაფებს, რომლებიც აჩვენებს ჩემი კონტეინერების მუშაობის სტატუსს. აქ საკმაოდ ბევრი საინტერესო მონაცემია. რა თქმა უნდა, არსებობს მრავალი კომერციული Docker და Kubernetes პროცესების მონიტორინგის ინსტრუმენტი, როგორიცაა SysDig, DataDog, NewRelic. ზოგიერთ მათგანს აქვს 30 წლიანი უფასო საცდელი პერიოდი, ასე რომ თქვენ შეგიძლიათ სცადოთ და იპოვოთ ის, რომელიც საუკეთესოდ შეესაბამება თქვენ. პირადად მე მირჩევნია გამოვიყენო SysDig და NewRelic, რომლებიც კარგად აერთიანებს Kubernetes-ს. არსებობს ინსტრუმენტები, რომლებიც ერთნაირად კარგად აერთიანებს როგორც Docker, ასევე 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