Tanzu RabbitMQ on Kubernetes 3.13

4.0 3.13

VMware Tanzu RabbitMQ for Kubernetes Release Notes

Last Updated February 26, 2025

These release notes include detailed release information for Tanzu RabbitMQ on Kubernetes.

VMware Tanzu RabbitMQ for Kubernetes software is available for download from the Broadcom Support Portal. For instructions, go to Access the VMware Tanzu RabbitMQ for Kubernetes Docker Images.

Important Notes before Continuing

  • The current VMware Tanzu RabbitMQ for Kubernetes release is 3.13 (the latest patch release is 3.13.8). For users who are currently using 1.5 releases, note that 3.13 is the next release after 1.5. This is different from the expectation that the next release would be 1.6. The reason for this change is to align product version numbers between open source RabbitMQ and commercial VMware Tanzu RabbitMQ product versions.

  • The latest patch release number for this VMware Tanzu RabbitMQ for Kubernetes release is 3.13.8. It matches the included open-source RabbitMQ version, which is also 3.13.8. Note, there was no VMware Tanzu RabbitMQ for Kubernetes 3.13.7 patch release.

  • VMware Tanzu RabbitMQ for Kubernetes was formerly known as VMware RabbitMQ for Kubernetes. To avoid confusion, all releases listed in this release notes information are referred to using the current product offering name VMware Tanzu RabbitMQ for Kubernetes.

    If the specific release that you are using is called VMware RabbitMQ for Kubernetes and it is referred to as VMware Tanzu RabbitMQ for Kubernetes in these release notes, note that this is the same product offering, its naming has just varied over time.

  • You can also avail of documentation for the Open Source RabbitMQ product. As the Tanzu RabbitMQ for Kubernetes product offering is built from the open source RabbitMQ product, open source RabbitMQ documentation is a core part of the Tanzu RabbitMQ for Kubernetes offering documentation. When you are using this Tanzu RabbitMQ for Kubernetes documentation, you will be redirected to the open source RabbitMQ documentation as required.

VMware Tanzu RabbitMQ for Kubernetes Release 3.13

VMware Tanzu RabbitMQ for Kubernetes Release 3.13.8

VMware Tanzu RabbitMQ for Kubernetes 3.13.8 contains the following packages and changes:

  • Open-source RabbitMQ 3.13.8
  • Erlang 26.2.5
  • Cluster Operator 2.12.1
  • Messaging Topology Operator 1.15.0

Open-source RabbitMQ 3.13.8 Changes

Open-source RabbitMQ version 3.13.8 is a maintenance release in the 3.13.x release series.

For information about the changes in the core broker and so on, see the 3.13.8 release notes.

To see the release notes for the entire 3.13.x release series, see all the open-source RabbitMQ release notes and then select the relevant version.

VMware Tanzu RabbitMQ for Kubernetes Release 3.13.6

VMware Tanzu RabbitMQ for Kubernetes 3.13.6 contains the following packages and changes:

VMware Tanzu RabbitMQ on Kubernetes Release 3.13.6

VMware Tanzu RabbitMQ on Kubernetes 3.13.6 contains the following packages and changes:

  • Open-source RabbitMQ 3.13.6
  • Erlang 26.2.5
  • Cluster Operator 2.9.0 (the version has not changed since previous releases)
  • Messaging Topology Operator 1.14.2
  • Standby Replication Operator 0.7.2

Open-source RabbitMQ 3.13.6 Changes

Open-source RabbitMQ version 3.13.6 is a maintenance release in the 3.13.x release series.

For details on the changes in the core broker and so on, review the 3.13.6 release notes.

To review the release notes for the entire 3.13.x release series, go to all open-source RabbitMQ release notes and choose the specific version of the release notes that you want.

VMware Tanzu RabbitMQ for Kubernetes Release 3.13.3

VMware Tanzu RabbitMQ for Kubernetes 3.13.3 contains the following packages and changes:

Open-source RabbitMQ 3.13.2/3.13.3 Changes

Open-source RabbitMQ 3.13.2 and 3.13.3 are maintenance releases in the 3.13.x release series.

For details on the changes in the core broker, CLI tools, Management Plugin, and so on, review the 3.13.2 and 3.13.3 release notes.

To review the release notes for the entire 3.13.x release series, go to all open-source RabbitMQ release notes and choose the specific version of the release notes that you want.

Cluster Operator 2.9.0

The main changes are:

  • Only required objects are cached from the Kubernetes API, which has resulted in lower memory usage in large Kubernetes clusters.
  • There are correct annotations for certificates that are generated via a vault intermediate Certificate Authority (CA).
  • The graceful shutdown issue is fixed.
  • The RabbitMQ cluster does not restart after a scale-out.

Upgrading the cluster operator to version 2.9.0 causes a rolling update of the underlying StatefulSets. If you want to control when a RabbitMQ cluster gets updated (“updated” here means updating the RabbitMQ cluster resources, it does not mean the RabbitMQ version gets updated), you must pause reconciliation before you upgrade the cluster operator. After the cluster operator upgrade is complete, resume reconciliation whenever it is safe to update the RabbitMQ cluster.

For more details of 2.9.0 changes, review What’s Changed.

Message Topology Operator 1.14.1

The main changes are:

  • It now supports RabbitMQ operator policies.
  • You can now use the if-empty and if-unused parameters when you are deleting queues.
  • The all category is removed from the custom resource definitions (CRDs).

