k8s, RabbitMQ и Peer Discovery - PullRequest
Новая
       38

k8s, RabbitMQ и Peer Discovery

0 голосов
/ 22 января 2019

Мы пытаемся запустить экземпляр диаграммы RabbitMQ с помощью Helm из проекта helm / charts / stable / rabbit .У меня он работал отлично, но потом мне пришлось перезапустить K8s для некоторого обслуживания.Теперь мы совершенно не можем запустить диаграмму RabbitMQ в любом виде или форме.Я даже не пытаюсь запустить диаграмму с любыми переменными, то есть только значениями по умолчанию.

Вот все, что я делаю: 

helm install stable/rabbitmq

Я подтвердил, что могу просто запустить по умолчанию прямо на моем локальном k8s, который я использую с Docker for Desktop.Когда мы запускаем диаграмму кролика на наших общих k8s точно так же, как на рабочем столе, и то, что мы делали до перезапуска, выдается следующая ошибка: 

Failed to get nodes from k8s - 503

Я также опубликовал проблему на диаграммах Helmрепо тоже. Нажмите здесь, чтобы увидеть проблему на Github.

Мы подозреваем DNS, но пока не можем ничего подтвердить.Что очень расстраивает, так это то, что после перезапуска все остальные установленные нами диаграммы перезапускались идеально, за исключением Rabbit, который теперь вообще не запускается.

Кто-нибудь знает, что я могу сделать, чтобы сделать открытие Кролика равным?Кто-нибудь видел такую ​​проблему после перезапуска k8s?

Ответы [ 2 ]

0 голосов
/ 25 января 2019

Так что я действительно заставил кролика бежать.Оказывается, моя проблема заключалась в том, что обнаружение равноправного узла k8s не могло подключиться через порт 443 по умолчанию, и мне пришлось использовать внешний порт 6443, потому что kubernetes.default.svc.cluster.local разрешен для общего порта и не может найти внутренний, так что да, наша конфигурация тоже испорчена,

Мне потребовалось некоторое время, чтобы понять, что приведенная ниже переменная не переопределяется, когда я переопределил ее с помощью helm install . -f server-values.yaml.

rabbitmq:
  configuration: |-
    ## Clustering
    cluster_formation.peer_discovery_backend  = rabbit_peer_discovery_k8s
    cluster_formation.k8s.host = kubernetes.default.svc.cluster.local
    cluster_formation.k8s.port = 6443
    cluster_formation.node_cleanup.interval = 10
    cluster_formation.node_cleanup.only_log_warning = true
    cluster_partition_handling = autoheal
    # queue master locator
    queue_master_locator=min-masters
    # enable guest user
    loopback_users.guest = false

Мне пришлось добавить cluster_formation.k8s.port = 6443 к основному values.yaml файлу вместо моего собственного.Как только порт был специально изменен в values.yaml, кролик запустился.

0 голосов
/ 24 января 2019

Мне интересно, в чем причина использования плагина rabbit_peer_discovery_k8s, если значение values.yaml по умолчанию равно 1 реплике (ваш файл манифеста не переопределяет этот параметр)?

Я пытался воспроизвести вашу проблему с указанными вами значениями переопределения (dev-server.yaml), как описано в вашей проблеме github # 10811, но мне это не удалось. Вот мои наблюдения:

  1. Если установить диаграмму RabbitMQ с вашими пользовательскими значениями, мой модуль rabbitmq-dev-default-0 застревает в состоянии CrashLoopBackOff. Для меня это довольно трудно устранить, поскольку контейнеры изображений rabbitmq для bitnami, используемые в этой таблице rabbitmq Helm, поставляются с учетной записью без полномочий root.
  2. С другой стороны, если диаграмма rabbitmq установлена ​​в моем кластере Kubernetes (v1.13.2) в простейшем виде:

helm install stable / rabbitmq

Я наблюдаю подобную проблему тогда. Я имею в виду, что сервер rabbitmq переживает симулированный перезапуск виртуальной машины всех узлов кластера (включая главный), но я не могу подключиться к нему извне:

После перезагрузки виртуальной машины, я получаю следующую ошибку от моего python mqclient: 

socket.gaierror: [Errno -2] Name or service not known

Несколько замечаний здесь:

Да, я сделал переадресацию портов в соответствии с инструкциями для команды "helm status":

Датчик готовности работает нормально: 

curl -sS -f --user user:<my_pwd> 127.0.0.1:15672/api/healthchecks/node
{"status":"ok"}

Соединение rabbitmqctl с rabbitmq-сервером изнутри контейнера тоже работает нормально: 

kubectl exec rabbitmq-dev-default-0 -- rabbitmqctl list_queues
warning: the VM is running with native name encoding of latin1 which may cause Elixir to malfunction as it expects utf8. Please ensure your locale is set to UTF-8 (which can be verified by running "locale" in your shell)
Timeout: 60.0 seconds ...
Listing queues for vhost / ...
name    messages
hello   11

С того момента, как я использовал kubectl port-forward для pod вместо службы, соединение с сервером rabbitmq восстанавливается: 

kubectl port-forward --namespace default pod/rabbitmq-dev-default-0 5672:5672

$ python send.py
 [x] Sent 'Hello World!'
...