Pozn. přek.: Autorem původního materiálu je Henning Jacobs ze společnosti Zalando. Vytvořil nové webové rozhraní pro práci s Kubernetes, které je označováno jako „kubectl pro web“. Proč se objevil tento nový open source projekt a jaké kritéria nesplnily již existující řešení – čtěte v jeho článku.
V této publikaci se zabývám různými open source webovými rozhraními Kubernetes, předkládám své požadavky na univerzální UI a vysvětluji, proč jsem je vyvinul – rozhraní, jehož cílem je usnadnit podporu a odstraňování chyb simultánně ve více clusterech.
Použití
Ve společnosti Zalando obsluhujeme velké množství uživatelů Kubernetes (900+) a clusterů (100+). Existuje několik typických scénářů použití, kdy by velmi pomohlo specializované webové nástroje:
- komunikace s kolegy v rámci podpory;
- reakce na incidenty a vyšetřování jejich příčin.
Podpora
Z mé zkušenosti komunikace v rámci podpory často vypadá takto:
– Pomozte, naše služba XYZ není dostupná!
– Co vidíte, když provedete kubectl describe ingress ...?
Nebo něco podobného pro CRD:
– Mám nějaký problém se službou identifikace…
– A co ukazuje příkaz kubectl describe platformcredentialsset ...?
Taková komunikace obvykle spočívá v zadávání různých variant příkazu kubectl s cílem zjistit problém. V důsledku toho obě strany rozhovoru musí neustále přepínat mezi terminálem a webovým chatem, navíc pozorují různou situaci.
Proto bych chtěl, aby webové rozhraní pro Kubernetes umožnilo následující:
- uživatelé by mohli sdílet odkazy a vidět totéž;
- pomáhalo by vyhnout se lidským chybám v podpoře: například přihlášení do špatného clusteru v příkazovém řádku, překlepy v CLI příkazech atd.;
- umožňovalo by generovat vlastní pohledy pro zasílání kolegům, tedy přidávat sloupce s etiketami, zobrazovat různé typy zdrojů na jedné stránce;
- v ideálním případě by tento webový nástroj měl umožňovat vytváření „hlubokých“ odkazů na konkrétní části YAML (například ukazovat na chybné parametry, které způsobují selhání).
Reakce na incidenty a analýza
Reakce na incidenty v infrastruktuře vyžaduje situational awareness, schopnost hodnotit dopady a hledat vzory v klastrech. Některé příklady z reálného života:
- kritický produkční servis má problémy a musíte najít všechny Kubernetes zdroje podle názvu ve všech klastrech, abyste odstranili závady;
- uzly začínají padat při škálování a musíte najít všechny pod'y se statusem „Pending“ ve všech klastrech, abyste posoudili rozsah problému;
- někteří uživatelé hlásí problém s DaemonSet nasazeným ve všech klastrech a je třeba zjistit, zda má problém celoplošnou povahu.
Moje standardní řešení v takových případech je něco jako for i in $clusters; do kubectl ...; done. Samozřejmě je možné vyvinout nástroj, který poskytuje podobné možnosti.
Existující webové rozhraní Kubernetes
Svět open source webových rozhraní pro Kubernetes není příliš velký*, takže jsem se pokusil shromáždit další informace pomocí :
* Moje vysvětlení omezeného počtu webových rozhraní pro Kubernetes: cloudové služby a dodavatelé Kubernetes obvykle nabízejí své vlastní frontendové aplikace, takže trh pro „dobrá“ volná Kubernetes UI je relativně malý.
Díky tweetu jsem se dozvěděl o , a . Podívejme se na ně a další existující open source řešení a pokusme se pochopit, co představují.
K8Dash
„K8Dash je nejjednodušší způsob, jak spravovat Kubernetes cluster.“
vypadá docela dobře a rychle funguje, ale má několik nedostatků pro výše uvedené scénáře použití:
- Funguje pouze v rámci jednoho clusteru.
- Třídění a filtrování je možné, ale nemá trvalé odkazy.
- Chybí podpora Custom Resource Definitions (CRDs).
Kubernator
„Kubernator je alternativní UI pro Kubernetes. Na rozdíl od vysoce úrovňového panelu Kubernetes Dashboard poskytuje nízkoúrovňovou kontrolu a skvělý přehled všech objektů v clusteru s možností vytvářet nové, upravovat je a řešit konflikty. Jako plně klientská aplikace (jako kubectl) nevyžaduje žádný backend kromě samotného API serveru Kubernetes a zohledňuje pravidla přístupu k clusteru.“
To je docela přesný popis . Bohužel mu chybí některé funkce:
- Obsluhuje pouze jeden cluster.
- Není k dispozici režim zobrazení seznamu (tj. není možné zobrazit všechny pod ’y se stavem „Pending“).
Kubernetes Dashboard
„Kubernetes Dashboard je univerzální webové rozhraní pro clustery Kubernetes. Umožňuje uživatelům spravovat aplikace běžící v clusteru a odstraňovat jejich potíže, stejně jako spravovat samotný cluster.“
Bohužel, není příliš užitečný pro mé činnosti v oblasti podpory a reakce na incidenty, protože v něm:
- není trvalých odkazů, například když filtrují prostředky nebo mění pořadí třídění;
- neexistuje snadný způsob, jak filtrovat podle stavu – například vidět všechny pod ’y se stavem „Pending“;
- podporován je pouze jeden cluster;
- nepodporují se CRD (tato funkce je ve vývoji);
- neexistují žádné vlastní sloupce (například sloupce s štítky typu
kubectl -L).
Kubernetes Operational View (kube-ops-view)
„Systémový panel pro monitorování prostoru clusterů K8s.“
V je zcela jiný přístup: tento nástroj pouze zobrazuje uzly clusteru a pod’ y pomocí WebGL, bez jakýchkoli textových podrobností o objektech. Je výborný pro operativní přehled stavu clusteru („pod’ y padají?“)*, ale není vhodný pro výše uvedené případy použití v oblasti podpory a reakce na incidenty.
* Pozn. přek.: V tomto ohledu vás může také zajímat náš plugin , o kterém jsme psali podrobněji v .
Kubernetes Resource Report (kube-resource-report)
„Shromážděte údaje o požadavcích na prostředky pod’ů a clusteru Kubernetes, porovnejte je s využitím prostředků a vytvářejte statický HTML.“
vytváří statické HTML zprávy o využívání prostředků a rozdělení nákladů mezi týmy/aplikacemi v clusterech. Zpráva je do určitého stupně užitečná pro podporu a reakci na incidenty, protože umožňuje rychleji najít cluster, ve kterém je aplikace nasazena.
Pozn. přek.: Při pohledu na údaje o rozdělení prostředků a jejich nákladech u cloudových poskytovatelů může být také užitečný servis a nástroj , jehož přehled jsme .
Octant
„Rozšiřitelná webová platforma pro vývojáře, navržená tak, aby poskytovala lepší porozumění složitosti clusterů Kubernetes.“
, vytvořený ve VMware, je nový produkt, o kterém jsem se dozvěděl poměrně nedávno. Umožňuje pohodlně prozkoumávat klastr na lokálním stroji (existují dokonce vizualizace), nicméně se do určité míry dotýká problematiky podpory a reakce na incidenty. Nevýhody Octantu:
- Není vyhledávání v klastra.
- Funguje pouze na lokálním stroji (není nasazován v klastru).
- Není možné třídit/filterovat objekty (podporován je pouze selektor štítků).
- Nelze zadávat vlastní sloupce.
- Nelze zobrazit seznam objektů podle prostorů jmen.
Měl jsem také problémy s stabilitou Octantu v klastra Zalando: na některých CRD .
Představuji Kubernetes Web View
"kubectl pro web."
Po analýze dostupných rozhraní pro Kubernetes jsem se rozhodl vytvořit nové: . Vždyť v podstatě potřebuji veškerou sílu kubectl ve webu, a to konkrétně:
- dostupnost všech (jen ke čtení) operací, které uživatelé preferují používat v kubectl;
- všechny URL by měly být trvalé a představovat stránku v originálním znění, aby si je kolegové mohli vyměňovat a používat v jiných nástrojích;
- podpora všech objektů Kubernetes, což umožní řešit jakýkoli typ problému;
- seznamy zdrojů by měly být stahovatelné pro další práci (v elektronických tabulkách, CLI nástrojích jako
grep) a pro uchovávání (například pro postmortemy); - podpora výběru zdrojů podle štítků (podobně jako
kubectl get .. -l); - možnost vytvářet kombinované seznamy různých typů zdrojů (podobně jako
kubectl get all) pro získání celkového operačního obrazu mezi kolegy (například při reakci na incident); - možnost přidávat přizpůsobené "inteligentní" hluboké odkazy na další nástroje, jako jsou monitorovací panely, loggery, registry aplikací atd. pro usnadnění hledání/odstraňování chyb a reakci na incidenty;
- frontend by měl být co nejjednodušší (čistý HTML), aby se předešlo náhodným problémům, například zaseknutému JavaScriptu;
- podpora mnoha klastrů pro zjednodušení interakce při vzdáleném poradenství (například zapamatování pouze jednoho URL);
- pokud možno by se měl zjednodušit situativní rozbor (například se odkazy na stažení zdrojů ze všech klastrů/prostorů jmen);
- další funkce pro vytváření flexibilních odkazů a zvýraznění textových informací, například pro označení konkrétní části v popisu zdroje (řádku v YAML);
- možnost přizpůsobení specifickým požadavkům zákazníka, například umožnění vytváření speciálních šablon zobrazení pro CRD, vlastních tabulkových zobrazení, úpravy CSS stylů;
- nástroje pro další studium v příkazovém řádku (například ukazující kompletní příkazy
kubectl, připravené k zkopírování);
Mimo úkoly řešené v Kubernetes Web View (non-goals) zůstávají:
- abstrahování objektů Kubernetes;
- správa aplikací (například správa deploymentů, Helm chartů atd.);
- operace zápisu (musí být prováděny prostřednictvím bezpečného nástroje CI/CD a/nebo GitOps);
- hezké rozhraní (JavaScript, motivy atd.);
- vizualizace (viz );
- analýzu nákladů (viz ).
Jak Kubernetes Web View pomáhá při podpoře a reakci na incidenty?
Podpora
- Všechny odkazy jsou trvalé, což usnadňuje sdílení informací s kolegy.
- Je možné vytvářet svá zobrazení, například zobrazit všechny Deploymenty a Pody s určitou značkou ve dvou konkrétních clusterech (více názvů clusterů a typů zdrojů lze zadat v odkazu, oddělené čárkami).
- Můžete odkazovat na určité řádky v YAML souboru objektu, který ukazuje na potenciální problémy ve specifikaci objektu.
Hledání v clusterech v Kubernetes Web View
Reakce na incidenty
- Globální hledání (global search) umožňuje hledat objekty ve všech clusterech.
- Zobrazení jako seznamy mohou zobrazit všechny objekty s určitou stavovou/sloupcovou hodnotou ve všech clusterech (například potřebujeme najít všechny pody se stavem "Pending").
- Seznamy objektů lze stáhnout ve formátu hodnot oddělených tabulátory (TSV) pro následnou analýzu.
- umožňují přepínat na odpovídající panely sledování a další nástroje.
Kubernetes Web View: seznam podů se stavem "Pending" ve všech clusterech
Pokud chcete vyzkoušet Kubernetes Web View, doporučuji se seznámit s nebo se podívat na .
Určitě by mohl být uživatelský rozhraní lepší, ale zatím je Kubernetes Web View nástrojem pro "pokročilé uživatele", kteří se nebojí ručně manipulovat s URL cestami, pokud je to potřeba. Pokud máte jakékoli připomínky/doplnění/přání, prosím, kontaktujte !
Tento článek je krátkým vyprávěním o předpokladech, které vedly ke vzniku Kubernetes Web View. Následovat budou další! (Pozn. přek.: Očekávejte je .)
P.S. od překladatele
Přečtěte si také náš blog:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
