🥇Tillkännagivande av Kubernetes Web View gränssnittet (och en kort översyn av andra web UI för Kubernetes)

Obs. övers.: Den ursprungliga artikelförfattaren är Henning Jacobs från Zalando. Han har skapat ett nytt webbgränssnitt för att arbeta med Kubernetes, som marknadsförs som "kubectl för webben". Läs hans artikel för att ta reda på varför detta nya Open Source-projekt har dykt upp och vilka kriterier som inte uppfylldes av de befintliga lösningarna.

I denna publikation behandlar jag olika webbgränssnitt för Kubernetes med öppen källkod, presenterar mina krav på en universell UI och berättar varför jag utvecklade Kubernetes Web View — ett gränssnitt som syftar till att underlätta stöd och felsökning i flera kluster samtidigt.

Användningsscenarier

På Zalando betjänar vi ett stort antal Kubernetes-användare (över 900) och kluster (över 100). Det finns ett par typiska användningsscenarier där en specialiserad webbverktyg skulle vara mycket användbar:

kommunikation med kollegor inom supporten;
reaktion på incidenter och utredning av deras orsaker.

Support

Enligt min erfarenhet ser kommunikationen inom supporten ofta ut som följer:

— hjälp, vår tjänst XYZ är otillgänglig!
— Vad ser du när du kör kubectl describe ingress ...?

Eller något liknande för CRD:

— Jag har ett problem med identifieringstjänsten...
— Vad ger kommandot kubectl describe platformcredentialsset ...?

Sådan kommunikation handlar vanligtvis om att skriva in olika varianter av kommandot kubectl för att etablera problemet. Resultatet är att båda parter i samtalet ständigt måste växla mellan terminalen och webbchatten, och de ser olika situationer.

Därför önskar jag att webbfronten för Kubernetes skulle möjliggöra följande:

användare skulle kunna dela länkar och se samma sak;
hjälpa till att undvika mänskliga misstag i supporten: till exempel att logga in i fel kluster i kommandoraden, stavfel i CLI-kommandon osv.;
skulle möjliggöra att generera egna vyer för att skicka till kollegor, det vill säga att lägga till etikettkolumner, visa flera typer av resurser på en och samma sida;
idealiskt bör detta webbverktyg möjliggöra att sätta "djupa" länkar till specifika delar av YAML (till exempel peka på en felaktig parameter som orsakar krascher).

Reaktion på incidenter och analys

Reagering på incidenter i infrastrukturen kräver situationsmedvetenhet, förmåga att bedöma påverkan och leta efter mönster i kluster. Några verkliga exempel:

ett kritiskt produktionssystem har problem och du behöver hitta alla Kubernetes-resurser efter namn i alla kluster, för att åtgärda problem;
noder börjar falla vid skalning och du behöver hitta alla poddar med status "Pending" i alla kluster, för att bedöma omfattningen av problemet;
individuella användare rapporterar ett problem med DaemonSet som är distribuerat i alla kluster och det behöver utredas, om problemet är omfattande.

Min standardlösning i sådana fall är något i stil med for i in $clusters; do kubectl ...; done. Uppenbarligen kan ett verktyg utvecklas som erbjuder liknande möjligheter.

Befintliga webbgränssnitt för Kubernetes

Öppen källkod-världen av webbgränssnitt för Kubernetes är inte så stor*, så jag försökte samla mer information med hjälp av Twitter:

* Min förklaring av det begränsade antalet webbgränssnitt för Kubernetes: Molntjänster och Kubernetes-leverantörer erbjuder ofta sina egna gränssnitt, så marknaden för "bra" gratis Kubernetes UI är relativt liten.

Genom en tweet fick jag veta om K8Dash, Kubernator och Octant. Låt oss titta på dem och andra befintliga Open Source-lösningar, och försöka förstå vad de handlar om.

K8Dash

"K8Dash är det enklaste sättet att hantera ett Kubernetes-kluster."

K8Dash ser bra ut och känns responsivt, men har flera nackdelar för de ovan nämnda användningsscenarierna:

Fungerar endast inom ett kluster.
Sortering och filtrering är möjliga, men har inga permanenta länkar.
Ingen stöd för Custom Resource Definitions (CRDs).

Kubernator

"Kubernator är ett alternativt UI för Kubernetes. Till skillnad från det högkvalitativa gränssnittet Kubernetes Dashboard erbjuder den låg nivå kontroll och en utmärkt översikt över alla objekt i klustret med möjlighet att skapa nya, redigera dem och lösa konflikter. Som en helt klientapplikation (som kubectl) kräver den ingen backend förutom själva Kubernetes API-servern och beaktar även åtkomstreglerna för klustret."

Detta är en ganska exakt beskrivning av Kubernator.Tyvärr saknar det vissa funktioner:

Betjänar endast ett kluster.
Det finns inget listvy-läge (dvs. det går inte att visa alla poddar med status "Pending").

Kubernetes Dashboard

„Kubernetes Dashboard är ett universellt webgränssnitt för Kubernetes-kluster. Det gör det möjligt för användare att hantera applikationer som körs i klustret och felsöka dem, samt att hantera själva klustret.”

Tyvärr, Kubernetes Dashboard hjälper det inte särskilt mycket i mina insatser för stöd och incidenthantering, eftersom det:

inte har permanenta länkar, till exempel när jag filtrerar resurser eller ändrar sorteringsordning;
det finns inget enkelt sätt att filtrera efter status – till exempel att se alla poddar med status "Pending";
det stöder bara ett kluster;
CRD stöds inte (den funktionen är under utveckling);
det finns inga anpassade kolumner (till exempel kolumner med etiketter liknande kubectl -L).

Kubernetes Operational View (kube-ops-view)

„Översiktspanel för K8s-klusterutrymmen.”

Hos Kubernetes Operational View har en helt annan ansats: detta verktyg visar endast klusterknoten och poddar med hjälp av WebGL, utan några textuella detaljer om objekten. Det är utmärkt för en operativ översikt av klusterstatusen ("faller poddar?"), men det är inte bra för de användningsfall som beskrivits ovan i stöd och incidenthantering.

* Obs. övers.: I detta avseende kan du också vara intresserad av vår plugin grafana-statusmap, som vi har berättat mer om i denna artikel.

Kubernetes Resource Report (kube-resource-report)

„Samla in information om resursförfrågningar för poddar och Kubernetes-klustret, jämför dem med resursanvändning och generera statisk HTML.”

Kubernetes Resource Report genererar statiska HTML-rapporter om resursanvändning och kostnadsfördelning mellan team/applikationer i kluster. Rapporten är delvis användbar för stöd och incidenthantering eftersom den gör det möjligt att snabbare hitta det kluster där applikationen är utplacerad.

Obs. övers.: I översikten av resursfördelning och dess kostnader kan även tjänsten och verktyget Kubecostvara användbart, som vi.

Octant

nyligen publicerade en översyn av, som är en „utvidgningsbar webbaserad plattform för utvecklare, avsedd att ge en bättre förståelse för komplexiteten i Kubernetes-kluster.”

Octant, skapad i VMware, är en ny produkt som jag har lärt mig om relativt nyligen. Med hjälp av den är det enkelt att utforska klustret på den lokala maskinen (det finns till och med visualiseringar), men den berör problematiken kring stöd och incidenthantering endast i begränsad omfattning. Nackdelar med Octant:

Ingen sökning mellan kluster.
Fungerar endast på lokala maskiner (kan inte distribueras i kluster).
Det går inte att sortera/filtera objekt (endast label-selector stöds).
Det går inte att definiera anpassade kolumner.
Det går inte att lista objekt efter namnrymder.

Jag har också haft problem med stabiliteten i Octant med Zalando-kluster: på vissa CRD den kraschade.

Jag presenterar Kubernetes Web View

”kubectl för webben”.

Efter att ha analyserat de tillgängliga gränssnitten för Kubernetes bestämde jag mig för att skapa ett nytt: Kubernetes Web View. För i grunden behöver jag bara all kraft kubectl i webben, nämligen:

