ProHoster > Log > administrasjon > Kunngjøring av Kubernetes Web View (og en kort oversikt over andre nettgrensesnitt for Kubernetes)
Kunngjøring av Kubernetes Web View (og en kort oversikt over andre nettgrensesnitt for Kubernetes)
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 Kubernetes WebView — 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 Twitter:
*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 K8Dash, Kubernator и Oktant. 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å."
K8Dash 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 Kubernator. 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, Kubernetes Dashboard 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).
"System Dashboard Observer for K8s Cluster Space."
У Kubernetes operasjonell visning 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 grafana-statuskart, som vi snakket mer om i denne artikkelen.
Kubernetes ressursrapport (kube-ressursrapport)
"Samle pod- og Kubernetes-klyngressursforespørsler, sammenlign dem med ressursforbruk, og generer statisk HTML."
Kubernetes ressursrapport 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 Kubecost, som vi vurderer nylig publisert.
Oktant
"En utvidbar nettplattform for utviklere designet for å gi større forståelse av kompleksiteten til Kubernetes-klynger."
Oktant, 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 han falt.
Vi introduserer Kubernetes Web View
"kubectl for nettet".
Etter å ha analysert de tilgjengelige grensesnittalternativene for Kubernetes, bestemte jeg meg for å lage en ny: Kubernetes WebView. 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);
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.
Kubernetes Web View: liste over pods med «Venter»-status i alle klynger
Hvis du vil prøve Kubernetes Web View, anbefaler jeg å sjekke ut dokumentasjon eller se på live demo.
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 med meg på Twitter!
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 forfatterens blogg.)