Kubernetes Web View-ის განცხადება (და სხვა ვებ UI-ების მოკლე მიმოხილვა Kubernetes-ისთვის)

Შენიშვნა. თარგმნა: ორიგინალური მასალის ავტორია ჰენინგ ჯეიკობსი ზალანდოდან. მან შექმნა ახალი ვებ ინტერფეისი Kubernetes–თან მუშაობისთვის, რომელიც განთავსებულია როგორც „kubectl ვებისთვის“. რატომ გამოჩნდა ახალი Open Source პროექტი და რა კრიტერიუმებს არ აკმაყოფილებდა არსებული გადაწყვეტილებები - წაიკითხეთ მისი სტატია.

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

გამოიყენეთ შემთხვევები

Zalando-ში ჩვენ ვემსახურებით Kubernetes-ის მომხმარებელთა დიდ რაოდენობას (900+) და კლასტერებს (100+). არსებობს რამდენიმე ჩვეულებრივი გამოყენების შემთხვევა, რომელიც ისარგებლებს გამოყოფილი ვებ ინსტრუმენტით:

1. კომუნიკაცია კოლეგებთან მხარდაჭერისთვის;
2. ინციდენტებზე რეაგირება და მათი მიზეზების გამოძიება.

მხარდაჭერა

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

— დახმარება, ჩვენი XYZ სერვისი მიუწვდომელია!
— რას ხედავ, როცა ასრულებ kubectl describe ingress ...?

ან რამე მსგავსი CRD-ისთვის:

- რაღაც პრობლემა მაქვს საიდენტიფიკაციო სამსახურთან...
- რას იძლევა ბრძანება? kubectl describe platformcredentialsset ...?

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

ამიტომ, მსურს Kubernetes-ის ვებ ფრონტენტმა დაუშვას შემდეგი:

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

ინციდენტის რეაგირება და ანალიზი

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

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

ჩემი სტანდარტული გადაწყვეტა ასეთ შემთხვევებში არის რაღაც მსგავსი for i in $clusters; do kubectl ...; done. ცხადია, შესაძლებელია ისეთი ხელსაწყოს შემუშავება, რომელიც უზრუნველყოფს მსგავს შესაძლებლობებს.

არსებული Kubernetes ვებ ინტერფეისები

Kubernetes-ისთვის ვებ ინტერფეისების ღია კოდის სამყარო არც თუ ისე დიდია*, ამიტომ შევეცადე მეტი ინფორმაციის შეგროვება გამოყენებით Twitter:

*ჩემი ახსნა Kubernetes-ისთვის ვებ ინტერფეისების შეზღუდული რაოდენობის შესახებ: ღრუბლოვანი სერვისები და Kubernetes-ის გამყიდველები ჩვეულებრივ გვთავაზობენ საკუთარ ფრონტენტებს, ამიტომ „კარგი“ უფასო Kubernetes UI-ის ბაზარი შედარებით მცირეა.

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

K8Dash

"K8Dash არის Kubernetes კლასტერის მართვის უმარტივესი გზა."

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

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

კუბერნატორი

„Kubernator არის ალტერნატიული ინტერფეისი Kubernetes-ისთვის. მაღალი დონის Kubernetes Dashboard-ისგან განსხვავებით, ის უზრუნველყოფს დაბალი დონის კონტროლს და შესანიშნავ ხილვადობას კლასტერის ყველა ობიექტზე ახლის შექმნის, მათი რედაქტირების და კონფლიქტების გადაჭრის შესაძლებლობით. როგორც მთლიანად კლიენტის მხარის აპლიკაცია (როგორც kubectl), ის არ საჭიროებს რაიმე ბექენდს გარდა თავად Kubernetes API სერვერისა და ასევე პატივს სცემს კლასტერზე წვდომის წესებს.

ეს საკმაოდ ზუსტი აღწერაა კუბერნატორი. სამწუხაროდ, მას აკლია გარკვეული მახასიათებლები:

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

Kubernetes Dashboard

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

სამწუხაროდ, Kubernetes Dashboard ნამდვილად არ მეხმარება ჩემს მხარდაჭერასა და ინციდენტებზე რეაგირების აქტივობებში, რადგან ის:

