☰

Kubernetes RabbitMQ Operator: Der Cluster hat Startprobleme (ReadinessProbes schlagen fehl). Wie kann das Problem weiter behoben werden?

tag-icon • tag-icon kubernetes rabbitmq
Kubernetes RabbitMQ Operator: Der Cluster hat Startprobleme (ReadinessProbes schlagen fehl). Wie kann das Problem weiter behoben werden?

Mein RabbitMQ-Cluster wechselt nicht in den Bereitschaftszustand (Bereitschaftsprüfungen schlagen fehl), da beim Start Probleme auftreten.

Der Cluster wurde mit dem offiziellen RabbitMQ-Operator bereitgestellt. Leider enthalten die Protokolle keine wertvollen Informationen.

Die RabbitmqCluster-Ressource ist mehr oder weniger das Standardbeispiel für „Hallo Welt“:

cat <<EOF | kubectl apply -f -
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: why-not-ready
spec:
  persistence:
    storageClassName: nfs-client
---
EOF

Protokollausgabe:

rabbitmq 09:06:44.95
rabbitmq 09:06:44.96 Welcome to the Bitnami rabbitmq container
rabbitmq 09:06:44.96 Subscribe to project updates by watching https://github.com/bitnami/containers
rabbitmq 09:06:44.96 Submit issues and feature requests at https://github.com/bitnami/containers/issues
rabbitmq 09:06:44.96
rabbitmq 09:06:44.96 INFO  ==> ** Starting RabbitMQ setup **
rabbitmq 09:06:44.98 INFO  ==> Validating settings in RABBITMQ_* env vars..
rabbitmq 09:06:44.99 INFO  ==> Initializing RabbitMQ...
rabbitmq 09:06:45.03 INFO  ==> Starting RabbitMQ in background...
rabbitmq 09:09:03.93 ERROR ==> Couldn't start RabbitMQ in background.

Habe versucht das zusätzliche Logging zu aktivieren, leider war keine Ausgabe mehr sichtbar:

cat <<EOF | kubectl apply -n rabbitmq -f -
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: why-not-ready
spec:
  persistence:
    storageClassName: nfs-client
  rabbitmq:
     additionalConfig: |
      log.default.level = debug
      log.file = false
      log.console = true
      log.console.stdio = stdout   
      log.console.level = debug
---
EOF

Der Setup-Container scheint einwandfrei zu laufen > alle Dateien werden korrekt und mit gültigem Inhalt an die gewünschten Speicherorte kopiert:

> cat /var/lib/rabbitmq/.erlang.cookie
uxdvZFvkpHFMdAgXM5azu0LOCE283kzY

> cat /operator/enabled_plugins
[rabbitmq_peer_discovery_k8s,rabbitmq_prometheus,rabbitmq_management].

> cat /var/lib/rabbitmq/.rabbitmqadmin.conf
[default]
username = default_user_l4yC9XizAcUHQEIe3Ep
password = zjvyy5XYCss-kFxu2dCnH2vDrd3AUsbu

Einige zusätzliche Erkenntnisse aus der Fehlerbehebung:

  • /var/lib/rabbitmq/mnesia/ ist vom Container aus beschreibbar und wird auch auf dem persistenten Datenträger aktualisiert.
  • Ich habe dann überprüft, wie rabbitmq die Anwendung startet. Es gibt ein Setup-Skript /opt/bitnami/scripts/rabbitmq/setup.sh, das beim Start aufgerufen wird. Darin wird rabbitmq_initialize aufgerufen, was die folgende stdout-Zeile verursacht, INFO ==> Starting RabbitMQ in background...wie in den Protokollen zu sehen. Leider liefert es keine zusätzliche Ausgabe, wenn ich das Skript manuell aufrufe.

Hat jemand eine Idee, was beim Start fehlschlägt oder wie man zusätzliche Debug-Protokolle aktiviert? Jede Hilfe ist willkommen!

Danke und BR,

Philipp

Antwort1

Ich denke, dieser Fall war sehr speziell > trotzdem hätte ich mir eine Art Protokollierung für rabbitmq_initialize gewünscht, da diese derzeit fehlt.

In meinem Fall war es ein nicht erreichbarer Core-DNS (aufgrund einer ungültigen K8s-Routingkonfiguration), der beim Starten von RabbitMQ erforderlich zu sein scheint.

Ich konnte das Problem auch reproduzieren, indem ich die Schreibrechte für das persistente Volume entfernte. Das lag allerdings nur daran, dass mir die Ideen ausgingen :).

verwandte Informationen