Notă. transl.: Autorul materialului original este Henning Jacobs din Zalando. El a creat o nouă interfață web pentru lucrul cu Kubernetes, care este poziționată ca „kubectl pentru web”. De ce a apărut un nou proiect Open Source și ce criterii nu au fost îndeplinite de soluțiile existente - citiți articolul său.
În această postare, trec în revistă diferitele interfețe web Kubernetes cu sursă deschisă, îmi expun cerințele pentru o interfață de utilizare universală și explic de ce am dezvoltat — o interfață concepută pentru a facilita sprijinirea și depanarea mai multor clustere simultan.
Cazuri de utilizare
La Zalando deservim un număr mare de utilizatori Kubernetes (900+) și clustere (100+). Există câteva cazuri comune de utilizare care ar beneficia de un instrument web dedicat:
- comunicarea cu colegii pentru sprijin;
- răspunsul la incidente și investigarea cauzelor acestora.
Sprijini
Din experiența mea, comunicările de asistență arată adesea astfel:
— Ajutor, serviciul nostru XYZ nu este disponibil!
— Ce vezi când faci spectacol kubectl describe ingress ...?
Sau ceva similar pentru CRD:
— Am o problemă cu serviciul de identificare...
— Ce produce comanda? kubectl describe platformcredentialsset ...?
O astfel de comunicare se reduce de obicei la introducerea diferitelor variante ale comenzii kubectl pentru a identifica problema. Drept urmare, ambele părți ale conversației sunt forțate să comute constant între terminal și chat-ul web, plus că observă o situație diferită.
Prin urmare, aș dori ca interfața web Kubernetes să permită următoarele:
- utilizatorii ar putea schimb de link-uri și observați același lucru;
- ar ajuta evita greselile umane în suport: de exemplu, conectarea la un cluster greșit pe linia de comandă, greșeli de scriere în comenzile CLI etc.;
- ar permite generați propriile vederi pentru a trimite colegilor, adică adăugați coloane de etichete, afișați mai multe tipuri de resurse pe o singură pagină;
- În mod ideal, acest instrument web ar trebui să vă permită să setați linkuri „deep” către anumite secțiuni ale YAML (de exemplu, sublinierea unui parametru incorect care cauzează defecțiuni).
Răspunsul și analiza la incident
Răspunsul la incidentele de infrastructură necesită cunoașterea situației, capacitatea de a evalua impactul și de a căuta modele în clustere. Câteva exemple din viața reală:
- Un serviciu de producție critic are probleme și aveți nevoie găsiți toate resursele Kubernetes după nume în toate clusterelea depana;
- nodurile încep să cadă atunci când scalați și aveți nevoie găsiți toate podurile cu starea „În așteptare” în toate grupurilepentru a evalua amploarea problemei;
- utilizatorii individuali raportează o problemă cu DaemonSet implementat în toate clusterele și trebuie să-și dea seama Problema este totala?.
Soluția mea standard în astfel de cazuri este ceva de genul for i in $clusters; do kubectl ...; done. Evident, ar putea fi dezvoltat un instrument care să ofere capabilități similare.
Interfețe web Kubernetes existente
Lumea open source a interfețelor web cu Kubernetes nu este foarte mare*, așa că am încercat să adun mai multe informații folosind :
*Explicația mea pentru numărul limitat de interfețe web pentru Kubernetes: serviciile cloud și furnizorii Kubernetes oferă de obicei propriile interfețe, așa că piața pentru interfața de utilizare Kubernetes gratuită „bună” este relativ mică.
Printr-un tweet despre care am aflat , и . Să ne uităm la ele și la alte soluții Open Source existente, să încercăm să înțelegem care sunt acestea.
K8Dash
„K8Dash este cel mai simplu mod de a gestiona un cluster Kubernetes.”
Arată bine și se simte rapid, dar are o serie de dezavantaje pentru cazurile de utilizare enumerate mai sus:
- Funcționează numai în limitele unui cluster.
- Sortarea și filtrarea sunt posibile, dar nu au permalink-uri.
- Nu există suport pentru definițiile personalizate de resurse (CRD).
Kubernator
„Kubernator este o interfață de utilizare alternativă pentru Kubernetes. Spre deosebire de tabloul de bord Kubernetes de nivel înalt, acesta oferă control la nivel scăzut și vizibilitate excelentă asupra tuturor obiectelor din cluster, cu posibilitatea de a crea altele noi, de a le edita și de a rezolva conflicte. Fiind o aplicație în întregime pe partea clientului (cum ar fi kubectl), nu necesită niciun backend în afară de serverul API Kubernetes în sine și respectă, de asemenea, regulile de acces la cluster.”
Aceasta este o descriere destul de exactă . Din păcate, îi lipsesc câteva caracteristici:
- Deservește un singur grup.
- Nu există un mod de vizualizare a listei (adică nu puteți afișa toate podurile cu starea „În așteptare”).
Tabloul de bord Kubernetes
„Kubernetes Dashboard este o interfață web universală pentru clusterele Kubernetes. Permite utilizatorilor să gestioneze și să depaneze aplicațiile care rulează într-un cluster, precum și să gestioneze clusterul în sine.”
Din păcate, nu mă ajută cu adevărat cu activitățile mele de asistență și răspuns la incident, deoarece:
- nu există legături permanente, de exemplu când filtrez resurse sau schimb ordinea de sortare;
- nu există o modalitate ușoară de a filtra după stare - de exemplu, vedeți toate podurile cu starea „În așteptare”;
- este acceptat un singur cluster;
- CRD-urile nu sunt acceptate (această caracteristică este în curs de dezvoltare);
- fără coloane personalizate (cum ar fi coloanele etichetate după tip
kubectl -L).
Vedere operațională Kubernetes (kube-ops-view)
„System Dashboard Observer pentru K8s Cluster Space”.
У O abordare complet diferită: acest instrument arată doar nodurile și podurile de cluster folosind WebGL, fără detalii de obiect textual. Este grozav pentru o privire de ansamblu rapidă asupra stării cluster-ului (cad podurile?)*, dar nu este potrivit pentru cazurile de utilizare de asistență și răspuns la incident descrise mai sus.
* Notă. transl.: În acest sens, este posibil să fiți interesat și de pluginul nostru , despre care am vorbit mai detaliat în .
Raportul resurselor Kubernetes (kube-resource-report)
„Colectați cererile de resurse pentru pod și cluster Kubernetes, comparați-le cu consumul de resurse și generați HTML static.”
generează rapoarte HTML statice privind utilizarea resurselor și distribuția costurilor între echipe/aplicații din clustere. Raportul este oarecum util pentru asistență și răspuns la incident, deoarece vă permite să găsiți rapid clusterul în care este implementată aplicația.
Notă. transl.: Un serviciu și un instrument pot fi, de asemenea, util în vizualizarea informațiilor despre alocarea resurselor și costurile acestora între furnizorii de cloud , pe care o revizuim .
Octant
„O platformă web extensibilă pentru dezvoltatori, concepută pentru a oferi o mai bună înțelegere a complexității clusterelor Kubernetes.”
, creat de VMware, este un produs nou despre care am aflat relativ recent. Cu ajutorul acestuia, este convenabil să explorați clusterul pe o mașină locală (există chiar și vizualizări), dar abordează problemele de asistență și răspuns la incident doar într-o măsură limitată. Dezavantajele Octant:
- Nicio căutare în cluster.
- Funcționează numai pe mașina locală (nu se implementează într-un cluster).
- Nu se pot sorta/filtra obiectele (este acceptat doar selectorul de etichete).
- Nu puteți specifica coloane personalizate.
- Nu puteți lista obiecte după spațiu de nume.
Am avut probleme și cu stabilitatea lui Octant cu clustere Zalando: pe unele CRD-uri .
Vă prezentăm Kubernetes Web View
„kubectl pentru web”.
După ce am analizat opțiunile de interfață disponibile pentru Kubernetes, am decis să creez una nouă: . La urma urmei, de fapt, am nevoie doar de toată puterea kubectl pe web, și anume:
- disponibilitatea tuturor operațiunilor (numai în citire) pentru care utilizatorii preferă să folosească kubectl;
- toate URL-urile trebuie să fie permanente și să reprezinte pagina în forma sa originală, astfel încât colegii să le poată partaja și să le folosească în alte instrumente;
- suport pentru toate obiectele Kubernetes, care vă va permite să rezolvați orice tip de problemă;
- Listele de resurse ar trebui să fie descărcate pentru lucrări ulterioare (în foi de calcul, instrumente CLI precum
grep) și depozitare (de exemplu, pentru autopsie); - suport pentru selectarea resurselor după etichetă (similar cu
kubectl get .. -l); - capacitatea de a crea liste combinate de diferite tipuri de resurse (similar cu
kubectl get all) pentru a obține o imagine operațională comună între colegi (de exemplu, în timpul răspunsului la un incident); - capacitatea de a adăuga legături profunde inteligente personalizate la alte instrumente, cum ar fi tablouri de bord, loggere, registre de aplicații etc. pentru a facilita depanarea/rezolvarea erorilor și răspunsul la incidente;
- Interfața ar trebui să fie cât mai simplă posibil (HTML pur) pentru a evita probleme aleatorii, cum ar fi JavaScript înghețat;
- suport pentru mai multe clustere pentru a simplifica interacțiunea în timpul consultării la distanță (de exemplu, pentru a reține doar un URL);
- Dacă este posibil, analiza situațională ar trebui simplificată (de exemplu, cu link-uri pentru descărcarea resurselor pentru toate clusterele/spațiile de nume);
- oportunități suplimentare pentru crearea de legături flexibile și evidențierea informațiilor text, de exemplu, astfel încât să puteți indica colegii către o anumită secțiune din descrierea resursei (o linie în YAML);
- abilitatea de a personaliza la cerințele unui anumit client, de exemplu, permițându-vă să creați șabloane speciale de afișare pentru CRD-uri, propriile vederi de tabel și să schimbați stilurile CSS;
- instrumente pentru explorarea ulterioară pe linia de comandă (de exemplu, afișarea comenzilor complete
kubectl, gata pentru copiere);
Dincolo de sarcinile rezolvate în Kubernetes Web View (non-goaluri) a ramas:
- abstractizarea obiectelor Kubernetes;
- managementul aplicațiilor (de exemplu, managementul implementării, diagramele Helm etc.);
- operațiuni de scriere (trebuie făcute prin instrumente securizate CI/CD și/sau GitOps);
- interfață frumoasă (JavaScript, teme etc.);
- vizualizare (vezi );
- analiza costurilor (vezi ).
Cum ajută Kubernetes Web View cu asistență și răspuns la incident?
Sprijini
- Toate linkurile sunt permanente, ceea ce facilitează schimbul de informații cu colegii.
- Puteți crea ideile tale, de exemplu, afișați toate implementările și podurile cu o etichetă specifică în două grupuri specifice (mai multe nume de cluster și tipuri de resurse pot fi specificate în link, separate prin virgule).
- Vă puteți referi la linii specifice într-un fișier YAML obiect, indicând probleme potențiale în specificația obiectului.
Căutați după clustere în Kubernetes Web View
Răspuns la incident
- Căutare globală (căutare globală) vă permite să căutați obiecte în toate clusterele.
- Listă de vizualizări poate afișa toate obiectele cu o anumită stare/coloană în toate clusterele (de exemplu, trebuie să găsim toate podurile cu starea „În așteptare”).
- Listele de obiecte pot fi descărcate în format valori separate prin tabulatori (TSV) pentru analiză ulterioară.
- Vă permite să comutați la tablouri de bord asociate și la alte instrumente.
Kubernetes Web View: listă de pod-uri cu starea „În așteptare” în toate clusterele
Dacă doriți să încercați Kubernetes Web View, vă recomand să verificați sau uita-te la .
Desigur, interfața ar putea fi mai bună, dar deocamdată Kubernetes Web View este un instrument pentru „utilizatori avansați” care nu se feresc să manipuleze manual căile URL, dacă este necesar. Dacă aveți comentarii/adăugiri/sugestii, vă rugăm să contactați !
Acest articol este o scurtă istorie a contextului care a dus la crearea Kubernetes Web View. Vor urma mai multe! (Notă. transl.: Ar trebui să fie așteptați în .)
PSde la traducător
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com