Menu

Archive for the ‘New Features’ Category

RabbitMQ Kubernetes Operator reaches 1.0

Tuesday, November 17th, 2020

We are pleased to announce that the RabbitMQ Operator for Kubernetes is now generally available. The RabbitMQ Operator makes it easy to provision and manage RabbitMQ clusters consistently on any certified Kubernetes distribution.  Operators inform the Kubernetes container orchestration system how to provision and control specific applications. The Kubernetes (hereafter K8s) Operator pattern is a way to extend the K8s API and state management to include the provisioning and management of custom resources -- resources not provided in a default K8s deployment. In this post, we’ll discuss how the Operator enables the K8s system to control a RabbitMQ cluster.

Where do I start?

If you are new to K8s, start with learning the basics of K8s and kubectl before attempting to use the operator.  You can also visit the Kube Academy for more in-depth primers. Watch this episode of TGIR to see how easy it is to deploy and monitor a RabbitMQ cluster with the operator. Next you can try the quick start guide. In a minute or two you will have the operator and your first instance of operator created rabbitMQ cluster.

Want to go further? Look at the operator yaml examples for quick deployment of advanced clusters. For the entire set of supported features, look at the documentation.

The Rabbit K8s Operator

It’s recommended that you first be familiar with the basics of K8s. If you need a refresher, VMware’s Kube Academy has a comprehensive set of resources.  The Rabbit MQ K8s operator is composed of 2 building blocks:
  • Custom resources: An extension to the native K8s resources in order to manage custom state of a particular stateful platform or application. In our case the custom resource  is reflecting the configuration size and state of a RabbitMQ cluster 
  • Custom controller: A k8s controller is a non-terminating loop that regulates the state of standard K8s resources, like ReplicaSet, StatefulSet, or Deployments. The custom controller is adding a non-terminating control loop with custom logic to regulate the state of the custom resource. In the case of RabbitMQ cluster, the controller can settle changes to cluster & node configurations.

What’s the value of a RabbitMQ Cluster Operator?

The RabbitMQ Cluster Operator (aka the operator) is a bridge between K8s managed states and RabbitMQ configuration and state.  The RabbitMQ Cluster Operator helps to simplify two types of tasks:
  • Provisioning of new clusters
  • Post-installation tasks, managed by K8s

Provisioning of a new RabbitMQ cluster

Creating a new RabbitMQ cluster on K8s manually is a multi step process, that the operator is automating:
  1. Creating the RabbitMQ configuration file as a ConfigMap, so that is can be mounted as a file by the RabbitMQ container
  2. Setting the K8s secrets required by RabbitMQ (TLS certificates, default user password etc)
  3. Creating a StatefulSet that will manage the cluster nodes (as pods)
  4. Creating a headless service(a service without a cluster IP) to manage rabbitMQ node discovery
  5. Creating a service for RabbitMQ clients to access the cluster
 

The operator is not the only way to automate this process, but it has the benefit of mapping all the RabbitMQ configurations into a k8s descriptor and a custom resource.  This means that there is a single source of truth regarding the cluster state, and users can manage their clusters configurations using Gitops

By using an operator to provision RabbitMQ clusters, the user enjoys several benefits:

  • A declarative API to create a RabbitMQ cluster with any setting with a single command. The operator is automating the provisioning of the complex set of K8s resources composing the cluster: such as services, pods, statefulset, persistent volumes etc 
  • The operator comes with a set of YAML examples so in most cases you have almost no effort in order to have a development or even a production grade cluster.
  • Once the cluster is created it has a K8s state and description you can observe to know if your RMQ cluster is ready. RabbitMQ comes with in-built support for Prometheus. Node and cluster metrics can be visualised with Grafana.
  • The operator goes further and displays status conditions for the RabbitMQ cluster. The possible status conditions are: 
    • ClusterAvailable - RabbitMQ accessible by client apps
    • AllReplicasReady - RabbitMQ cluster fully available
    • ReconcileSuccess - Custom Resource reconciled successfully. This being false may denote that the user needs to intervene (for example if TLS is enabled but the secret does not exist).
  • K8s controllers can now regulate the set of resources that compose the cluster: The rabbitMQ nodes, the routing service, the node registry service and the volumes. If any of these resources is not available according to K8s liveness probe, K8s will auto heal it
While the operator is useful for day 1 tasks, it confers even greater benefits when we talk about day 2 operations triggered by the user or by k8s.

Post Installation Tasks

Having a RabbitMQ cluster provisioned is just the beginning of the journey as any developer and operator knows. There are various lifecycle events to take care of:
  • Scaling the cluster when the application messaging volume increases as a result of additional functionality or demand growth
  • Self healing the cluster when a node is crashed or the network breaks
  • Rotating certificates
  • Upgrading the cluster with zero downtime when a new version of RabbitMQ is needed for security patching or new features
Many of the above processes require graceful termination of a node, some RabbitMQ API call after node start, or more complex flows that have a sequence of K8s lifecycle events and RabbitMQ cluster events.This is exactly where the value of the operator stands out. 
  • The Cluster Operator will allow RabbitMQ users to address all of these with a simple K8s CLI declarative command.
  • The operator will automate these complex flows using both K8s building block and custom controller logic that takes care of the RabbitMQ administrative tasks
The operator now supports the core of day 2 RabbitMQ operations such as:
  • Reconfigurations
  • Enabling / disabling of plugins
  • Self healing 
  • Scaling
  • In place upgrade
  • Certificate rotations - using rolling updates
