🥇Annoncering af Kubernetes Web View-grænsefladen (og en kort oversigt over andre web UI til Kubernetes)

Bem. overs.: Forfatteren af det originale materiale er Henning Jacobs fra Zalando. Han har skabt et nyt webinterface til arbejde med Kubernetes, der præsenteres som 'kubectl til weben'. Læs i hans artikel, hvorfor dette nye open source-projekt er blevet udviklet, og hvilke kriterier eksisterende løsninger ikke lever op til.

I denne publikation undersøger jeg forskellige open source webinterfaces til Kubernetes, præsenterer mine krav til et universelt UI og forklarer, hvorfor jeg udviklede Kubernetes Web View — et interface designet til at lette support og fejlretning på tværs af mange klynger.

Brugsområder

Hos Zalando betjener vi et stort antal Kubernetes-brugere (900+) og klynger (100+). Der er et par typiske brugsområder, hvor en specialiseret webværktøj ville være meget nyttigt:

kommunikation med kolleger i forbindelse med support;
reaktion på hændelser og undersøgelse af deres årsager.

Support

Efter min erfaring ser kommunikationen i forbindelse med support ofte sådan ud:

— Hjælp, vores service XYZ er nede!
— Hvad ser du, når du kører kubectl describe ingress ...?

Eller noget lignende for CRD:

— Jeg har et problem med identitetstjenesten...
— Hvad viser kommandoen kubectl describe platformcredentialsset ...?

Sådan kommunikation fører normalt til indtastning af forskellige variationer af kommandoen kubectl for at forsøge at fastslå problemet. Resultatet er, at begge parter i samtalen konstant skal skifte mellem terminalen og webchatten, og de observerer desuden forskellige situationer.

Derfor ønsker man, at webfrontend'et til Kubernetes skal muliggøre følgende:

brugerne kan dele links og se det samme;
det skulle hjælpe med at undgå menneskelige fejl i supporten: for eksempel at logge ind i den forkerte klynge i kommandolinjen, tastefejl i CLI-kommandoer osv.;
det skulle give mulighed for at generere egne visninger til at sende til kolleger, dvs. tilføje labelkolonner, vise mange ressourcetyper på én side;
ideelt set skal dette webværktøj muliggøre at lave "dybe" links til specifikke sektioner af YAML (for eksempel at pege på en forkert parameter, der forårsager fejl).

Reaktion på hændelser og analyse

At reagere på hændelser i infrastrukturen kræver situational awareness, evnen til at vurdere påvirkningen og at finde mønstre i klynger. Nogle eksempler fra den virkelige verden:

et kritisk produktionsservice oplever problemer, og du skal finde alle Kubernetes-ressourcer efter navn på tværs af alle klynger, for at fejlsøge;
noder begynder at falde om ved skalering, og du skal finde alle pods med status "Pending" på tværs af alle klynger, for at vurdere omfanget af problemet;
enkeltbrugere rapporterer om et problem med DaemonSet, der er implementeret i alle klynger, og det er nødvendigt at finde ud af, om problemet er omfattende.

Min standardløsning i sådanne tilfælde er noget i retning af for i in $clusters; do kubectl ...; done. Det er klart, at man kan udvikle et værktøj, der giver lignende muligheder.

Eksisterende webgrænseflader til Kubernetes

Open Source-verdenen af webgrænseflader til Kubernetes er ikke særlig stor*, så jeg prøvede at samle yderligere information ved hjælp af Twitter:

* Min forklaring på det begrænsede antal webgrænseflader til Kubernetes: cloud-tjenester og Kubernetes-leverandører tilbyder normalt deres egne frontend-løsninger, så markedet for "gode" gratis Kubernetes-UI'er er relativt lille.

Ved hjælp af et tweet lærte jeg om K8Dash, Kubernator og Octant. Lad os kigge på dem og andre eksisterende Open Source-løsninger og forsøge at forstå, hvad de indebærer.

K8Dash

"K8Dash er den nemmeste måde at administrere et Kubernetes-klynge på."

K8Dash ser godt ud og føles hurtigt, men har nogle mangler til de ovenfor nævnte anvendelsesscenarier:

