🥇 Համաձայն Kubernetes Web View-ի վեբ-հետազոտության հայտարարությանը (և Kubernetes-ի այլ վեբ UI-ների կարճ ակնարկ)

Համար. թարգմանություն.: ՕրիգիNSURL նյութի հեղինակ՝ Henning Jacobs-ը Zalando ընկերությունից: Նա ստեղծել է Kubernetes-ի հետ աշխատելու համար նոր վեբ-վարք, որը ներկայացվում է որպես «kubectl վեբի համար»: Ինչու նոր Open Source նախագիծն ի հայտ եկավ և ինչ բանաձևերի պահանջներ չեն բավարարել արդեն գոյություն ունեցող լուծումները՝ կարդացեք նրա հոդվածում:

Այս հրապարակման մեջ ես դիտարկում եմ Kubernetes-ի տարբեր բաց աղբյուրի վեբ-վարքերը, ներկայացնում եմ իմ պահանջները հասարակ UI-ի համար և եզրակացնում, թե ինչու ստեղծեցի Kubernetes Web View — ինտերֆեյս, որի նպատակն է հեշտացնել աջակցությունը և խնդիրների լուծումը միանգամից մի շարք կլաստերներում:

Օգտագործման սցենարներ

Zalando-ում մենք սպասարկում ենք բազմաթիվ Kubernetes օգտվողների (900+) և կլաստերների (100+): Ունի մի քանի տիպիկ օգտագործման դեպք, որտեղ հատուկ վեբ գործիքները շատ օգտակար կլինեն:

հաղորդակցություն գործընկերների հետ աջակցման շրջանակներում;
հասցական պատահարներին արձագանքել և նրանց պատճառները հետաքննել:

Հետևում

Իմ փորձի համաձայն, աջակցման շրջանակներում հաղորդակցությունը հաճախ հետևյալ կերպ է թվում:

— Օգնեք, մեր XYZ ծառայությունը հասանելի չէ!
— Ի՞նչ եք տեսնում, երբ կատարում եք kubectl describe ingress ...?

Կամ ինչ-որ նման մի բան CRD-ի համար:

— Ինձ անհարմարություն կա նույնականացման ծառայությունում...
— Ի՞նչ է դուրս տալիս команда kubectl describe platformcredentialsset ...?

Այդպիսի հաղորդակցությունը հակված է ձևավորվելու տարբեր փոփոխությունների միջոցով команды kubectl проблема ոնց հասկանալ։ Արցախում երկու կողմերն էլ ստիպված են անընդմեջ անցնել տերմինալից դեպի վեբ-խոսակցություն, ավելին՝ նրանք տեսնում են տարբեր իրավիճակներ:

Ուստի ցանկալի է, որ Kubernetes-ի վեբ-ֆրոնտանդ ապահովի հետևյալը:

օգտագործողները կարողանան շնորհել հղումներ և տեսնել նույնը;
օգնեցնում է խուսափել մարդկային սխալներից աջակցության մեջ: օրինակ, մուտք գործելով միանգամից սխալ կլաստեր տերմինալում, CLI հրահանգների սխալ գրություններով և այլն;
պետք է թույլ տա ստեղծել ազգային քաղվածքներ ուղարկելու համար գործընկերներին, կտրամադրելով ձողակներ, շարժել բազմաթիվ ռեսուրսների տեսակներ մեկ էջում;
կարող է ապահովել, որ այս վեբ գործիքը թույլ տա «մեղրամոմ» հղումներ որոշակի YAML բաժինների (օրինակ, նշելով սխալ պարամետր, որն առաջացնում է խափանումներ):

Պատահարներին արձագանքել և վերլուծություն

Ինֆրանց տեսությունը նախաձեռնելու համար անհրաժեշտ է իրավիճակի գիտակցություն, կարողություն գնահատելու ազդեցությունը և որոնելու օրինաչափությունները կլաստերներում: Ցուցադրելի օրինակի օրինակներ:

մասնագիտացված արտադրանքի ծառայությունների վրա խնդիրներ առաջանում, և ձեզ անհրաժեշտ է գտնել բոլոր Kubernetes ռեսուրսները անունով բոլոր կլաստերներում, որպեսզի վերացնել խնդիրները;
ջեները սկսում են խափանվել, երբ կարելի է սանդղալել, և ձեզ անհրաժեշտ է գտնել բոլոր pod-երը «Pending» կարգավիճակում բոլոր կլաստերներում, որպեսզի գնահատել խնդրի ժամկետը;
անձնական օգտագործողները հաղորդում են DaemonSet-ի խնդրի մասին, որը despleվել է բոլոր կլաստաներում, և անհրաժեշտ է պարզել, փաստն այն է, արդյոք խնդիրը ընդհանուր բնույթ ունի.