• არ არსებობს მუდმივი ბმულები, მაგალითად, როდესაც ვფილტრავ რესურსებს ან ვცვლი დახარისხების წესრიგს;
• არ არსებობს მარტივი გზა სტატუსის მიხედვით გაფილტვრისთვის - მაგალითად, იხილეთ ყველა პოდი სტატუსით "მოლოდინში";
• მხარდაჭერილია მხოლოდ ერთი კლასტერი;
• CRD არ არის მხარდაჭერილი (ეს ფუნქცია დამუშავების პროცესშია);
• არ არის მორგებული სვეტები (როგორიცაა სვეტები ტიპის მიხედვით kubectl -L).

Kubernetes ოპერატიული ხედი (kube-ops-view)

"System Dashboard Observer for K8s Cluster Space."

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

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

Kubernetes რესურსების ანგარიში (kube-resource-report)

„შეაგროვეთ pod და Kubernetes კლასტერული რესურსების მოთხოვნები, შეადარეთ ისინი რესურსების მოხმარებას და შექმენით სტატიკური HTML“.

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

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

ოქტანტი

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

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

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

მე ასევე მქონდა პრობლემები ოქტანტის სტაბილურობასთან Zalando კლასტერებთან: ზოგიერთ CRD-ზე ის ვარდებოდა.

წარმოგიდგენთ Kubernetes Web View-ს

"kubectl ვებისთვის".

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

• ყველა (მხოლოდ წაკითხვადი) ოპერაციების ხელმისაწვდომობა, რისთვისაც მომხმარებლებს ურჩევნიათ გამოიყენონ kubectl;
• ყველა URL უნდა იყოს მუდმივი და წარმოადგენდეს გვერდს თავდაპირველ ფორმაში, რათა კოლეგებმა შეძლონ მათი გაზიარება და მათი გამოყენება სხვა ინსტრუმენტებში;
• Kubernetes-ის ყველა ობიექტის მხარდაჭერა, რაც საშუალებას მოგცემთ გადაჭრას ნებისმიერი ტიპის პრობლემა;
• რესურსების სიები უნდა იყოს ჩამოტვირთული შემდგომი მუშაობისთვის (ელცხრილებში, CLI ინსტრუმენტებში, როგორიცაა grep) და შენახვა (მაგალითად, სიკვდილის შემდეგ);
• რესურსების ეტიკეტის მიხედვით შერჩევის მხარდაჭერა (მსგავსი kubectl get .. -l);
• სხვადასხვა ტიპის რესურსების კომბინირებული სიების შექმნის შესაძლებლობა (მსგავსი kubectl get all) კოლეგებს შორის საერთო ოპერატიული სურათის მიღება (მაგალითად, ინციდენტზე რეაგირების დროს);
• პერსონალური ჭკვიანი ღრმა ბმულების დამატების შესაძლებლობა სხვა ინსტრუმენტებზე, როგორიცაა დაფები, ლოგერები, აპლიკაციების რეესტრები და ა.შ. პრობლემების აღმოფხვრა/შეცდომის გადაჭრა და ინციდენტებზე რეაგირების ხელშეწყობა;
• წინა ნაწილი უნდა იყოს რაც შეიძლება მარტივი (სუფთა HTML), რათა თავიდან იქნას აცილებული შემთხვევითი პრობლემები, როგორიცაა გაყინული JavaScript;
• მრავალი კლასტერის მხარდაჭერა დისტანციური კონსულტაციის დროს ურთიერთქმედების გასამარტივებლად (მაგალითად, მხოლოდ ერთი URL-ის დასამახსოვრებლად);
• თუ შესაძლებელია, სიტუაციური ანალიზი უნდა გამარტივდეს (მაგალითად, ყველა კლასტერის/სახელთა სივრცის რესურსების ჩამოტვირთვის ბმულებით);
• მოქნილი ბმულების შექმნისა და ტექსტური ინფორმაციის ხაზგასმის დამატებითი შესაძლებლობები, მაგალითად, ასე რომ თქვენ შეგიძლიათ მიუთითოთ კოლეგები რესურსის აღწერილობის კონკრეტულ განყოფილებაზე (ხაზი YAML-ში);
• კონკრეტული კლიენტის მოთხოვნებზე მორგების შესაძლებლობა, მაგალითად, საშუალებას გაძლევთ შექმნათ სპეციალური ჩვენების შაბლონები CRD-ებისთვის, თქვენი ცხრილის ხედები და შეცვალოთ CSS სტილები;
• ბრძანების სტრიქონზე შემდგომი შესწავლის ხელსაწყოები (მაგალითად, სრული ბრძანებების ჩვენება kubectl, მზადაა კოპირებისთვის);