Fungerer kun inden for en enkelt klynge.
Sortering og filtrering er mulige, men har ikke permanente links.
Manglende understøttelse af Custom Resource Definitions (CRDs).

Kubernator

"Kubernator er en alternativ UI til Kubernetes. I modsætning til den høj-niveau panel Kubernetes Dashboard, giver det lav-niveau kontrol og en fremragende oversigt over alle objekter i klyngen med mulighed for at oprette nye, redigere dem og løse konflikter. Da det er en fuldstændig klient-applikation (ligesom kubectl), kræver det ikke en backend undtagen selve API-serveren for Kubernetes, og det tager også højde for adgangsreglerne i klyngen."

Det er en ret præcis beskrivelse af Kubernator.Desværre mangler det nogle funktioner:

Betjener kun en enkelt klynge.
Der er ikke nogen listevisning (dvs. man kan ikke vise alle pods med status "Pending").

Kubernetes Dashboard

"Kubernetes Dashboard er et alsidigt webinterface til Kubernetes-klynger. Det giver brugerne mulighed for at administrere applikationer, der kører i klyngen, og fejlfinde dem samt administrere selve klyngen."

Desværre, Kubernetes Dashboard det hjælper ikke meget med mine aktiviteter inden for support og hændelsesrespons, fordi det har:

ingen permanente links, f.eks. når jeg filtrerer ressourcer eller ændrer sorteringsrækkefølgen;
ingen nem måde at filtrere efter status — for eksempel se alle pods med status "Pending";
kun én klynge understøttes;
CRD understøttes ikke (denne funktion er under udvikling);
ingen brugerdefinerede kolonner (f.eks. kolonner med etiketter som kubectl -L).

Kubernetes Operational View (kube-ops-view)

"Systemoversigt over K8s-klusterområdet."

Ved Kubernetes Operational View har en helt anden tilgang: dette værktøj viser kun cluster-noder og pods ved hjælp af WebGL, uden nogen tekstlige detaljer om objekterne. Det er ideelt til en hurtig oversigt over clusterets tilstand ("faldt pods?")*, men ikke egnet til de ovenfor beskrevne anvendelsestilfælde inden for support og hændelsesrespons.

* Bem. overs.: I denne forbindelse kan du også være interesseret i vores plugin grafana-statusmap, som vi har beskrevet nærmere i denne artikel.

Kubernetes Resource Report (kube-resource-report)

"Samler oplysninger om ressourceanmodninger for pods og Kubernetes-klyngen, sammenligner dem med ressourceforbruget og genererer statisk HTML."

Kubernetes Ressourcerapport genererer statiske HTML-rapporter om ressourceforbrug og omkostningsfordeling på tværs af teams/applikationer i klynger. Rapporten er i nogen grad nyttig til support og hændelsesrespons, da det muliggør hurtigere at finde den klynge, hvor applikationen er implementeret.

Bem. overs.: Ved visningen af oplysninger om ressourcefordeling og deres omkostninger kan der også vise sig at være nyttigt en tjeneste og et værktøj Kubecost, hvis oversigt vi for nylig offentliggjorde.

Octant

"En udvidelig webplatform for udviklere, designet til at give bedre forståelse af kompleksiteten i Kubernetes-klynger."

Octant, skabt i VMware, — et nyt produkt, som jeg først har lært om for nylig. Det er praktisk at udforske klyngen på en lokal maskine (der er endda visualiseringer), men det adresserer kun begrænset problematikken omkring support og reaktion på hændelser. Ulemper ved Octant:

Ingen søgning på klynger.
Fungerer kun på en lokal maskine (kan ikke implementeres i klyngen).
Det er ikke muligt at sortere/filtere objekter (kun labels-selektor understøttes).
Mulighed for at angive brugerdefinerede kolonner mangler.
Det er ikke muligt at vise objektlister efter navnerum.

Jeg har også haft problemer med stabiliteten af Octant med Zalando-klynger: med nogle CRD den faldt..

Jeg præsenterer Kubernetes Web View

«kubectl til web».

Efter at have analyseret de tilgængelige interface muligheder for Kubernetes, besluttede jeg at skabe en ny: Kubernetes Web View. For i bund og grund har jeg kun brug for al kraften kubectl i web, nemlig:

