🥇Преглед и сравнение на 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 валидиране, активни health check’и и др. Важно предимство пред NGINX Ingress е пълната поддръжка на TCP/UDP трафик (включително в community версията!). Недостатъкът е отсъствието на функции за разпределение на трафика, което обаче „има максимален приоритет за разработчиците“, но изисква време за реализация.

Kong Ingress

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

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

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

Важно свойство на продукта е, че работата в рамките на един контур (вместо 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 с ним предлагается «мягкое» обновление конфигурации (без потери трафика), service discovery на основе 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.

Также предлагается расширенный набор методов балансировки (присутствует зеркалирование запросов, автоповторы, ограничение по rate’у запросов и многое другое), детальный мониторинг потока трафика и сбоев. Возможно, для кого-то будет существенным недостатком отсутствие поддержки sticky sessions (хотя работы вече да е в ход).

Istio Ingress

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

Комплексно решение за service mesh, което не е само Ingress контролер, управляващ постъпващия трафик отвън, но и контролира целия трафик в рамките на клъстера. 'Под капака', като sidecar прокси за всяка услуга, се използва Envoy. Всъщност, това е голям комбайн, който 'може всичко', а основната му идея е максимална управляемост, разширяемост, сигурност и прозрачност. С негова помощ можете в детайли да настройвате маршрутизацията на трафика, авторизацията на достъпа между услугите, балансиране, мониторинг, канарийни релизи и много друго. Повече за 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.