Comments 19
В обновлённой версии этого обзора для нашего англоязычного блога: Comparing Ingress controllers for Kubernetes.
В рамках кластера Kubernetes с ним предлагается «мягкое» обновление конфигурации (без потери трафика), service discovery на основе DNS, динамическая конфигурация с помощью API
Мягкое обновление HAProxy, которое стало доступно сравнительно недавно, работет весьма специфично. Рядом с работающим HAProxy поднимается еще один экземпляр на который переключается трафик. То есть всегда нужно иметь практически двойной запас ресурсов чтобы было места где стартануть второй экземпляр HAProxy. Все это связано с тем что 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 в докере (по принципу один контейнер-один процесс)
Впрочем на практике при больших загрузках я это не пробовал у меня их просто нет. Возможно все не так уж и страшно. Просто не лишним было бы представлять как это работает.
Удивительно, что многие контроллеры, судя по таблице, не имеют трассировки запросов. Как же их при этом использовать в настоящем бою, где за каждый запрос нужно ручаться головой? Как отвечать на вопросы руководства: почему часть запросов тормозит, часть отваливается по таймауту, а часть возвращает ошибку?
Но что если в приложении всё хорошо (и с его логами тоже), а вот с сервисом в целом всё равно какие-то проблемы?
Ниже вот ответили, ставить istio с трейсером. Но по опыту, в 90% случаев, проблема в сети между нодами. В случае с тем же flannel, ломаться обычно просто нечему. Не говорю конечно о крайних случаях, когда что-то сложное — огромные нагрузки, огромные кластера, тысячи сервисов и так далее, но если это ваш кейс, совершенно непонятно как вы ещё живёте без чего-то вроде istio :)
- Jaeger
- Zipkin/OpenZipkin
- LightStep [x]PM
- kiali
Про http2 это упущение (там действительно есть нюансы, например не все ингрессы умеют проксировать http2, а только терминировать), которые к сожалению, скорее всего будут еще обнаруживаться, уж слишком большой объем обзора :(.
Обзор и сравнение контроллеров Ingress для Kubernetes