Преглед и сравнение на Ingress контролери за Kubernetes

Когато стартирате Kubernetes клъстер за конкретно приложение, трябва да разберете какво представлява самото приложение, бизнесът и разработчиците за този ресурс. С тази информация можете да започнете да вземате архитектурно решение и по-специално да изберете конкретен контролер Ingress, от който днес вече има голям брой. За да получите основна представа за наличните опции, без да се налага да преглеждате много статии / документация и т.н., подготвихме този преглед, включително основните (готови за производство) Ingress контролери.

Надяваме се, че ще помогне на колегите при избора на архитектурно решение - поне ще стане отправна точка за получаване на по-подробна информация и практически експерименти. Преди това изучавахме други подобни материали в мрежата и, колкото и да е странно, не намерихме нито един повече или по-малко пълен и най-важното - структуриран преглед. Така че нека запълним тази празнина!

критерии

По принцип, за да направите сравнение и да получите някакъв полезен резултат, трябва да разберете не само предметната област, но и да имате конкретен списък от критерии, които ще определят вектора на изследването. Без да се преструваме, че анализираме всички възможни случаи на използване на Ingress / Kubernetes, ние се опитахме да подчертаем най-общите изисквания към контролерите - бъдете готови, че във всеки случай ще трябва да изучавате всичките си специфики и подробности отделно.

Но ще започна с характеристиките, които са станали толкова познати, че са внедрени във всички решения и не се вземат предвид:

• динамично откриване на услуги (откриване на услуги);
• SSL терминиране;
• работа с websockets.

Сега за точките за сравнение:

Поддържани протоколи

Един от основните критерии за избор. Вашият софтуер може да не работи на стандартен HTTP или може да изисква работа по няколко протокола едновременно. Ако вашият случай е нестандартен, не забравяйте да вземете предвид този фактор, за да не се налага да преконфигурирате клъстера по-късно. За всички контролери списъкът с поддържани протоколи варира.

софтуер в основата

Има няколко варианта на приложения, на които се базира контролерът. Популярни са nginx, traefik, haproxy, envoy. В общия случай може да няма голям ефект върху начина на получаване и предаване на трафика, но винаги е полезно да знаете потенциалните нюанси и характеристики на това, което е „под капака“.

Маршрутизиране на трафика

Въз основа на какво е възможно да се вземе решение за посоката на трафика към определена услуга? Обикновено това са хост и път, но има и допълнителни възможности.

Пространство от имена в клъстер

Пространство от имена (пространство от имена) - способността за логическо разделяне на ресурсите в Kubernetes (например на сцената, производството и т.н.). Има Ingress контролери, които трябва да бъдат инсталирани отделно във всяко пространство от имена (и след това може да насочва трафика само към капсулите на това пространство). И има такива (и тяхното очевидно мнозинство), които работят глобално за целия клъстер - при тях трафикът се насочва към всеки под на клъстера, независимо от пространството на имената.

Образци за горни течения

Как се насочва трафикът към здрави копия на приложението, услугите? Има опции с активни и пасивни проверки, повторни опити, прекъсвачи (За повече подробности вижте напр. статия за Istio), собствени реализации на здравни проверки (персонализирани здравни проверки) и др. Много важен параметър, ако имате високи изисквания за наличност и своевременно премахване на неуспешни услуги от балансиране.

Алгоритми за балансиране

Има много опции: от традиционните обиколка към екзотиката rdp-бисквитка, както и отделни характеристики като лепкави сесии.

заверка

Какви схеми за оторизация поддържа контролерът? Basic, digest, oauth, external-auth - мисля, че тези опции трябва да са познати. Това е важен критерий, ако има много цикли за разработчици (и/или само частни), които са достъпни чрез Ingress.

Разпределение на трафика

Контролерът поддържа ли такива често използвани механизми за разпределение на трафика като канарчета (canary), A / B тестване, отразяване на трафика (огледало / засенчване)? Това е наистина болна тема за приложения, които изискват точно и прецизно управление на трафика за продуктивно тестване, отстраняване на грешки в продукта офлайн (или с минимални загуби), анализ на трафика и т.н.

Платен абонамент

Има ли платена опция за контролера, с разширена функционалност и/или техническа поддръжка?

Графичен потребителски интерфейс (Web UI)

Има ли GUI за управление на конфигурацията на контролера? Основно за "удобство" и / или за тези, които трябва да направят някои промени в конфигурацията на Ingress'a, но работата със "сурови" шаблони е неудобна. Може да бъде полезно, ако разработчиците искат да проведат някои експерименти с трафика в движение.

JWT валидиране

Наличието на вградена валидация на JSON уеб токени за авторизация и валидиране на потребителя до крайното приложение.

Възможности за персонализиране на конфигурацията

