При запуску кластера 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) є спірною темою: комусь видасться недоліком (доводиться плодити сутності для кожного контуру), а для когось - фіча (больший рівень ізоляції, т.к. якщо зламаний один контролер, то проблема обмежена лише контуром).
Traefik
Сайт:
Ліцензія: 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