Իմ ստանդարտ լուծումը նման դեպքերում նման է for i in $clusters; do kubectl ...; done. Очевидно, можно разработать инструмент, предоставляющий аналогичные возможности.

Կանոնավոր Kubernetes վեբ-փոխանակումներ

Open Source աշխարհը Kubernetes-ի վեբ-ճակատների համար չափազանց փոքր է*, այնպես որ փորձեցի հավաքել լրացուցիչ տեղեկություններ Twitter:

* Իմ բացատրությունը Kubernetes-ի վեբ-ճակատների սահմանափակ թվի համար. Cloud ծառայություններն ու Kubernetes մատակարարները սովորաբար առաջարկում են իրենց սեփական առջևային բաժինները, այդ իսկ պատճառով «լավ» ազատ Kubernetes UI-ների շուկայական միջավայրը համեմատաբար փոքր է:

Twitter-ով տեղեկացա K8Dash, Kubernator և Octant. Ունենք այն փորձենք ուսումնասիրել նրանց և մյուս առկա Open Source լուծումները և փորձենք հասկանալ, թե ինչ են դրանք:

K8Dash

«K8Dash-ը լիովին պարզ եղանակ է կառավարելու Kubernetes կլաստերը»:

K8Dash ավելի լավ տեսք ունի և զգեստավորվում է արագ, բայց ունի մի քանի թերություն նշված վերևի օգտագործման դեպքերի համար.

Աշխատում է միայն մեկ կլաստերի շրջանակներում:
Մոտեցումներն ու տրամադրումները հնարավոր են, բայց չունեն շարունակական հղումներ:
Չկան Custom Resource Definitions (CRD) աջակցություն:

Kubernator

«Kubernator-ը Kubernetes-ի համար այլընտրանքային UI է: Դա բարձր մակարդակի Kubernetes Dashboard-ի և ցածր մակարդակի, բոլոր օբյեկտների դիտարկում է: Կլինեն նորեր ստեղծելու, խմբագրելու և հակամարտությունները լուծելու հնարավորությունները: Այն ամբողջովին հաճախորդի հավելված է (ինչպես kubectl), հետևաբար որևէ հետևայն չէ այլ, քան հենց Kubernetes API սերվերը, և հաշվի է առնում կլաստերի տվյալներ»:

Այս նկարագիրը բավական ճշգրիտ է Kubernator-ի. Ցավոք, նրան բացակայում են որոշ հնարավորություններ:

Միմիայն աշխատում է մեկ կլաստերի հետ:
Չկան ցուցակային դիտման ռեժիմով (այդինքն, հնարավոր չէ ցուցադրել բոլոր pod-երը «Pending» trạng tháiով).

Kubernetes Dashboard

«Kubernetes Dashboard-ը բոլոր Kubernetes կլաստերի համար հայեցակարգային վեբ-փոխանակում է: Այն թույլ է տալիս օգտվողներին կառավարել կլաստերում աշխատող հավելվածներ և լուծել դրանց խնդիրները, ինչպես նաև կառավարել հենց կլաստերը»:

Ցավոք, Kubernetes Dashboard հատուկ օգուտ չի տալիս իմ աջակցման և պատահած դեպքերում արձագանքելու միջոցառումների համար, որովհետև այնտեղ:

չկա շարունակական կապ, օրինակ, երբ ես ֆիլտրում եմ ռեսուրսներ կամ փոխում դասավորությունը;
չկա պարզ եղանակ ֆիլտրելու վիճակով՝ օրինակ, տեսնել բոլոր pod-երը «Pending» վիճակներով;
գործում է միայն մեկ կլաստերի՝
չեն աջակցվում CRD (այս ֆունկցիան ընթացքի մեջ է);
չկա օգտվողական սյուներ (օրինակ, նշումների ըստ սյունակներում kubectl -L).

Kubernetes Operational View (kube-ops-view)

«K8s կլաստերի տարածքի դիտարկման համակարգ».

Ու Kubernetes Operational View հավաստի այլ մոտեցում. Այս գործիքը միայն ցույց է տալիս կլաստերի узлы և pod-երը WebGL-ի օգնությամբ, առանց տարածքային տեղեկությունների: Այն շատ հարմար է կլաստերի վիճակի օպերատիվ դիտարկման համար («pod-երը ընկնում են՞»), սակայն չի համապատասխանում վերոնვების քարոզներին աջակցության և պատասխանի ինտենսիվության համար:

