Команда Sealos Cloud успешно разобралась в запутанном мире популярных опенсорсных API-шлюзов. Мы перевели статью, в которой компания помогает понять, с какими вызовами можно столкнуться при выборе API-шлюза для публичного облака с высокими требованиями, как не наступить на известные грабли, и делится выводами, которые команда подтвердила на практике.
Специфика Sealos Cloud: в каких жёстких условиях работает наш API-шлюз
С самого старта Sealos Cloud стремительно растёт — у нас уже 87 тысяч регистраций. Каждому пользователю, который деплоит свои приложения, нужен свой эндпойнт для доступа. В итоге таблица роутинга в кластере растёт экспоненциально, и ей нужно как-то переваривать сотни тысяч Ingress-правил. Из-за таких масштабов мы очень тщательно подходим к выбору шлюза для Kubernetes.
Для работы общих сервисов кластера в интернете нужна строгая мультитенантность (multi-tenancy). Пользовательский трафик должен быть полностью изолирован, а средства управления трафиком должны исключать любое влияние тенантов друг на друга.
В публичном облаке с безопасностью всегда непросто. Злоумышленники бьют и по приложениям пользователей, и по выходным точкам платформы. Для нас как операторов это создаёт кучу проблем. Так что без надёжного и масштабируемого API-шлюза не обойтись.
Контроллеры работают на пределе. С ростом таблиц маршрутизации многие решения начинают потреблять чрезмерный объём ресурсов. Обычно это заканчивается плачевно: шлюз падает из-за нехватки памяти (OOM) — критическая проблема для любого ingress-решения production-уровня для Kubernetes.
С чего все началось: почему мы отказались от Nginx Ingress
Изначально наша система работала на Nginx Ingress, но мы столкнулись с несколькими серьёзными недостатками, которые мешали развернуть публичное облако для клиентов:
Проблемы со стабильностью при перезагрузке: любое изменение конфигурации вызывало кратковременные сбои в соединениях. В многопользовательских кластерах, в которых конфигурация Ingress меняется постоянно, это приводило к хронической нестабильности сети.
Обрывы долгих соединений: во время обновления конфигурации активные соединения часто разрывались, что было критично для real-time-приложений.
Низкая производительность: мы заметили, что конфигурации применялись медленно, а потребление ресурсов под нагрузкой было высоким. Таким образом, Nginx не вписывался в образ производительного API-шлюза, который был нам нужен.
Эти проблемы с Nginx Ingress, по сути, поставили крест на большинстве решений, базирующихся на нём. Сравнительное тестирование показало, что решения на Envoy показывают себя в разы лучше, при этом почти не нагружая ни управляющий слой, ни слой данных.
Очевидное превосходство в производительности окончательно убедило нас полностью перейти на решения с Envoy для построения более эффективного нативного облачного шлюза.
Размышления об APISIX: многообещающее ядро, но нестабильный контроллер
APISIX — в своей основе отличный проект, который эффективно решает часть проблем, характерных для Nginx. Поэтому мы изначально и выбрали APISIX для нашей платформы Laf. Но на практике возникли серьёзные проблемы с его Ingress-контроллером, который оказался нестабильным. Падения управляющего слоя вызывали кучу критических сбоев и даже OOM самого контроллера.
Мы, правда, очень хотели заставить его работать, но постоянные сбои вынудили нас от него отказаться. Надо отдать должное: сообщество APISIX активно работает над этими проблемами и постоянно улучшает платформу.
Короче говоря, у APISIX стабильное ядро, но его контроллер нужно серьёзно оптимизировать и стабилизировать для жёстких production-условий. Сообщество у проекта отличное, но наши горящие production-требования не могли ждать, пока разработчики неспешно доведут всё до ума. В конце концов нам пришлось искать альтернативу.
Cilium Gateway: что с ним не так
Мы довольно давно перевели наш CNI на Cilium, и это решение оказалось технически верным. Поэтому было логично посмотреть на Cilium Gateway в качестве основного шлюза. Однако на практике выявились серьёзные ограничения, которые сделали его непригодным для нашего конкретного сценария.
Дело в том, что Cilium Gateway работает только в режиме балансировщика нагрузки (LB), что создаёт жёсткую привязку к LB-сервисам облачных вендоров. Это идёт вразрез с нашими требованиями к приватным развёртываниям, для которых мы предпочитаем независимые архитектуры. Кроме того, проявились проблемы со стабильностью. При работе с большим количеством маршрутов правила Cilium Gateway Ingress раскатывались недопустимо долго — процесс занимал несколько минут. А наш SLA требует, чтобы сходимость маршрутов не превышала 5 секунд. Учитывая эти ограничения, мы решили отложить внедрение Cilium Gateway до момента, когда эти критические недостатки будут устранены.
Envoy Gateway: почему он ещё не готов для прода
Сейчас Kubernetes переходит на стандартные Gateway API вместо классического Ingress. Учитывая, что мы предпочитаем решения на основе Envoy, Envoy Gateway с самого начала казался очень перспективным. Однако исследование показало, что проект ещё «сырой» и страдает от нескольких серьёзных проблем: утечек памяти, которые приводят к OOM, неверной настройки политик путей (pathpolicy) и функциональных пробелов в режиме объединённых шлюзов (merged gateway).
Мы активно контрибьютим в апстрим, сообщая о багах и предлагая улучшения, но для наших сложных и масштабных систем Envoy Gateway пока не готов к production-использованию.
Стандарт Gateway API в Kubernetes: красиво в теории, но непрактично для мультитенантности
Стандарт Kubernetes Gateway API на практике оказывается не таким удобным, как на бумаге. По-моему, его авторы не до конца представили, с какими проблемами сталкиваются шлюзы в реальных Kubernetes-кластерах, где работает сразу много тенантов. Как только в кластере появляется больше одного пользователя, необходимо чёткое разграничение прав доступа между администраторами и пользователями. В текущей архитектуре Gateway это ключевое соображение отсутствует.
Рассмотрим следующий пример: конфигурации портов для прослушивания сети должны быть исключительной прерогативой администраторов кластера, а не обычных пользователей. В то же время настройки TLS-сертификатов специфичны для приложений: хотя администраторы сохраняют привилегии на конфигурацию, отдельные пользователи должны иметь возможность управлять собственными сертификатами. Такое пересечение привилегий требует доступа к Gateway на уровне пользователя. Это, в свою очередь, требует сложных систем контроля привилегий на уровне контроллера — с белыми списками портов и механизмами решения конфликтов.
В идеале все специфичные для тенанта настройки стоило бы вынести на уровень ниже — в HTTPRoute — или реализовать через отдельные Custom Resource Definitions (CRD). Такая архитектура провела бы чёткую границу между тем, что могут делать пользователи, и тем, за что отвечает суперадминистратор. Текущий гибридный подход работает, но выглядит несколько громоздким, хотя и остаётся пригодным для использования.
Higress: как мы решили критические проблемы со шлюзами в Sealos
После тщательного изучения и тестов в «боевых» условиях мы стали искать шлюз, у которого нет недостатков предыдущих решений. Higress, работающий на базе Envoy, оказался отличным вариантом, потому что смог решить наши основные проблемы:
Быстрая настройка Ingress: при использовании других решений мы сталкивались со значительными задержками начальной настройки Ingress при обработке большого количества маршрутов (новые маршруты активировались более двух минут). Higress, за счёт оптимизаций от сообщества и механизма инкрементальной загрузки конфигурации, сократил это время до ~3 секунд. Такой высочайший уровень производительности, который теперь опережает даже время готовности контейнера, критически важен для нашего динамического окружения.
Стабильность контроллера и экономное потребление ресурсов: проблемы с нехваткой памяти (OOM) у контроллера, с которыми мы сталкивались на других шлюзах при нединамической загрузке конфигурации, были решены. Контроллер Higress доказал свою стабильность и поразительную ресурсоэффективность даже под нагрузкой с огромным количеством маршрутов.
Решение проблемы с аномальными тайм-аутами: мы избавились от периодических аномальных тайм-аутов, которые наблюдали в одном из кластеров при использовании параметров onDemandRDS в прошлой системе. Этого удалось достичь тонкой настройкой конфигураций, что обеспечило стабильную производительность во всех кластерах при работе с Higress.
Что касается безопасности, многие из наших прошлых инцидентов были вызваны узкими местами в производительности. Всплески трафика, перегружающие шлюзы, в нашей ситуации — обычное дело, что делает производительность API-шлюза абсолютно критичной. Тесты подтверждают: Envoy показывает себя значительно лучше, а Higress особенно выделяется в этом плане благодаря реализации своего контроллера:
Даже при огромных нагрузках, связанных с маршрутизацией, и в сценариях со сверхвысоким параллелизмом, Higress требует на удивление мало ресурсов.
Ключевым фактором для нас стала совместимость Higress с синтаксисом Nginx Ingress через аннотации. Так как существующая кодовая база уже использует Ingress, стоимость миграции практически нулевая — обновиться можно всего за несколько минут. Такой бесшовный переход стал большим плюсом.
Чтобы помочь развитию проекта и расширить спектр применения Higress, мы предложили несколько идей:
Улучшенная поддержка стандарта Gateway API: хотя совместимость с версией v1 есть, до полного набора возможностей Ingress ей пока далеко, и это точка роста.
Открытие исходного кода продвинутых фич: такие революционные функции, как продвинутая защита и механизмы «автоматического выключателя» (circuit breaker), в идеале должны быть опенсорсными. Мы также открыты к коммерческой интеграции по мере развития платформы.
Расширение архитектуры плагинов: периферийная функциональность должна расширяться через продвинутую архитектуру плагинов для сохранения целостности и надёжности основных функций.
Резюме: о выборе правильного шлюза для облака
Шлюзы — критически важные компоненты облачной инфраструктуры и приложений. По мере масштабирования Sealos неизбежно появятся новые задачи в управлении API-шлюзами. Мы стремимся к тесному сотрудничеству с сообществами разработчиков (upstream и downstream), чтобы развивать технологии шлюзов с открытым исходным кодом.
Перечисленные выше решения — Nginx Ingress, APISIX, Cilium Gateway и Envoy Gateway — сами по себе отличные проекты. То, что Sealos их не внедрила, говорит не о недостатках, а о наших крайне требовательных и уникальных сценариях, для которых нужен высокопроизводительный, масштабируемый и мультитенантный API-шлюз.
На самом деле существует очень мало шлюзов, способных поддерживать мультитенантные окружения в публичных интернет-развёртываниях такого масштаба, как у нас. Поэтому мы рекомендуем читателям выбирать исходя из своих конкретных задач. Наш путь приводится лишь для справки. При этом сама Sealos Cloud продолжит непредвзято следить за развитием других проектов.
Во второй части цикла мы расскажем, как команда Sealos решила проблему с производительностью шлюза, когда количество доменов превысило 20 000. Для этого они углубились в архитектуру Higress, Istio и Envoy, выявили и устранили узкие места, сократив время активации домена с нескольких минут до считаных секунд. Оптимизации позволили в 20 раз ускорить отклик Ingress и значительно повысить эффективность и масштабируемость всей платформы. Следите за публикациями в блоге «Фланта».
P. S.
Читайте также в нашем блоге: