Thingshub can use two different forms of NATS depending on the availability and the architecture.
Internal NATS (Thingshub brings it with each tenant)
External NATS (Need to be configured separately)
In order to use the internal nats, configure the following section in the tenant configuration file:
global: nats: is_cluster_wide: false nats: enabled: true
The thingshub will deploy a NATS message broker in a single pod (no High Availability capabilities), and configure the services to use the internally deployed NATS.
This form of using NATS is deprecated due to the Architectural constraints. We plan to remove this support completely in the future.
Thingshub can connect to the external NATS through basic authentication. In order to use the external nats, configure the following section in the tenant configuration file:
global: nats: is_cluster_wide: true nats_url: nats://nats-svc.thub.svc.cluster.local:4222 user: a password: a nats: enabled: false
With this configuration, the thingshub will not deploy the NATS by itself, and instead only connects to the externally deployed NATS.
This is the preferred way to use the NATS installation with the Thingshub.
As thingshub currently does not support NATS connection through TLS, it is advised to keep the NATS deployment in the same cluster as the rest of the tenants. Additionally, it is advised that no
NodePortservices are used for exposing NATS. Just using the
ClusterIPshould be fine as long as the NATS and tenants are in the same cluster.
It is advised to deploy the NATS in High Availability mode (at least 3 replicas).
It is advised that the NATS installation be monitored separately (the monitoring parameters are exposed at port 8222)