я исследую Очереди кворума RabbitMQ для повышения доступности некоторых сервисов в кластере Kubernetes. Как я читаю, они разработаны с учетом безопасности данных.
Однако глава "Управление репликами" состояния:
Реплики очереди кворума явно управляются оператором.
Когда в кластер добавляется новый узел, в нем не будет очереди кворума.
реплики, если оператор явно не добавляет их к члену (реплике)
список очереди кворума или набор очередей кворума.
Представляется поэтому, что в случае нарушения (особенно непроизвольно) могла возникнуть следующая ситуация (для 3-узлового кластера):
- после сбоя узел выйдет из строя: два других узла по-прежнему составляют большинство и будут «поддерживать очередь в живых», возможно, выбирая нового лидера;
- kubernetes предоставит новый узел (pod) взамен вышедшего из строя узла; новый узел автоматически присоединится к кластеру RabbitMQ, но
- если только оператор вручную вмешивается, новый узел будет нет вносить вклад в существующие очереди кворума;
- для кластера из 3 узлов это означает, что высокой доступности больше нет: если когда-нибудь в будущем один из других узлов выйдет из строя, очередь будет фактически потеряна;
Есть ли способ смягчить этот сценарий? Например, возможно ли, чтобы узлы автоматически присоединялись ко всем существующим кластерам очередей кворума? Возможно, поддерживая список «команд запуска» (которые запускаются после запуска RabbitMQ), к которым мы могли бы добавить присоединиться к командам?