For more details of 1.14.1 changes, review What’s Changed.

Warm Standby Replication Improvements

The following Warm Standby Replication improvements are now available in the 3.13.3 Tanzu RabbitMQ for Kubernetes release.

  • Users can now configure connection endpoints and credentials using rabbitmq.conf.

  • Streams can now be replicated.

  • You can view Warm Standby Replication metrics from the replication tabs in the RabbitMQ Management UI. Users can monitor the upstream (primary) and downstream (standby) clusters in a Warm Standby Replication configuration and check the status of both message and schema replication. For instructions, go to Warm Standby Replication Documentation, Method 1.

  • New CLI commands are introduced such as the rabbitmqctl promote_warm_standby command, which completes all promotion tasks in one step.

  • Bug fixes.

FIPS Compliance

One of the key features exclusive to this 3.13.3 Tanzu RabbitMQ for Kubernetes release is compliance with the Federal Information Processing Standard (FIPS) 140-2. This compliance provides another level of security to RabbitMQ messaging using OpenSSL 3.

Security of financial and governmental systems is essential for organizations. Setting up the correct configuration can be challenging enough without having to setup FIPS compliance (which is built into Erlang) also. Now with the Tanzu RabbitMQ for Kubernetes 3.13.3 release, this FIPS configuration is provided out of the box.

If you are using FIPS, you must pull the FIPS variant images from the Broadcom Support Portal. For instructions on how to get those images, go to Install Tanzu RabbitMQ for Kubernetes.

Support for MQTT 5.0

The previous 1.5.x releases of Tanzu RabbitMQ included some significant improvements to the performance of the MQTT (Message Queuing Telemetry Transport) protocol, which is used extensively in IoT applications. For more details, refer to this blog.

The previous 1.5.x releases of Tanzu RabbitMQ included some significant improvements to the performance of the MQTT (Message Queuing Telemetry Transport) protocol, which is used extensively in IoT applications. For more details, refer to this blog.

If you are using FIPS, you must pull the FIPS variant images from the Broadcom Support Portal. For instructions on how to get those images, go to Access the VMware Tanzu RabbitMQ for Kubernetes Docker Images.

Support for MQTT 5.0

Filtering for RabbitMQ Streams

Since the launch of streams in RabbitMQ, there is a steady growth in the adoption of this highly performant message transport mechanism. Streams not only provide the ability to route high volumes of data, they can also be partitioned into topics to make the consumption easier for client applications using super streams.

Now in this Tanzu RabbitMQ for Kubernetes 3.13.3 release, users can filter a stream. This feature lightens the load on client applications while at the same time saving network bandwidth. In high throughput message topologies, it is common for microservices to become overburdened and in extreme cases cease to be micro at all.

Filtering for streams is very helpful in this type of application. Visit the Stream Filtering documentation for more information.

The Introduction of Message Containers

Message containers are now introduced in the Tanzu RabbitMQ for Kubernetes 3.13.3 release. This change is not obvious to users, it is an internal update in the way messages are handled internally. Why are they introduced? RabbitMQ was originally built as an AMQP 0-9-1 broker. However, over the years, support for AMQP 1.0, MQTT, STOMP, and streams was added, which has led to internal message format conversions since different protocols have mostly similar concepts, but differ in the details such as available data types.

Message containers use the AMQP 1.0 data format. Message containers modernize internal message representation with today’s multi-protocol assumptions and makes all the conversions between protocols explicit. Message containers offer greater flexibility for users looking to leverage protocols other than AMQP 0.9.1.

Previously all non AMQP 0.9.1 messages were handled via a translation layer which increased the processing overhead and had the potential to lose some metadata. With message containers, messages are wrapped and preserved throughout the routing of Tanzu RabbitMQ and only reconstructed back into their original format when consumed.

Metadata is preserved where possible, Obviously if consuming in a different protocol to that which published a message, a compromise in metadata mapped is needed. Integrating event driven architectures across disparate systems can be very complex especially if earlier versions of protocols (such as MQTTv3) are being used.

Message containers allow users to consume messages from earlier versions of protocols and integrate them into a more modern microservice architecture without having to rewrite consuming clients from the beginning.

To summarize, message containers have helped Tanzu RabbitMQ for Kubernetes become even more flexible and has the potential to adopt many more protocols in the future.

New Experimental Metadata Database: Khepri

This 3.13.3 release of Tanzu RabbitMQ for Kubernetes is an important milestone in the roll out plan for a new storage backend for RabbitMQ metadata: Khepri. It is designed to replace the current Mnesia metadata store in a future release.

This should significantly improve RabbitMQ’s tolerance to network partitions. After Khepri is in use, there is no partition-handling strategy configuration (pause_minority, autoheal, and so on). Just like quorum queues, Khepri is also based on the Raft protocol therefore the semantics of what to do when a partition occurs are well defined and not configurable.

In this 3.13.3 release users can try out Khepri but note that Mnesia is still the default metadata store until Khepri is implemented in a future Tanzu RabbitMQ for Kubernetes release.

Improvements to the Memory Footprint

The memory footprint for the robust quorum queue and conventional classic queues v2 is greatly improved in the VMware Tanzu RabbitMQ for Kubernetes 3.13.3 release. As a result of these improvements, the benefits include better resource efficiency, cost savings, enhanced performance, and greater stability overall.