Операция выполнена!
Закрыть
Хабы: Блог компании АО «ГНИВЦ», Kubernetes, Системное администрирование, DevOps

Когда проект Kubernetes только начинал свой путь, вопрос как пустить трафик в кластер решался просто: как-нибудь. Сервисы торчали наружу через NodePort, потом появился LoadBalancer, а чуть позже — объект Ingress, который на долгие годы стал стандартной точкой входа в HTTP-мир Kubernetes.

Ingress был своевременным решением. Он дал декларативный способ описывать маршрутизацию, TLS и виртуальные хосты, не заставляя инженеров напрямую настраивать nginx-конфиги или HAProxy руками. Для своего времени — шаг вперёд, и весьма заметный. Проблема в том, что Kubernetes рос быстрее, чем сам Ingress.

Со временем выяснилось, что спецификация Ingress намеренно минималистична. В ней нет ни чёткого разделения ответственности, ни расширяемой модели, ни нормального способа описывать сложные сценарии маршрутизации. Всё, что выходило за рамки базового use case, уезжало в аннотации ingress-контроллеров. В результате у нас появился единый стандарт, который на практике вёл себя по-разному в зависимости от того, какой контроллер стоял в кластере. Формально — Ingress, фактически — vendor-specific конфигурация с YAML-обвязкой.

Читать далее
Читайте также
НОВОСТИ

ПИШИТЕ

Техническая поддержка проекта ВсеТут

info@vsetut.pro