Notu. transl.: La aŭtoro de la originala materialo estas Henning Jacobs el Zalando. Li kreis novan retan interfacon por labori kun Kubernetes, kiu estas poziciigita kiel "kubectl por la reto". Kial aperis nova Open Source projekto kaj kiajn kriteriojn ne plenumis ekzistantaj solvoj - legu lian artikolon.
En ĉi tiu afiŝo, mi revizias la diversajn malfermfontajn interfacojn de Kubernetes, prezentas miajn postulojn por universala UI kaj klarigas kial mi disvolvis - interfaco desegnita por faciligi subteni kaj solvi problemojn de pluraj aretoj samtempe.
Uzkazoj
Ĉe Zalando ni servas grandan nombron da uzantoj de Kubernetes (900+) kaj aretoj (100+). Estas kelkaj oftaj uzkazoj, kiuj profitus el dediĉita interreta ilo:
- komunikado kun kolegoj por subteno;
- respondi al okazaĵoj kaj esplori iliajn kaŭzojn.
subteno
Laŭ mia sperto, subtenaj komunikadoj ofte aspektas jene:
— Helpu, nia servo XYZ estas neatingebla!
— Kion vi vidas kiam vi plenumas kubectl describe ingress ...?
Aŭ io simila por CRD:
— Mi havas iun problemon kun la identiga servo...
— Kion produktas la komando? kubectl describe platformcredentialsset ...?
Tia komunikado kutime signifas enigi diversajn variaĵojn de la komando kubectl por identigi la problemon. Kiel rezulto, ambaŭ partioj al la konversacio estas devigitaj konstante ŝanĝi inter la terminalo kaj la retbabilejo, krome ili observas malsaman situacion.
Tial mi ŝatus, ke la interreta fasado de Kubernetes permesu la jenon:
- uzantoj povus interŝanĝi ligilojn kaj observu la samon;
- helpus eviti homajn erarojn en subteno: ekzemple, ensaluti en la malĝusta areto sur la komandlinio, tajperaroj en CLI-komandoj, ktp.;
- permesus generi viajn proprajn vidojn sendi al kolegoj, tio estas, aldoni kolumnojn de etikedoj, montri multajn specojn de rimedoj sur unu paĝo;
- Ideale, ĉi tiu retejo-ilo devus ebligi al vi agordi "profundaj" ligoj al specifaj sekcioj de YAML (ekzemple, atentigante malĝustan parametron, kiu kaŭzas malsukcesojn).
Okazaĵrespondo kaj analizo
Respondi al infrastrukturaj okazaĵoj postulas situacian konscion, la kapablon taksi efikon, kaj serĉi ŝablonojn en aretoj. Kelkaj realaj ekzemploj:
- Kritika produktadservo havas problemojn kaj vi bezonas trovi ĉiujn Kubernetes-resursojn laŭnome en ĉiuj aretojsolvi problemojn;
- nodoj komencas fali dum grimpado kaj vi bezonas trovi ĉiujn podojn kun la statuso "Atendante" en ĉiuj aretojtaksi la amplekson de la problemo;
- individuaj uzantoj raportas problemon kun DaemonSet deplojita tra ĉiuj aretoj kaj bezonas eltrovi Ĉu la problemo estas totala?.
Mia norma solvo en tiaj kazoj estas io simila for i in $clusters; do kubectl ...; done. Evidente, eblas evoluigi ilon kiu provizas similajn kapablojn.
Ekzistantaj interfacoj de Kubernetes
La malfermfonta mondo de retinterfacoj al Kubernetes ne estas tre granda*, do mi provis kolekti pli da informoj uzante :
*Mia klarigo pri la limigita nombro da TTT-interfacoj por Kubernetes: nubaj servoj kaj Kubernetes-vendistoj kutime ofertas siajn proprajn fasadojn, do la merkato por "bona" senpaga Kubernetes UI estas relative malgranda.
Per tweet mi eksciis , и . Ni rigardu ilin kaj aliajn ekzistantajn Malfermfontajn solvojn, ni provu kompreni, kio ili estas.
K8 Dash
"K8Dash estas la plej simpla maniero administri Kubernetes-grupon."
Aspektas bone kaj sentiĝas rapide, sed havas kelkajn malavantaĝojn por la uzkazoj listigitaj supre:
- Funkcias nur ene de la limoj de unu areto.
- Ordigo kaj filtrado eblas, sed ne havas konstantajn ligilojn.
- Ne ekzistas subteno por Propraj Rimedaj Difinoj (CRDs).
Kubernatoro
"Kubernator estas alternativa UI por Kubernetes. Male al la altnivela Kubernetes Dashboard, ĝi provizas malaltnivelan kontrolon kaj bonegan videblecon en ĉiuj objektoj en la areto kun la kapablo krei novajn, redakti ilin kaj solvi konfliktojn. Estante tute klientflanka aplikaĵo (kiel kubectl), ĝi ne postulas ajnan backend krom la Kubernetes API-servilo mem, kaj ankaŭ respektas la regulojn de aliro al grapo.
Ĉi tio estas sufiĉe preciza priskribo . Bedaŭrinde, al ĝi mankas iuj funkcioj:
- Servas nur unu areton.
- Ne ekzistas listvida reĝimo (t.e., vi ne povas montri ĉiujn podojn kun la "Atendata" statuso).
Kubernetes Panelo
"Kubernetes Dashboard estas universala retinterfaco por Kubernetes-grupoj. Ĝi permesas al uzantoj administri kaj solvi problemojn pri aplikaĵoj kurantaj en areto, kaj ankaŭ administri la areton mem."
Bedaŭrinde, ne vere helpas kun miaj subtenaj kaj okazaĵaj respondaj agadoj ĉar ĝi:
- ne ekzistas konstantaj ligiloj, ekzemple kiam mi filtras rimedojn aŭ ŝanĝas la ordigon;
- ne estas facila maniero filtri laŭ stato - ekzemple, vidu ĉiujn podojn kun la stato "Atendata";
- nur unu areto estas subtenata;
- CRD-oj ne estas subtenataj (ĉi tiu funkcio estas evoluinta);
- neniuj kutimaj kolumnoj (kiel ekzemple kolumnoj etikeditaj laŭ tipo
kubectl -L).
Kubernetes Operacia Vido (kube-ops-view)
"Sistema Dashboard Observer por K8s Cluster Space."
У Tute malsama aliro: ĉi tiu ilo nur montras grapolnodojn kaj podojn uzante WebGL, sen iuj tekstaj objektodetaloj. Ĝi estas bonega por rapida superrigardo de la sano de la areto (ĉu guŝoj falas?)*, sed ĝi ne taŭgas por la uzkazoj de subteno kaj okazaĵrespondo priskribitaj supre.
* Notu. transl.: Tiusence, vi ankaŭ eble interesiĝos pri nia kromaĵo , pri kiu ni parolis pli detale en .
Kubernetes Rimeda Raporto (kube-resource-report)
"Kolektu petojn pri rimedo de pod kaj Kubernetes-grupo, komparu ilin kun konsumo de rimedoj kaj generu senmovan HTML."
generas senmovajn HTML-raportojn pri uzado de rimedoj kaj kostdistribuo tra teamoj/aplikoj en aretoj. La raporto estas iom utila por subteno kaj okazaĵrespondo ĉar ĝi permesas vin rapide trovi la areton kie la aplikaĵo estas deplojita.
Notu. transl.: Servo kaj ilo ankaŭ povas esti utilaj por vidi informojn pri la asigno de resursoj kaj iliaj kostoj inter nubaj provizantoj. , kiun ni revizias .
Octant
"Etendebla retejo-platformo por programistoj desegnita por doni pli grandan komprenon pri la komplekseco de Kubernetes-grupoj."
, kreita de VMware, estas nova produkto pri kiu mi lernis relative lastatempe. Kun ĝia helpo, estas oportune esplori la areton sur loka maŝino (ekzistas eĉ bildigoj), sed ĝi traktas la temojn de subteno kaj incidenta respondo nur en limigita mezuro. Malavantaĝoj de Octant:
- Neniu grupserĉo.
- Funkcias nur sur la loka maŝino (ne deplojiĝas al areto).
- Ne povas ordigi/filtri objektojn (nur etikedelektilo estas subtenata).
- Vi ne povas specifi kutimajn kolumnojn.
- Vi ne povas listigi objektojn laŭ nomspaco.
Mi ankaŭ havis problemojn pri la stabileco de Octant kun Zalando-grupoj: ĉe kelkaj CRD-oj .
Prezentante Kubernetes Web View
"kubectl por la reto".
Analizinte la disponeblajn interfacajn opciojn por Kubernetes, mi decidis krei novan: . Post ĉio, fakte, mi nur bezonas la tutan potencon kubectl en la reto, nome:
- havebleco de ĉiuj (nurlegeblaj) operacioj por kiuj uzantoj preferas uzi kubectl;
- ĉiuj URL-oj devas esti konstantaj kaj reprezenti la paĝon en ĝia originala formo, por ke kolegoj povu kunhavigi ilin kaj uzi ilin en aliaj iloj;
- subteno por ĉiuj Kubernetes-objektoj, kiuj permesos al vi solvi ajnan tipon de problemo;
- rimedlistoj devus esti elŝuteblaj por plua laboro (en kalkultabeloj, CLI-iloj kiel
grep) kaj konservado (ekzemple, por postmortems); - subteno por elektado de rimedoj per etikedo (simila al
kubectl get .. -l); - la kapablo krei kombinitajn listojn de diversaj specoj de rimedoj (similaj al
kubectl get all) akiri komunan funkcian bildon inter kolegoj (ekzemple, dum incidenta respondo); - la kapablo aldoni kutimajn inteligentajn profundajn ligilojn al aliaj iloj kiel instrumentpaneloj, registriloj, aplikaĵaj registroj ktp. faciligi problemojn/solvi erarojn kaj respondi al okazaĵoj;
- La fasado estu kiel eble plej simpla (pura HTML) por eviti hazardajn problemojn, kiel frostigitan JavaScript;
- subteno por multoblaj aretoj por simpligi interagadon dum fora konsultado (ekzemple, por memori nur unu URL);
- Se eble, situacia analizo devus esti simpligita (ekzemple, kun ligiloj por elŝuti rimedojn por ĉiuj aretoj/nomspacoj);
- kromaj ŝancoj por krei flekseblajn ligilojn kaj reliefigi tekstajn informojn, ekzemple, por ke vi povu indiki kolegojn al specifa sekcio en la priskribo de rimedoj (linio en YAML);
- la kapablo personecigi al la postuloj de specifa kliento, ekzemple, permesante al vi krei specialajn ekranŝablonojn por CRD-oj, viajn proprajn tabelajn vidojn kaj ŝanĝi CSS-stilojn;
- iloj por plia esplorado sur la komandlinio (ekzemple, montrante plenajn komandojn
kubectl, preta por kopiado);
Preter la taskoj solvitaj en Kubernetes Web View (ne-celoj) restis:
- abstraktado de Kubernetes-objektoj;
- administrado de aplikaĵoj (ekzemple, administrado de deplojo, Helm-diagramoj, ktp.);
- skribi operaciojn (devas esti faritaj per sekuraj CI/KD kaj/aŭ GitOps-iloj);
- bela interfaco (JavaScript, temoj, ktp.);
- bildigo (vidu );
- analizo de kostoj (vidu ).
Kiel Kubernetes Web View helpas kun subteno kaj incidenta respondo?
subteno
- Ĉiuj ligiloj estas konstantaj, kiu faciligas interŝanĝi informojn kun kolegoj.
- Vi povas krei viajn ideojn, ekzemple, montru ĉiujn Deplojojn kaj Pods kun specifa etikedo en du specifaj aretoj (pluraj aretnomoj kaj rimedotipoj povas esti specifitaj en la ligilo, apartigitaj per komoj).
- Vi povas rilati al specifaj linioj en YAML-dosiero objekto, indikante eblajn problemojn en la objektospecifo.
Serĉu per aretoj en Kubernetes Web View
Okazaĵo-Respondo
- Tutmonda serĉo (tutmonda serĉo) permesas serĉi objektojn en ĉiuj aretoj.
- Listo Vidoj povas montri ĉiujn objektojn kun certa stato/kolumno en ĉiuj aretoj (ekzemple, ni devas trovi ĉiujn podojn kun la statuso "Atendante").
- Listo de objektoj estas elŝuteblaj en klapeta-separata valoro (TSV) formato por pli posta analizo.
- Ebligas al vi ŝanĝi al rilataj paneloj kaj aliaj iloj.
Kubernetes Web View: listo de podoj kun "Atendata" statuso en ĉiuj aretoj
Se vi volas provi Kubernetes Web View, mi rekomendas kontroli aŭ rigardu .
Kompreneble, la interfaco povus esti pli bona, sed nuntempe Kubernetes Web View estas ilo por "altnivelaj uzantoj", kiuj ne evitas manipuli URL-vojojn permane se necese. Se vi havas komentojn/aldonojn/sugestojn, bonvolu kontakti !
Ĉi tiu artikolo estas mallonga historio de la fono kiu kaŭzis la kreadon de Kubernetes Web View. Pli sekvos! (Notu. transl.: Oni devus atendi ilin en .)
PSde la tradukisto
Legu ankaŭ en nia blogo:
- «»;
- «»;
- «»;
- «".
fonto: www.habr.com