RabbitMQ Cluster Operator on Kubernetes with Kapitan

The RabbitMQ Cluster Operator 2.23.1 with its webhooks, RBAC and CRD, rendered by the kadet-hub kubernetes generator 1.9.0 and certmanager generator 1.0.2 from the project’s release manifest.

• Source: release manifest rabbitmq/cluster-operator@v2.23.1 (cluster-operator.yml), sha256:ae35a547751656bc64bb734026249a845d226d96aba5a73783e05c5ec3444687
• Proof level: deploys, compared with the manifest by the kadet-hub/recipes CI
• Prerequisites, installed once per cluster before the recipe: cert-manager
• Generators: kubernetes 1.9.0 sha256:987694d4d8b061a6937fb5b8acd17416a16ed3fea36786a7604e6d607c210e24, certmanager 1.0.2 sha256:ba7632e9e06a593fbe20e9fa6774139203d7df65992adff9db94779606888ad9

What it deploys

• recipes.rabbitmq-cluster-operator (init.yml)
• recipes.rabbitmq-cluster-operator.operator (operator.yml): rabbitmq-cluster-operator

Required parameters

No parameter has to be set.

Include

A target includes the recipe and its options as classes and can override anything the recipe sets:

classes:
  - recipes.rabbitmq-cluster-operator
parameters:
  namespace: rabbitmq-system
  kapitan:
    vars:
      target: rabbitmq-cluster-operator

Fetching it

Until this recipe is published as an OCI artifact, a separate fetch inventory pins kadet-hub/recipes by commit. This is fetch/targets/recipes.yml at the commit the page was built from:

parameters:
  kapitan:
    vars:
      target: recipes
    dependencies:
      - type: git
        source: https://github.com/kadet-hub/recipes.git
        ref: 21d393a220614c2e353c431ae0c3bff4b8485c90
        subdir: rabbitmq-cluster-operator
        output_path: inventory/classes/recipes/rabbitmq-cluster-operator

The first command fetches the recipe into inventory/classes/recipes/rabbitmq-cluster-operator, the second the generators and compiles:

kapitan compile --inventory-path fetch --fetch --output-path .
kapitan compile --fetch

The first command exits with status 1 because the fetch target compiles nothing. Kapitan's --fetch checks neither the digest nor the attestation of a generator. Using a recipe describes how to verify them and how to raise the pin.

Settings

The webhook Service cluster-operator-webhook-service has one port without a name, as in the manifest. The recipe writes it with an empty key, which the API stores as no name. The Certificate metrics-certs keeps the manifest’s DNS names SERVICE_NAME.SERVICE_NAMESPACE.svc, placeholders its Kustomize base does not replace. No pod mounts its Secret.

Renamed RBAC objects

The kubernetes generator names a role and its binding after the entry. The roles keep the manifest’s names.

Proof

check rabbitmq-cluster-operator --level deploys with tests/target.yml, on kind kindest/node:v1.37.0, with cert-manager installed first. The objects outside RBAC differ only in these classes:

• Selector scheme: the Deployment and both Services select on name, the manifest on app.kubernetes.io/name and, in the Services, app.kubernetes.io/component.
• Explicit default: the pod and the ServiceAccount set automountServiceAccountToken: true, and both Certificates privateKey.rotationPolicy: Always.
• Derived name: the container is named after the component, where the manifest names it operator.

The ServiceAccount and users bound to view, edit and admin have the same permissions. tests/smoke creates a RabbitmqCluster in the namespace rabbitmq-smoke. The webhooks admit it with the CA that cert-manager injected, the mutating webhook sets its image, and its replica becomes ready.

The recipe's files are in kadet-hub/recipes. All recipes