tillgänglighet för alla (read-only) operationer som användare föredrar att använda kubectl för;
alla URL:er bör vara permanenta och representera sidan i sitt originalskick så att kollegor kan dela dem och använda dem i andra verktyg;
stöd för alla Kubernetes-objekt, vilket gör det möjligt att lösa problem av alla typer;
resurslistor ska vara nedladdningsbara för vidare arbete (i kalkylblad, CLI-verktyg som grep) och lagring (till exempel för postmortems);
stöd för resursurval baserat på labels (som med kubectl get .. -l);
möjlighet att skapa sammanställda listor över olika typer av resurser (som med kubectl get all) för att få en övergripande operationell bild bland kollegor (till exempel under incidenthantering);
möjlighet att lägga till anpassade ”intelligenta” djup-länkar till andra verktyg som dashboards, loggverktyg, applikationsregister osv. för att underlätta sökning/avhjälpning och incidenthantering;
frontend ska vara så enkel som möjligt (ren HTML) för att undvika oavsiktliga problem, såsom hängande JavaScript;
stöd för flera kluster för att förenkla interaktionen vid fjärrkonsultation (till exempel för att komma ihåg endast en URL);
situationsanalysen bör förenklas om möjligt (till exempel med länkar för nedladdning av resurser över alla kluster/namnrymder);
ytterligare funktioner för att skapa flexibla länkar och extrahera textinformation, till exempel för att kunna ange specifika avsnitt i resursbeskrivningen (rad i YAML);
möjlighet att anpassa efter specifika kundkrav, exempelvis genom att tillåta skapande av specialanpassade visningsmallar för CRD, egna tabellrepresentationer, ändra CSS-stilar;
verktyg för vidare studier i kommandoraden (till exempel genom att visa kompletta kommandon kubectl, redo för kopiering);

Utanför de uppgifter som hanteras av Kubernetes Web View (icke-mål) återstår:

abstraktion av Kubernetes-objekt;
hantering av applikationer (till exempel hantering av deploymentar, Helm-diagram osv.);
skrivoperationer (måste utföras via ett säkert CI/CD- och/eller GitOps-verktyg);
ett vackert gränssnitt (JavaScript, teman osv.);
visualiseringar (se kube-ops-view);
kostnadsanalys (se kube-resource-report).

Hur hjälper Kubernetes Web View till med incidenthantering och respons?

Support

Alla länkar är permanenta, vilket underlättar informationsutbytet med kollegor.
Det går att skapa egna vyer, till exempel för att visa alla deploymentar och pods med en viss etikett i två specifika kluster (flera klusternamn och resurstyp kan anges i länken, åtskilda med kommatecken).
Det går att referera till specifika rader i YAML-filen för objektet, vilket pekar på potentiella problem i objektets specifikation.

Sökning av kluster i Kubernetes Web View

Incidenthantering

Global sökning (global search) möjliggör sökning av objekt i alla kluster.
Listvyer kan visa alla objekt med ett visst tillstånd/kolumn i alla kluster (till exempel, vi behöver hitta alla pods med status "Pending").
Objektslistor kan laddas ner i tabulatoravgränsade värden (TSV) för vidare analys.
Anpassningsbara externa länkar möjliggör att växla till relevanta övervakningspaneler och andra verktyg.

Kubernetes Web View: lista över pods med status "Pending" i alla kluster

Om du vill prova Kubernetes Web View rekommenderar jag att du bekantar dig med dokumentationen eller kollar på en live demoversion.

Självklart, gränssnittet skulle kunna vara bättre, och hittills är Kubernetes Web View ett verktyg för "erfarna användare" som inte är rädda för att manipulera URL-vägar manuellt om det behövs. Om du har några åsikter/kommentarer/önskemål, vänligen kontakta mig på Twitter!

Denna artikel är en kort berättelse om de förutsättningar som ledde till skapandet av Kubernetes Web View. Fler artiklar följer! (Obs. övers.: De bör förväntas i bloggen för författaren.)