* Համար. թարգմանություն.: Այս իմաստով հաստավ ունեք մեր հավելվածը, որը կարող է ձեզ հետաքրքրել grafana-statusmap, որի մասին մենք ավելի մանրամասն ենք հայտնել այս հոդվածի.

Kubernetes Resource Report (kube-resource-report)

«Հավաքեք pod-երի և Kubernetes կլաստերի ռեսուրսների պահանջների տվյալները, համեմատեք դրանք ռեսուրսների սպառման հետ և ստեղծեք ստատիկ HTML»:

Kubernetes Resource Report ստեղծում է ստատիկ HTML-հաշվետվություններ ռեսուրսների օգտագործման և ծախսերի բաշխման մասին թիմերի/ջանքերի կլաստերում: Հաշվետվությունը մի փոքր օգուտ է տալիս աջակցության և պատասխանի գտնելու համար, քանի որ արագ օգնում է գտնել կլաստեր, որտեղ կիրառվում է հավելված:

Համար. թարգմանություն.: Ռեսուրսների և դրանց գների բաշխման տեղեկությունները դիտելու,ycloudproviders-ներում կարող է նաև օգտակար լինել ծառայություն և գործիք Kubecost, որի վերանայումն մենք նորօրինակ բացահայտել ենք.

Octant

«Հաշմանդամ web-платформа մշակողների համար, որը նախատեսված է ապահովելու քանակավորումը Kubernetes կլաստերի բարդությունների».

Octant, որը ստեղծել է VMware: Ինձ մի քանի ժամանակ առաջ տեղեկացրեց նոր արտադրանքը: Այն հարմար է տեղաշարժելու կլաստեր տեղական մեքենայում (թողնելով նույնիսկ վիզուալիզացիաներ), սակայն մարտահրավերներով աջակցության և պատասխանի ինտենսիվության կլաստերներով վերաբերվում միայն սահմանափակ սփարումներ: Octant-ի մահացությունները:

Դուք չունեք որոնում կլաստերների համար.
Այն գործում է միայն տեղական մեքենայում (չի պահելու կլաստերներում).
Ձեր հնարավոր չէ կլաստերները sort/filter անել (համապատասխան է միայն tag selector).
Չի կարելի ստեղծել անձնական սյանը.
Չի կարելի ցուցադրել.obj համարները տարբեր namespaces-ով.

Նման խնդիրներ եմ ունեցել Octant-ի աշխատելու կայունության հետ Zalando կլաստերներում: որոշ CRD այն ընկել է.

Ներկայացնեմ Kubernetes Web View

«kubectl դանդաղվում է»:

Դիտարկելով կայքերում առկա տարբերակները Kubernetes-ի համար, ենդում եմ նորոգել. Kubernetes Web View. Ինձ օգտագործել են միայն ամբողջ ուժը kubectl ինտերնետում, այսինքն.

բոլոր (read-only) գործընթացների հասանելիությունը, որտեղ օգտվողներն ուզում են օգտագործել kubectl.
բոլոր URL-ները պետք է լինեն մշտական և ներկայացնեն էջը սկզբնական տեսքով, որպեսզի գործընկերներն կարողանան փոխանակել դրանք և օգտագործել ուրիշ գործիքներում.
Կաջակցենք բոլոր Kubernetes-յան օբյեկտներին, ինչը թույլ կտա լուծել յուրաքանչյուր տեսակ խնդիր.
ռեսուրսների ցուցակները պետք է ներբեռնվեն հետագա աշխատանքի համար (էլեկտրոնային աղյուսակների, CLI աշխատելու գործիքներով) և պահպանվելու համար (օրինակ, postmortem-ների համար). grepառաջարկում ենք ռեսուրսներ ընտրել labels-ի միջոցով (հավատարմ կպահպանման նմանությամբ
kubectl get .. -l ընտրել տարբեր տիպերի ռեսուրսների համակցված ցուցակներ (հաշմանդամների վրա));
անդամի մասին. kubectl get all) ընդհանուր գործունեության պատկերի ստացման համար գործընկերների մեջ (օրինակ՝ միջադեպի արձագանման գործընթացում);
կողմի վրա իրական «խելացի» խորքային հղումների ավելացման հնարավորություն այլ գործիքների, օրինակ՝ մոնիտորինգի վահանակների, լոգերի, ծրագրային ռեեստրերի և այլն, հեշտացնելու համար որոնում/թույլատրելու մոնիտորինգի և միջադեպերի արձագակման;
առջևի մասը պետք է լինի հնարավորինս պարզ (մաքուր HTML), պատահական խնդիրներից խուսափելու համար, օրինակ՝ կախված JavaScript;
կլաստերներին աջակցություն հեշտացնելու համար հեռակոնսուլտացիայի դեպքում (օրինակ՝ հիշել միայն մեկ URL);
Հնարավորության դեպքում պետք է պարզեցվի իրավիճակային վերլուծությունը (օրինակ՝ բոլոր կլաստերների/անունների տարածքների միջոցով աղբյուրների ներբեռնելու հղումների համար);
բացարձակ հնարավորություն ձևավորելու ուրախ հղումներ և տեքստային տեղեկություններ առանձնացնելու, օրինակ՝ գործընկերներին նշելու համար որոշակի հատվածը աղբյուրի նկարագրության մեջ (տող YAML-ում);
հնարավորություն հարմարեցնել կոնկրետ հաճախորդի պահանջներին, օրինակ՝ թույլ տալով ստեղծել հատուկ ցուցադրման շաբլոններ CRD-ների համար, սեփական աղյուսակային ներկայացումներ, CSS ոճերի փոփոխություն;
ալիքներ հետագա ուսումնասիրության համար հրամանային տողում (օրինակ՝ ցուցադրելով լիարժեք հրամաններ, kubectl, որոնք պատրաստ են պատճենելու);

