Nota traducătorului.: Autorul materialului original este Henning Jacobs de la Zalando. El a creat o nouă interfață web pentru lucrul cu Kubernetes, care se poziționează ca „kubectl pentru web”. De ce a apărut acest nou proiect Open Source și ce criterii nu au fost îndeplinite de soluțiile existente - citiți în articolul său.

În această publicație, analizez diferite interfețe web Kubernetes cu sursă deschisă, stabilesc cerințele mele pentru o interfață utilizator universală și explic de ce am dezvoltat — o interfață menită să faciliteze suportul și soluționarea problemelor în mai multe clustere simultan.
Scenarii de utilizare
În Zalando, servim un număr mare de utilizatori Kubernetes (peste 900) și clustere (peste 100). Există câteva cazuri tipice de utilizare, în care ar fi foarte util ajutorul unui instrument web specializat:
- comunicarea cu colegii în cadrul suportului;
- reacționarea la incidente și investigarea cauzelor acestora.
Asistență
Din experiența mea, comunicarea în cadrul suportului arată adesea astfel:
— Ajutați, serviciul nostru XYZ nu este disponibil!
— Ce vedeți când rulați kubectl describe ingress ...?
Sau ceva similar pentru CRD:
— Am o problemă cu serviciul de identificare...
— Și ce returnează comanda kubectl describe platformcredentialsset ...?
Această comunicare se reduce de obicei la introducerea diferitelor variații ale comenzii kubectl pentru a stabili problema. Ca urmare, ambele părți ale conversației trebuie să comute constant între terminal și chat-ul web, plus că observă situații diferite.
Așadar, ar fi bine ca frontend-ul web pentru Kubernetes să permită următoarele:
- utilizatorii ar putea schimba link-uri și să observe același lucru;
- ar ajuta să evite erorile umane în suport: de exemplu, conectarea la clusterul greșit în linia de comandă, greșelile de tipar în comenzile CLI etc.;
- ar permite generarea de viziuni proprii pentru a le trimite colegilor, adică să adauge coloane de etichete, să afișeze mai multe tipuri de resurse pe aceeași pagină;
- în ideal, acest instrument web ar trebui să permită setarea link-uri "adânci" către secțiuni specifice YAML (de exemplu, să indice un parametru greșit care cauzează eșecuri).
Reacționarea la incidente și analiza
Reacția la incidente în infrastructură necesită conștientizare situațională, abilitatea de a evalua impactul și căutarea de tipare în clustere. Iată câteva exemple din viața reală:
- un serviciu de producție critic întâmpină probleme și trebuie să găsești toate resursele Kubernetes după nume în toate clusterele, pentru a remedia defecțiunile;
- nodurile încep să cadă în timpul scalării, și trebuie să găsești toate pod-urile cu statut „Pending” în toate clusterele, pentru a evalua amploarea problemei;
- utilizatorii individuali raportează o problemă cu DaemonSet-ul desfășurat în toate clusterele, și este necesar să stabilim dacă problema este totală.
Soluția mea standard în astfel de cazuri este ceva de genul for i in $clusters; do kubectl ...; done. Evident, putem dezvolta un instrument care oferă funcționalități similare.
Interfețele web existente pentru Kubernetes
Lumea Open Source a interfețelor web pentru Kubernetes nu este foarte mare*, așa că am încercat să adun informații suplimentare prin :

* Explicația mea pentru numărul limitat de interfețe web pentru Kubernetes: servicii cloud și furnizori de Kubernetes oferă de obicei front-end-uri proprii, așa că piața pentru „bune” interfețe UI Kubernetes gratuite este relativ mică.
Printr-un tweet am aflat despre , și . Să ne uităm la ele și la alte soluții Open Source existente, să încercăm să înțelegem ce reprezintă.
K8Dash
„K8Dash este cel mai simplu mod de a gestiona un cluster Kubernetes”.

