Opmerking vertaler.: Auteur van het originele materiaal — Henning Jacobs van Zalando. Hij heeft een nieuwe webinterface ontwikkeld voor het werken met Kubernetes, dat wordt gepositioneerd als 'kubectl voor het web'. Waarom dit nieuwe Open Source-project is ontstaan en welke criteria niet werden vervuld door de bestaande oplossingen — lees het in zijn artikel.
In deze publicatie bespreek ik verschillende open source webinterfaces voor Kubernetes, formuleer ik mijn vereisten voor een universele UI en vertel ik waarom ik het heb ontwikkeld. — een interface die is ontworpen om de ondersteuning en probleemoplossing in meerdere clusters te vergemakkelijken.
Gebruikscenarios
Bij Zalando bedienen we een groot aantal Kubernetes-gebruikers (900+) en clusters (100+). Er zijn een paar typische gebruiksscenario's waarin de hulp van een gespecialiseerde webtool zeer handig zou zijn:
- communicatie met collega's binnen de ondersteuning;
- reageren op incidenten en het onderzoeken van hun oorzaken.
Ondersteuning
Uit mijn ervaring lijkt communicatie binnen de ondersteuning vaak het volgende:
— Help, onze service XYZ is niet beschikbaar!
— Wat zie je wanneer je kubectl describe ingress ...?
Of iets soortgelijks voor CRD:
— Ik heb een probleem met de identificatieservice...
— Wat geeft het commando kubectl describe platformcredentialsset ...?
Deze communicatie komt meestal neer op het invoeren van verschillende variaties van het commando kubectl om het probleem vast te stellen. Als gevolg hiervan moeten beide partijen zich voortdurend tussen de terminal en de webchat verplaatsen, en zien ze een verschillende situatie.
Daarom willen we dat de webfrontend voor Kubernetes het volgende mogelijk maakt:
- gebruikers zouden links kunnen delen en hetzelfde zouden kunnen zien;
- het zou helpen menselijke fouten in de ondersteuning te vermijden: bijvoorbeeld het inloggen op de verkeerde cluster in de commandoregel, typfouten in CLI-commando's, enz.;
- het zou mogelijk maken eigen weergaven te genereren om naar collega's te sturen, dat wil zeggen kolommen met labels toe te voegen, meerdere soorten middelen op één pagina weer te geven;
- ideaal gezien zou dit webinstrument het mogelijk moeten maken om "diepe" links naar specifieke secties van YAML te plaatsen (bijvoorbeeld te wijzen op een onjuist parameter dat foutmeldingen veroorzaakt).
Reageren op incidenten en analyse
Incident response in infrastructure requires situational awareness, the ability to assess impact, and pattern finding in clusters. Here are some real-life examples:
- a critical production service is experiencing issues, and you need to find all Kubernetes resources by name in all clusters, to troubleshoot;
- nodes begin to fail when scaling, and you need to find all pods with a 'Pending' status in all clusters, to assess the scope of the problem;
- individual users report an issue with a DaemonSet deployed across all clusters, and you need to determine whether the problem is widespread..
My standard solution in such cases is something like for i in $clusters; do kubectl ...; done. Clearly, an tool can be developed that provides similar capabilities.
Existing web interfaces for Kubernetes
The Open Source world of web interfaces for Kubernetes is not very large*, so I tried to gather additional information through :
* My explanation for the limited number of web interfaces for Kubernetes: cloud services and Kubernetes vendors usually offer their own frontends, making the market for 'good' free Kubernetes UIs relatively small.
Through a tweet, I learned about , en . Let's take a look at them and other existing Open Source solutions to understand what they are.
K8Dash
"K8Dash is the simplest way to manage a Kubernetes cluster."
it looks decent and feels fast, but has several shortcomings for the scenarios mentioned above:
- It only works within a single cluster.
- Sorting and filtering are possible but do not have persistent links.
- No support for Custom Resource Definitions (CRDs).
Kubernator
"Kubernator is an alternative UI for Kubernetes. Unlike the high-level Kubernetes Dashboard, it offers low-level control and an excellent overview of all objects in the cluster with the ability to create new ones, edit them, and resolve conflicts. Being a fully client-side application (like kubectl), it does not require a backend other than the Kubernetes API server and takes cluster access rules into account."
This is a fairly accurate description of Unfortunately, it lacks some capabilities:
- It only serves a single cluster.
- Er is geen lijstweergave (d.w.z. je kunt niet alle pods met de status 'Pending' weergeven).
Kubernetes Dashboard
„Kubernetes Dashboard is een veelzijdige webinterface voor Kubernetes-clusters. Het stelt gebruikers in staat om applicaties die in het cluster draaien te beheren en problemen op te lossen, evenals het cluster zelf te beheren.“
Helaas, helpt niet echt bij mijn ondersteunings- en incidentresponsactiviteiten, omdat het:
- geen permanente links heeft, bijvoorbeeld wanneer ik bronnen filter of de sorteer volgorde wijzig;
- geen eenvoudige manier biedt om te filteren op status — bijvoorbeeld om alle pods met de status 'Pending' te zien;
- slechts één cluster ondersteunt;
- CRD's worden niet ondersteund (deze functie is in ontwikkeling);
- geen aangepaste kolommen ondersteunt (bijvoorbeeld kolommen met labels zoals
kubectl -L).
Kubernetes Operational View (kube-ops-view)
„Een systeempaneel voor het observeren van cluster ruimtes van K8s.“
Er heeft een totaal andere benadering: dit gereedschap toont alleen de cluster nodes en pods met behulp van WebGL, zonder enige tekstuele details van objecten. Het is uitstekend geschikt voor een operationeel overzicht van de status van het cluster ('vallen de pods?'*), maar is niet geschikt voor de eerder beschreven gebruiks gevallen in ondersteuning en incidentrespons.
* Opmerking vertaler.: In dit opzicht ben je misschien ook geïnteresseerd in onze plugin , waarover we in meer detail hebben gesproken in .
Kubernetes Resource Report (kube-resource-report)
„Verzamelt informatie over resource-aanvragen van pods en Kubernetes-clusters, vergelijkt deze met resourceverbruik en genereert statische HTML.“
genereert statische HTML-rapporten over resourcegebruik en kostenverdeling per teams/applicaties in clusters. Het rapport is in zekere zin nuttig voor ondersteuning en incidentrespons, omdat het makkelijker maakt om het cluster te vinden waar de applicatie is ingezet.
Opmerking vertaler.: De weergave van informatie over resourceverdeling en de kosten ervan kan ook een nuttige service en tool zijn van cloudproviders. , waarvan we .
Octant
„Een uitbreidbaar webplatform voor ontwikkelaars dat is ontworpen om een beter inzicht in de complexiteit van Kubernetes-clusters te bieden.“
, gemaakt in VMware, is een nieuw product waarvan ik pas relatief recent heb gehoord. Het stelt je in staat om eenvoudig een cluster op een lokale machine te verkennen (er zijn zelfs visualisaties), maar het raakt het probleem van ondersteuning en incidentrespons slechts in beperkte mate aan. Nadelen van Octant:
- Geen zoekfunctie voor clusters.
- Werkt alleen op een lokale machine (niet geïmplementeerd in een cluster).
- Het is niet mogelijk om objecten te sorteren/filteren (alleen labelselectoren worden ondersteund).
- Aangepaste kolommen kunnen niet worden ingesteld.
- Kan geen lijst van objecten per namespaces weergeven.
Daarnaast had ik problemen met de stabiliteit van Octant met Zalando-clusters: bij sommige CRD .
Ik stel Kubernetes Web View voor.
‘kubectl voor het web’.
Na het analyseren van de beschikbare interface-opties voor Kubernetes, besloot ik een nieuwe te maken: . Ik heb eigenlijk alleen de volledige kracht nodig kubectl in de browser, namelijk:
- toegang tot alle (read-only) acties die gebruikers bij voorkeur met kubectl uitvoeren;
- alle URL's moeten permanent zijn en de pagina in originele vorm weergeven, zodat collega's deze kunnen delen en in andere tools kunnen gebruiken;
- ondersteuning voor alle Kubernetes-objecten, zodat problemen van elke soort kunnen worden opgelost;
- lijsten met middelen moeten downloadbaar zijn voor verdere verwerking (in spreadsheets, CLI-tools zoals
grep) en opslag (bijvoorbeeld voor postmortems); - ondersteuning voor het filteren van middelen op labels (vergelijkbaar met
kubectl get .. -l); - de mogelijkheid om gecombineerde lijsten van verschillende soorten middelen te maken (vergelijkbaar met
kubectl get all) om een algemeen operationeel beeld onder collega's te krijgen (bijvoorbeeld bij het reageren op een incident); - de mogelijkheid om configureerbare ‘slimme’ dieplinks naar andere tools toe te voegen, zoals dashboards, loggers, applicatieregisters, enz., om het zoeken/oplossen van problemen en het reageren op incidenten te vergemakkelijken;
- de frontend moet zo eenvoudig mogelijk zijn (schone HTML) om toevallige problemen te vermijden, zoals vastlopende JavaScript;
- ondersteuning voor meerdere clusters om de interactie tijdens externe consultaties te vergemakkelijken (bijvoorbeeld door slechts één URL te onthouden);
- indien mogelijk moet de situationele analyse worden vereenvoudigd (bijvoorbeeld met links voor het downloaden van middelen over alle clusters/namespaces);
- extra mogelijkheden voor het maken van flexibele links en het markeren van tekstinformatie, bijvoorbeeld om collega’s naar een bepaald gedeelte in de beschrijving van de bron te verwijzen (een regel in YAML);
- de mogelijkheid om aan te passen aan de eisen van specifieke klanten, bijvoorbeeld door speciale weergavesjablonen voor CRD te maken, eigen tabelweergaven aan te passen, CSS-stijlen te wijzigen;
- middelen voor verder onderzoek in de commandoregel (bijvoorbeeld volledige commando's weergeven,
kubectl, gereed om te kopiëren);
Buiten de in Kubernetes Web View opgeloste taken (non-goals) blijven over:
- abstractie van Kubernetes-objecten;
- applicatiebeheer (bijvoorbeeld het beheren van deployments, Helm-charts, etc.);
- schrijfbewerkingen (moeten worden uitgevoerd via veilige CI/CD-tools en/of GitOps);
- een aantrekkelijke interface (JavaScript, thema's, etc.);
- visualisaties (zie );
- kostenanalyse (zie ).
Hoe helpt Kubernetes Web View bij het ondersteunen en reageren op incidenten?
Ondersteuning
- Alle links zijn permanent,, wat het delen van informatie met collega's vergemakkelijkt.
- Men kan eigen weergaven creëren,bijvoorbeeld om alle deployments en pods met een specifieke label in twee specifieke clusters weer te geven (meerdere namen van clusters en resource types kunnen in de link worden opgegeven, gescheiden door komma's).
- Men kan verwijzen naar bepaalde regels in het YAML-bestand van het object, wat wijst op mogelijke problemen in de objectspecificatie.
Zoeken in clusters in Kubernetes Web View
Reageren op incidenten
- Globale zoekfunctie (global search) maakt het mogelijk om objecten in alle clusters te doorzoeken.
- Lijstweergaven kunnen alle objecten met een bepaalde status/kolom in alle clusters weergeven (bijvoorbeeld als we alle pods met de status 'Pending' moeten vinden).
- Objectlijsten kunnen worden gedownload in tab-gescheiden waarden (TSV) voor verdere analyse.
- maakt het schakelen naar de betreffende dashboards en andere tools mogelijk.
Kubernetes Web View: lijst van pods met de status 'Pending' in alle clusters
Als je Kubernetes Web View wilt uitproberen, raad ik aan om te kijken naar of een live demo-versie te bekijken. .
Natuurlijk, de interface kan beter, maar voorlopig is Kubernetes Web View een hulpmiddel voor 'gevorderde gebruikers' die niet bang zijn om URL-paden handmatig te manipuleren indien nodig. Als u opmerkingen of suggesties heeft, neem dan alsjeblieft contact op !
Dit artikel is een korte schets van de achtergronden die hebben geleid tot de creatie van Kubernetes Web View. Er zullen meer volgen! (Opmerking vertaler.: Deze worden verwacht in .)
P.S. van de vertaler
Lees ook op onze blog:
- «»;
- «»;
- «»;
- «».
Bron: habr.com
