Обзор

VK Private Cloud 4.3.0 содержит RabbitMQ 3.11 без PersistentVolumeClaim (PVC), VK Private Cloud 4.3.DS — RabbitMQ 3.13 с PVC.

Для корректной работы кластера RabbitMQ 3.13 необходимо сохранение данных базы RabbitMQ между перезапуском отдельных узлов кластера. Без них каждый перезапущенный процесс не сможет присоединиться к кластеру. В VK Private Cloud 4.3.0 c RabbitMQ 3.11 база данных RabbitMQ хранится в директории, которая уничтожается вместе с процессом RabbitMQ при перезапуске пода Kubernetes.

Обновление RabbitMQ с 3.11 до RabbitMQ 3.13 без ручных действий невозможно по следующим причинам:

• Каждый под RabbitMQ привязан к конкретному управляющему узлу с помощью PVC.

• В RabbitMQ StatefulSet есть правило Anti-Affinity, которое запрещает размещение двух подов RabbitMQ на одном управляющем узле.

• Обычно поды расположены не по порядку:

   
  $ kubectl -n rabbitmq get pod -o wide | grep neutron

  Пример ожидаемого результата

   
  rabbitmq-neutron-0                   1/1     Running   1 (121m ago)   19h   10.220.0.74    cpn003   <none>           <none>rabbitmq-neutron-1                   1/1     Running   1 (131m ago)   19h   10.220.0.27    cpn002   <none>           <none>rabbitmq-neutron-2                   1/1     Running   1 (144m ago)   19h   10.220.1.255   cpn001   <none>           <none>

Попытка автоматического обновления RabbitMQ с 3.11 до 3.13 проходит по такому сценарию:

1. Helm обновит StatefulSet до новой версии с PVC.

2. StatefulSet остановит под rabbitmq-nova-2. Согласно его настройкам, он привязан к узлу cpn003, но так как есть правило Anti-Affinity, он не сможет запустить там под и зависнет в статусе:

    
   pending: "Warning FailedScheduling 9s default-scheduler 0/3 nodes are available: 1 node(s) didn't satisfy existing pods anti-affinity rules, 2 node(s) had volume node affinity conflict. preemption: 0/3 nodes are available: 1 No preemption victims found for incoming pod, 2 Preemption is not helpful for scheduling."

3. Попытка удалить под rabbitmq-nova-0, чтобы освободить узел, приведет к потере кворума. Под rabbitmq-nova-1, согласно настройке сluster_partition_handling = pause_minority, перейдет в режим ожидания Cluster minority/secondary status detected – awaiting recovery и полностью остановит брокер с сообщением RabbitMQ is asked to stop.