ingress контроллер что такое
Kubernetes Ingress глазами новичка
Ingress это базовый тип ресурса в кубертенесе. Если просто объявить объект типа Ingress в кубернетисе то ничего не произойдет.
Что бы этот ресурс начал работу в кластере кубернетиса должен быть установлен Ingress Controller, который настроит реверсивный прокси в соответствии с Ingress объектом.
Ingress Controller состоит из 2х компонентов — реверсивного прокси и контроллера который общается с API сервером кубернетеса. Реверсивный прокси слушает входящий трафик на портах которые указаны в настройках (обычно в настройках по умолчанию указан только порт 80). Контроллер может быть как отдельным демоном (как в nginx), так и встроенным в прокси (как в traefik).
Не все клауд провайдеры кубернетеса предустанавливают Ingress Controller по умолчанию.
Контроллеры могут запускаться либо как DaemonSet либо как Deployment. DaemonSet идеально использовать как единственный Ingress Controller, что бы реверсивное прокси слушало на всех IP адресах воркеров. Deployment отлично подходит если перед Ingress контроллером стоит балансировщик — от провайдера кубернетиса (GKE, AKS), MetalLB если онпремис или обычный haproxy/nginx установленный на сервере (требутеся ручная настройка). При этой установке возможно установить несколько Ingress Controller.
Как входящий трафик попадает на Ingress Controller
Во всех случаях реверс прокси в Ingress Controller слушает порты где ожидает http/https соединения.
Трафик на этоти порты может попасть тремя путями:
NodePort
Ставить Ingress Controller на NodePort без LoadBalancer имеет мало смысла, так как URL будет включать порт который указан в NodePort http://domain.example.org:32200/.
Для этого варианта лучше использовать Deployments. Это позволит проще скейлить количество подов ответственных за входящий трафик, прописывать им nodeAffinity и запускать несколько ingress controller (например для production и staging).
HostPort
При использовании HostPort порт пробрасывается с хоста где запущен под в этот самый Pod. LoadBalancer на вход не нужен, но для работы сайта в DNS нужно указывать что адрес домена находится на всех узлах.
Пример конфигурации DNS для 3х воркеров:
Для этой установки лучше всего использовать DaemonSet т.к. он позволяет запустить не более одного Pod на хосте. Deployment возможен, но имеет мало смысла т.к. надо прописывать affinity что бы не назначилось 2 Pod на один хост, иначе будет конфликт по портам.
Host network
При запуске Ingress Controller в общей сети с хостом не требуется никаких пробросов портов, но в этом случае все порты которые открыты в Pod будут доступны из интернета. Для запуска лучше использовать DaemonSet. Причины такие же как и с HostPort — что бы избежать конфликта портов.
Что выбрать
Если есть LoadBalancer на входе — NodePort, если нет — HostPort + DNS Round Robin. Для экспериментов можно попробовать Host network, но это не безопасно.
Что такое контроллер объекта ingress Шлюза приложений?
Контроллер объекта ingress Шлюза приложений (AGIC) — это приложение Kubernetes, которое позволяет клиентам Службы Azure Kubernetes (AKS) использовать собственную подсистему балансировки нагрузки уровня 7 Шлюза приложений Azure, чтобы предоставлять доступ к облачному программному обеспечению через Интернет. Контроллер AGIC отслеживает кластер Kubernetes, в котором он размещен, и постоянно передает в шлюз приложений обновленные данные, чтобы выбранные службы были доступны в Интернете.
Контроллер объекта ingress работает в собственном pod в AKS клиента. AGIC отслеживает изменения, вносимые в подмножество ресурсов Kubernetes. Состояние кластера AKS преобразовывается в конфигурацию шлюза приложений и применяется к Azure Resource Manager (ARM).
Преимущества контроллера объекта ingress Шлюза приложений
AGIC помогает устранить необходимость создания другой подсистемы балансировки нагрузки или общедоступного IP-адреса для кластера AKS и избежать нескольких прыжков в пути данных, по которому запросы передаются в кластер AKS. Шлюз приложений обращается к модулям pod напрямую с помощью частных IP-адресов и не нуждается в службах NodePort или KubeProxy. Это также повышает производительность развертываний.
Контроллер объекта ingress поддерживается исключительно номерами SKU Standard_v2 и WAF_v2, что также обеспечивает преимущества автомасштабирования. Шлюз приложений может реагировать на увеличение или уменьшение объема трафика и соответствующим образом изменять масштаб, не используя ресурсы из кластера AKS.
Использование Шлюза приложений в дополнение к AGIC также помогает защитить кластер AKS, так как обеспечивает политику TLS и функции брандмауэра веб-приложения (WAF).
Для настройки AGIC используется ресурс ingress Kubernetes, а также службы, развертывания и модули pod. AGIC предоставляет ряд функций, использующих встроенную подсистему балансировки нагрузки уровня 7 Шлюза приложений Azure. Вот некоторые из них:
Разница между развертыванием Helm и надстройкой AKS
Существуют два способа развертывания AGIC в кластере AKS. Первый способ — используя Helm, второй — используя AKS в качестве надстройки. Основное преимущество развертывания AGIC в качестве надстройки AKS заключается в том, что это гораздо проще, чем развертывание с помощью Helm. Для новой конфигурации можно развернуть новый шлюз приложений и новый кластер AKS с AGIC, включенным в качестве надстройки, выполнив одну строку команд в Azure CLI. Надстройка также является полностью управляемой службой, что предоставляет дополнительные преимущества, такие как автоматическое обновление и расширенная поддержка. Оба способа развертывания AGIC (с помощью Helm и надстройки AKS) полностью поддерживаются корпорацией Майкрософт. Кроме того, надстройка обеспечивает лучшую интеграцию с AKS, так как является надстройкой первого класса.
Надстройка AGIC по-прежнему развертывается как pod в кластере AKS клиента, однако существует ряд различий между версией развертывания Helm и версией надстройки AGIC. Ниже приведен список различий между этими двумя версиями.
Клиенты могут развернуть только одну надстройку AGIC в кластере AKS, и каждая надстройка AGIC в настоящее время может быть назначена только одному шлюзу приложений. Для развертываний, требующих более одного контроллера AGIC на кластер или нескольких контроллеров AGIC, предназначенных для одного шлюза приложений, можно использовать контроллеры AGIC, развернутые с помощью Helm.
Ingress-контроллер: что это и как выбрать
Kubernetes — достаточно сложная для понимания вещь, даже сами авторы это признают. В этой статье мы попытаемся простым языком объяснить, что такое Ingress-контроллер и для чего он нужен.
Начнем с того, что в Kubernetes есть целых два типа сущностей. Первый — сам Ingress, некоторый набор правил, позволяющий трафику извне достичь сервисов внутри кластера. Второй — Ingress-контроллер, представляющий собой ни что иное, как pod с запущенным приложением-контроллером. Здесь стоит оговориться, что отдельно эти два типа сущностей бесполезны.
На ум приходит аналогия с автомобилем. Ingress — это как автомобиль со снятым двигателем, а Ingress-контроллер — тот самый двигатель. Так что если вы создадите Ingress без установленного контроллера, то само собой ничего работать не будет.
Работая вместе, Ingress и Ingress-контроллер позволяют создать единую точку входа для трафика и выполняют одновременно роль прокси и балансировщика нагрузки, работая на 7 уровне сетевой модели OSI.
Итак, основная задача выбора Ingress-контроллера лишь в том, какое именно приложение будет разруливать весь трафик. В идеале различные Ingress-контроллеры должны работать одинаково по спецификации, но на практике все же есть различия. Возвращаясь к автомобильной аналогии, двигатели бывают разного типа: атмосферные, компрессорные, турбированные и даже электрические.
Важно понимать, что Ingress-контроллер не отменяет необходимость во внешнем балансировщике нагрузки, он лишь добавляет дополнительный уровень маршрутизации и большую гибкость в распределении трафика.
Какие существуют Ingress-контроллеры
Условно все Ingress-контроллеры можно поделить на две группы.
Первая группа — специфичные приложения, рассчитанные на работу с трафиком каких-либо экосистем, например, Citrix ingress controller. Эта штука предназначена для работы с Citrix ADC — комплексным решением по доставке приложений для исполнения на bare-metal, а также внутри контейнеров и виртуальных машин.
Точно такое же специфичное решение — AKS Application Gateway Ingress Controller. Его назначение — балансирование рабочих нагрузок, размещенных в Azure, о чем нам намекают в названии AKS (Azure Kubernetes Service). Многие крупные провайдеры облачной инфраструктуры создают свои решения и предлагают их в рамках использования определенной экосистемы. Например, F5 BIG-IP Container Ingress Services for Kubernetes создавался для работы с виртуальными серверами F5 BIG-IP.
Переходим ко второй группе, где у нас находятся универсальные Ingress-контроллеры. Их достаточно много, но можно выделить несколько, базирующихся на одном и том же ПО, например, на Envoy:
Особняком стоят Ingress-контроллеры, заточенные под использование в паре с определенным ПО:
Все перечислять не будем. Из вышесказанного можно сделать однозначный вывод о том, что вопрос выбора Ingress-контроллера может быть решен, если какое-либо ПО уже есть и оно готово к рабочим нагрузкам соответствующего контроллера.
Взглянем чуть более детально, какие контроллеры чаще всего используют.
Наиболее используемый Ingress-контроллер
Прежде чем набивать шишки, всегда проще посмотреть на чужой опыт и сделать выводы. На момент написания этой статьи в подавляющем большинстве источников на роль Ingress-контроллера рекомендуют использовать nginx-ingress. Причина проста: разработкой и поддержкой этого контроллера занимаются разработчики Kubernetes. Длительный опыт использования, а также масса документации и учебных материалов играют существенную роль в «боевой» эксплуатации. Так что вряд ли вы столкнетесь с нерешаемыми проблемами.
Дабы исключить всякую путаницу: существует еще и NGINX Ingress для Kubernetes, продукт от NGINX Inc (ныне компания поглощена F5 Networks). В отличие от nginx-ingress у этого продукта есть еще и платная версия, реализованная на NGINX Plus.
Чуть меньшую популярность завоевал HAProxy Ingress. Достаточно производительный и гибкий, с понятной документацией и обширным комьюнити в Slack и на StackOverflow, этот контроллер однозначно заслуживает внимания. Определенную долю рынка занимает Traefik Kubernetes Ingress и Kong для Kubernetes, также основанный на NGINX.
Критерии выбора
Прежде чем сделать выбор, стоит задать несколько важных вопросов:
Эти простые вопросы позволят сходу отсечь варианты, когда наличие дополнительных возможностей потребует больших вложений, но эти возможности не будут востребованы.
Следующий вопрос, который важен для принятия решения, — о производительности. Получить на него ответ можно будет либо эмпирическим путем, либо основываясь на уже существующих научных исследованиях.
В качестве примера приведем научную публикацию «Исследование производительности различных имплементаций Ingress-контроллеров в кластере Kubernetes», основанную на проведенных исследованиях в Белорусском государственном университете информатики и радиоэлектроники (Шуляк А.В., Савенко А.Г.). Получившиеся выводы весьма интересны и показательны. Выяснились следующие факты:
Заключение
Процесс выбора Ingress-контроллера в большинстве случаев зависит от решаемых задач и требований к поддержке дополнительных функций. Практически все существующие контроллеры способны решать простые задачи, так что выбор можно сделать в пользу наиболее простого и хорошо задокументированного варианта.
Если же у вас высоконагруженные системы, следует большее внимание уделить производительности решения, а также наличию коммерческой поддержки. Так вы минимизируете возможные простои и не будете тратить время на глубокое погружение в особенности используемой системы.
Обзор и сравнение контроллеров Ingress для Kubernetes
При запуске кластера Kubernetes для конкретного приложения следует понимать, какие требования представляет к этому ресурсу само приложение, бизнес и разработчики. При наличии этой информации можно приступать к принятию архитектурного решения и, в частности, к выбору конкретного Ingress-контроллера, коих на сегодняшний день уже большое количество. Чтобы составить базовое представление об имеющихся вариантах без необходимости изучать множество статей/документации и т.п., мы и подготовили этот обзор, включив в него основные (production ready) Ingress-контроллеры.
Надеемся, что он поможет коллегам в выборе архитектурного решения — по крайней мере, станет отправной точкой для получения более подробной информации и практических экспериментов. Предварительно мы изучили другие подобные материалы в сети и, как ни странно, не обнаружили ни одного более-менее полного, а главное — структурированного — обзора. Итак, заполним же этот пробел!
Критерии
Чтобы в принципе проводить сравнение и получить сколько-нибудь полезный результат, надо понимать не просто предметную область, но и иметь конкретный список критериев, которые и будут задавать вектор исследования. Не претендуя на анализ всех возможных случаев применения Ingress/Kubernetes, мы постарались выделить наиболее общие требования к контроллерам — будьте готовы, что всю свою специфику и частности в любом случае придётся изучать отдельно.
Но начну с характеристик, которые стали настолько привычными, что реализованы во всех решениях и не рассматриваются:
Поддерживаемые протоколы
Один из основополагающих критериев для выбора. Ваше ПО может работать не по стандартному HTTP или же требовать работу сразу по множеству протоколов. Если ваш случай — нестандартный, обязательно берите в расчет этот фактор, дабы не пришлось потом перенастраивать кластер. У всех контроллеров список поддерживаемых протоколов варьируется.
ПО в основе
Есть несколько вариантов приложений, на которых основан контроллер. Популярные — это nginx, traefik, haproxy, envoy. В общем случае, возможно, не слишком влияет на то, как принимается и передается трафик, однако всегда полезно знать потенциальные нюансы и особенности того, что «под капотом».
Маршрутизация трафика
На основе чего можно принимать решение о направлении трафика в тот или иной сервис? Обычно это host и path, но бывают и дополнительные возможности.
Пространство имен в рамках кластера
Пространство имён (namespace) — возможность логически разбивать ресурсы в Kubernetes (например, на stage, production и т.п.). Есть Ingress-контроллеры, которые надо ставить отдельно в каждый namespace (и тогда он может направлять трафик только в 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
Простые алгоритмы rate limit или же более сложные варианты отсеивания трафика на основе адресов, белых списков, стран и т.д.
Трассировка запросов
Возможности наблюдения, отслеживания и отладки запросов от Ingress’ов к конкретным сервисам/pod’ам, а в идеале — и между сервисами/pod’ами тоже.
Контроллеры Ingress
Список контроллеров был сформирован на основе официальной документации Kubernetes и этой таблицы. Некоторые из них мы исключили из обзора ввиду специфичности или малой распространенности (ранней стадии развития). Оставшиеся же рассмотрены ниже. Начнём с общего описания решений и продолжим сводной таблицей.
Ingress от Kubernetes
Это официальный контроллер для Kubernetes, который разрабатывается сообществом. Очевидно из названия, он основан на nginx и дополнен различным набором Lua-плагинов, применяемых для реализации дополнительных возможностей. Благодаря популярности самого nginx’а и минимальных модификаций над ним при использовании в качестве контроллера, этот вариант может быть самым простым и понятным в конфигурации среднестатистическим инженером (с опытом в web).
Ingress от NGINX Inc
Официальный продукт разработчиков nginx. Имеет платную версию, основанную на NGINX Plus. Основная идея — высокий уровень стабильности, постоянная обратная совместимость, отсутствие каких-либо посторонних модулей и заявленная повышенная скорость (в сравнении с официальным контроллером), достигнутая благодаря отказу от Lua.
Бесплатная версия существенно урезана, в том числе даже при сравнении с официальным контроллером (из-за отсутствия всё тех же Lua-модулей). Платная при этом имеет достаточно широкий дополнительный функционал: метрики в реальном времени, JWT-валидация, активные health check’и и другое. Важное преимущество перед NGINX Ingress — полноценная поддержка TCP/UDP-трафика (и в community-версии тоже!). Минус — отсутствие фич по распределению трафика, что, впрочем, «имеет максимальный приоритет для разработчиков», но требует времени на реализацию.
Kong Ingress
Продукт, разрабатываемый компанией Kong Inc. в двух вариантах: коммерческий и бесплатный. Основан на nginx, возможности которого расширены большим количеством модулей на Lua.
Изначально был ориентирован на обработку и маршрутизацию запросов API, т.е. как API Gateway, однако на данный момент стал полноценным Ingress-контроллером. Основные преимущества: множество дополнительных модулей (в том числе и от сторонних разработчиков), которые легко ставить и конфигурировать и с помощью которых реализуется широкий спектр дополнительных возможностей. Впрочем, встроенные функции уже предлагают многие возможности. Конфигурация работы производится с помощью CRD-ресурсов.
Важная особенность продукта — работа в рамках одного контура (вместо cross-namespaced) является спорной темой: кому-то покажется недостатком (приходится плодить сущности для каждого контура), а для кого-то — фича (больший уровень изоляции, т.к. если сломан один контроллер, то проблема ограничена одним только контуром).
Traefik
Прокси, который изначально создавался для работы с маршрутизацией запросов для микросервисов и их динамической среды. Отсюда и многие полезные возможности: обновление конфигурации совсем без перезагрузок, поддержка большого количества методов балансировки, веб-интерфейс, проброс метрик, поддержка различных протоколов, REST API, канареечные релизы и многое другое. Приятной особенностью также является поддержка сертификатов Let’s Encrypt из коробки. Недостаток — для организации высокой доступности (HA) у контроллера потребуется устанавливать и подключать собственное KV-хранилище.
HAProxy
HAProxy давно известен в качестве прокси и балансировщика трафика. В рамках кластера Kubernetes с ним предлагается «мягкое» обновление конфигурации (без потери трафика), service discovery на основе DNS, динамическая конфигурация с помощью API. Привлекательным может стать полная кастомизация шаблона конфигов с помощью замены CM’а, а также возможности использования в нём функций библиотеки Sprig. В целом же основной акцент решения делается на высокую скорость работы, его оптимизированность и эффективность в потребляемых ресурсах. Преимущество контроллера — поддержка рекордного числа различных способов балансировки.
Voyager
Основанный на HAproxy контроллер, который позиционируется как универсальное решение, поддерживающее широкие возможности на большом количестве провайдеров. Предлагается возможность для балансировки трафика на L7 и L4, а балансировку TCP L4-трафика в целом можно назвать одной из ключевых фич решения.
Contour
В основу этого решения не только лёг Envoy: оно разработано совместно с авторами этого популярного прокси. Важная особенность — возможность разделения управления ресурсами Ingress с помощью CRD-ресурсов IngressRoute. Для организаций со множеством команд разработки, использующих один кластер, это помогает максимально обезопасить работу с трафиком в соседних контурах и защитить их от ошибок при изменении ресурсов Ingress.
Также предлагается расширенный набор методов балансировки (присутствует зеркалирование запросов, автоповторы, ограничение по rate’у запросов и многое другое), детальный мониторинг потока трафика и сбоев. Возможно, для кого-то будет существенным недостатком отсутствие поддержки sticky sessions (хотя работы уже ведутся).
Istio Ingress
Комплексное service mesh-решение, которое является не только Ingress-контроллером, управляющим поступающим трафиком извне, но и контролирует весь трафик в рамках кластера. «Под капотом», в качестве sidecar-прокси для каждого сервиса, используется Envoy. В сущности это большой комбайн, который «может всё», а основная его идея — максимальная управляемость, расширяемость, безопасность и прозрачность. С его помощью вы можете в тонкостях настраивать маршрутизацию трафика, авторизацию доступа между сервисами, балансировку, мониторинг, канареечные релизы и многое другое. Подробнее об Istio читайте в серии статей «Назад к микросервисам с Istio».
Ambassador
Ещё одно решение на основе 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.