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

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

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

Критерии

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

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

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

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

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

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

ПО в основата

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

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

На каква основа може да се вземе решение за посоката на трафика към определен сървис? Обикновено това са host и path, но има и допълнителни възможности.

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

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

Проби за upstream-ове

Как се осигурява насочването на трафика към здрави инстанции на приложението, сървисите? Има варианти с активни и пасивни проверки, повторни опити (retries), circuit breakers (повече за тях вижте, например, в статията за Istio), собствени реализации на проверки за состояние (custom health checks) и т.н. Това е много важен параметър, особено ако имате високи изисквания към наличността и навременния изключване на повредени сървиси от балансирането.

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

Има множество варианти: от традиционни round-robin до екзотични като rdp-cookie, както и отделни възможности като sticky sessions.

Аутентикация

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

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

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

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

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

Графичен интерфейс (Web UI)

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

JWT валидация

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

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

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

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

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

Проследяване на заявки

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

WAF

Поддръжка прикладен firewall.

Контролери Ingress

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

Ingress от 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 трафик (и в community версията също!). Недостатък — отсъствие на функции за разпределение на трафика, което обаче „има максимален приоритет за разработчиците“, но изисква време за реализация.

Kong Ingress

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

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

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

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

Traefik

Сайт: github.com/containous/traefik
Лицензия: MIT

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

HAProxy

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

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

Voyager

Сайт: github.com/appscode/voyager
Лицензия: Apache 2.0

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

Contour

Сайт: github.com/heptio/contour
Лицензия: Apache 2.0

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

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

Istio Ingress

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

Комплексно решение за service mesh, което не е само Ingress контролер, управляващ входящия трафик, а също така контролира целия трафик в рамките на клъстера. Под капака, за всеки сервис се използва Envoy като sidecar прокси. По същество това е голям комбайн, който „може всичко“, а основната му идея е максимална управляемост, разширяемост, сигурност и прозрачност. С негова помощ можете в детайли да настройвате маршрутизацията на трафика, авторизацията на достъпа между услугите, балансирането, мониторинга, канарейните версии и много друго. Повече за Istio прочетете в серия от статии „Назад към микросервисите с Istio».

Ambassador

Сайт: github.com/datawire/ambassador
Лицензия: Apache 2.0

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

Сравнителна таблица

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

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

Нека обобщим

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

Класическият 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.

P.S.

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

• «Назад към микросервисите с Istio»: част 1 (запознаване с основните възможности), част 2 (маршрутизиране, управление на трафика), част 3 (автентификация и авторизация);
• «Kubernetes tips & tricks: персонализирани страници с грешки в NGINX Ingress»;
• «Kubernetes tips & tricks: достъп до dev-платформи».

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