Skip to content

HiveMQ Platform Operator for Kubernetes 2.1.0 is now available!

by HiveMQ Team

The HiveMQ Team is excited to announce HiveMQ Platform Operator for Kubernetes 2.1.0. This release adds helpful new configuration and monitoring options to the HiveMQ Charts, enhances operability of the HiveMQ Platform Operator, and includes several performance enhancements and bug fixes.

Highlights

  • Added configuration options in the HiveMQ Helm charts
  • Expanded Monitoring Capabilities in the HiveMQ Platform Operator

Flexible New Helm Chart Configuration Options

New option to disable Helm tests

The HiveMQ Platform Helm chart now lets you control test resource generation using the testing.enabled configuration option. By default, Helm tests are enabled and create test pods that verify MQTT connectivity after an installation or upgrade.

The helm test command is frequently used in CI/CD pipelines (such as ArgoCD, Flux, etc.). For deployments where MQTT listeners require authentication or client certificates, these connectivity tests can fail, potentially causing the deployment to fail. If you cannot modify your CI/CD pipeline configuration, you can now disable the connectivity check in the HiveMQ Platform Helm chart:

    testing:
  enabled: false
  

When Helm tests are disabled, running helm test does not execute any tests, and no test pod resources are created in the cluster.

Added support to configure start-mandatory for extensions

The HiveMQ Platform Helm chart can now configure the start-mandatory setting in the extension.xml of extensions. This setting determines how the HiveMQ broker behaves if the startup of an extension fails.

For example, the HiveMQ Enterprise Extension for PostgreSQL can be configured as a mandatory component:

    extensions:
  - name: hivemq-postgresql-extension
    enabled: true
    startMandatory: true
  

Check our documentation for more details.

Added the ability to monitor external ConfigMaps and Secrets for changes to trigger a rolling restart

The HiveMQ Platform Operator can now automatically monitor Kubernetes ConfigMaps and Secrets for changes and trigger rolling restarts when updates are detected. This new HiveMQ Platform Helm Chart option removes the need for manual intervention when configuration changes require a broker restart.

Now, you can configure the operator to monitor entire resources:

    monitoredResources:
  - name: hivemq-custom-config
    type: ConfigMap
  

Or monitor specific files within a resource for fine-grained control:

    monitoredResources:
  - name: hivemq-custom-config
    type: Secret
    files:
      - custom-settings.xml
      - custom-credentials.xml
  

When a monitored file changes, the HiveMQ Platform pods automatically perform a rolling restart to apply the new configuration.

New HiveMQ Platform Operator Features

Added support for declared shared subscriptions to trigger a rolling restart

Previously, the HiveMQ Platform Operator only monitored changes to the config.xml file in the broker configuration ConfigMap or Secret. Starting with the 2.1.0 release, the operator can also monitor the optional declared-shared-subscriptions.xml file. Any changes to the content of these files now automatically trigger a rolling restart of the HiveMQ Platform pods.

To avoid overwhelming your Kubernetes cluster when you update your operator, the new monitoring feature does not take effect until the next rolling restart. If needed, see this example of how to trigger a rolling restart manually.

Additional Features and Improvements

HiveMQ Platform Operator Helm Charts

  • Added configuration options for HiveMQ Pulse.
  • Added support for numerical CPU requests and limits configuration, such as nodes.resources.cpu: 2.
  • Fixed an issue with the MQTT service connection test when a custom service name is configured.

HiveMQ Platform Operator for Kubernetes

  • Improved the operator health endpoints to provide detailed information about failed components.
  • Fixed an issue to ensure that rolling restarts do not proceed when the cluster topology is unstable, such as after a split cluster is merged.
  • Fixed an issue that could cause infinite rolling restarts in GKE Autopilot deployments.

Get Started Today

To get started with the new HiveMQ Platform Operator, see our HiveMQ Platform Operator Quick Start Guide.

To update from a previous version of the HiveMQ Platform Operator for Kubernetes, you need to update your HiveMQ Platform custom resource definition (CRD). For step-by-step instructions, see our Upgrade Guide.

To learn more about our operator, see HiveMQ Platform Operator for Kubernetes.

HiveMQ Team

The HiveMQ team loves writing about MQTT, Sparkplug, Unified Namespace (UNS), Industrial IoT protocols, IoT Data Streaming, how to deploy our platform, and more. We focus on industries ranging from energy, to transportation and logistics, to automotive manufacturing. Our experts are here to help, contact us with any questions.

HiveMQ logo
Review HiveMQ on G2