Назад | Перейти на главную страницу

Как настроить Traefik для HA? Нужен обратный прокси перед Traefik?

Я пытаюсь установить Traefik на производственном сайте, но у меня возникают проблемы с высокой доступностью. Думаю, нам все еще нужен обратный прокси перед кластером Traefik. Вот возможные варианты настройки, которые я рассмотрел, и почему, похоже, необходим обратный прокси:

  1. Настройте записи DNS A, чтобы они указывали на каждый из узлов Traefik для балансировки нагрузки и переключения при отказе.

    • Эта практика не приветствуется на нескольких сайтах, включая этот ТАК вопрос и этот вопрос SF.

    • Даже использование такой службы, как DNSMadeEasy, кажется нецелесообразным из-за проблем с кешированием DNS и TTL.

  2. Направьте одну запись DNS на один из узлов, на которых работает Traefik.

    • Этот узел становится SPOF. Мои узлы работают на CoreOS, которая перезагружается после каждого обновления, поэтому у нас будет несколько минут простоя каждую неделю.

    • Мы можем переместить DNS-запись на альтернативный узел всякий раз, когда ожидается простой. Было бы сложно управлять этим вручную. Я могу представить себе решение в паре с locksmithd, которое обрабатывает это автоматически, но я действительно не хочу его создавать, и оно не справится с неожиданными простоями.

    • Одна из причин использования Docker Swarm (или Kubernetes) - сделать узлы взаимозаменяемыми.

  3. Поместите балансировщик нагрузки / обратный прокси перед кластером Traefik. Обратный прокси-сервер может обеспечить переключение между всеми узлами Traefik, а DNS будет указывать на обратный прокси.

    • Да, это SPOF, но по моему опыту, с такой настройкой довольно легко добиться хорошего времени безотказной работы. Если требуется периодическое обслуживание, запись DNS может указывать на новый прокси.

Я что-то упускаю или думаю об этом?

есть разные решения.

1) Создайте собственный HA Loadbalancer перед кластером Swarm / Kubernetes, чтобы распределять трафик и выполнять аварийное переключение.

Есть много разных устройств:

  1. Netscaler
  2. Кемп
  3. F5

Хотя этот подход является HA, он обычно стоит недешево.

Более дешевой альтернативой этому может быть Nginx / Haproxy + Keepalived Настроить.

Однако вам, конечно же, нужен плавающий IP-адрес и нужно позаботиться о кешах arp.

2) Воспользуйтесь «облачным балансировщиком нагрузки». Digital Ocean, AWS, GKE, Openstack предоставляют такую ​​функцию. Его проще настроить (в большинстве случаев), однако, если он дешевле, вам придется рассчитать.

В DigitalOcean LB стоит всего 20 долларов, и есть бета-версия с управляемым кластером Kubernetes. Вы можете захотеть взглянуть на это. Все компоненты хорошо соединяются вместе https://www.digitalocean.com/products/kubernetes/

3) Если ваши приложения не критичны на 100%, я могу предложить специальное решение, которое я использовал до сих пор:

Cloudflare + низкий TTL + https://github.com/Berndinox/cloudflare-ddns

Это работает так просто: https://github.com/Berndinox/compose-v3-collection/blob/master/wordpress/www.yml Как: он развивает WordPress и все его требования, включая контейнер DNS. Контейнер DNS обновляет запись DNS домена в Cloudflare (зависит от того, на каком хосте запускается контейнер, IP-адрес отличается). Хорошо, если один хост перезагружается или проверка работоспособности контейнера завершается неудачно, контейнер будет перепланирован. При перепланировании и изначально выбранном хосте в автономном режиме контейнер запускается на другом хосте, а затем отправляет новый IP-адрес в Cloudflare. Все это происходит автоматически, без каких-либо действий. :)

TTL Cloudflare действительно низкие, поэтому время простоя может составлять всего несколько секунд.