Merk. overs.: Forfatteren av originalmaterialet er Henning Jacobs fra Zalando. Han opprettet et nytt nettgrensesnitt for å jobbe med Kubernetes, som er posisjonert som "kubectl for nettet." Hvorfor et nytt Open Source-prosjekt dukket opp og hvilke kriterier ikke ble oppfylt av eksisterende løsninger - les artikkelen hans.
I dette innlegget gjennomgår jeg de forskjellige Kubernetes-nettgrensesnittene med åpen kildekode, legger opp kravene mine til et universelt brukergrensesnitt og forklarer hvorfor jeg utviklet — et grensesnitt designet for å gjøre det enklere å støtte og feilsøke flere klynger samtidig.
Brukssaker
Hos Zalando betjener vi et stort antall Kubernetes-brukere (900+) og klynger (100+). Det er et par vanlige brukstilfeller som vil ha nytte av et dedikert nettverktøy:
- kommunikasjon med kolleger for støtte;
- reagere på hendelser og undersøke årsakene deres.
Støtte
Etter min erfaring ser støttekommunikasjon ofte slik ut:
— Hjelp, vår tjeneste XYZ er utilgjengelig!
— Hva ser du når du opptrer kubectl describe ingress ...?
Eller noe lignende for CRD:
— Jeg har et problem med identifikasjonstjenesten...
— Hva produserer kommandoen? kubectl describe platformcredentialsset ...?
Slik kommunikasjon kommer vanligvis ned til å legge inn ulike varianter av kommandoen kubectl for å identifisere problemet. Som et resultat blir begge parter i samtalen tvunget til hele tiden å bytte mellom terminalen og nettchatten, pluss at de observerer en annen situasjon.
Derfor vil jeg at Kubernetes nettgrensesnitt skal tillate følgende:
- brukere kunne utveksle lenker og observer det samme;
- ville hjelpe unngå menneskelige feil i støtte: for eksempel å logge på feil klynge på kommandolinjen, skrivefeil i CLI-kommandoer osv.;
- ville tillate generere dine egne synspunkter å sende til kolleger, det vil si legge til kolonner med tagger, vise mange typer ressurser på én side;
- Ideelt sett bør dette nettverktøyet tillate deg å sette "dyp" lenker til spesifikke deler av YAML (for eksempel å peke på en feil parameter som forårsaker feil).
Hendelsesrespons og analyse
Å reagere på infrastrukturhendelser krever situasjonsbevissthet, evne til å vurdere påvirkning og se etter mønstre i klynger. Noen eksempler fra det virkelige liv:
- En kritisk produksjonstjeneste har problemer, og du trenger det finn alle Kubernetes-ressurser etter navn i alle klyngerå feilsøke;
- noder begynner å falle når skalering og du trenger finn alle pods med statusen «Venter» i alle klyngerå vurdere omfanget av problemet;
- individuelle brukere rapporterer et problem med DaemonSet distribuert på tvers av alle klynger og må finne ut av det Er problemet totalt?.
Min standardløsning i slike tilfeller er noe sånt som for i in $clusters; do kubectl ...; done. Det er åpenbart mulig å utvikle et verktøy som gir lignende muligheter.
Eksisterende Kubernetes-nettgrensesnitt
Den åpne kildekodeverdenen av nettgrensesnitt til Kubernetes er ikke særlig stor*, så jeg prøvde å samle inn mer informasjon ved å bruke :
*Min forklaring på det begrensede antallet nettgrensesnitt for Kubernetes: skytjenester og Kubernetes-leverandører tilbyr vanligvis sine egne grensesnitt, så markedet for "gode" gratis Kubernetes-grensesnitt er relativt lite.
Gjennom en tweet fikk jeg vite om , и . La oss se på dem og andre eksisterende Open Source-løsninger, la oss prøve å forstå hva de er.
K8Dash
"K8Dash er den enkleste måten å administrere en Kubernetes-klynge på."
Ser bra ut og føles raskt, men har en rekke ulemper for brukstilfellene som er oppført ovenfor:
- Fungerer bare innenfor grensene til én klynge.
- Sortering og filtrering er mulig, men har ikke permalinker.
- Det er ingen støtte for Custom Resource Definitions (CRD-er).
Kubernator
"Kubernator er et alternativt brukergrensesnitt for Kubernetes. I motsetning til Kubernetes Dashboard på høyt nivå, gir det kontroll på lavt nivå og utmerket synlighet til alle objekter i klyngen med muligheten til å lage nye, redigere dem og løse konflikter. Siden den er en helt klientsideapplikasjon (som kubectl), krever den ingen annen backend enn selve Kubernetes API-serveren, og respekterer også klyngetilgangsregler.
Dette er en ganske nøyaktig beskrivelse . Dessverre mangler den noen funksjoner:
- Betjener kun én klynge.
- Det er ingen listevisningsmodus (dvs. du kan ikke vise alle pods med «Venter»-status).
Kubernetes Dashboard
"Kubernetes Dashboard er et universelt nettgrensesnitt for Kubernetes-klynger. Den lar brukere administrere og feilsøke applikasjoner som kjører i en klynge, samt administrere klyngen selv."
Dessverre, hjelper egentlig ikke med mine støtte- og hendelsesresponsaktiviteter fordi det:
- det er ingen permanente lenker, for eksempel når jeg filtrerer ressurser eller endrer sorteringsrekkefølgen;
- det er ingen enkel måte å filtrere etter status - se for eksempel alle pods med statusen "Venter";
- bare én klynge støttes;
- CRD-er støttes ikke (denne funksjonen er under utvikling);
- ingen egendefinerte kolonner (for eksempel kolonner merket etter type
kubectl -L).
Kubernetes operasjonell visning (kube-ops-visning)
"System Dashboard Observer for K8s Cluster Space."
У En helt annen tilnærming: dette verktøyet viser bare klyngenoder og poder ved hjelp av WebGL, uten noen tekstobjektdetaljer. Det er flott for en rask oversikt over klyngens helse (faller pods?)*, men det er ikke egnet for brukstilfellene for støtte og hendelsesrespons beskrevet ovenfor.
* Merk. overs.: I denne forstand kan du også være interessert i vår plugin , som vi snakket mer om i .
Kubernetes ressursrapport (kube-ressursrapport)
"Samle pod- og Kubernetes-klyngressursforespørsler, sammenlign dem med ressursforbruk, og generer statisk HTML."
genererer statiske HTML-rapporter om ressursbruk og kostnadsfordeling på tvers av team/applikasjoner i klynger. Rapporten er noe nyttig for støtte og hendelsesrespons fordi den lar deg raskt finne klyngen der applikasjonen er distribuert.
Merk. overs.: En tjeneste og et verktøy kan også være nyttig for å se informasjon om allokering av ressurser og deres kostnader blant skyleverandører , som vi vurderer .
Oktant
"En utvidbar nettplattform for utviklere designet for å gi større forståelse av kompleksiteten til Kubernetes-klynger."
, laget av VMware, er et nytt produkt som jeg lærte om relativt nylig. Med dens hjelp er det praktisk å utforske klyngen på en lokal maskin (det er til og med visualiseringer), men det tar kun opp problemer med støtte og hendelsesrespons i begrenset grad. Ulemper med oktant:
- Ingen klyngesøk.
- Fungerer bare på den lokale maskinen (distribueres ikke til en klynge).
- Kan ikke sortere/filtrere objekter (bare etikettvelger støttes).
- Du kan ikke spesifisere egendefinerte kolonner.
- Du kan ikke liste objekter etter navneområde.
Jeg hadde også problemer med stabiliteten til Octant med Zalando-klynger: på noen CRD-er .
Vi introduserer Kubernetes Web View
"kubectl for nettet".
Etter å ha analysert de tilgjengelige grensesnittalternativene for Kubernetes, bestemte jeg meg for å lage en ny: . Tross alt, faktisk trenger jeg bare all kraften kubectl på nettet, nemlig:
- tilgjengelighet for alle (skrivebeskyttede) operasjoner som brukere foretrekker å bruke kubectl for;
- alle nettadresser må være permanente og representere siden i sin opprinnelige form slik at kolleger kan dele dem og bruke dem i andre verktøy;
- støtte for alle Kubernetes-objekter, som lar deg løse alle typer problemer;
- ressurslister bør være nedlastbare for videre arbeid (i regneark, CLI-verktøy som
grep) og lagring (for eksempel for postmortem); - støtte for valg av ressurser etter etikett (ligner på
kubectl get .. -l); - muligheten til å lage kombinerte lister over ulike typer ressurser (ligner på
kubectl get all) for å få et felles operasjonsbilde blant kolleger (for eksempel under en hendelsesrespons); - muligheten til å legge til tilpassede smarte dyplenker til andre verktøy som dashbord, loggere, applikasjonsregistre, etc. for å lette feilsøking/løsning av feil og svare på hendelser;
- Frontend bør være så enkelt som mulig (ren HTML) for å unngå tilfeldige problemer, for eksempel frossen JavaScript;
- støtte for flere klynger for å forenkle interaksjon under ekstern rådgivning (for eksempel for å huske bare én URL);
- Om mulig bør situasjonsanalyse forenkles (for eksempel med lenker for å laste ned ressurser for alle klynger/navnerom);
- ytterligere muligheter for å lage fleksible lenker og fremheve tekstinformasjon, for eksempel, slik at du kan peke kolleger til en bestemt del i ressursbeskrivelsen (en linje i YAML);
- muligheten til å tilpasse til kravene til en spesifikk klient, for eksempel, slik at du kan lage spesielle visningsmaler for CRD-er, dine egne tabellvisninger og endre CSS-stiler;
- verktøy for videre utforskning på kommandolinjen (for eksempel vise fullstendige kommandoer
kubectl, klar for kopiering);
Utover oppgavene som er løst i Kubernetes Web View (ikke-mål) ble igjen:
- abstraksjon av Kubernetes-objekter;
- applikasjonsadministrasjon (for eksempel distribusjonsadministrasjon, Helm-diagrammer, etc.);
- skriveoperasjoner (må gjøres gjennom sikre CI/CD og/eller GitOps-verktøy);
- vakkert grensesnitt (JavaScript, temaer, etc.);
- visualisering (se );
- kostnadsanalyse (se ).
Hvordan hjelper Kubernetes Web View med støtte og hendelsesrespons?
Støtte
- Alle lenker er permanente, som gjør det lettere å utveksle informasjon med kolleger.
- Du kan lage dine ideer, for eksempel, vis alle distribusjoner og poder med en spesifikk etikett i to spesifikke klynger (flere klyngenavn og ressurstyper kan spesifiseres i koblingen, atskilt med komma).
- Du kan henvise til spesifikke linjer i en YAML-fil objekt, som indikerer potensielle problemer i objektspesifikasjonen.
Søk etter klynger i Kubernetes Web View
Hendelsesrespons
- Globalt søk (globalt søk) lar deg søke etter objekter i alle klynger.
- Listevisninger kan vise alle objekter med en bestemt tilstand/kolonne i alle klynger (for eksempel må vi finne alle pods med statusen «Venter»).
- Lister over objekter kan lastes ned i TSV-format (tab-separated value) for senere analyse.
- Lar deg bytte til relaterte instrumentbord og andre verktøy.
Kubernetes Web View: liste over pods med «Venter»-status i alle klynger
Hvis du vil prøve Kubernetes Web View, anbefaler jeg å sjekke ut eller se på .
Selvfølgelig kan grensesnittet vært bedre, men foreløpig er Kubernetes Web View et verktøy for "avanserte brukere" som ikke viker unna å manipulere URL-baner manuelt om nødvendig. Hvis du har kommentarer/tilføyelser/forslag, ta kontakt !
Denne artikkelen er en kort historie om bakgrunnen som førte til opprettelsen av Kubernetes Web View. Flere vil følge! (Merk. overs.: De bør forventes i .)
PS fra oversetteren
Les også på bloggen vår:
- «";
- «";
- «";
- «'.
Kilde: www.habr.com