Configuring Core Services

Enabling mutual Transport Layer Security (mTLS)

As an alternative to password-based authentication you can use mutual TLS (mTLS) as the authentication for Connectware. mTLS is an X.509 certificate-based authentication and provides better performance compared to password-based authentication. We recommend using mTLS when handling a large number of agents.

When mTLS is activated, password authentication is no longer possible when using encrypted connections to the Connectware broker (Port TCP/8883 by default).

1. To activate mTLS authentication, set the Helm value authentication.mTLS.enabled within the global context to true.

authentication:
  mTLS:
    enabled: true

1. Apply the configuration changes via the helm upgrade. For more information, see Applying Helm configuration changes.

Configuring podAntiAffinity to spread workloads

Kubernetes podAntiAffinity is used to ensure replicas of the same workload are not running on the same Kubernetes node to ensure redundancy. All Connectware workloads that support scaling use soft podAntiAffinity by default. The following behaviors can be configured:

Mode	Behavior of Pods of the same workload (for example: broker)
soft	(default) Pods will be spread over different Kubernetes cluster nodes, but may be on the same node
hard	Pods will be spread over different Kubernetes cluster nodes, or will fail to be scheduled
none	No podAntiAffinity scheduling requirements will be used

Additionally you can define a topology key, which is a label all Kubernetes nodes need to have for podAntiAffinity to work correctly. By default the label kubernetes.io/hostname is used.

To change the podAntiAffinity behavior you can use the Helm values podAntiAffinity and podAntiAffinityTopologyKey in the services Helm value block. For this example we will use the broker workload:

broker:
  podAntiAffinity: <strong>hard</strong>
  podAntiAffinityTopologyKey: <strong>kubernetes.io/os=linux</strong>

Apply the configuration changes via the helm upgrade. For more information, see Applying Helm configuration changes.

Configure storage volume size for the MQTT broker

Prerequisites

• Helm version 3 is installed on your system.

• The Kubernetes command line tool kubectl is configured and has access to the target installation.

• You know the name and namespace of your Connectware installation. See Obtaining the name, namespace, and version of your Connectware installation.

• The values.yaml file is available.

Procedure

Please note that the size of existing volumes can’t be changed through this procedure.

Please use Resizing Broker Volumes in Kubernetes to resize existing volumes, and return to this procedure for the final step of that guide.

The Connectware MQTT broker uses two volumes, the size of each can be configured through Helm configuration values:

VOLUME	PURPOSE	HELM VALUE
data	Stored retained messages, offline queues and cluster metadata	global.broker.storage.data.size
log	Stores logfiles	global.broker.storage.log.size

These values can be filled by a Kubernetes quantity specifying the volume size, for example 5Gi to use a volume of 5 GiB size.

Example

global:
  broker:
    storage:
      data:
        size: 5Gi
      log:
        size: 500Mi

Apply the configuration changes via the helm upgrade. For more information, see Applying Helm configuration changes.