Opmerking. vert.: De auteur van het originele materiaal is Henning Jacobs van Zalando. Hij creëerde een nieuwe webinterface voor het werken met Kubernetes, die is gepositioneerd als ‘kubectl voor het web’. Waarom er een nieuw Open Source-project verscheen en aan welke criteria niet werd voldaan door bestaande oplossingen - lees zijn artikel.
In dit bericht bespreek ik de verschillende open source Kubernetes-webinterfaces, leg ik mijn vereisten voor een universele gebruikersinterface uiteen en leg ik uit waarom ik deze heb ontwikkeld — een interface die is ontworpen om het eenvoudiger te maken meerdere clusters tegelijk te ondersteunen en problemen op te lossen.
Gebruiksgevallen
Bij Zalando bedienen we een groot aantal Kubernetes-gebruikers (900+) en clusters (100+). Er zijn een aantal veel voorkomende gebruiksscenario's die baat zouden hebben bij een speciale webtool:
- communicatie met collega's voor ondersteuning;
- het reageren op incidenten en het onderzoeken van de oorzaken ervan.
Ondersteunen
In mijn ervaring ziet ondersteuningscommunicatie er vaak als volgt uit:
— Help, onze service XYZ is niet beschikbaar!
— Wat zie je als je optreedt? kubectl describe ingress ...?
Of iets soortgelijks voor CRD:
— Ik heb een probleem met de identificatiedienst...
— Wat levert het bevel op? kubectl describe platformcredentialsset ...?
Dergelijke communicatie komt meestal neer op het invoeren van verschillende varianten van het commando kubectl om het probleem te identificeren. Hierdoor worden beide gesprekspartners gedwongen voortdurend te wisselen tussen de terminal en de webchat, en zien ze een andere situatie.
Daarom zou ik graag willen dat de Kubernetes-webfrontend het volgende toestaat:
- gebruikers konden koppelingen uitwisselen en observeer hetzelfde;
- zou helpen vermijd menselijke fouten ter ondersteuning: bijvoorbeeld inloggen op het verkeerde cluster op de opdrachtregel, typefouten in CLI-opdrachten, enz.;
- zou toestaan uw eigen visie genereren om naar collega's te sturen, dat wil zeggen kolommen met tags toevoegen, vele soorten bronnen op één pagina weergeven;
- Idealiter zou deze webtool u in staat moeten stellen om in te stellen "diepe" links naar specifieke secties van YAML (bijvoorbeeld door te wijzen op een onjuiste parameter die fouten veroorzaakt).
Incidentrespons en analyse
Het reageren op infrastructuurincidenten vereist situationeel bewustzijn, het vermogen om de impact te beoordelen en patronen in clusters te zoeken. Enkele voorbeelden uit het echte leven:
- Een kritische productiedienst heeft problemen en dat moet ook vind alle Kubernetes-bronnen op naam in alle clustersproblemen oplossen;
- knooppunten beginnen te vallen tijdens het schalen en dat heb je nodig vind alle pods met de status 'In behandeling' in alle clustersom de omvang van het probleem te beoordelen;
- individuele gebruikers melden een probleem waarbij DaemonSet in alle clusters is geïmplementeerd en moeten dit uitzoeken Is het probleem totaal?.
Mijn standaardoplossing in dergelijke gevallen is zoiets als for i in $clusters; do kubectl ...; done. Uiteraard is het mogelijk om een tool te ontwikkelen die vergelijkbare mogelijkheden biedt.
Bestaande Kubernetes-webinterfaces
De open source-wereld van webinterfaces met Kubernetes is niet erg groot*, dus ik probeerde meer informatie te verzamelen met behulp van :
*Mijn verklaring voor het beperkte aantal webinterfaces voor Kubernetes: cloudservices en Kubernetes-leveranciers bieden meestal hun eigen frontends aan, dus de markt voor een ‘goede’ gratis Kubernetes-gebruikersinterface is relatief klein.
Via een tweet hoorde ik erover , и . Laten we ze en andere bestaande Open Source-oplossingen bekijken, laten we proberen te begrijpen wat ze zijn.
K8Dash
“K8Dash is de eenvoudigste manier om een Kubernetes-cluster te beheren.”
Ziet er goed uit en voelt snel aan, maar heeft een aantal nadelen voor de hierboven genoemde gebruiksscenario's:
- Werkt alleen binnen de grenzen van één cluster.
- Sorteren en filteren zijn mogelijk, maar hebben geen permalinks.
- Er is geen ondersteuning voor aangepaste resourcedefinities (CRD's).
Kubernator
“Kubernator is een alternatieve gebruikersinterface voor Kubernetes. In tegenstelling tot het Kubernetes Dashboard op hoog niveau biedt het controle op laag niveau en uitstekend inzicht in alle objecten in het cluster, met de mogelijkheid om nieuwe te maken, te bewerken en conflicten op te lossen. Omdat het een volledig client-side applicatie is (zoals kubectl), heeft het geen andere backend nodig dan de Kubernetes API-server zelf, en respecteert het ook de clustertoegangsregels.”
Dit is een vrij nauwkeurige beschrijving . Helaas mist het enkele functies:
- Bedient slechts één cluster.
- Er is geen lijstweergavemodus (dat wil zeggen dat u niet alle pods met de status 'In behandeling' kunt weergeven).
Kubernetes-dashboard
“Kubernetes Dashboard is een universele webinterface voor Kubernetes-clusters. Het stelt gebruikers in staat om applicaties die in een cluster draaien te beheren en problemen op te lossen, maar ook om het cluster zelf te beheren.”
Helaas helpt niet echt bij mijn ondersteunings- en incidentresponsactiviteiten, omdat het:
- er zijn geen permanente links, bijvoorbeeld wanneer ik bronnen filter of de sorteervolgorde wijzig;
- er is geen gemakkelijke manier om op status te filteren - bekijk bijvoorbeeld alle pods met de status "In behandeling";
- er wordt slechts één cluster ondersteund;
- CRD's worden niet ondersteund (deze functie is in ontwikkeling);
- geen aangepaste kolommen (zoals kolommen gelabeld op type
kubectl -L).
Operationele weergave van Kubernetes (kube-ops-view)
"Systeemdashboardwaarnemer voor K8s Cluster Space."
У Een heel andere aanpak: deze tool toont alleen clusterknooppunten en pods met behulp van WebGL, zonder enige tekstuele objectdetails. Het is geweldig voor een snel overzicht van de status van het cluster (vallen er pods?)*, maar het is niet geschikt voor de hierboven beschreven gebruiksscenario's voor ondersteuning en incidentrespons.
* Opmerking. vert.: In die zin bent u wellicht ook geïnteresseerd in onze plug-in , waar we het in meer detail over hadden .
Kubernetes-bronrapport (kube-resource-report)
“Verzamel pod- en Kubernetes-clusterresourceverzoeken, vergelijk ze met het resourceverbruik en genereer statische HTML.”
genereert statische HTML-rapporten over het gebruik van bronnen en de verdeling van de kosten over teams/applicaties in clusters. Het rapport is enigszins nuttig voor ondersteuning en respons op incidenten, omdat u hiermee snel het cluster kunt vinden waar de applicatie is geïmplementeerd.
Opmerking. vert.: Een dienst en tool kunnen ook nuttig zijn bij het bekijken van informatie over de toewijzing van bronnen en hun kosten onder cloudproviders , die wij beoordelen .
Octant
"Een uitbreidbaar webplatform voor ontwikkelaars, ontworpen om meer inzicht te geven in de complexiteit van Kubernetes-clusters."
, gemaakt door VMware, is een nieuw product waar ik relatief recent over heb gehoord. Met zijn hulp is het handig om het cluster op een lokale machine te verkennen (er zijn zelfs visualisaties), maar het pakt de problemen van ondersteuning en incidentrespons slechts in beperkte mate aan. Nadelen van Octant:
- Geen clusterzoekopdracht.
- Werkt alleen op de lokale computer (wordt niet geïmplementeerd in een cluster).
- Kan geen objecten sorteren/filteren (alleen labelselector wordt ondersteund).
- U kunt geen aangepaste kolommen opgeven.
- U kunt objecten niet op naamruimte weergeven.
Ik had ook problemen met de stabiliteit van Octant met Zalando-clusters: op sommige CRD's .
Maak kennis met Kubernetes-webweergave
"kubectl voor internet".
Nadat ik de beschikbare interface-opties voor Kubernetes had geanalyseerd, besloot ik een nieuwe te maken: . Eigenlijk heb ik gewoon alle kracht nodig kubectl op internet, namelijk:
- beschikbaarheid van alle (alleen-lezen) bewerkingen waarvoor gebruikers bij voorkeur kubectl gebruiken;
- alle URL's moeten permanent zijn en de pagina in de oorspronkelijke vorm weergeven, zodat collega's ze kunnen delen en in andere tools kunnen gebruiken;
- ondersteuning voor alle Kubernetes-objecten, waarmee u elk type probleem kunt oplossen;
- bronnenlijsten moeten kunnen worden gedownload voor verder werk (in spreadsheets, CLI-tools zoals
grep) en opslag (bijvoorbeeld voor autopsie); - ondersteuning voor het selecteren van bronnen op label (vergelijkbaar met
kubectl get .. -l); - de mogelijkheid om gecombineerde lijsten van verschillende soorten bronnen te maken (vergelijkbaar met
kubectl get all) het verkrijgen van een gemeenschappelijk operationeel beeld onder collega’s (bijvoorbeeld tijdens een incidentrespons); - de mogelijkheid om aangepaste slimme deep links toe te voegen aan andere tools zoals dashboards, loggers, applicatieregisters, enz. om het oplossen van problemen/oplossen van fouten en het reageren op incidenten te vergemakkelijken;
- De frontend moet zo eenvoudig mogelijk zijn (pure HTML) om willekeurige problemen, zoals bevroren JavaScript, te voorkomen;
- ondersteuning voor meerdere clusters om de interactie tijdens advies op afstand te vereenvoudigen (bijvoorbeeld om slechts één URL te onthouden);
- Indien mogelijk moet de situatieanalyse worden vereenvoudigd (bijvoorbeeld met links om bronnen voor alle clusters/naamruimten te downloaden);
- extra mogelijkheden om bijvoorbeeld flexibele koppelingen te maken en tekstinformatie te markeren, zodat u collega's kunt verwijzen naar een specifiek gedeelte in de bronbeschrijving (een regel in YAML);
- de mogelijkheid om aan te passen aan de vereisten van een specifieke klant, waardoor u bijvoorbeeld speciale weergavesjablonen voor CRD's en uw eigen tabelweergaven kunt maken en CSS-stijlen kunt wijzigen;
- tools voor verdere verkenning op de opdrachtregel (bijvoorbeeld volledige opdrachten weergeven).
kubectl, klaar om te kopiëren);
Naast de taken die zijn opgelost in Kubernetes Web View (niet-doelen) bleef:
- abstractie van Kubernetes-objecten;
- applicatiebeheer (bijvoorbeeld implementatiebeheer, Helm-grafieken, etc.);
- schrijfbewerkingen (moeten worden uitgevoerd via beveiligde CI/CD- en/of GitOps-tools);
- mooie interface (JavaScript, thema's, enz.);
- visualisatie (zie );
- Kostenanalyse (zie ).
Hoe helpt Kubernetes Web View met ondersteuning en respons op incidenten?
Ondersteunen
- Alle links zijn permanent, waardoor het gemakkelijker wordt om informatie uit te wisselen met collega's.
- Je kunt creëren jouw ideeënGeef bijvoorbeeld alle implementaties en pods met een specifiek label in twee specifieke clusters weer (verschillende clusternamen en resourcetypen kunnen in de link worden opgegeven, gescheiden door komma's).
- U kunt verwijzen naar specifieke regels in een YAML-bestand object, wat potentiële problemen in de objectspecificatie aangeeft.
Zoek op clusters in Kubernetes Web View
Reactie op incidenten
- Globaal zoeken (algemene zoekopdracht) Hiermee kunt u zoeken naar objecten in alle clusters.
- Lijstweergaven kan alle objecten met een bepaalde status/kolom in alle clusters weergeven (we moeten bijvoorbeeld alle pods vinden met de status "In behandeling").
- Lijsten met objecten kunnen worden gedownload in door tabs gescheiden waarden (TSV) voor latere analyse.
- Hiermee kunt u overschakelen naar gerelateerde dashboards en andere tools.
Kubernetes Web View: lijst met pods met de status 'In behandeling' in alle clusters
Als je Kubernetes Web View wilt proberen, raad ik je aan om het eens te proberen of kijk naar .
Natuurlijk kan de interface beter, maar voorlopig is Kubernetes Web View een tool voor ‘gevorderde gebruikers’ die er niet voor terugschrikken om URL-paden indien nodig handmatig te manipuleren. Heeft u opmerkingen/aanvullingen/suggesties, neem dan gerust contact op !
Dit artikel is een korte geschiedenis van de achtergrond die heeft geleid tot de creatie van Kubernetes Web View. Er zullen er meer volgen! (Opmerking. vert.: Ze moeten binnen verwacht worden .)
PSvan de vertaler
Lees ook op onze blog:
- «";
- «";
- «";
- «.
Bron: www.habr.com