Աջակցվող խնդրալի խնդիրներ Kubernetes Web View-ի ժամանակ (անհանգստություններ) մնացած են:

Kubernetes օբյեկտների Abstraction;
համակարգի կառավարում (օրինակ՝ deployment-ների, Helm-ի փաթեթների և այլն);
գրանցման գործողություններ (պետք է իրականացվեն անվտանգ CI/CD գործիքների միջոցով և/կամ GitOps);
պատկերային ինտերֆեյս (JavaScript, թեմաներ և այլն);
տեսապատկերներ (տես․ kube-ops-view);
ծախսերի վերլուծություն (տես․ kube-resource-report).

Ինչպես է Kubernetes Web View-ը օգնում միջադեպերի պահպանում և արձագանքման հարցում?

Հետևում

Բոլոր հղումները՝ մշտական են,, ինչը հեշտացնում է տեղեկատվության փոխանակությունը գործընկերների հետ.
Հնարավոր է ստեղծել իրենց ներկայացումները, օրինակ՝ ամբողջ Deployment-ները և Pod-ները ներկայացնել որոշակի նշակի մեջ երկու կոնկրետ կլաստերներում (բազմաթիվ կլաստերների անուններ և ռեսուրսների տեսակներ կարող են ցուցադրվել հղման մեջ, բաժանվելով կողակի միջոցով):
Հնարավոր է հղվել որոշակի տողերի YAML-ֆայլի, օբյեկտի, նշելով ներքին հարցեր օբյեկտի մասնագիտացման մեջ:

Կլաստերների որոնում Kubernetes Web View-ում

Միջադեպերի արձագանքում

Թողնում եք որոնման առկայություն (միավոր որոնում) թույլ է տալիս որոնել օբյեկտներ բոլոր կլաստերներում.
Ցուցակային ներկայացումներ մենակ կարող են ցուցադրել բոլոր օբյեկտները որոշակի վիճակ/սյունակով բոլոր կլաստերներում (օրինակ՝ մենք պետք է գտնենք բոլոր pod-ները ‘Pending’ կարգավիճակով):
Օբյեկտների ցուցակները կարելի է տեղադրել թվերի բաժանել-ով (TSV) ձևաչափով հետագա վերլուծության համար.
Ավելացված արտաքին հղումները թույլատրում են ուղիղ փոխվել համապատասխան մոնիտորինգի և այլ գործիքների միջև.

Kubernetes Web View: list of pods with status ‘Pending’ across all clusters

Եթե ցանկանում եք փորձել Kubernetes Web View, խորհուրդ եմ տալիս ծանոթանալ փաստաթղթի կամ դիտել խոշոր демонстрация.

Իհարկե, ինտերֆեյսը կարող էր ավելի լավը լինել, սակայն Kubernetes Web View-ը նախատեսված է «առաջադեմ օգտվողների» համար, ովքեր պատրաստ են ձեռքով կապակցել URL-ներին, եթե դա անհրաժեշտ է: Եթե ունեք մեկնաբանություններ/լրացումներ/ցանկություններ, խնդրում եմ կապվել իմ հետ Twitter-ում!

Այս հոդվածը կարճ պատմություն է այն նախադրյալների մասին, որոնք հանգեցրել են Kubernetes Web View-ի ստեղծմանը: Դրա հետևում կգան ուրիշները: (Համար. թարգմանություն.: Դրանք պետք է սպասել ծրագրի հեղինակային բլոգում.)