Обзор и сравнение контроллеров Ingress для Kubernetes

[badrazor]

Неплохо было бы добавить skipper

[andreios]

Хмм, интересно, спасибо — посмотрим на этот контроллер тоже.

[shurup]

Всего полгода прошло, и мы-таки добавили :-)
В обновлённой версии этого обзора для нашего англоязычного блога: Comparing Ingress controllers for Kubernetes.

[apapacy]

В рамках кластера Kubernetes с ним предлагается «мягкое» обновление конфигурации (без потери трафика), service discovery на основе DNS, динамическая конфигурация с помощью API

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

[andreios]

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

[nesoneg]

Вы не правы. По умолчанию в haproxy-ingress есть релоад при обновлении конфига и даже можно включить добавление-удаление сервисов вообще без релоада, через сокет. Вот тут подробнее github.com/jcmoraisjr/haproxy-ingress#dynamic-scaling

[apapacy]

Весь вопрос как 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 в докере (по принципу один контейнер-один процесс)

Впрочем на практике при больших загрузках я это не пробовал у меня их просто нет. Возможно все не так уж и страшно. Просто не лишним было бы представлять как это работает.

[maslakov]

И еще один новенький в этом зоопарке («can function as a feature-rich ingress controller») — Gloo

[ferocactus]

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

[ProFfeSsoRr]

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

[ferocactus]

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

[andreios]

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

[ferocactus]

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

[andreios]

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

[MMik]

Istio в комбинации с:

• Jaeger
• Zipkin/OpenZipkin
• LightStep [x]PM
• kiali

[varyumin]

А где обзор какой тип балансировки они поддерживают L7 или L4. Так же сравнение кто умеет HTTP2, GRPC проксировать кто нет.

[andreios]

Поддерживаемые протоколы есть в таблице, также обычно все кто поддерживает tcp в полной мере, имеют полноценную l4 балансировку.
Про http2 это упущение (там действительно есть нюансы, например не все ингрессы умеют проксировать http2, а только терминировать), которые к сожалению, скорее всего будут еще обнаруживаться, уж слишком большой объем обзора :(.

[andreios]

На практике это удавалось проверить или допущение?
И если можно — уточните, что вкладываете в понятие «высокие нагрузки» в каких-то абсолютных показателях?