Разширяемост на шаблона в смисъл на наличие на механизми, които ви позволяват да добавяте свои собствени директиви, флагове и т.н. към стандартните шаблони за конфигурация.

Основни DDOS механизми за защита

Прости алгоритми за ограничаване на скоростта или по-сложни опции за филтриране на трафик въз основа на адреси, бели списъци, държави и т.н.

Заявка за проследяване

Възможността за наблюдение, проследяване и отстраняване на грешки на заявки от Ingresses към конкретни услуги/pods, и в идеалния случай също между услуги/pods.

WAF

Подкрепа защитна стена на приложението.

Контролери

Списъкът на контрольорите е формиран въз основа на официална документация на Kubernetes и тази таблица. Изключихме някои от тях от прегледа поради специфичност или ниско разпространение (ранен стадий на развитие). Останалите са обсъдени по-долу. Нека започнем с общо описание на решенията и продължим с обобщена таблица.

Влизане от Kubernetes

Уебсайт: github.com/kubernetes/ingress-nginx
Лиценз: Apache 2.0

Това е официалният контролер за Kubernetes и се разработва от общността. Очевидно от името, той е базиран на nginx и е допълнен от различен набор от Lua плъгини, използвани за внедряване на допълнителни функции. Поради популярността на самия nginx и минималните му модификации, когато се използва като контролер, тази опция може да е най-лесната и лесна за конфигуриране за обикновения инженер (с уеб опит).

Ingress от NGINX Inc.

Уебсайт: github.com/nginxinc/kubernetes-ingress
Лиценз: Apache 2.0

Официалният продукт на разработчиците на nginx. Има платена версия, базирана на NGINX Plus. Основната идея е високо ниво на стабилност, постоянна обратна съвместимост, липса на външни модули и декларирана повишена скорост (в сравнение с официалния контролер), постигната поради отхвърлянето на Lua.

Безплатната версия е значително намалена, включително дори в сравнение с официалния контролер (поради липсата на същите модули Lua). В същото време платеният има доста широка допълнителна функционалност: показатели в реално време, JWT валидиране, активни проверки на здравето и др. Важно предимство пред NGINX Ingress е пълната поддръжка на TCP / UDP трафик (и във версията на общността също!). минус - отсъствие функция за разпределение на трафика, която обаче „има най-висок приоритет за разработчиците“, но отнема време за внедряване.

Kong Ingress

Уебсайт: github.com/Kong/kubernetes-ingress-controller
Лиценз: Apache 2.0

Продукт, разработен от Kong Inc. в две версии: комерсиална и безплатна. Базиран на nginx, който е разширен с голям брой Lua модули.

Първоначално той беше фокусиран върху обработката и маршрутизирането на API заявки, т.е. като API Gateway, но в момента се е превърнал в пълноценен Ingress контролер. Основни предимства: много допълнителни модули (включително от разработчици на трети страни), които са лесни за инсталиране и конфигуриране и с помощта на които се реализира широк набор от допълнителни функции. Вградените функции обаче вече предлагат много възможности. Конфигурирането на задание се извършва с помощта на CRD ресурси.

Важна характеристика на продукта - работата в рамките на един и същ контур (вместо кръстосано пространство от имена) е спорна тема: за някои ще изглежда като недостатък (трябва да създавате обекти за всеки контур), а за някой това е функция ( bоПо-високо ниво на изолация, като ако единият контролер е повреден, тогава проблемът е ограничен само до веригата).

Траефик

Уебсайт: github.com/containous/traefik
Лиценз: MIT

Прокси, който първоначално е създаден, за да работи с маршрутизиране на заявки за микроуслуги и тяхната динамична среда. Оттук много полезни функции: актуализиране на конфигурацията без изобщо да рестартирате, поддръжка за голям брой методи за балансиране, уеб интерфейс, пренасочване на показатели, поддръжка за различни протоколи, REST API, версии на Canary и много други. Друга хубава функция е поддръжката на Let's Encrypt сертификати от кутията. Недостатъкът е, че за да организира висока наличност (HA), контролерът ще трябва да инсталира и свърже собствено KV хранилище.

HAProxy

Уебсайт: github.com/jcmoraisjr/haproxy-ingress
Лиценз: Apache 2.0

HAProxy отдавна е известен като прокси и балансиращ трафик. Като част от Kubernetes клъстер, той предлага „мека“ актуализация на конфигурацията (без загуба на трафик), откриване на услуги на базата на DNS, динамична конфигурация с помощта на API. Може да бъде привлекателно напълно да персонализирате шаблона за конфигурация чрез замяна на CM, както и възможността да използвате функциите на библиотеката Sprig в него. Като цяло, основният акцент на решението е върху високата скорост, нейната оптимизация и ефективност в изразходваните ресурси. Предимството на контролера е поддръжката на рекорден брой различни методи за балансиране.