arată destul de bine și, din impresie, funcționează rapid, dar are câteva dezavantaje pentru scenariile de utilizare menționate mai sus:
- Funcționează doar în limitele unui singur cluster.
- Sortarea și filtrarea sunt posibile, dar nu au linkuri permanente.
- Lipsa suportului pentru Custom Resource Definitions (CRDs).
Kubernator
„Kubernator este o interfață alternativă pentru Kubernetes. Spre deosebire de panoul de control high-level Kubernetes Dashboard, oferă control low-level și o vedere excelentă asupra tuturor obiectelor din cluster, cu posibilitatea de a crea noi, a le edita și a rezolva conflicte. Fiind o aplicație complet client-side (ca kubectl), nu necesită un backend în afară de serverul API Kubernetes, și ia în considerare regulile de acces la cluster.”

Este o descriere destul de exactă a . Din păcate, îi lipsesc unele funcționalități:
- Serveste un singur cluster.
- Nu există un mod de vizualizare în formă de listă (adică nu se pot lista toate pod-urile cu statutul „Pending”).
Kubernetes Dashboard
„Kubernetes Dashboard este o interfață web universală pentru clusterele Kubernetes. Permite utilizatorilor să gestioneze aplicațiile care rulează în cluster și să le depaneze, precum și să administreze însuși clusterul.”

Din păcate, nu ajută prea mult în activitățile mele de suport și răspuns la incidente, deoarece:
- nu există link-uri permanente, de exemplu, atunci când filtrez resursele sau schimb ordinea de sortare;
- nu există o modalitate ușoară de a filtra după statut — de exemplu, de a vedea toate pod-urile cu statutul „Pending”;
- se susține doar un singur cluster;
- nu se susțin CRD (această funcționalitate este în curs de dezvoltare);
- nu există coloane personalizate (de exemplu, coloane cu etichete de tipul
kubectl -L).
Kubernetes Operational View (kube-ops-view)
„Panou sistem de monitorizare pentru spațiile cluster-ului K8s.”

În adoptă o abordare complet diferită: acest instrument arată doar nodurile cluster-ului și pod-urile folosind WebGL, fără detalii textuale despre obiecte. Este excelent pentru un overview operațional al stării cluster-ului („pod-urile cad?”)*, dar nu se potrivește cazurilor de utilizare descrise mai sus în suport și răspuns la incidente.
* Nota traducătorului.: În acest sens, s-ar putea să fiți interesat și de plugin-ul nostru , despre care am discutat mai detaliat în .
Kubernetes Resource Report (kube-resource-report)
„Colectați informații despre cererile de resurse ale pod-urilor și cluster-ului Kubernetes, comparați-le cu consumul de resurse și generați HTML static.”

generează rapoarte HTML statice despre utilizarea resurselor și distribuția costurilor pe echipe/aplicații în clustere. Rapoartele sunt oarecum utile pentru suport și răspuns la incidente, deoarece permit identificarea rapidă a cluster-ului în care este desfășurată aplicația.
Nota traducătorului.: În vizionarea informațiilor despre distribuția resurselor și costul acestora, serviciul și instrumentul ar putea fi, de asemenea, utile .
Octant
publicat recent un articol despre „O platformă web extensibilă pentru dezvoltatori, menită să asigure o înțelegere mai bună a complexității clusterele Kubernetes.”

, creat în VMware, este un nou produs de care am aflat relativ recent. Cu ajutorul său, este convenabil să explorez cluster-ul pe un computer local (există chiar și vizualizări), totuși abordează problema suportului și a reacției la incidente doar într-o măsură limitată. Disadvantagele Octant:
- Fără căutare în clustere.
- Funcționează doar pe computerul local (nu este implementat în cluster).
- Nu este posibil să sortezi/filtrezi obiectele (se suportă doar selectorul de etichete).
- Nu poți defini coloane personalizate.
- Nu poți lista obiectele pe spații de nume.
De asemenea, am avut probleme cu stabilitatea Octant-ului cu clusterele Zalando: în unele CRD .
Prezint Kubernetes Web View
„kubectl pentru web”.

