Administrator guide

An administrator controls what users can deploy with RabbitClass objects. A RabbitClass is a cluster-wide object: every Rabbit object references a class, and the module checks the object against the class before it deploys RabbitMQ or applies a change.

Default class

When the module is enabled, it creates a RabbitClass named default. A Rabbit object uses this class if its spec.rabbitClassName parameter is not set.

The default class has the following settings:

The class cannot be changed. If it is deleted, the module creates it again with the same settings at its next start or update. To set other rules, create your own class.

Creating a class

The following manifest describes a class with two sizing policies, validation rules and placement of pods on dedicated nodes:

apiVersion: managed-services.deckhouse.io/v1alpha1
kind: RabbitClass
metadata:
  name: production
spec:
  sizingPolicies:
    - cores:
        min: 1
        max: 3
      memory:
        min: 512Mi
        max: 4Gi
        step: 256Mi
      coreFractions:
        - "25%"
        - "50%"
        - "100%"
    - cores:
        min: 4
        max: 16
      memory:
        min: 4Gi
        max: 16Gi
        step: 1Gi
      coreFractions:
        - "50%"
        - "100%"
  validations:
    - message: "At least 1Gi of memory is required"
      rule: "instance.memory.size >= 1073741824"
  overridableConfiguration:
    - maxMessageSize
  configuration:
    channelMax: 128
    sessionMaxPerConnection: 64
    linkMaxPerSession: 256
  nodeSelector:
    node.deckhouse.io/group: rabbit
  tolerations:
    - key: dedicated
      operator: Equal
      value: rabbit
      effect: NoSchedule

The parameters are described in the following sections and in the RabbitClass reference.

Sizing policies

Sizing policies in the sizingPolicies parameter define the allowed CPU and memory of instances. The module checks a Rabbit object against a policy as follows:

1. The module selects the first policy in the list whose cores range contains the requested number of cores. The range bounds are included.
2. The requested memory must be within the memory range of the selected policy and be a multiple of its step.
3. The requested coreFraction must be one of the coreFractions values of the selected policy.

If the ranges of several policies overlap, the policy that comes first in the list is used. A Rabbit object whose number of cores is outside all ranges is rejected.

Validation rules

Validation rules in the validations parameter are CEL expressions. A Rabbit object is rejected if a rule returns false; the user sees the message of the rule.

The following variables are available in the rules:

For example, the following rule allows at most 4 cores:

spec:
  validations:
    - message: "No more than 4 cores are allowed"
      rule: "instance.cpu.cores <= 4"

Settings available to users

The overridableConfiguration parameter lists the RabbitMQ settings that users can set in the spec.configuration section of a Rabbit object. The only available value is maxMessageSize.

A Rabbit object that sets a setting not listed in overridableConfiguration is rejected.

RabbitMQ settings of the class

The configuration parameter sets RabbitMQ settings for all instances of the class. The module writes them to the RabbitMQ configuration as follows:

If a parameter is not set, the RabbitMQ default value applies.

The module also sets the following RabbitMQ settings for every instance from its spec.instance.memory.size value, because RabbitMQ in a container cannot detect the memory limit of the pod:

• total_memory_available_override_value: equal to the memory size;
• vm_memory_high_watermark.absolute: 60% of the memory size. When RabbitMQ reaches this threshold, it blocks publishers.

Pod placement

The nodeSelector, nodeAffinity and tolerations parameters are copied to the RabbitMQ pods of the class. They follow the same rules as the fields of the Kubernetes pod specification.

For example, the following class places the pods on nodes of the rabbit NodeGroup with node affinity:

spec:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
        - matchExpressions:
            - key: node.deckhouse.io/group
              operator: In
              values:
                - rabbit

If no node satisfies these rules, the Rabbit objects of the class get the ScaledToLastValidConfiguration condition with the ScaleError reason.

Changing a class

A RabbitClass cannot be changed after it is created. An attempt to change it fails with the error RabbitClass is immutable. Create new one if you need to change configuration.

To change the rules for existing instances, follow these steps:

1. Create a class with the new rules.
2. In each Rabbit object, set the name of the new class in the spec.rabbitClassName parameter. The module checks the object against the new class and applies the class settings.
3. Delete the old class when no Rabbit object references it.

The module does not prevent deleting a class that Rabbit objects reference. Such instances keep running, but the module does not apply changes to them until a class with the same name exists again.

Access control

The module adds permissions for the access levels of the user-authz module:

Module components

The module components run in the d8-managed-rabbit namespace:

• Deployment managed-rabbit-operator deploys RabbitMQ and updates the status of Rabbit objects;
• Deployment managed-rabbit-webhook checks Rabbit objects against their classes when they are created or changed.

To see the operator logs, run the following command:

d8 k -n d8-managed-rabbit logs deploy/managed-rabbit-operator