Re: [rabbitmq-users] RabbitMQ failing when applying health-checks probes

[Michal Kuratczyk]

Hi,

We have built the Operator https://www.rabbitmq.com/kubernetes/operator/operator-overview.html so that people don't have to reinvent the wheel.

Please use it or at least do the same things that it does. There are many things wrong with your setup:

- Deployment is not the right abstraction for a stateful service like RabbitMQ

- we use different readinessProbes

- we don't use livenessProbes

- your resource requests/limits are low and strange

The Operator is not perfect but it's a consistent way of deploying RabbitMQ and we spent a lot of time discussing and testing things before we settled on what it is.

Best,

On Mon, Oct 17, 2022 at 10:53 AM juan Perez <juan.pere...@gmail.com> wrote:

We had a recent issue with RabbitMQ failing health-checks probes, tried in different clusters and all same result, basically the pod does not starts because health-checks failures, if not probes are setup in the yml works just fine

Have anyone found this issue? I even tested it in a simple docker-desktop local cluster and confirms the above

apiVersion: apps/v1
kind: Deployment
metadata:  
  labels:  
  name: rabbitmq
  namespace: test
spec:
  selector:
    matchLabels:
      app: rabbitmq
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: rabbitmq
        deployment: IDHP
    spec:
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - rabbitmq
              topologyKey: kubernetes.io/hostname
            weight: 50
      containers:
      - env:
        - name: RABBITMQ_DEFAULT_USER
          value: admin
        - name: RABBITMQ_DEFAULT_PASS
          value: Midiway2018$
        - name: RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS
          value: -rabbit path_prefix "/rabbitmq/"
        image: rabbitmq:3.10-alpine
        imagePullPolicy: Always
        livenessProbe:
          exec:
            command:
            - rabbitmq-diagnostics
            - ping
          failureThreshold: 3
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: rabbitmq
        readinessProbe:
          exec:
            command:
            - rabbitmq-diagnostics
            - ping
          failureThreshold: 3
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources:
          limits:
            cpu: 800m
            memory: 2560Mi
          requests:
            cpu: 15m
            memory: 500Mi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities: {}
          privileged: false
          readOnlyRootFilesystem: false
          runAsNonRoot: false
        startupProbe:
          exec:
            command:
            - rabbitmq-diagnostics
            - ping
          failureThreshold: 3
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        stdin: true
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        tty: true
      dnsPolicy: ClusterFirst
      imagePullSecrets:
      - name: nexusall
      - name: nexus-ssl-vm
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30

--
You received this message because you are subscribed to the Google Groups "rabbitmq-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rabbitmq-user...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/rabbitmq-users/532acb3a-e625-405d-b3ad-b6411c23102en%40googlegroups.com.

--

Michał

RabbitMQ team