Пътник в космоса

Уебсайт: github.com/appscode/voyager
Лиценз: Apache 2.0

Базиран на HAproxy контролер, който е позициониран като универсално решение, което поддържа широк набор от функции на голям брой доставчици. Предлага се възможност за балансиране на трафика на L7 и L4, а балансирането на TCP L4 трафик като цяло може да се нарече една от ключовите характеристики на решението.

контура

Уебсайт: github.com/heptio/contour
Лиценз: Apache 2.0

Това решение не се основава само на Envoy: то е разработено от съвместно с авторите на това популярно прокси. Важна характеристика е възможността за отделно управление на ресурсите на Ingress с помощта на ресурсите на IngressRoute CRD. За организации с много екипи за разработка, използващи един и същ клъстер, това помага да се увеличи максимално сигурността при работа с трафик в съседни цикли и да ги предпази от грешки при промяна на ресурсите на Ingress.

Той също така предлага разширен набор от методи за балансиране (има огледално копиране на заявки, автоматично повторение, ограничаване на скоростта на заявките и много други), подробен мониторинг на потока на трафика и повреди. Може би за някой ще бъде значителен недостатък липсата на поддръжка за лепкави сесии (въпреки че работата вече е в ход).

Istio Ingress

Уебсайт: istio.io/docs/tasks/traffic-management/ingress
Лиценз: Apache 2.0

Цялостно мрежово решение за услуга, което е не само Ingress контролер, който управлява входящия трафик отвън, но също така контролира целия трафик в рамките на клъстера. Под капака, Envoy се използва като помощно средство за всяка услуга. По същество това е голям комбинат, който „може всичко“, а основната му идея е максимална управляемост, разширяемост, сигурност и прозрачност. С него можете да настроите фино маршрутизирането на трафика, разрешение за достъп между услугите, балансиране, наблюдение, освобождаване на канари и много други. Прочетете повече за Istio в поредицата от статии "Обратно към микроуслугите с Istio".

Посланик

Уебсайт: github.com/datawire/ambassador
Лиценз: Apache 2.0

Друго решение, базирано на Envoy. Има безплатни и търговски версии. Той е позициониран като „напълно естествен за Kubernetes“, което носи съответните предимства (тясна интеграция с методите и обектите на клъстера K8s).

Таблица за сравнение

И така, кулминацията на статията е тази огромна таблица:

Може да се кликне за по-близък преглед и също така е наличен във формат Google Таблици.

За да обобщим

Целта на тази статия е да предостави по-пълно разбиране (но в никакъв случай не изчерпателно!) за това какъв избор да направите във вашия конкретен случай. Както обикновено, всеки контролер има своите предимства и недостатъци...

Класическият Ingress от Kubernetes е добър за своята наличност и доказаност, достатъчно богати функции - в общия случай трябва да е „достатъчно за очите“. Въпреки това, ако има повишени изисквания за стабилност, ниво на функции и развитие, трябва да обърнете внимание на Ingress с NGINX Plus и платен абонамент. Kong има най-богатия набор от плъгини (и съответно възможностите, които предоставят), а в платената версия те са още повече. Има широки възможности за работа като API Gateway, динамична конфигурация, базирана на CRD ресурси, както и основни услуги на Kubernetes.

С повишени изисквания за балансиране и методи за оторизация, погледнете Traefik и HAProxy. Това са проекти с отворен код, доказали се през годините, много стабилни и активно развиващи се. Contour е на пазара от няколко години, но все още изглежда твърде млад и има само основни функции, добавени към Envoy. Ако има изисквания за наличието / вграждането на WAF пред приложението, трябва да обърнете внимание на същия Ingress от Kubernetes или HAProxy.

И най-богатите по отношение на функции са продуктите, изградени върху Envoy, особено Istio. Изглежда, че е всеобхватно решение, което „може да прави всичко“, което обаче означава и значително по-висок входен праг за конфигуриране/стартиране/администриране в сравнение с други решения.

Избрахме и все още използваме Ingress от Kubernetes като стандартен контролер, който покрива 80-90% от нуждите. Той е доста надежден, лесен за конфигуриране и разширяване. Като цяло, при липса на специфични изисквания, той трябва да отговаря на повечето клъстери / приложения. От същите универсални и сравнително прости продукти могат да се препоръчат Traefik и HAProxy.

PS

Прочетете също в нашия блог:

• „Назад към микроуслугите с Istio“: част 1 (въведение в основните характеристики), част 2 (маршрутизиране, контрол на трафика), част 3 (удостоверяване и оторизация);
• «Съвети и трикове на Kubernetes: персонализирани страници за грешки в NGINX Ingress»;
• «Съвети и трикове на Kubernetes: достъп до сайтове за разработчици".

Източник: www.habr.com