Это решение сверху. Но вообще, таким образом мы не сталкиваемся с проблемой сетевой связности между кластерами. Для нас важнее изоляция. Каждый ЦОД имеет независимую панель управления кубером, и проблемы с сетью между площадками или с панелью кубера одного кластера не должны влиять на работоспособность второго. Нужно решать quorum, а честного quorum с двумя ЦОДами без третьего участника добиться тяжело
2. А если кластер не тянутый, то как вы обеспечиваете отказоустойчивость?
За счёт того, что приложение независимо развёрнуто в нескольких ЦОДах. Отказ одного Kubernetes-кластера не означает отказ второго.
Для внутреннего трафика у нас используется Consul с healthcheck, и в случае если инстанс сервиса в одном ДЦ не показывает признаков жизни, то консул перенаправляет запросы на второй инстанс.
3. Если запрет на тянутость спущен сверху, то почему не распределенные блокировки через тянутый кластер zookeeper\etcd поверх двух кубер кластеров?
Так тоже можно сделать. Но это значит для нас появление еще одного stateful-компонента, за отказоустойчивостью которого нужно будет следить самим. В нашей инфраструктуре за отказоустойчивость PostgreSQL отвечает отдельная команда. Так что было решено взять сервис, который мы считаем, что всегда жив. Если постгрес умрет, то приложение и без блокировок работать не будет в принципе.
4. Если все-таки решение на уровне бд, то как обеспечивается его отказоустойчивость? ПГ тоже нужно 3 синхронные реплики минимум.
Как я сказал ранее, в нашей ситуации - БД мы считаем всегда доступным. Тк у нас все критичные данные хранятся там, то при отказе БД мы уже ничего не сможем сделать, и не работающие CronJob'ы будет нашей наименьшей проблемой
Ну и это уже вопрос к самой БД, а не к механизму в статье. У нас механизм такой, если база недоступна, то лок взять нельзя и задача не может быть выполнена.
Да и ко всему прочему, поднимать отдельный consensus-кластер только ради координации CronJob, это overkill.
5. Как синхронизируются два кластера? проблема с кроном, наверное, наименьшая из возможных при таком подходе - нечестном active-active
Да никак :) В этом и есть наш подход к отказоустойчивости. Если кластеры не знают о существовании друг друга, то падение одного из них никак не заденет второй, кроме повышенной на него нагрузки. А проблема повышенной нагрузки решается с помощью hpa.
Спасибо за вопросы. Попробую по пунктам:
1. Почему не тянутый кластер кубера?
Это решение сверху. Но вообще, таким образом мы не сталкиваемся с проблемой сетевой связности между кластерами. Для нас важнее изоляция. Каждый ЦОД имеет независимую панель управления кубером, и проблемы с сетью между площадками или с панелью кубера одного кластера не должны влиять на работоспособность второго. Нужно решать quorum, а честного quorum с двумя ЦОДами без третьего участника добиться тяжело
2. А если кластер не тянутый, то как вы обеспечиваете отказоустойчивость?
За счёт того, что приложение независимо развёрнуто в нескольких ЦОДах. Отказ одного Kubernetes-кластера не означает отказ второго.
Для внутреннего трафика у нас используется Consul с healthcheck, и в случае если инстанс сервиса в одном ДЦ не показывает признаков жизни, то консул перенаправляет запросы на второй инстанс.
3. Если запрет на тянутость спущен сверху, то почему не распределенные блокировки через тянутый кластер zookeeper\etcd поверх двух кубер кластеров?
Так тоже можно сделать. Но это значит для нас появление еще одного stateful-компонента, за отказоустойчивостью которого нужно будет следить самим. В нашей инфраструктуре за отказоустойчивость PostgreSQL отвечает отдельная команда. Так что было решено взять сервис, который мы считаем, что всегда жив. Если постгрес умрет, то приложение и без блокировок работать не будет в принципе.
4. Если все-таки решение на уровне бд, то как обеспечивается его отказоустойчивость? ПГ тоже нужно 3 синхронные реплики минимум.
Как я сказал ранее, в нашей ситуации - БД мы считаем всегда доступным. Тк у нас все критичные данные хранятся там, то при отказе БД мы уже ничего не сможем сделать, и не работающие CronJob'ы будет нашей наименьшей проблемой
Ну и это уже вопрос к самой БД, а не к механизму в статье. У нас механизм такой, если база недоступна, то лок взять нельзя и задача не может быть выполнена.
Да и ко всему прочему, поднимать отдельный consensus-кластер только ради координации CronJob, это overkill.
5. Как синхронизируются два кластера? проблема с кроном, наверное, наименьшая из возможных при таком подходе - нечестном active-active
Да никак :) В этом и есть наш подход к отказоустойчивости. Если кластеры не знают о существовании друг друга, то падение одного из них никак не заденет второй, кроме повышенной на него нагрузки. А проблема повышенной нагрузки решается с помощью hpa.