Patch RabbitMQ operator manifests using kustomize

I am experimenting with rabbitmq-operator & message-topology-operator in my homelab, and quickly ran into a problem – both of these operators are trying to create the same namespace, which kustomize doesn’t like. This entry outlines a lazy hack to remove these attempts without doing it manually, using kustomize.

Table of Contents

As always with Kubernetes¹, there are a few components involved:

• ArgoCD, which will deploy the manifests,
• An ArgoCD Application, which will describe where ArgoCD can find the manifests to deploy,
• A number of kustomize manifests,
• A simple JSON6902 patch per operator to remove the namespace creation manifests

Kustomize

My end goal was to use the YAML manifests released by the project, but make them work in my cluster. In the end, the kustomize app looked like this:

.
├── cluster-operator
│   └── kustomization.yaml
├── clusters
│   └── kustomization.yaml
├── kustomization.yaml
├── messaging-topology-operator
│   └── kustomization.yaml
└── namespace.yaml

4 directories, 5 files

The main kustomization file (in the root folder) looks like this:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - namespace.yaml
  - cluster-operator
  - messaging-topology-operator
  - clusters

We create the namespace first, then include the rest of the manifests after it.

The namespace creation:

apiVersion: v1
kind: Namespace
metadata:
  name: rabbitmq-system

cluster-operator bits

The cluster-operator kustomization looks like this:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - https://github.com/rabbitmq/cluster-operator/releases/download/v2.22.0/cluster-operator-quay-io.yml

patches:
  - target:
      kind: Namespace
      name: rabbitmq-system
    patch: |-
      $patch: delete
      apiVersion: v1
      kind: Namespace
      metadata:
        name: rabbitmq-system

We download the released manifest, and apply the patch to remove the namespace. We will use this operator to spin up new RabbitMQ clusters later on.

messaging-topology-operator bits

The same goes for messaging-topology-operator:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - https://github.com/rabbitmq/messaging-topology-operator/releases/download/v1.19.3/messaging-topology-operator-quay-io.yaml

patches:
  - target:
      kind: Namespace
      name: rabbitmq-system
    patch: |-
      $patch: delete
      apiVersion: v1
      kind: Namespace
      metadata:
        name: rabbitmq-system

This operator can be used to create queues, exchanges, and routing in RabbitMQ. It can even handle this on non-managed clusters, which is neat even though I think I prefer the terraform provider for that?

Spinning up RabbitMQ clusters

There is a folder called clusters which contains…RabbitMQ cluster definitions:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - hello-world.yaml

…and hello-world.yaml looks something like this:

apiVersion: rabbitmq.com/v1beta1
kind: RabbitmqCluster
metadata:
  name: hello-world
spec:
  replicas: 1

Wait a minute or two, and now you have a single replica RabbitMQ cluster running! After operating a traditional RabbitMQ cluster for a few years, this is quite impressive, especially considering that the operator can manage life cycle more or less automatically for you…

ArgoCD application

To deploy the above, I also have a simple ArgoCD application:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: rabbitmq-operator
spec:
  project: default
  source:
    # Update URL obviously
    repoURL: ssh://git@git.example.com/secret-org/homelab-repo.git
    targetRevision: trunk
    path: rabbitmq-operator # Path to the files outlined above
  destination:
    server: https://kubernetes.default.svc
    namespace: rabbitmq-system
  syncPolicy:
    automated:
      prune: true
      selfHeal: true

Bonus kustomize hack – using a pull-through cache

You can use kustomize to update image names and tags, which I typically use with renovatebot to keep my containers updated. But we can also use it to change where we pull these images from – like from a local Harbor instance, setup as a pull-through cache.

# ...
images:
  - name: quay.io/rabbitmqoperator/messaging-topology-operator
    newName: harbor.example.com/quayio/rabbitmqoperator/messaging-topology-operator

Just add something like the above to the relevant kustomization.yaml file. You can also use newTag to override which tag to use.

Conclusion

That’s a lot of YAML to write, but not a lot of YAML to spin up, upgrade, and manage a RabbitMQ cluster!