Как мы выбирали ингресс для платформы

Как некоторые тут знают, я занимаюсь https://yandex.cloud/ru/services/stackland, он-прем копией Яндекс Облака. Талос, кубер, операторы, всё что я люблю.

В самом начале мы взяли ingress-nginx - на тот момент реально самый популярный контроллер, без вариантов.

А потом ingress-nginx заархивировали. Репа в архиве с конца марта, официальный преемник InGate умер, не дожив до релиза. А у нас на нём вся платформа: IAM, console, docs, grafana, OpenBao - всё через один ingress-класс.

Че делать? Ну ясно че - искать замену.

Наивный план звучит так: «быстро выбрать новый контроллер и накатить». Ингрессов же вагон, есть проверенные старички. Бери да ставь. Только это выбор не с того конца.
Дольше всего у нас заняли не контроллеры, а инварианты - список того, что платформа НЕ имеет права сломать. Пока его нет, любой выбор - вкусовщина: "этот покрасивее, у того CRD удобнее". А инвариант - это не "не красиво", это конкретная строка. Например: backend TLS до апстрима должен жить. У нас IAM отдаёт HTTPS на 8080, gRPC-сервис - GRPCS на 4292, OpenBao ходит по TLS. Убери это - и придётся рефакторить сами сервисы, чего на переезде никто подписывать не собирался.

Выписываешь такие строчки - и поле кандидатов схлопывается само. Было 9+ штук. После прогона каждой строки совместимости против инвариантов осталось два живых.

Само согласование списка с коллегами и продуктом заняло несколько дней. Зато дальше выбор перестал быть спором о вкусах.

Проверять, что контроллеры реально умеют по нашим требованиям, я ходил с LLM - вполне приземлённо. Скачивал исходники и просил пройтись: поддерживает фичу или нет.

Так отвалился Cilium. По документации он выглядит заманчиво: CNI, Ingress, Gateway API, Envoy внутри. Но в исходниках видно важное отличие: для kind: Ingress он не превращает наш nginx-style backend TLS в TLS origination к апстриму. Эта логика у него живёт в Gateway API path через BackendTLSPolicy. А наш контракт сейчас - именно Ingress. Значит, миграция превращалась бы не в замену контроллера, а в переписывание маршрутов и части сервисной модели.
В документации этого нет. Видно только в исходниках. Сам бы я это выкапывал полдня, а тут получил ответ за минуты. Тот самый инвариант про backend TLS - Cilium на нём и сдох.

Важное: LLM ничего за меня не выбирала. Это был инструмент аудита, решение всё равно сверялось с инвариантами.

Сначала меня тянуло к nginx-ingress от F5 - он ближе всего к nginx-семантике, удобный мост, да и знаю я его. С Envoy я знаком с 2021-го и говна с ним поел прилично, так что в его сторону идти не хотелось. Но выбрали в итоге Contour - а он как раз на Envoy. Причина простая: у nginx-ingress Gateway идёт отдельным продуктом, не в поставке. А переходить на Gateway API всё равно придётся, и эту дверь надо открыть клиентам заранее.

И да, предвижу вопрос: а чего Ingress, а не сразу Gateway API? Во-первых, Ingress не задеприкейчен. Во-вторых, нам надо не за модой бежать, а делать так, чтобы Stackland было удобно использовать. Gateway API мы дадим как путь вперёд, а не как способ сломать то, что у людей уже работает.

Вывод, который я предлагаю забрать вам: если выбор инфры начинается с вопроса "какой контроллер взять" - вы уже выбираете не с того конца. Контроллер это последняя миля. Сначала разберитесь, что нельзя сломать.

А вы что выбрали в качестве замены?

#kubernetes #k8s #ingress #networking