How to Configure Pod Node-Affinity for HiveMQ Platform (new) on Kubernetes

When deploying the HiveMQ Platform on a Kubernetes cluster, there are scenarios where you may want to ensure all pods are scheduled on a specific node group, such as nodegroup1. This can be useful for resource isolation, cost management, or ensuring a specific node group is optimized for the workload. In Kubernetes, this can be achieved by configuring node affinity rules, guiding the Kubernetes scheduler to place pods on the designated nodes.

This article explains how to configure pod node affinity for the HiveMQ Platform to ensure all pods are deployed on nodegroup1.

 Instructions

Below is an example of a pod nodeAffinity rule that you can add to your HiveMQ Platform's Kubernetes deployment configuration (a.k.a. values.yaml):

# Configures how the HiveMQ platform pods should be scheduled on the Kubernetes worker nodes. podScheduling: affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: "kubernetes.io/nodegroup" operator: In values: - nodepool1 podAntiAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchExpressions: - key: hivemq-platform operator: In values: - broker topologyKey: "kubernetes.io/hostname"

Explanation of the Configuration

  • podScheduling: Encapsulates the scheduling rules for HiveMQ Platform pods.

  • affinity: This section contains both affinity and anti-affinity rules. The specific configuration here is a node affinity rule.

  • nodeAffinity: Ensures that pods are scheduled only on nodes that meet specific criteria. In this case, it confines pods to nodes in nodegroup1.

  • requiredDuringSchedulingIgnoredDuringExecution: Specifies that Kubernetes must follow this rule when scheduling pods. If the rule cannot be met, the pods will not be scheduled.

  • matchExpressions: This is where you define the condition. In this case, the rule applies to nodes with the label kubernetes.io/nodegroup=nodegroup1.

Benefits of Pod Node Affinity

  • Targeted Resource Utilization: By placing pods on specific nodes, you can ensure the optimal use of nodegroup resources.

  • Cost Management: If nodegroup1 consists of nodes with cost-efficient configurations, placing pods there can reduce infrastructure costs.

  • Resource Isolation: Ensures that critical workloads like HiveMQ are scheduled on nodes optimized for their performance needs.

Applying the Configuration

  1. Locate HiveMQ Platform Helm Chart’s values.yaml: Open the YAML file where your HiveMQ Platform deployment is configured.

  2. Insert the Node Affinity Rule: Add the provided node affinity configuration under the podScheduling section of your deployment YAML.

  3. Deploy Changes: Apply the changes using the updated values.yaml and the following command:

    helm upgrade broker --install hivemq/hivemq-platform --values values.yaml

    Here, “broker” is the release name of an example HiveMQ Platform. If you use a different name for the HiveMQ Platform release in your environment, update the command accordingly.

  4. Verify Deployment: Confirm that the pods are being scheduled on the correct nodes:

    kubectl get pods -o wide

    Check the NODE column to verify that all HiveMQ Platform pods are scheduled on nodes from nodegroup1.

Conclusion

Configuring pod node affinity for the HiveMQ Platform provides a straightforward method to ensure that all pods are scheduled on specific nodes like nodegroup1. This approach allows for better resource management, cost optimization, and resource isolation.

 

For further assistance, please contact HiveMQ Support.

 Related articles