Analizând opțiunile disponibile de interfețe pentru Kubernetes, am decis să creez un nou: . De fapt, am nevoie doar de toată puterea kubectl în web, adică:
- disponibilitatea tuturor operațiunilor (doar citire) în care utilizatorii preferă să folosească kubectl;
- toate URL-urile trebuie să fie permanente și să reprezinte pagina în forma originală, astfel încât colegii să le poată împărtăși și utiliza în alte instrumente;
- suport pentru toate obiectele Kubernetes, ceea ce va permite rezolvarea problemelor de orice tip;
- listelor de resurse trebuie să fie descărcabile pentru prelucrarea ulterioară (în foi de calcul, instrumente CLI precum
grep) și stocarea (de exemplu, pentru postmortem-uri); - suport pentru filtrarea resurselor după etichete (în mod similar cu
kubectl get .. -l); - posibilitatea de a crea liste combinate de diferite tipuri de resurse (în mod similar cu
kubectl get all) pentru a obține o imagine generală operațională între colegi (de exemplu, în timpul reacției la un incident); - posibilitatea de a adăuga linkuri profunde „inteligente” personalizabile către alte instrumente, cum ar fi panouri de monitorizare, logger-e, registre de aplicații etc., pentru a facilita căutarea/soluționarea problemelor și reacția la incidente;
- frontend-ul trebuie să fie cât mai simplu (HTML curat), pentru a evita problemele accidentale, cum ar fi JavaScript-ul blocat;
- suport pentru multiple clustere pentru a simplifica interacțiunile în consultanța la distanță (de exemplu, pentru a memora doar un URL);
- dacă este posibil, analiza situațională trebuie simplificată (de exemplu, cu linkuri pentru descărcarea resurselor din toate clustere/ spații de nume);
- funcții suplimentare pentru crearea de linkuri flexibile și extragerea de informații textuale, de exemplu, pentru a putea indica colegilor o anumită secțiune din descrierea resursei (linie în YAML);
- capabilitatea de a se adapta cerințelor unui client specific, de exemplu, permițând crearea de șabloane speciale de afișare pentru CRD, propriile vizualizări tabelare, modificarea stilurilor CSS;
- instrumente pentru studiul ulterior în linia de comandă (de exemplu, arătând comenzi complete
kubectl, gata de copiat);
Dincolo de sarcinile abordate în Kubernetes Web View (non-obiective) au rămas:
- abstrarea obiectelor Kubernetes;
- gestionarea aplicațiilor (de exemplu, gestionarea deployment-urilor, Helm charts etc.);
- operațiuni de scriere (care trebuie realizate prin instrumente CI/CD și/sau GitOps securizate);
- interfață atractivă (JavaScript, teme etc.);
- vizualizări (vezi );
- analiza costurilor (vezi ).
Cum ajută Kubernetes Web View în suportul și reacția la incidente?
Asistență
- Toate linkurile sunt permanente, ceea ce facilitează schimbul de informații cu colegii.
- Se pot crea vizualizări proprii, de exemplu, pentru a afișa toate Deployment-urile și Pod-urile cu o anumită etichetă în două clustere specifice (mai multe nume de clustere și tipuri de resurse pot fi specificate în link, separându-le cu virgule).
- Se poate face referire la linii specifice din fișierul YAML al obiectului, indicând problemele potențiale în specificația obiectului.

Căutare în clustere în Kubernetes Web View
Reacție la incidente
- Căutare globală (cautare globală) permite căutarea de obiecte în toate clusterele.
- Vizualizări sub formă de liste pot afișa toate obiectele cu un anumit statut/coloană în toate clusterele (de exemplu, trebuie să găsim toate pod-urile cu statutul «Pending»).
- Listele de obiecte pot fi descărcate în format tab-separated values (TSV) pentru o analiză ulterioară.
- permit trecerea la panourile de monitorizare corespunzătoare și la alte instrumente.

Kubernetes Web View: lista pod-urilor cu statutul «Pending» în toate clusterele
Dacă doriți să încercați Kubernetes Web View, vă recomand să consultați sau să vă uitați la .
Desigur, interfața ar putea fi mai bună, dar deocamdată Kubernetes Web View este un instrument pentru "utilizatori avansați" care nu ezită să manipuleze manual căile URL, dacă este necesar. Dacă aveți sugestii/comentarii/dorinte, vă rog să mă contactați !
Acest articol este o scurtă poveste despre premisele care au dus la crearea Kubernetes Web View. Vor urma altele! (Nota traducătorului.: Acestea sunt de așteptat în .)
P.S. de la translator
Citiți și în blogul nostru:
- «»;
- «»;
- «»;
- «».
Sursa: habr.com
