Всем привет!
Зачастую, кластер Kubernetes существует в единственном числе недолгое время. Рано или поздно кластеров становится несколько.
Например, из-за технических (сокращение задержки), организационных (отдельный кластер под определённую команду) или регуляторных (сокращение «области действия» требований) причин.
И тут начинается самое весёлое: всё, что было сделано для того «первого» кластера надо отмасштабировать на остальные. И не только отмасштабировать, но и централизованно управлять всем этим, что приводит к «двойной работе».
В статье от Kedify описан подход, который использовала команда, чтобы решить эту задачу. Если кратко, то всё просто: создание единого «мозга», который всем управляет. Но дьявол в деталях!
Ребята используют один KEDA-кластер, который анализирует метрики и взаимодействует с Member-кластерами через
kube-apiserver.Member-кластеры, в свою очередь, создают необходимые нагрузки и всё это с минимально-необходимыми правами.
Для того, чтобы KEDA-кластер мог управлять Member-кластерами команда сделала свой CRD -
DistributedScaledObject.Он определяет, на каких Member-кластерах можно создавать ресурсы, что делать в случае их недоступности, как собирать информацию о «здоровье» и т.д.
В итоге получается конструкция, которая позволяет управлять несколькими кластерами Kubernetes «на масштабе» и может работать в случае недоступности некоторых Member-кластеров.
Больше информации, как обычно, можно найти в статье.
