Заўв. перав.: Аўтар арыгінальнага матэрыялу - Henning Jacobs з кампаніі Zalando. Ён стварыў новы вэб-інтэрфейс для працы з Kubernetes, які пазіцыянуецца як "kubectl для вэба". Чаму новы Open Source-праект з'явіўся і якім крытэрам не задаволілі ўжо існуючыя рашэнні - чытайце ў яго артыкуле.
У гэтай публікацыі я разглядаю розныя вэб-інтэрфейсы Kubernetes з адчыненым зыходным кодам, прад'яўляю свае патрабаванні да ўніверсальнага UI і распавядаю, чаму распрацаваў - інтэрфейс, закліканы палегчыць падтрымку і ўхіленне непаладак адразу ў мностве кластараў.
Сцэнары выкарыстання
У Zalando мы абслугоўваем вялікую колькасць карыстальнікаў Kubernetes (900+) і кластараў (100+). Ёсць пара тыповых выпадкаў выкарыстання, у якіх бы вельмі спатрэбілася дапамога спецыялізаванага вэб-прылады:
- зносіны з калегамі ў рамках падтрымкі;
- рэагаванне на інцыдэнты і расследаванне іх прычын.
Падтрымка
На маю вопыту, зносіны ў рамках падтрымкі часта выглядае наступным чынам:
- Дапамажыце, наш сэрвіс XYZ недаступны!
- Што вы бачыце, калі выконваеце kubectl describe ingress ...?
Або нешта падобнае для CRD:
- У мяне нейкая праблема з сэрвісам ідэнтыфікацыі…
- А што выдае каманда kubectl describe platformcredentialsset ...?
Такія зносіны звычайна зводзіцца да ўводу розных варыяцый каманды kubectl з мэтай устанавіць праблему. У выніку абодва бакі размовы вымушаны пастаянна пераключацца паміж тэрміналам і вэб-чатам, плюс яны назіраюць розную сітуацыю.
Таму хочацца, каб вэб-франтэнд да Kubernetes дазваляў наступнае:
- карыстальнікі маглі б абменьвацца спасылкамі і назіраць адно і тое ж;
- дапамагаў бы пазбягаць чалавечых памылак у падтрымцы: напрыклад, уваходу не ў той кластар у камандным радку, памылак друку ў камандах CLI і т. п.;
- дазваляў бы генераваць уласныя ўяўленні для адпраўкі калегам, гэта значыць дадаваць слупкі пазнак, адлюстроўваць мноства тыпаў рэсурсаў на адной старонцы;
- у ідэале гэты вэб-інструмент павінен дазваляць ставіць "глыбокія" спасылкі на канкрэтныя раздзелы YAML (напрыклад, паказваць на няправільны параметр, які выклікае збоі).
Рэагаванне на інцыдэнты і аналіз
Рэагаванне на інцыдэнты ў інфраструктуры патрабуе наяўнасці сітуацыйнай дасведчанасці, здольнасці ацэньваць уздзеянне і пошуку заканамернасцяў у кластарах. Некаторыя прыклады з рэальнага жыцця:
- у крытычна важнага production-сэрвісу ўзнікаюць праблемы і вам неабходна знайсці ўсе рэсурсы Kubernetes па імені ва ўсіх кластарах, Каб ухіліць непаладкі;
- вузлы пачынаюць падаць пры маштабаванні, і вам неабходна знайсці ўсе pod'ы са статусам «Pending» ва ўсіх кластарах, Каб ацаніць размах праблемы;
- асобныя карыстачы паведамляюць аб праблеме з DaemonSet, разгорнутым ва ўсіх кластарах, і неабходна высветліць, ці мае праблема татальны характар.
Маё стандартнае рашэнне ў такіх выпадках - нешта накшталт for i in $clusters; do kubectl ...; done. Відавочна, можна распрацаваць прыладу, які прадстаўляе аналагічныя магчымасці.
Існуючыя вэб-інтэрфейсы Kubernetes
Open Source-свет вэб-інтэрфейсаў да Kubernetes не занадта вялікі*, так што я паспрабаваў сабраць дадатковую інфармацыю з дапамогай :
* Маё тлумачэнне абмежаванай колькасці вэб-інтэрфейсаў для Kubernetes: хмарныя сэрвісы і вендары Kubernetes звычайна прапануюць уласныя франтэнды, таму рынак для «добрых» вольных Kubernetes UI параўнальна невялікі.
З дапамогай твіту я даведаўся пра , и . Паглядзім на іх і іншыя існыя Open Source-рашэнні, паспрабуем зразумець, што яны сабой уяўляюць.
K8Dash
K8Dash гэта найпросты спосаб кіраваць кластарам Kubernetes .
нядрэнна выглядае і па адчуваннях хутка працуе, але валодае шэрагам недахопаў для пералічаных вышэй сцэнараў выкарыстання:
- Працуе толькі ў межах аднаго кластара.
- Сартаванне і фільтраванне магчымыя, але не маюць пастаянных спасылак.
- Адсутнічае падтрымка Custom Resource Definitions (CRDs).
Kubernator
«Kubernator – гэта альтэрнатыўны UI для Kubernetes. У адрозненне ад высокаўзроўневай панэлі Kubernetes Dashboard, ён забяспечвае нізкаўзроўневы кантроль і выдатны агляд усіх аб'ектаў у кластары з магчымасцю ствараць новыя, рэдагаваць іх і вырашаць канфлікты. Будучы цалкам кліенцкім дадаткам (як kubectl), ён не патрабуе які-небудзь бэкенда за выключэннем самога API-сервера Kubernetes, а таксама ўлічвае правілы доступу да кластара».
Гэта даволі дакладнае апісанне . Нажаль, яму бракуе некаторых магчымасцяў:
- Абслугоўвае толькі адзін кластар.
- Няма рэжыму прагляду ў выглядзе спісу (т. е. нельга вывесці ўсе pod'ы са статутам «Pending»).
Прыборная панэль Kubernetes
«Kubernetes Dashboard – гэта ўніверсальны вэб-інтэрфейс для кластараў Kubernetes. Ён дазваляе карыстальнікам кіраваць праграмамі, якія працуюць у кластары, і ўстараняць іх непаладкі, а таксама кіраваць самім кластарам».
На жаль, не асабліва дапамагае ў маіх мерапрыемствах па падтрымцы і рэагаванні на інцыдэнты, таму што ў ім:
- няма пастаянных спасылак, напрыклад, калі я фільтрую рэсурсы або мяняю парадак сартавання;
- няма простага спосабу фільтраваць па статусе - напрыклад, убачыць усе pod'ы са статусам «Pending»;
- падтрымліваецца толькі адзін кластар;
- не падтрымліваюцца CRD (гэтая функцыя ў працэсе распрацоўкі);
- няма карыстацкіх слупкоў (напрыклад, слупкоў з пазнакамі па тыпе
kubectl -L).
Kubernetes Operational View (kube-ops-view)
"Сістэмная панэль-назіральнік за прасторай кластараў K8s".
У зусім іншы падыход: гэтая прылада толькі паказвае вузлы кластара і pod'ы з дапамогай WebGL, без якія-небудзь тэкставых падрабязнасцяў аб'ектаў. Ён выдатна падыходзіць для аператыўнага агляду стану кластара («pod'ы падаюць?»)*, але не падыходзіць для апісаных вышэй выпадкаў выкарыстання ў падтрымцы і рэагаванні на інцыдэнты.
* Заўв. перав.: У гэтым сэнсе вас таксама можа зацікавіць наша плягін. , пра які мы расказвалі падрабязней у .
Kubernetes Resource Report (kube-resource-report)
"Збірайце звесткі аб запытах на рэсурсы pod'аў і кластара Kubernetes, параўноўвайце іх са спажываннем рэсурсаў і генеруйце статычны HTML".
генеруе статычныя HTML-справаздачы аб выкарыстанні рэсурсаў і размеркаванні выдаткаў па камандам/прыкладанням у кластарах. Справаздача ў некаторай ступені карысны для падтрымкі і рэагавання на інцыдэнты, паколькі дазваляе хутчэй знайсці кластар, у якім разгорнута дадатак.
Заўв. перав.: У праглядзе звестак аб размеркаванні рэсурсаў і іх кошце ў хмарных правайдэраў можа таксама апынуцца карысным сэрвіс і інструмент , агляд якога мы .
Актант
"Пашыраецца вэб-платформа для распрацоўшчыкаў, закліканая забяспечыць лепшае разуменне складанасці кластараў Kubernetes".
, Створаны ў VMware, – новы прадукт, пра які я даведаўся параўнальна нядаўна. З яго дапамогай зручна даследаваць кластар на лакальнай машыне (ёсць нават візуалізацыі), аднак ён закранае праблематыку падтрымкі і рэагаванні на інцыдэнты толькі ў абмежаванай ступені. Недахопы Octant:
- Няма пошуку па кластарах.
- Працуе толькі на лакальнай машыне (не разгортваецца ў кластары).
- Немагчыма сартаваць/фільтраваць аб'екты (падтрымліваецца толькі селектар метак).
- Нельга задаваць карыстацкія слупкі.
- Нельга выводзіць спіс аб'ектаў па прасторах імёнаў.
Таксама ў мяне быў праблемы з устойлівасцю працы Octant з кластарамі Zalando: на некаторых CRD .
Уяўляю Kubernetes Web View
"kubectl для вэба".
Прааналізаваўшы даступныя варыянты інтэрфейсаў для Kubernetes, я вырашыў стварыць новы: . Бо ў сутнасці мне ўсяго толькі патрэбна ўся моц kubectl у вэбе, а менавіта:
- даступнасць усіх (read-only) аперацый, у якіх карыстачы аддаюць перавагу выкарыстоўваць kubectl;
- усе URL павінны быць сталымі і прадстаўляць старонку ў арыгінальным выглядзе, каб калегі маглі абменьвацца імі і выкарыстоўваць у іншых інструментах;
- падтрымка ўсіх аб'ектаў Kubernetes, што дасць магчымасць вырашаць праблему любога тыпу;
- спісы рэсурсаў павінны быць пампаванымі для далейшай працы (у электронных табліцах, CLI-інструментах накшталт
grep) і захоўвання (напрыклад, для postmortem'ов); - падтрымка адбору рэсурсаў па лэйблах (па аналогіі з
kubectl get .. -l); - магчымасць ствараць аб'яднаныя спісы розных тыпаў рэсурсаў (па аналогіі з
kubectl get all) для атрымання агульнай аперацыйнай карціны сярод калег (напрыклад, у працэсе рэакцыі на інцыдэнт); - магчымасць дадаваць наладжвальныя "разумныя" глыбокія спасылкі да іншых інструментаў, такім як панэлі маніторынгу, логгеры, рэестры прыкладанняў і да т.п. для палягчэння пошуку/ліквідавання памылак і рэагавання на інцыдэнты;
- франтэнд павінен быць максімальна простым (чысты HTML), каб пазбегнуць выпадковых праблем, напрыклад, які завіс JavaScript;
- падтрымка мноства кластараў для спрашчэння ўзаемадзеяння пры выдаленым кансультаванні (напрыклад, каб запамінаць толькі адзін URL);
- пры магчымасці павінен спрашчацца сітуатыўны аналіз (напрыклад, са спасылкамі на запампоўку рэсурсаў па ўсіх кластарах/прасторах імёнаў);
- дадатковыя магчымасці па фарміраванні гнуткіх спасылак і выдзяленні тэкставай інфармацыі, напрыклад, каб можна было ўказаць калегам на пэўны раздзел у апісанні рэсурсу (радок у YAML);
- магчымасць падладкі пад патрабаванні канкрэтнага кліента, напрыклад, дазваляючы ствараць спецыяльныя шаблоны адлюстравання для CRD, свае таблічныя ўяўленні, змяняць CSS-стылі;
- сродкі для далейшага вывучэння ў камандным радку (напрыклад, паказваючы паўнавартасныя каманды
kubectl, гатовыя для капіявання);
Па-за развязальных у Kubernetes Web View задач (non-goals) засталіся:
- абстрагаванне аб'ектаў Kubernetes;
- кіраванне праграмамі (напрыклад, кіраванне deployment'амі, Helm-чартамі і да т.п.);
- аперацыі запісы (павінны ажыццяўляцца праз бяспечны інструментар CI/CD і/ці GitOps);
- прыгожы інтэрфейс (JavaScript, тэмы і да т.п.);
- візуалізацыі (гл. );
- аналіз затрат (гл. ).
Як Kubernetes Web View дапамагае ў падтрымцы і рэагаванні на інцыдэнты?
Падтрымка
- Усе спасылкі - сталыя, Што палягчае абмен інфармацыяй з калегамі.
- Можна ствараць свае ўяўленні, напрыклад, вывесці ўсе Deployment'ы і Pod'ы з пэўнай пазнакай у двух канкрэтных кластарах (некалькі імёнаў кластараў і тыпаў рэсурсаў можна задаваць у спасылцы, падзяляючы іх коскамі).
- Можна спасылацца на пэўныя радкі ў YAML-файле аб'екта, паказваючы на патэнцыйныя праблемы ў спецыфікацыі аб'екта.
Пошук па кластарах у Kubernetes Web View
Рэагаванне на інцыдэнты
- Глабальны пошук (global search) дазваляе шукаць аб'екты ва ўсіх кластарах.
- Уяўленні ў выглядзе спісаў могуць адлюстроўваць усе аб'екты з вызначаным станам/слупком ва ўсіх кластарах (напрыклад, нам трэба знайсці ўсе pod'ы са статутам «Pending»).
- Спісы аб'ектаў можна спампоўваць у фармаце значэнняў, падзеленых табуляцыяй (TSV), для наступнага аналізу.
- дазваляюць перамыкацца на якія адпавядаюць панэлі маніторынгу і іншыя прылады.
Kubernetes Web View: спіс pod'аў са статусам "Pending" ва ўсіх кластарах
Калі жадаеце паспрабаваць Kubernetes Web View, раю азнаёміцца з ці паглядзець на .
Вядома, інтэрфейс мог бы быць і лепей, а пакуль Kubernetes Web View з'яўляецца прыладай для "прасунутых карыстальнікаў", якія не цураюцца маніпулявання з URL-шляхамі ўручную, калі гэта неабходна. Калі ў вас ёсць заўвагі/дапаўненні/пажаданні, калі ласка, звяжыцеся !
Гэты артыкул з'яўляецца кароткім аповядам аб перадумовах, якія прывялі да стварэння Kubernetes Web View. За ёй рушаць услед іншыя! (Заўв. перав.: Іх трэба чакаць у .)
PSад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com