Keycloak ― построение отказоустойчивого кластера

[MalevMih]

Можно уточнить, какую скорость failover удалось достигнуть таким образом?

[Okunev_Sergey]

Все узлы в данной конфигурации работают в режиме active / active, точную скорость не мерял, но в случае отказа infinispan почти сразу удаляет ноду из кластера, остаётся разве что снять анонсы bgp. Этим у меня занимается healthcheck скрипт.

[KorDen32]

и если с БД всё более-менее понятно

Прошлись бы мимоходом, какую СУБД используете и как кластеризуете.

Скажем, красивые инструкции по запуску Keycloak на CockroachDB на практике не такие красивые - выполнить последующий апгрейд даже на минорную версию будет невозможно из-за несовместимости при обработке транзакций.

[Okunev_Sergey]

Посчитал, что это выходит за рамки статьи. Всё достаточно обыденно, но это я ещё не обновлял ни разу keycloak, только предстоит.

Используем в качестве БД PostgreSQL 15, кластеризуем через Patroni 3.0.2, балансируем нагрузку с помощью HAProxy.

[KorDen32]

Как раз при использовании обычного PostgreSQL проблем на уровне Keycloak нет.

А вот при использовании Postrgres-совместимой CockroachDB, например как описано в статье, на которую вы сослались в источниках, вылезают проблемы именно в момент апгрейда. Заподозрить неладное можно уже из предлагаемого пути установки: сначала предлагается ставить на PostgreSQL, а затем импортировать дамп в CockroachDB.

[rakhinskiy]

А как же настройка самого Infinispan?

Если я правильно помню, то по умолчанию он хранит только один экземпляр в кэше и если перезапустить keycloak на одной из нод, то все сессии на ней пропадут. Нужно явно указать количество owners для записей.

Keycloak replication

[Okunev_Sergey]

Посмотрел, в нашей конфигурации keycloak 20.0.3 по умолчанию проставлено owners="2" для всех кэшей.

Подобной настройки не производил, не думал в эту сторону, так как для нас подобные последствия из-за отказа одной из нод не являются значимыми. Но узнать было полезно, спасибо.

[rakhinskiy]

Я уже давно с keycloak не сталкивался, раньше видимо по умолчанию было owners="1", а так как там хранятся сессии, то upgrade бы приводил к logout части пользователей. На саму доступность сервиса это не влияет. В целом keycloak довольно удобен, но я сейчас присматриваюсь к zitadel (она по умолчанию использует CockroachDB)

[ufoton]

Мы сделали через

--cache-stack=kubernetes
-Djgroups.dns.query=dns-name

dns-name возвращает несколько A записей.

[Okunev_Sergey]

Честно говоря я исключил этот вариант сразу же, так как название стэка ввело в заблуждение, у нас же не в кубере разворачивается кейклок. Сейчас открыл его дефолтный конфиг и удивился. Оно, по факту, не относится напрямую к k8s, странный нейминг.

Полезно было узнать, спасибо.