ингресу в котором прописано правило с путем к микросервису, перед которым этот ингресс и стоит?
Ну это обычно то, что делаешь в первую очередь
Наверное, норм
ну говорят ингресу не комфортно будет
Ты хочешь чтобы все микросервисы работали через ингресс? Публичные и не публичные ?
я лишь хочу что бы микросервисы могли общаться между собой, но тот кто настраивал наш кубер. сделал сервисы с рандомными портами вместо 80ого. из-за чего обращаться по имени http://service-name.namespace уже нельзя, т.к. нужно знать порт. без ингреса тут не понятно как обойтись, но говорят ингрес для внешних запросов, а не внутренней коммуникации
Можно и через ингресс, ничего страшного. Касательно сервисов - хорошее дело их унифицировать ₽ тут ты тоже прав
что под унификацией понимаешь?
Использование Ingress для межсервисного взаимодействия плюсы: 1) метрики L7 балансера из под коробки - удобно, если разрабы не умеют сами в метрики 2) дополнительный слой контроля трафика при желании можно и canary, и b/g минусы: 1) при деплоях, которые затрагивают конфиги ingress-a происходит reload, при этом сбрасываются все активные коннекты, т.е. он подходит только для коротких запросов между сервисами 2) дополнительный хоп - оверхед для летанси 3) только HTTP Кроме этого ловили разные спецэффекты - выглядило так, что иногда ingress продолжал роутить трафик в никуда, если pod от приложения заэвиктился. Природу этого не удалось выяснить, это было в 1.18.
3) нет, нжинкс ингресс контроллер может и в л4 1) если обновление ингрессов происходит довольно редко - можно и для 'длинных' сессий, сброс по причине worker shutdown timeout будет редким кейсом
Обсуждают сегодня