Adding Agents Inside your Connectware Installation

Setting up Agents inside Connectware

Connectware protocol-mapper agents are additional components of the Connectware that can be deployed and started individually. You can use agents for the following:

  • Inside your Connectware installation for specialization and load distribution

  • Outside your Connectware installation as edge deployments close to your shopfloor

Related Links

Adding Agents inside Your Connectware Installation

You can add additional agents to your Connectware installation via the Connectware Helm chart. The section to add agents is commented out by default.

  1. In the values.yaml file, search for #protocolMapperAgents within the global context and remove the #.

  2. Add the agents. The minimum configuration requires you to add the agent name.

Note: You cannot change the name of an agent after creating it.

  1. Add configurations to each agent. For example, define the storage size or the CPU and memory resources of each agent.

Example

In this example, two agents are added to the protocolMapperAgents section of the values.yaml file.

protocolMapperAgents:
    - name: welder-robots
    - name: bender-robots

Specifying the Storage Size for Agents (Optional)

Agents require a persistent volume to store their data. The default storage size value is 40 Mi (40 Mebibytes).

  • To specify the storage size for an agent, add the parameter storageSize and define the storage size. Specify the storage size as Kubernetes quantities.

You cannot change the storage size of an agent after creating it.

Example

protocolMapperAgents:
    - name: bender-robots
      storageSize: 1Gi

Related Links

Specifying a StorageClass for Agents (Optional)

Agents require a persistent volume to store their data. By default, the agents use the default storage class of the Kubernetes cluster. You can specify any Kubernetes StorageClass that offers the ReadWriteOnce access mode and is available in your Kubernetes cluster.

  • To specify a StorageClass for a persistent volume, add the parameter storageClassName and define a name. Note: You cannot change the name of the StorageClass after creating it.

Example

protocolMapperAgents:
    - name: bender-robots
      storageClassName: longhorn

Related Links

Specifying CPU and Memory Resources for Agents

You can use the Kubernetes resource requests and limits to specify CPU and memory resources for agents.

Depending on their role and workload, agents can consume varying amounts of CPU and memory resources. We recommend that you use the Kubernetes metrics-server to identify the resource requirements of each agent and adjust the configuration if necessary.

Important: Adjusting CPU and memory resources can impact the performance and availability of Connectware. When you customize the settings for CPU and memory resources, make sure that you monitor the performance and make adjustments if necessary.

  • In the values.yaml file, specify the CPU and memory limits and requests in the Helm value global.podResources.distributedProtocolMapper. Specify the limits and requests as Kubernetes quantities.

Example

protocolMapperAgents:
    - name: bender-robots
      resources:
          requests:
              cpu: 1000m
              memory: 1000Mi
          limits:
              cpu: 2000m
              memory: 2000Mi

Related Links

Specifying Additional Environment Variables for Agents

You can specify a YAML array of objects to add additional environment variables for agents.

In the values.yaml file, define a name and a value for the environment variable. Note: Kubernetes only accepts strings as environment variables.

Do not specify the following environment variables as they are already used by the Helm chart of Connectware:

  • CYBUS_AGENT_NAME

  • CYBUS_AGENT_MODE

  • CYBUS_MQTT_HOST

  • CYBUS_MQTT_PORT

  • CYBUS_MQTT_DATA_HOST

  • CYBUS_MQTT_DATA_PORT

  • CYBUS_MQTT_SCHEME

  • USE_MUTUAL_TLS

Example

protocolMapperAgents:
    - name: bender-robots
      env:
          - name: CYBUS_HOSTNAME_INGRESS
            value: connectware
          - name: SOME_OTHER_VARIABLE
            value: bar

Directly Targeting the MQTT Broker

Agents target the MQTT broker of Connectware through an Ingress proxy via the Kubernetes LoadBalancer Service. In your new Connectware installation, the LoadBalancer is named connectware. However, you can bypass the Ingress proxy. This allows you to reduce the number of services that move data, increase throughput or reduce load.

Note: Only target the MQTT broker directly if the necessity was identified.

  1. To directly target the MQTT broker, do one of the following in the values.yaml file:

  • If you are using a separate control-plane broker, set the Helm value mqttHost to control-plane-broker.

  • Otherwise, set the Helm value mqttHost and mqttDataHost to broker.

  1. Set the environment variable CYBUS_HOSTNAME_INGRESS to connectware.

Example

Directly target the MQTT broker:

protocolMapperAgents:
    - name: bender-robots
      mqttHost: broker
      mqttDataHost: broker
      env:
          - name: CYBUS_HOSTNAME_INGRESS
            value: connectware

Directly target the MQTT broker while using a separate control-plane broker:

protocolMapperAgents:
    - name: bender-robots
      mqttHost: control-plane-broker
      mqttDataHost: broker
      env:
          - name: CYBUS_HOSTNAME_INGRESS
            value: connectware

Defining Kubernetes Labels and Annotations for Agents

You can define sets of labels and annotations that are added to the pod and controller resources of your agents. The following Helm values are available:

Helm value
Applied to

labels

Controller (StatefulSet), Pod, Service, PersistentVolumeClaim

service.labels

Service

podLabels

Pod

annotations

Controller (StatefulSet)

podAnnotations

Pod

service.annotations

Service

Example

protocolMapperAgents:
    - name: bender-robots
      labels:
          tld.mycompany/robots: benders # label is common to all resources
      podLabels:
          pod: only # label is only on pods
      annotations:
          controller: only # annotation is only on StatefulSet controller
      podAnnotations:
          pod: only # annotation is only on pods
      service:
          labels:
              service: only # label is only on the service
          annotations:
              service: only # annotations is only on the service

Related Links

Last updated

Was this helpful?