In the future, the operator can be upgraded to provide new flows. For example, a new version of the operator may be released with a new major version of RabbitMQ. The use of the operator pattern means we can provide specific logic to, say, upgrade the existing RabbitMQ clusters to a new major version without losing messages and without downtime. The existence of a new operator version does not force users to upgrade existing clusters; K8s will still be able to manage these clusters going forward. 

It is only a K8s operator that can automate such complex and delicate processes in such an elegant way and without a risk. Here’s an example of how RabbitMQ will save users from pain and errors by automating the process of in-place upgrade. The diagram lists the manual steps a user need to perform in order to have a rolling upgrade of the cluster (without an operator)

Now watch as Gerhard covers more advanced topics in running RabbitMQ reliably on K8s.

But wait - there’s more

The operator comes with a kubectl plugin that provides many commands to make your life easier. As described here, you can install the kubectl plugin using krewSome handy commands are installing the cluster operator as well as creating, listing and deleting RabbitMQ clusters. Other commands targeting a specific RabbitMQ cluster include printing the default user secret, opening the RabbitMQ management UI, enabling debug logging on all RabbitMQ nodes, and running perf-test.

What’s next?

The Cluster Operator gives users a lot of power to create clusters and manage them. There is still a wider scope of functionality to support, depending on your requests and feedback.

Some examples are:

  • Examples of topologies using Istio for encryption /decryption of traffic between nodes as well as client with traffic
  • Scaling down gracefully
  • Monitoring the operator - the operator will report metrics in Prometheus format
  • Labelling cluster resources with RMQ and operator metadata
  • Testing on additional K8s providers (currently testing on Tanzu Kubernetes Grid and GKE)
In addition, we plan to add another operator that will wrap some of RabbitMQ's APIs with K8s declarative API, allowing for creation of users, queues and exchanges.

We welcome feedback, feature requests, bug reports and any questions you have regarding RabbitMQ:

 

RabbitMQ Gets an HA Upgrade

Monday, April 20th, 2020

This is the first part of a series on quorum queues, our new replicated queue type. We'll be covering everything from what quorum queues are, to hardware requirements, migration from mirrored queues and best practices.

Introducing Quorum Queues

Mirrored queues, also known as HA queues have been the de facto option for years when requiring extra data safety guarantees for your messages. Quorum queues are the next generation of replicated queue that aim to replace most use cases for mirrored queues and are available from the 3.8 release and onward.

In this blog series we’re going to cover the following:

(more…)

RabbitMQ 3.8 Release Overview

Monday, November 11th, 2019

RabbitMQ 3.8 has just been released and has some major new features which focus on reliability, operations, and observability.

You can find the new 3.8 release on the GitHub releases page which includes information about what is included in the release as well as various installation assets. See our upgrade guide for more information about upgrading to 3.8.0.

Our team dedicates this release to Joe Armstrong, the creator of Erlang. Joe’s work in the fields of concurrent and distributed systems benefits RabbitMQ to this day. Equally importantly, Joe was a rare example of a brilliant engineer who was also very humble and kind.

Let’s take a quick look at the new features in this release.

(more…)

Simplifying rolling upgrades between minor versions with feature flags

Tuesday, April 23rd, 2019

In this post we will cover feature flags, a new subsystem in RabbitMQ 3.8. Feature flags will allow a rolling cluster upgrade to the next minor version, without requiring all nodes to be stopped before upgrading.

Minor Version Upgrades Today: RabbitMQ 3.6.x to 3.7.x

It you had to upgrade a cluster from RabbitMQ 3.6.x to 3.7.x, you probably had to use one of the following solutions:

  • Deploy a new cluster alongside the existing one (this strategy is known as the blue-green deployment), then migrate data & clients to the new cluster
  • Stop all nodes in the existing cluster, upgrade the last node that was stopped first, then continue upgrading all other nodes, one-by-one

Blue-green deployment strategy is low risk but also fairly complex to automate. On the other hand, a cluster-wide shutdown affects availability. Feature flags are meant to provide a 3rd option by making rolling cluster upgrades possible and reasonably easy to automate.

(more…)

RabbitMQ Java Client Metrics with Micrometer and Datadog

Tuesday, April 10th, 2018

In this post we'll cover how the RabbitMQ Java client library gathers runtime metrics and sends them to monitoring systems like JMX and Datadog.

(more…)

New Configuration Format in RabbitMQ 3.7

Thursday, February 22nd, 2018

In this post we'll cover a new configuration format available in RabbitMQ 3.7.0.

(more…)

Peer Discovery Subsystem in RabbitMQ 3.7

Monday, February 12th, 2018

In this blog post we're going to take a closer look at a new subsystem introduced in RabbitMQ 3.7.0.

(more…)

What’s New in RabbitMQ 3.7

Monday, February 5th, 2018

After over 1 year in the works, RabbitMQ 3.7.0 has quietly shipped right before the start of the holiday season. The release was heavily inspired by the community feedback on 3.6.x. In this post we’d like to cover some of the highlights in this release.

(more…)

New Reactive Client for RabbitMQ HTTP API

Wednesday, October 18th, 2017

The RabbitMQ team is happy to announce the release of version 2.0 of HOP, RabbitMQ HTTP API client for Java and other JVM languages. This new release introduce a new reactive client based on Spring Framework 5.0 WebFlux.

(more…)

RabbitMQ Java Client 5.0 is Released

Friday, September 29th, 2017

The RabbitMQ team is happy to announce the release of version 5.0 of the RabbitMQ Java Client. This new release is now based on Java 8 and comes with a bunch of interesting new features.

(more…)