Shën. përkth.: Autor i materialit origjinal — Henning Jacobs nga kompania Zalando. Ai krijoi një ndërfaqe të re në web për të punuar me Kubernetes, e cila pozicionohet si "kubectl për webin". Pse u shfaq ky projekt i ri Open Source dhe cilave kritere nuk iu përgjigjën zgjidhjet ekzistuese — lexoni në artikullin e tij.

Në këtë publikim shqyrtoj ndërfaqet e ndryshme web Kubernetes me kod të hapur, paraqes kërkesat e mia për një UI universal dhe tregoj pse e zhvillova — ndërfaqe e cila synon të lehtësojë mbështetje dhe zgjidhjen e problemeve në shumë klastera.
Scenarët e përdorimit
Në Zalando ne shërbejmë një numër të madh përdoruesish Kubernetes (më shumë se 900) dhe klasterash (më shumë se 100). Ka disa raste tipike përdorimi, ku ndihma e një instrumenti të specializuar web do të ishte shumë e dobishme:
- komunikimi me kolegët në mbështetje;
- reagimi ndaj incidenteve dhe hetimi i shkakëve të tyre.
Mbështetje
Nga përvoja ime, komunikimi në mbështetje shpesh duket kështu:
— Më ndihmoni, shërbimi ynë XYZ është i paarritshëm!
— Çfarë shihni kur ekzekutoni kubectl describe ingress ...?
Ose diçka të ngjashme për CRD:
— Kam një problem me shërbimin e identifikimit...
— Çfarë nxjerr komanda kubectl describe platformcredentialsset ...?
Ky komunikim zakonisht reduktohet në futjen e variacioneve të ndryshme të komandës kubectl me qëllim të vendosim problemin. Si rezultat, të dy palët e bisedës janë të detyruara të kalojnë vazhdimisht midis terminalit dhe bisedës në web, plus ata vëzhgojnë situata të ndryshme.
Prandaj dëshirojmë që frontend-i web për Kubernetes të lejojë të siguiente:
- përdoruesit të mund të ndajnë lidhje dhe të shohin të njëjtën gjë;
- të ndihmojë të shmangin gabimet njerëzore në mbështetje: për shembull, mos të hyjnë në klasterin e gabuar në komandën e linjës, gabime në komandat CLI etj.;
- të lejojë të gjenerojnë përfytyrime të tyre për t'ua dërguar kolegëve, dmth. të shtojnë kolona etiketash, të shfaqin shumë lloje burimesh në një faqe;
- në mënyrë ideale ky instrument web duhet të lejojë vendosjen e "lidhjeve të thella" në pjesë specifike të YAML (për shembull, t'iu referohet një parametri të gabuar që shkakton dështime).
Reagimi ndaj incidenteve dhe analiza
Reagimi ndaj incidenteve në infrastrukturë kërkon njohuri situative, aftësi për të vlerësuar ndikimin dhe kërkimin e tendencave në klasterë. Disa shembuj nga jeta reale:
- një shërbimi kritike production i ndodhin probleme dhe ju duhet të gjeni të gjitha resurset Kubernetes sipas emrit në të gjitha klasterët, për të riparuar defektin;
- nodalët fillojnë të bien gjatë shkallëzimit, dhe ju duhet të gjeni të gjitha pod’ët me status "Pending" në të gjitha klasterët, për të vlerësuar shkallën e problemit;
- përdoruesit e veçantë raportojnë një problem me DaemonSet, i implementuar në të gjitha klasterët, dhe duhet të speedy nëse problemi është i përgjithshëm.
Zgjidhja ime standarde në këto raste është diçka si for i in $clusters; do kubectl ...; done. Sigurisht, mund të zhvillohet një mjet që ofron mundësi të ngjashme.
Ndërfaqet e web-it ekzistuese të Kubernetes
Bota Open Source e ndërfaqeve të web-it për Kubernetes nuk është shumë e madhe, kështu që provova të grumbulloj informacion shtesë përmes :

* Shpjegimi im për numrin e kufizuar të ndërfaqeve të web-it për Kubernetes: shërbimet cloud dhe furnizuesit e Kubernetes zakonisht ofrojnë front-endet e veta, prandaj tregu për UI të "mirë" falas për Kubernetes është relativisht i vogël.
Me një tweet mësova për , dhe . Le të shikojmë ata dhe zgjidhjet e tjera ekzistuese Open Source, dhe të përpiqemi të kuptojmë se çfarë përfaqësojnë.
K8Dash
"K8Dash është mënyra më e thjeshtë për të menaxhuar një klaster Kubernetes."

dukjet mirë dhe ndjehet shpejt në punë, por ka disa disavantazhe për skenarët e përdorimit të përmendur më sipër:
- Punon vetëm brenda një klasteri.
- Renditja dhe filtrimi janë të mundshme, por nuk kanë lidhje të përhershme.
- Nuk mbështet Definicione të Burimeve të Personalizuara (CRD).
Kubernator
"Kubernator është një UI alternativ për Kubernetes. Në kundërshtim me panelin e nivelit të lartë Kubernetes Dashboard, ai ofron kontroll të nivelit të ulët dhe një përmbledhje të shkëlqyer të të gjithë objekteve në klaster me mundësinë për të krijuar të reja, për t'i redaktuar ato dhe për të zgjidhur konflikte. Duke qenë një aplikacion tërësisht klientesh (si kubectl), ai nuk kërkon ndonjë backend përveç vetë API-serverit Kubernetes, dhe merr parasysh rregullat e aksesit në klaster."

Kjo është një përshkrim mjaft i saktë Fatkeqësisht, atij i mungojnë disa funksionalitete:
- Shërben vetëm një klaster.
- Nuk ka mënyrë shikimi në formën e listës (domethënë, nuk është e mundur të tregoni të gjithë podët me status 'Pending').
Kubernetes Dashboard
«Kubernetes Dashboard është një ndërfaqe e barkut e universale për klasterët Kubernetes. Ajo u lejon përdoruesve të menaxhojnë aplikacionet që funksionojnë në klaster dhe të zgjidhin problemet e tyre, si dhe të menaxhojnë vetë klasterin».

Pështu nuk ndihmon shumë në aktivitetet e mia të mbështetjes dhe reagimit ndaj incidenteve, sepse:
- nuk ka lidhje të vazhdueshme, për shembull, kur filtroj burimet ose ndryshoj renditjen;
- nuk ka asnjë mënyrë të thjeshtë për të filtruar sipas statusit - për shembull, për të parë të gjithë podët me status 'Pending';
- mbështetet vetëm një klaster;
- nuk mbështeten CRD (kjo veçori është në proces zhvillimi);
- nuk ka kolona të personnalisuara (për shembuj, kolona me etiketat si
kubectl -L).
Kubernetes Operational View (kube-ops-view)
«Panairi i sistemit për vëzhgimin e hapësirave të klasterit K8s».

Me ka një qasje tërësisht ndryshe: ky mjet tregon vetëm nyjet e klasterit dhe podët duke përdorur WebGL, pa detaje tekstuale të objekteve. Ai është shumë efektiv për një pasqyrë operative të gjendjes së klasterit ('podët po bien?')*, por nuk i përshtatet rasteve të përdorimit të përmendura më sipër në mbështetje dhe reagim ndaj incidenteve.
* Shën. përkth.: Në këtë kuptim, mund të ju interesojë edhe plugini ynë , për të cilin folëm më gjërë në .
Kubernetes Resource Report (kube-resource-report)
«Mblidhni informacione mbi kërkesat për burime të podëve dhe klasterit Kubernetes, krahasojini ato me konsumimin e burimeve dhe gjeneroni HTML statik».

gjeneron raporte HTML statike mbi përdorimin e burimeve dhe shpërndarjen e kostove midis ekipeve/aplikacioneve në klastere. Raporti është në një farë mënyre i dobishëm për mbështetje dhe reagim ndaj incidenteve, pasi lejon gjetjen më të shpejtë të klasterit në të cilin është vendosur aplikacioni.
Shën. përkth.: Në shikimin e informacionit mbi shpërndarjen e burimeve dhe kostot e tyre, shërbimi dhe mjeti , për të cilin kemi .
Octant
«Një platformë e zgjerueshme për zhvilluesit, e destinuar për të ofruar një kuptim më të mirë të kompleksitetit të klasterëve Kubernetes.»

, i krijuar në VMware, është një produkt i ri që e kam mësuar relativisht së fundmi. Me të është e lehtë të eksplorosh klasterin në makinë lokale (ka edhe vizualizime), megjithatë ai preku problemin e mbështetjes dhe reagimit ndaj incidenteve vetëm në një masë të kufizuar. Disavantazhet e Octant:
- Nuk ka kërkim për klasterat.
- Punon vetëm në makinë lokale (nuk implementohet në klaster).
- Nuk është e mundur të renditen/filterohen objektet (mbështetet vetëm selektori i etiketave).
- Nuk mund të përcaktohen kolona të personalizuara.
- Nuk është e mundur të shfaqet lista e objekteve sipas hapësirave emër.
Gjithashtu kam pasur probleme me stabilitetin e punës së Octant me klasterat Zalando: në disa CRD .
Paraqes Kubernetes Web View
«kubectl për web».

Pas analizimit të mundësive të disponueshme të ndërfaqeve për Kubernetes, vendosa të krijoj një të re: . Sepse në thelb, unë kam nevojë vetëm për gjithë fuqinë kubectl në web, dhe konkretisht:
- disponueshmërinë e të gjitha operacioneve (read-only), në të cilat përdoruesit preferojnë të përdorin kubectl;
- të gjitha URL-të duhet të jenë të përhershme dhe të paraqesin faqen në formatin origjinal, në mënyrë që kolegët të mund të ndajnë ato dhe t'i përdorin në mjete të tjera;
- mbështetje për të gjitha objektet e Kubernetes, që do të lejojë zgjidhjen e problemeve të çdo lloji;
- listat e burimeve duhet të jenë të shkarkueshme për përdorim të mëtejshëm (në tabela elektronike, mjetet CLI si
grep) dhe ruajtje (p.sh., për postmortem’ë); - mbështetje për selektimin e burimeve sipas etiketave (analogjia me
kubectl get .. -l); - mundësia për të krijuar lista të bashkuara të llojeve të ndryshme të burimeve (analogjia me
kubectl get all) për të marrë një pamje të përgjithshme operative mes kolegëve (p.sh., gjatë reagimit ndaj një incidenti); - mundësia për të shtuar lidhje të thella «të mençura» të personalizuara në mjete të tjera si panelet e monitorimit, logguesit, regjistrat e aplikacioneve, etj. për lehtësimin e kërkimit/zhbllokimit të problemeve dhe reagimit ndaj incidenteve;
- frontend duhet të jetë sa më i thjeshtë (HTML i pastër), për të shmangur problemet e rastësishme, për shembull, JavaScript të ngrirë;
- mbështetje për shumë klastera për të lehtësuar ndërveprimin gjatë konsulencës në distancë (p.sh., për të mbajtur mend vetëm një URL);
- nëse është e mundur, duhet të thjeshtohet analiza situative (p.sh., me lidhje për shkarkimin e burimeve nga të gjithë klasterat/hapësirat emër);
- mundësi të shtuar për krijimin e lidhjeve fleksibile dhe nxjerrjen e informacionit tekstor, për shembull, për të lejuar që të tjerët të shpjegojnë një seksion të caktuar në përshkrimin e burimit (një rresht në YAML);
- mundësi për t'u përshtatur me kërkesat e klientëve konkretë, për shembull, duke lejuar krijimin e templative speciale për shfaqjen në CRD, pamje të personalizuara të tabelave, të ndryshoni stilin CSS;
- mjetet për hulumtime të mëtejshme në komandën e linjës (për shembull, duke treguar komandat e plota
kubectl, të gatshme për kopjim);
Përveç detyrave të zgjidhura në Kubernetes Web View (non-goals) kanë mbetur:
- abstraktimi i objekteve Kubernetes;
- menaxhimi i aplikacioneve (për shembull, menaxhimi i deployment-eve, Helm-chart-eve, etj.);
- operacione të shkrimit (duhet të realizohen përmes mjeteve të sigurta CI/CD dhe/ose GitOps);
- një ndërfaqe e bukur (JavaScript, tema, etj.);
- vizualizime (shih );
- analiza e kostove (shih ).
Si ndihmon Kubernetes Web View në mbështetje dhe reagim ndaj incidenteve?
Mbështetje
- Të gjitha lidhjet janë të qëndrueshme, e cila lehtëson shkëmbimin e informacionit me kolegët.
- Mund të krijoni pamje të personalizuara, për shembull, të tregoni të gjitha deployment-et dhe pod-et me një etiketë të caktuar në dy klastera të veçantë (emrat e disa klasterëve dhe llojeve të burimeve mund të vendosen në lidhje, duke i ndarë ato me presje).
- Mund të referoheni në rreshta të caktuar në skedarin YAML të objektit, duke treguar për probleme potenciale në specifikimin e objektit.

Kërkoni në klasterët në Kubernetes Web View
Reagimi ndaj incidenteve
- Kërkimi global (global search) lejon kërkimin e objekteve në të gjitha klasterët.
- Pamjet në formë liste mund të tregojnë të gjitha objektet me një gjendje/shtyllë të caktuar në të gjitha klasterët (për shembull, na nevojitet të kërkojmë të gjithë pod-et me status «Pending»).
- Listat e objekteve mund të shkarkohen në formatin e vlerave të ndara me tab (TSV), për analizë të mëtejshme.
- mundësojnë kalimin në panelet përkatëse të monitorimit dhe mjete të tjera.

Kubernetes Web View: lista e pod-eve me status «Pending» në të gjitha klasterët
Nëse dëshironi të provoni Kubernetes Web View, rekomandoj të njiheni me ose të shihni .
Sigurisht, ndërfaqja mund të ishte edhe më e mirë, ndërsa Kubernetes Web View është një mjet për "përdoruesit e avancuar" që nuk hezitojnë të manovrojnë manualisht me rrugët URL, nëse është e nevojshme. Nëse keni komente/sugjerime/dëshira, ju lutem kontaktoni !
Ky artikull është një tregim i shkurtër mbi parakushtet që çuan në krijimin e Kubernetes Web View. Ndjekin artikuj të tjerë! (Shën. përkth.: Pritet të dalin në .)
P.S. nga përkthyesi
Lexoni gjithashtu në blogun tonë:
- «»;
- «»;
- «»;
- «».
Burimi: habr.com
