Как стать автором
Обновить

Комментарии 19

Неплохо было бы добавить skipper
Хмм, интересно, спасибо — посмотрим на этот контроллер тоже.
Всего полгода прошло, и мы-таки добавили :-)
В обновлённой версии этого обзора для нашего англоязычного блога: Comparing Ingress controllers for Kubernetes.
В рамках кластера Kubernetes с ним предлагается «мягкое» обновление конфигурации (без потери трафика), service discovery на основе DNS, динамическая конфигурация с помощью API


Мягкое обновление HAProxy, которое стало доступно сравнительно недавно, работет весьма специфично. Рядом с работающим HAProxy поднимается еще один экземпляр на который переключается трафик. То есть всегда нужно иметь практически двойной запас ресурсов чтобы было места где стартануть второй экземпляр HAProxy. Все это связано с тем что HAProxy не умеет перечитывать конфиги. Я бы упомянул это как недостаток.

Спасибо за информацию, я о таком нюансе не знал!
Посмотрим, проверим по возможности.

Вы не правы. По умолчанию в haproxy-ingress есть релоад при обновлении конфига и даже можно включить добавление-удаление сервисов вообще без релоада, через сокет. Вот тут подробнее github.com/jcmoraisjr/haproxy-ingress#dynamic-scaling
Весь вопрос как haproxy релизует перегрузку конфигов «без релоада». Это описано здесь.
github.com/neo4j/docker-library-docs/tree/master/haproxy#reloading-config
Подробности в этом документе п.4
www.haproxy.org/download/1.7/doc/management.txt

В момент когда отправляется сигнал на перегрузку конфигов haproxy там некоторое аремя работают два инстанса.
Это лучше чем hard restart т.к. не теряются коннекты которые в работе.
Но хуже т.к. может привести к повышенному расходованию ресурсов системы.

И т.к. процесс реально второй это не будет работать если запускать haproxy в докере (по принципу один контейнер-один процесс)

Впрочем на практике при больших загрузках я это не пробовал у меня их просто нет. Возможно все не так уж и страшно. Просто не лишним было бы представлять как это работает.
И еще один новенький в этом зоопарке («can function as a feature-rich ingress controller») — Gloo

Удивительно, что многие контроллеры, судя по таблице, не имеют трассировки запросов. Как же их при этом использовать в настоящем бою, где за каждый запрос нужно ручаться головой? Как отвечать на вопросы руководства: почему часть запросов тормозит, часть отваливается по таймауту, а часть возвращает ошибку?

И какое решение вы выбрали, чтобы с трассировкой?

Не выбрали, пока остались на Openshift, в котром HAProxy.

Обычно это решается частично со стороны приложения, с помощью apm, типа NewRelic.

Но что если в приложении всё хорошо (и с его логами тоже), а вот с сервисом в целом всё равно какие-то проблемы?

Ниже вот ответили, ставить istio с трейсером. Но по опыту, в 90% случаев, проблема в сети между нодами. В случае с тем же flannel, ломаться обычно просто нечему. Не говорю конечно о крайних случаях, когда что-то сложное — огромные нагрузки, огромные кластера, тысячи сервисов и так далее, но если это ваш кейс, совершенно непонятно как вы ещё живёте без чего-то вроде istio :)

Istio в комбинации с:
  • Jaeger
  • Zipkin/OpenZipkin
  • LightStep [x]PM
  • kiali
А где обзор какой тип балансировки они поддерживают L7 или L4. Так же сравнение кто умеет HTTP2, GRPC проксировать кто нет.
Поддерживаемые протоколы есть в таблице, также обычно все кто поддерживает tcp в полной мере, имеют полноценную l4 балансировку.
Про http2 это упущение (там действительно есть нюансы, например не все ингрессы умеют проксировать http2, а только терминировать), которые к сожалению, скорее всего будут еще обнаруживаться, уж слишком большой объем обзора :(.
НЛО прилетело и опубликовало эту надпись здесь
На практике это удавалось проверить или допущение?
И если можно — уточните, что вкладываете в понятие «высокие нагрузки» в каких-то абсолютных показателях?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий