Пры запуску кластара Kubernetes для канкрэтнага прыкладання варта разумець, якія патрабаванні прадстаўляе да гэтага рэсурсу само дадатак, бізнес і распрацоўшчыкі. Пры наяўнасці гэтай інфармацыі можна прыступаць да прыняцця архітэктурнага рашэння і, у прыватнасці, да выбару пэўнага Ingress-кантролера, якіх на сённяшні дзень ужо вялікая колькасць. Каб скласці базавую паданне аб наяўных варыянтах без неабходнасці вывучаць мноства артыкулаў/дакументацыі і да т.п., мы і падрыхтавалі гэты агляд, улучыўшы ў яго асноўныя (production ready) Ingress-кантролеры.
Спадзяемся, што ён дапаможа калегам у выбары архітэктурнага рашэння - прынамсі, стане адпраўной кропкай для атрымання больш падрабязнай інфармацыі і практычных эксперыментаў. Папярэдне мы вывучылі іншыя падобныя матэрыялы ў сеткі і, як ні дзіўна, не выявілі ніводнага больш-менш поўнага, а галоўнае – структураванага – агляду. Такім чынам, запоўнім ж гэты прабел!
крытэрыі
Каб у прынцыпе праводзіць параўнанне і атрымаць колькі-небудзь карысны вынік, трэба разумець не проста прадметную вобласць, але і мець пэўны спіс крытэрыяў, якія і будуць задаваць вектар даследавання. Не прэтэндуючы на аналіз усіх магчымых выпадкаў прымянення Ingress / Kubernetes, мы пастараліся вылучыць найбольш агульныя патрабаванні да кантролераў – будзьце гатовыя, што ўсю сваю спецыфіку і прыватнасці ў любым выпадку давядзецца вывучаць асобна.
Але пачну з характарыстык, якія сталі настолькі звыклымі, што рэалізаваны ва ўсіх рашэннях і не разглядаюцца:
- дынамічнае выяўленне сэрвісаў (service discovery);
- SSL-тэрмініраванне;
- праца з websocket'амі.
Зараз - аб пунктах параўнання:
Падтрымліваюцца пратаколы
Адзін з асноўных крытэрыяў для выбару. Ваша ПЗ можа працаваць не па стандартным HTTP ці ж патрабаваць працу адразу па мностве пратаколаў. Калі ваш выпадак - нестандартны, абавязкова бярыце ў разлік гэты фактар, каб не прыйшлося потым пераналаджваць кластар. Ва ўсіх кантролераў спіс падтрымліваемых пратаколаў вар'іруецца.
ПЗ у аснове
Ёсць некалькі варыянтаў прыкладанняў, на якіх заснаваны кантролер. Папулярныя - гэта nginx, traefik, haproxy, envoy. У агульным выпадку, магчыма, не занадта ўплывае на тое, як прымаецца і перадаецца трафік, аднак заўсёды карысна ведаць патэнцыйныя нюансы і асаблівасці таго, што пад капотам .
Маршрутызацыя трафіку
На аснове чаго можна прымаць рашэнне аб накіраванні трафіку ў той ці іншы сэрвіс? Звычайна гэта host і path, але бываюць і дадатковыя магчымасці.
Прастора імёнаў у рамках кластара
Прастора імёнаў (namespace) - магчымасць лагічна разбіваць рэсурсы ў Kubernetes (напрыклад, на stage, production і да т.п.). Ёсць Ingress-кантролеры, якія трэба ставіць асобна ў кожны namespace (і тады ён можа накіроўваць трафік толькі у pod'ы гэтай прасторы). А ёсць такія (і іх відавочная большасць), што працуюць глабальна на ўвесь кластар - у іх трафік накіроўваецца ў любы pod кластара, незалежна ад прасторы імёнаў.
Пробы для upstream'аў
Якім чынам забяспечваецца накіраванне трафіку ў здаровыя экзэмпляры прыкладання, сэрвісаў? Ёсць варыянты з актыўнымі і пасіўнымі праверкамі, паўторнымі спробамі (retries), circuit breakers (падрабязней пра іх гл., напрыклад, у ), уласнымі рэалізацыямі праверак стану (custom health checks) і да т.п. Вельмі важны параметр, калі ў вас высокія патрабаванні да даступнасці і своечасовай высновы з балансавання якія адмовілі сэрвісаў.
Алгарытмы балансавання
Тут мноства варыянтаў: ад традыцыйных да экзатычных накшталт , а таксама асобныя магчымасці накшталт .
аўтэнтыфікацыя
Якія схемы аўтарызацыі падтрымлівае кантролер? Basic, digest, oauth, external-auth - думаю, што гэтыя опцыі павінны быць знаёмыя. Гэта важны крытэр, калі выкарыстоўваецца шмат контураў для распрацоўнікаў (і/ці проста зачыненых), доступ да якіх ажыццяўляецца праз Ingress.
Размеркаванне трафіку
Ці падтрымлівае кантролер такія часта прымяняюцца механізмы для размеркавання трафіку, як канарэечных выкаты (canary), A / B-тэставанне, люстраванне трафіку (mirroring/shadowing)? Гэта па-сапраўднаму балючая тэма для прыкладанняў, якія патрабуюць акуратнага і дакладнага кіравання трафіку для прадуктыўнага тэсціравання, адладкі прадуктовых памылак не на баі (або з мінімальнымі стратамі), аналізу трафіку і да т.п.
Платная падпіска
Ці ёсць платны варыянт у кантролера, з пашыранымі функцыянальнымі магчымасцямі і/ці тэхнічнай падтрымкай?
Графічны інтэрфейс (Web UI)
Ці маецца які-небудзь графічны інтэрфейс для кіравання канфігурацыяй кантролера? Галоўным чынам для «зручнасці» і/ці для тых, каму патрабуецца ўносіць нейкія змены ў канфігурацыю Ingress'а, але працаваць з «волкімі» шаблонамі няёмка. Можа спатрэбіцца ў выпадку, калі распрацоўшчыкі хочуць налёту праводзіць якія-небудзь эксперыменты з трафікам.
JWT-валідацыя
Наяўнасць убудаванай праверкі JSON web-токенаў для аўтарызацыі і валідацыі карыстальніка канчатковаму з дадаткам.
Магчымасці для кастамізацыі канфіга
Пашыральнасць шаблонаў у сэнсе наяўнасці механізмаў, якія дазваляюць дадаваць у стандартныя шаблоны канфігурацыі ўласныя дырэктывы, сцягі і г.д.
Базавыя механізмы абароны ад DDOS
Простыя алгарытмы rate limit ці больш складаныя варыянты адсявання трафіку на аснове адрасоў, белых спісаў, краін і г.д.
Трасіроўка запытаў
Магчымасці назірання, адсочвання і адладкі запытаў ад Ingress'аў да пэўных сэрвісаў/pod'ам, а ў ідэале - і паміж сэрвісамі/pod'амі таксама.
WAF
Падтрымка .
Кантралёры Ingress
Спіс кантролераў быў сфарміраваны на аснове и . Некаторыя з іх мы выключылі з агляду з прычыны спецыфічнасці ці малой распаўсюджанасці (ранняй стадыі развіцця). Астатнія ж разгледжаны ніжэй. Пачнём з агульнага апісання рашэнняў і працягнем зводнай табліцай.
Ingress ад Kubernetes
Сайт:
Ліцэнзія: Apache 2.0
Гэта афіцыйны кантролер для Kubernetes, які распрацоўваецца супольнасцю. Відавочна з назвы, ён заснаваны на nginx і дапоўнены розным наборам Lua-плагінаў, якія выкарыстоўваюцца для рэалізацыі дадатковага магчымасцяў. Дзякуючы папулярнасці самага nginx'а і мінімальных мадыфікацый над ім пры выкарыстанні ў якасці кантролера, гэты варыянт можа быць самым простым і зразумелым у канфігурацыі сярэднестатыстычным інжынерам (з досведам у web).
Ingress ад NGINX Inc
Сайт:
Ліцэнзія: Apache 2.0
Афіцыйны прадукт распрацоўшчыкаў nginx. Мае платную версію, заснаваную на . Асноўная ідэя – высокі ўзровень стабільнасці, пастаянная зваротная сумяшчальнасць, адсутнасць якіх-небудзь старонніх модуляў і заяўленая падвышаная хуткасць (у параўнанні з афіцыйным кантролерам), дасягнутая дзякуючы адмове ад Lua.
Бясплатная версія істотна падрэзана, у тым ліку нават пры параўнанні з афіцыйным кантролерам (з-за адсутнасці ўсё тых жа Lua-модуляў). Платная пры гэтым мае дастаткова шырокі дадатковы функцыянал: метрыкі ў рэальным часе, JWT-валідацыя, актыўныя health check'і і іншае. Важная перавага перад NGINX Ingress – паўнавартасная падтрымка TCP/UDP-трафіку (і ў community-версіі таксама!). Мінус - фіч па размеркаванні трафіку, што, зрэшты, "мае максімальны прыярытэт для распрацоўшчыкаў", але патрабуе часу на рэалізацыю.
Kong Ingress
Сайт:
Ліцэнзія: Apache 2.0
Прадукт, які распрацоўваецца кампаніяй Kong Inc. у двух варыянтах: камерцыйны і бясплатны. Заснаваны на nginx, магчымасці якога пашыраны вялікай колькасцю модуляў на Lua.
Першапачаткова быў арыентаваны на апрацоўку і маршрутызацыю запытаў API, г.зн. як API Gateway, аднак на дадзены момант стаў паўнавартасным Ingress-кантролерам. Асноўныя перавагі: мноства дадатковых модуляў (у тым ліку і ад іншых распрацоўшчыкаў), якія лёгка ставіць і канфігураваць і з дапамогай якіх рэалізуецца шырокі спектр дадатковых магчымасцей. Зрэшты, убудаваныя функцыі ўжо прапануюць шматлікія магчымасці. Канфігурацыя працы робіцца з дапамогай CRD-рэсурсаў.
Важная асаблівасць прадукта – праца ў рамках аднаго контуру (замест cross-namespaced) з'яўляецца спрэчнай тэмай: камусьці здасца недахопам (даводзіцца пладзіць сутнасці для кожнага контуру), а для кагосьці – фіча (больший ўзровень ізаляцыі, т. да. калі зламаны адзін кантролер, то праблема абмежавана адным толькі контурам).
Траефік
Сайт:
Ліцэнзія: MIT
Проксі, які першапачаткова ствараўся для працы з маршрутызацыяй запытаў для мікрасэрвісаў і іх дынамічнага асяроддзя. Адгэтуль і шматлікія карысныя магчымасці: абнаўленне канфігурацыі зусім без перазагрузак, падтрымка вялікай колькасці метадаў балансавання, вэб-інтэрфейс, пракід метрык, падтрымка розных пратаколаў, REST API, канарэечныя рэлізы і шматлікае іншае. Прыемнай асаблівасцю таксама з'яўляецца падтрымка сертыфікатаў Let's Encrypt са скрынкі. Недахоп - для арганізацыі высокай даступнасці (HA) у кантролера запатрабуецца ўсталёўваць і падлучаць уласнае KV-сховішча.
HAProxy
Сайт:
Ліцэнзія: Apache 2.0
HAProxy даўно вядомы ў якасці проксі і балансавальніка трафіку. У рамках кластара Kubernetes з ім прапануецца "мяккае" абнаўленне канфігурацыі (без страты трафіку), service discovery на аснове DNS, дынамічная канфігурацыя з дапамогай API. Прывабным можа стаць поўная кастамізацыя шаблону канфігаў з дапамогай замены CM'а, а таксама магчымасці выкарыстання ў ім функцый бібліятэкі Sprig. У цэлым жа асноўны акцэнт рашэння робіцца на высокую скорасць работы, яго аптымізаванасць і эфектыўнасць у спажываемых рэсурсах. Перавага кантролера - падтрымка рэкорднага ліку розных спосабаў балансавання.
Падарожнік
Сайт:
Ліцэнзія: Apache 2.0
Заснаваны на HAproxy кантролер, які пазіцыянуецца як універсальнае рашэнне, якое падтрымлівае шырокія магчымасці на вялікай колькасці правайдэраў. Прапануецца магчымасць для балансавання трафіку на L7 і L4, а балансаванне TCP L4-трафіку ў цэлым можна назваць адной з ключавых фіч рашэння.
контур
Сайт:
Ліцэнзія: Apache 2.0
У аснову гэтага рашэння не толькі лёг Envoy: яно распрацавана сумесна з аўтарамі гэтага папулярнага проксі. Важная асаблівасць - магчымасць падзелу кіравання рэсурсамі Ingress з дапамогай CRD-рэсурсаў IngressRoute. Для арганізацый са мноствам каманд распрацоўкі, выкарыстоўвалых адзін кластар, гэта дапамагае максімальна засцерагчы працу з трафікам у суседніх контурах і абараніць іх ад памылак пры змене рэсурсаў Ingress.
Таксама прапануецца пашыраны набор метадаў балансавання (прысутнічае люстраванне запытаў, аўтапаўторы, абмежаванне па rate'у запытаў і шматлікае іншае), дэталёвы маніторынг струменя трафіку і збояў. Магчыма, для кагосьці будзе істотным недахопам адсутнасць падтрымкі sticky sessions (хоць працы ).
Istio Ingress
Сайт:
Ліцэнзія: Apache 2.0
Комплекснае service mesh-рашэнне, якое з'яўляецца не толькі Ingress-кантролерам, які кіруе паступаючым трафікам звонку, але і кантралюе ўвесь трафік у рамках кластара. Пад капотам , у якасці sidecar-проксі для кожнага сэрвісу, выкарыстоўваецца Envoy. Па сутнасці гэта вялікі камбайн, які "можа ўсё", а асноўная яго ідэя - максімальная кіравальнасць, пашыральнасць, бяспека і празрыстасць. З яго дапамогай вы можаце ў тонкасцях наладжваць маршрутызацыю трафіку, аўтарызацыю доступу паміж сэрвісамі, балансаванне, маніторынг, канарэечныя рэлізы і шматлікае іншае. Падрабязней пра Istio чытайце ў серыі артыкулаў «.
Пасол
Сайт:
Ліцэнзія: Apache 2.0
Яшчэ адно рашэнне на аснове Envoy. Мае бясплатную і камерцыйную версіі. Пазіцыянуецца як "цалкам роднае для Kubernetes", што прыносіць адпаведныя перавагі (цесная інтэграцыя з метадамі і сутнасцямі кластара K8s).
параўнальная табліца
Такім чынам, кульмінацыя артыкула - гэта велізарная табліца:
Яна клікабельная для магчымасці больш дэталёвага прагляду, а таксама даступная ў фармаце .
падвядзем вынікі
Мэта артыкула - даць больш поўнае разуменне (зрэшты, зусім не вычарпальнае!) таго, які выбар зрабіць у вашым канкрэтным выпадку. Як звычайна бывае, кожны кантролер мае свае добрыя якасці і недахопы…
Класічны Ingress ад Kubernetes добры сваёй даступнасцю і праверанасцю, дастаткова багатымі магчымасцямі – у агульным выпадку яго павінна «хапіць за вочы». Аднак, калі ёсць падвышаныя патрабаванні да стабільнасці, узроўню фіч і распрацоўкі, варта звярнуць увагу на Ingress з NGINX Plus і платнай падпіскай. Kong мае найбагацейшы набор плагінаў (і, адпаведна, якія забяспечваюцца імі магчымасцяў), прычым у платнай версіі іх нават больш. У яго шырокія магчымасці па працы ў якасці API Gateway, дынамічнага канфігуравання на аснове CRD-рэсурсаў, а таксама базавых сервісаў Kubernetes.
Пры падвышаных патрабаваннях да балансавання і метадам аўтарызацыі прыгледзьцеся да Traefik і HAProxy. Гэта Open Source-праекты, правераныя гадамі, вельмі стабільныя і актыўна якія развіваюцца. Contour з'явіўся ўжо пару гадоў як на святло, але выглядае ўсё яшчэ занадта маладо і мае толькі базавыя магчымасці, дададзеныя па-над Envoy. Калі ёсць патрабаванні па наяўнасці / убудаванні WAF перад дадаткам, варта звярнуць увагу на той жа Ingress ад Kubernetes або HAProxy.
А самыя багатыя па функцый – гэта прадукты, пабудаваныя на базе Envoy, асабліва Istio. Ён уяўляецца комплексным рашэннем, які "можа ўсё", што, зрэшты, азначае і значна больш высокі парог уваходжання па канфігурацыі/запуску/адміністраванні, чым у іншых рашэнняў.
Намі ў якасці стандартнага кантролера быў абраны і да гэтага часу выкарыстоўваецца Ingress ад Kubernetes, які пакрывае 80-90% патрэбаў. Ён суцэль надзейны, лёгка канфігуруецца, пашыраецца. У агульным выпадку, пры адсутнасці спецыфічных патрабаванняў, ён павінен падысці большасці кластараў/прыкладанняў. З такіх жа ўніверсальных і адносна простых прадуктаў можна парэкамендаваць Traefik і HAProxy.
PS
Чытайце таксама ў нашым блогу:
- «Назад да мікрасэрвісаў разам з Istio»: , , ;
- «»;
- «.
Крыніца: habr.com