Если etcd-кластер разворачивается на мастер нодах, то их количество должно быть нечетное - т.е. минимум 3, в текущем примере выход из строя одной из мастер-нод переведет оставшуюся ноду etcd в readonly состояние - не будет похоже на HA. Размещение etcd на рабочих нодах, как в примере из статьи, крайне не рекомендуется с точки зрения безопансости.
Не обязательно разворачивать ингресс на каждой ноде - зачастую такого количества ингресов не нужно, можно использовать и Deployment. Без сервиса с типом LoadBalancer лучшим выбором будет hostport, а задачу контроля доступности возложить на балансировщик
Простейшим способом организовать HA для входящего трафика - использовать балансировщик, например haproxy и, используя его возможности по активным проверкам доступности апстримов, балансировать трафик на hostport каждой ноды. Например, запустить 2 инстанса haproxy с публичными IP и использовать DNS Roundrobin в качестве простейшего решения
В качестве DNS сервера можно использовать PowerDNS - он поддерживает активные health-check и может на основе них возвращать разный набор A-записей. Единственная проблема организации HA на уровне DNS сохраняется - это относительно продолжительное время обновления записей в кеширующих DNS, но плюсы тоже на месте - восстановление доступности сервисов произойдет без человеческого вмешательства
Если нас интересует только HA для балансировщиков, то можно настроить "плавающий" ip с использованием keepalived между этими двумя балансировщиками. В случае отказа основного, ip спрыгнет на резервный и трафик продолжит ходить через второй сервис. В таком случае не потребуется приплясывать с DNS
Данная библиотека не работает на подобии selenium, а воспроизводит протокол WhatsappWeb. Это ощутимое преимущество, но и потенциально повышенный шанс получить блокировку. Хотя, пока, лично у меня, не было такого случая.
Монорепы - зло
Классная статья!
Добавлю лишь несколько замечаний
Если etcd-кластер разворачивается на мастер нодах, то их количество должно быть нечетное - т.е. минимум 3, в текущем примере выход из строя одной из мастер-нод переведет оставшуюся ноду etcd в readonly состояние - не будет похоже на HA. Размещение etcd на рабочих нодах, как в примере из статьи, крайне не рекомендуется с точки зрения безопансости.
Не обязательно разворачивать ингресс на каждой ноде - зачастую такого количества ингресов не нужно, можно использовать и Deployment. Без сервиса с типом LoadBalancer лучшим выбором будет hostport, а задачу контроля доступности возложить на балансировщик
Простейшим способом организовать HA для входящего трафика - использовать балансировщик, например haproxy и, используя его возможности по активным проверкам доступности апстримов, балансировать трафик на hostport каждой ноды. Например, запустить 2 инстанса haproxy с публичными IP и использовать DNS Roundrobin в качестве простейшего решения
В качестве DNS сервера можно использовать PowerDNS - он поддерживает активные health-check и может на основе них возвращать разный набор A-записей. Единственная проблема организации HA на уровне DNS сохраняется - это относительно продолжительное время обновления записей в кеширующих DNS, но плюсы тоже на месте - восстановление доступности сервисов произойдет без человеческого вмешательства
Если нас интересует только HA для балансировщиков, то можно настроить "плавающий" ip с использованием keepalived между этими двумя балансировщиками. В случае отказа основного, ip спрыгнет на резервный и трафик продолжит ходить через второй сервис. В таком случае не потребуется приплясывать с DNS
Не смогу подсказать. Мне кажется, невысокий трафик. Чтобы не сочли спамом, контакты должны быть добавлены друг у друга.
Пользуюсь этой библиотекой
https://github.com/Rhymen/go-whatsapp
Можно сказать, что пользуюсь api через web-клиент