Desplegando RabbitMQ con el Operator en Kubernetes

Jul 10, 2025 - 6 min read - 864 words

En una arquitectura de microservicios moderna, la comunicación directa y síncrona no siempre es la mejor opción. Para desacoplar nuestros servicios y construir sistemas resilientes y escalables, necesitamos un Message Broker. Aquí es donde entra RabbitMQ.

En este tutorial, desplegaremos un clúster de RabbitMQ utilizando el RabbitMQ Cluster Kubernetes Operator, esta vez del popular catálogo de Bitnami.

Prerrequisitos

Clúster de Kubernetes: Un clúster funcional (como el que montamos con MicroK8s).
Helm y kubectl: Instalados y configurados en tu máquina de desarrollo.
Istio Ingress Gateway: Desplegado y configurado, ya que lo usaremos para exponer la UI de RabbitMQ.

Parte 1: Instalando el RabbitMQ Operator

Añadir el Repositorio de Helm de Bitnami Primero, añadimos el repositorio de Bitnami, que contiene una vasta colección de charts de alta calidad, incluyendo el del RabbitMQ Operator.
Terminal window
```
helm repo add bitnami https://charts.bitnami.com/bitnami
```
Instalar el Operator Ahora, desplegamos el Operator en su propio namespace para mantener la organización. Este Operator se encargará de gestionar el ciclo de vida de nuestros clústeres de RabbitMQ.
Terminal window
```
helm install rabbitmq bitnami/rabbitmq-cluster-operator --namespace rabbitmq-operator --create-namespace
```
El estado STATUS: deployed confirma la instalación correcta.

En Lens, podemos verificar la nueva release rabbitmq en el namespace rabbitmq-operator.

Parte 2: Desplegando el Clúster de RabbitMQ

Crear y Etiquetar el Namespace Desplegaremos nuestro clúster de RabbitMQ en su propio namespace. Crucialmente, lo etiquetaremos para la inyección automática del sidecar de Istio.
Terminal window
```
kubectl create ns srv-rabbitmq
kubectl label namespace srv-rabbitmq istio-injection=enabled
```
Al etiquetar el namespace, Istio añadirá automáticamente un proxy Envoy a cada pod de RabbitMQ. Esto nos permitirá aplicar políticas de seguridad mTLS (Mutual TLS) en el futuro, garantizando que toda la comunicación de mensajería dentro del clúster esté cifrada y sea segura, sin tener que configurar TLS en RabbitMQ directamente.

Podemos verificar en Lens que el namespace srv-rabbitmq ha sido creado con la etiqueta correcta.
Definir el Clúster con un Recurso Personalizado El Operator nos permite definir nuestro clúster de RabbitMQ de forma declarativa con un Custom Resource. Creamos un archivo cluster.yaml:
```
# https://www.rabbitmq.com/kubernetes/operator/using-operator
apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: rabbitmq-cluster
  namespace: srv-rabbitmq
spec:
  replicas: 3
  persistence:
    storageClassName: microk8s-hostpath
```
Este simple manifiesto le ordena al Operator que cree un clúster de RabbitMQ llamado rabbitmq-cluster con 3 nodos para alta disponibilidad.
Aplicar el Manifiesto del Clúster Aplicamos el archivo para que el Operator comience a trabajar.
Terminal window
```
kubectl apply -f .\cluster.yaml
```
Verificar los Recursos Creados
- En Lens, bajo Custom Resources > RabbitmqCluster, vemos nuestro nuevo recurso.
- En la sección de Pods, vemos que el Operator ha creado 3 pods para nuestro clúster (rabbitmq-cluster-server-0, 1, y 2).
- En “Network > Services”, vemos que el Operator ha creado un servicio rabbitmq-cluster. Este es de tipo ClusterIP, lo que significa que solo es accesible desde dentro del clúster.

Parte 3: Exponiendo la UI de Gestión con Istio

El tráfico de mensajería entre nuestros microservicios y RabbitMQ será interno (usando el servicio ClusterIP). Sin embargo, necesitamos acceder a la interfaz de gestión web de RabbitMQ para monitorizar y administrar las colas. Para esto, usaremos nuestro Gateway de Istio.

Crear el VirtualService Crearemos un VirtualService para indicarle a Istio cómo enrutar el tráfico que llegue a rabbitmq.codedesignplus.app. Creamos un archivo network.yaml:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: rabbitmq-virtualservice
  namespace: srv-rabbitmq
spec:
  hosts:
  - rabbitmq.codedesignplus.app
  gateways:
  - istio-ingress/istio-inventory-gateway
  http:
  - route:
    - destination:
        host: rabbitmq-cluster.srv-rabbitmq.svc.cluster.local
        port:
          number: 15672

Esta regla dirige todo el tráfico para rabbitmq.codedesignplus.app al servicio interno de RabbitMQ en el puerto 15672.

Aplicar el VirtualService
Terminal window
```
kubectl apply -f .\network.yaml
```
Verificamos en Lens que el nuevo VirtualService ha sido creado.
Configurar el Acceso Local (Archivo hosts) Como en artículos anteriores, añadimos una entrada temporal a nuestro archivo hosts para poder acceder al dominio desde nuestra máquina.
```
192.168.0.30    rabbitmq.codedesignplus.app
```
Obtener las Credenciales de Acceso El Operator de RabbitMQ genera automáticamente un usuario y una contraseña por defecto y los almacena en un secreto de Kubernetes.
- En Lens, vamos a Config > Secrets y seleccionamos el namespace srv-rabbitmq.
- Hacemos clic en el secreto rabbitmq-cluster-default-user.
- Lens nos muestra los valores decodificados para username y password. ¡Copiamos ambos!
Acceder a la UI de RabbitMQ Abrimos un navegador y vamos a https://rabbitmq.codedesignplus.app.

Usamos las credenciales que acabamos de obtener del secreto para iniciar sesión.

¡Y listo! Estamos dentro de la consola de gestión de RabbitMQ, donde podemos ver nuestros 3 nodos del clúster funcionando perfectamente.

Conclusión

Has desplegado con éxito un clúster de RabbitMQ de alta disponibilidad utilizando el patrón Operator. Has aprendido a:

Instalar y usar el RabbitMQ Cluster Operator de Bitnami.
Desplegar un clúster declarativamente con un Custom Resource.
Entender la diferencia entre el tráfico de mensajería interno y la exposición segura de la UI de gestión a través de Istio.

Con RabbitMQ en su lugar, nuestra arquitectura está ahora preparada para la comunicación asíncrona y orientada a eventos, un pilar fundamental para construir microservicios desacoplados y resilientes.