Introduction

The easiest way to get a basic RabbitMQ deployment running on Kubernetes is to use a maintained Helm chart. That gives you a working broker, a service, credentials, optional persistence, and a management UI without hand-writing every manifest from scratch.

What "Basic Setup" Should Include

Even a simple RabbitMQ deployment on Kubernetes should usually have:

• a dedicated namespace or clear release name
• a stable service for clients
• persistent storage if messages must survive pod restarts
• credentials managed as Kubernetes secrets

For a local experiment you can relax some of those, but for anything beyond a demo, persistence and secret management matter immediately.

Install With Helm

Start by adding the chart repository and installing RabbitMQ:

1helm repo add bitnami https://charts.bitnami.com/bitnami
2helm repo update
3
4kubectl create namespace messaging
5
6helm install rabbitmq bitnami/rabbitmq \
7  --namespace messaging

That creates the core Kubernetes objects and generates a default username and password stored in a secret.

Retrieve the Credentials

After installation, fetch the generated password:

kubectl get secret --namespace messaging rabbitmq \
  -o jsonpath="{.data.rabbitmq-password}" | base64 --decode
echo

The default username for this style of setup is often user, but always confirm with the chart output or values you provided.

Access the Management UI

For a quick test, use port forwarding to reach the management interface:

kubectl port-forward --namespace messaging svc/rabbitmq 15672:15672

Then open:

http://localhost:15672

This is fine for development. In production, expose the UI deliberately through ingress or a secure internal access path rather than leaving it casually reachable.

Add Persistence

If the broker restarts and you care about message durability, enable persistence with a values file.

1auth:
2  username: appuser
3  password: apppassword
4
5persistence:
6  enabled: true
7  size: 8Gi

Install or upgrade with that file:

helm upgrade --install rabbitmq bitnami/rabbitmq \
  --namespace messaging \
  -f values.yaml

This is a much better baseline than a purely ephemeral broker if your workloads are more than disposable tests.

Verify the Pod and Service

Check that the pod is running and the service exists:

kubectl get pods --namespace messaging
kubectl get svc --namespace messaging

You want the pod in Running state and the service exposing the AMQP port, typically 5672, plus the management port if enabled.

Test a Client Connection

Once the broker is reachable, connect with an AMQP client or a test program. A simple Python example with pika looks like this:

1import pika
2
3credentials = pika.PlainCredentials("appuser", "apppassword")
4params = pika.ConnectionParameters(host="localhost", port=5672, credentials=credentials)
5
6connection = pika.BlockingConnection(params)
7channel = connection.channel()
8channel.queue_declare(queue="hello")
9channel.basic_publish(exchange="", routing_key="hello", body="hello rabbitmq")
10connection.close()

If you are running the client outside the cluster, combine this with kubectl port-forward or expose the service appropriately.

What to Improve After the First Deployment

A "basic" RabbitMQ on Kubernetes setup is usually just the start. Once the broker works, the next decisions are:

• whether to use a StatefulSet-based clustered setup
• how to expose clients inside and outside the cluster
• resource requests and limits
• backup and upgrade strategy
• policies for queues, TTL, and dead lettering

You do not need all of that to begin, but you do need to know that a single Helm install is not a full production architecture by itself.

Common Pitfalls

The biggest mistake is deploying RabbitMQ without persistence and then being surprised when messages disappear after a pod restart.

Another issue is exposing the broker or management UI too casually. Kubernetes makes port exposure easy, but it does not make it safe by default.

Developers also forget to retrieve the generated credentials and assume anonymous access will work. Most maintained charts do not leave the broker open.

Finally, do not confuse "pod is running" with "RabbitMQ is ready for your workload." Always verify connectivity through a real client connection.

Summary

• Helm is the fastest path to a basic RabbitMQ deployment on Kubernetes.
• Retrieve the generated credentials from the Kubernetes secret after install.
• Use port forwarding for quick local access to the management UI.
• Enable persistence if you care about durability across pod restarts.
• Treat the first working deployment as a baseline, not the end of production design.