Kubernetes Web View-ში გადაჭრილი ამოცანების მიღმა (არაგოლები) დარჩა:

• Kubernetes ობიექტების აბსტრაქცია;
• აპლიკაციების მენეჯმენტი (მაგალითად, განლაგების მენეჯმენტი, Helm სქემები და ა.შ.);
• ჩაწერის ოპერაციები (უნდა განხორციელდეს უსაფრთხო CI/CD და/ან GitOps ინსტრუმენტების მეშვეობით);
• ლამაზი ინტერფეისი (JavaScript, თემები და ა.შ.);
• ვიზუალიზაცია (იხ kube-ops-view);
• ხარჯების ანალიზი (იხ kube-resource-report).

როგორ ეხმარება Kubernetes Web View მხარდაჭერას და ინციდენტზე რეაგირებას?

მხარდაჭერა

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

ძიება კლასტერების მიხედვით Kubernetes Web View-ში

ინციდენტის რეაგირება

• გლობალური ძებნა (გლობალური ძებნა) საშუალებას გაძლევთ მოძებნოთ ობიექტები ყველა კლასტერში.
• სიის ნახვები შეუძლია აჩვენოს ყველა ობიექტი გარკვეული მდგომარეობით/სვეტით ყველა კლასტერში (მაგალითად, ჩვენ უნდა ვიპოვოთ ყველა pods სტატუსით „Pending“).
• ობიექტების სიების ჩამოტვირთვა შესაძლებელია ჩანართებით გამოყოფილი მნიშვნელობის (TSV) ფორმატში შემდგომი ანალიზისთვის.
• კონფიგურირებადი გარე ბმულები საშუალებას გაძლევთ გადახვიდეთ დაკავშირებულ დაფებზე და სხვა ინსტრუმენტებზე.

Kubernetes Web View: პოდების სია „მოლოდინში“ სტატუსით ყველა კლასტერში

თუ გსურთ სცადოთ Kubernetes Web View, გირჩევთ შეამოწმოთ დოკუმენტაცია ან შეხედე ცოცხალი დემო.

რა თქმა უნდა, ინტერფეისი შეიძლება უკეთესი იყოს, მაგრამ ამ დროისთვის Kubernetes Web View არის ინსტრუმენტი „მოწინავე მომხმარებლებისთვის“, რომლებიც საჭიროების შემთხვევაში არ ერიდებიან URL ბილიკების ხელით მანიპულირებას. თუ თქვენ გაქვთ რაიმე კომენტარი/დამატება/შემოთავაზება, გთხოვთ დაგვიკავშირდეთ ჩემთან ერთად Twitter-ზე!

ეს სტატია არის ფონის მოკლე ისტორია, რამაც გამოიწვია Kubernetes Web View-ს შექმნა. მეტი მოჰყვება! (Შენიშვნა. თარგმნა: მათ უნდა ველოდოთ ავტორი ბლოგი.)

PS მთარგმნელისგან

ასევე წაიკითხეთ ჩვენს ბლოგზე:

• «kubebox და სხვა ჭურვები Kubernetes-ისთვის";
• «ინსტრუმენტები Kubernetes-ზე გაშვებული აპლიკაციების დეველოპერებისთვის";
• «Kubelive კონსოლის პროგრამა გამოჩნდა Kubernetes-თან ინტერაქტიული მუშაობისთვის";
• «სასარგებლო უტილიტები Kubernetes-თან მუშაობისას".

წყარო: www.habr.com