tilgængelighed af alle (læse-only) operationer, hvor brugerne foretrækker at bruge kubectl;
alle URL'er skal være permanente og repræsentere siden i original form, så kolleger kan dele dem og bruge dem i andre værktøjer;
understøttelse af alle Kubernetes-objekter, så enhver type problem kan løses;
ressourcelister skal være downloadbare til videre bearbejdning (i regneark, CLI-værktøjer som grep) og opbevaring (f.eks. til postmortems);
understøttelse af filtrering af ressourcer efter labels (som i kubectl get .. -l);
mulighed for at oprette sammenlagte lister over forskellige typer ressourcer (som i kubectl get all) for at få et samlet operativt billede blandt kolleger (f.eks. i forbindelse med hændelsesreaktion);
mulighed for at tilføje tilpassede «smarte» dybe links til andre værktøjer som dashboards, loggere, applikationsregistre osv. for at lette søgning/fejlfinding og hændelsesreaktion;
frontend skal være ekstremt simpel (ren HTML) for at undgå utilsigtede problemer, f.eks. hængende JavaScript;
understøttelse af mange klynger for at gøre interaktionen lettere ved fjernrådgivning (f.eks. for kun at skulle huske én URL);
situationsanalyse skal forenkles, hvis muligt (f.eks. med links til download af ressourcer på tværs af alle klynger/navnerum);
yderligere funktioner til at danne fleksible links og fremhæve tekstinformation, for eksempel så man kan pege kolleger mod et bestemt afsnit i ressourcebeskrivelsen (en række i YAML);
mulighed for tilpasning til krav fra bestemte kunder, for eksempel ved at tillade oprettelse af specialfremstillede visningsskabeloner for CRD, egne tabelvisninger, ændring af CSS-stile;
midler til videre undersøgelse i kommandolinjen (for eksempel ved at vise komplette kommandoer kubectl, klar til kopiering);

Udover opgaver som løses i Kubernetes Web View (non-goals) forbliver:

abstraktion af Kubernetes-objekter;
applikationsstyring (for eksempel styring af deployment’er, Helm-diagrammer osv.);
skrivningsoperationer (skal udføres gennem sikre CI/CD-værktøjer og/eller GitOps);
flot grænseflade (JavaScript, temaer osv.);
visualiseringer (se. kube-ops-view);
omkostningsanalyse (se. kube-resource-report).

Hvordan hjælper Kubernetes Web View med support og respons på hændelser?

Support

Alle links er permanente, hvilket letter informationsdeling med kolleger.
Man kan oprette sine visninger, for eksempel at vise alle Deployment’er og Pod’er med en bestemt etiket i to specifikke klynger (flere klynge navne og ressource typer kan angives i linket, adskilt af kommaer).
Man kan henvise til bestemte linjer i YAML-filen af objektet, der peger på potentielle problemer i objektets specifikation.

Søgning i klynger i Kubernetes Web View

Reaktion på hændelser

Global søgning (global search) giver mulighed for at søge efter objekter i alle klynger.
Listerede visninger kan vise alle objekter med en bestemt tilstand/kolonne i alle klynger (for eksempel, hvis vi skal finde alle pod’er med status «Pending»).
Objekter kan downloades i TSV-format (tab-separated values) til efterfølgende analyse.
Tilpassede eksterne links gør det muligt at skifte til de relevante overvågningspaneler og andre værktøjer.

Kubernetes Web View: liste over pod’er med status «Pending» i alle klynger

Hvis du ønsker at prøve Kubernetes Web View, anbefaler jeg at se på dokumentation eller se på den live demo-version.

Selvfølgelig kunne grænsefladen være bedre, men indtil videre er Kubernetes Web View et værktøj for "avancerede brugere", der ikke er bange for at manipulere URL-stier manuelt, hvis nødvendigt. Hvis du har kommentarer / tilføjelser / ønsker, så kontakt mig på Twitter!

Denne artikel er en kort fortælling om forudsætningerne, der førte til skabelsen af Kubernetes Web View. Flere følger! (Bem. overs.: De bør forventes i forfatterens blog.)