Skip to main content

Prerequisites

Kubernetes Cluster​

Kubernetes distributions and service providers​

ThingPark Enterprise can be deployed on any Kubernetes cluster providing the following prerequisites. Validated procedures and materials are provided in this documentation to deploy on the following hosting environments:

  • Azure Kubernetes Service (AKS)
  • Elastic Kubernetes Service (EKS) from Amazon Web Services

To deploy ThingPark Enterprise in any other hosting environment, the deployment procedure should be adapted to the specificity of the environment, for example to provide the storage requirements.

Supported releases​

  • ThingPark Enterprise 8.0.0
    • 1.26
    • 1.27
    • 1.28

Permissions​

ThingPark Enterprise deployment requires two profiles of Kubernetes Account:

  • A cluster administrator account with cluster-admin role allowing to deploy following cluster wide resources:
    • StorageClasses,
    • PriorityClasses,
    • IngressClass,
    • CustomResourcesDefinitions,
    • ClusterRoles/ClusterRoleBinding required by third parties controllers
  • An application operator account to manage Thingpark Enterprise resources. It must have the following permissions on the deployment namespace:
    • admin ClusterRole permissions,
    • All verbs on resources under kafka.strimzi.io and psmdb.percona.com

PriorityClass​

ThingPark deployment requires 3 PriorityClasses to set workload scheduling decisions. Helm Charts are preset with following PriorityClassNames:

  • thingpark-datapath: the corresponding priority class must be set with the highest priority
  • thingpark-data: the corresponding priority class must be set with an intermediate priority regarding the two others
  • thingpark-others: the corresponding priority class must be set with a lower priority
Info

A manifest is provided to create PriorityClass resources with default settings. The next install procedure will allow choose between using it or configuring your own PriorityClass.

Ingress controller​

If an ingress-nginx controller already runs on the Kubernetes cluster, it must ignore Ingress resources set with the ingress-tpe IngressClass. Also, its Admission WebHook Configuration must ignore Ingress resources deployed under the ThingPark deployment namespace.

Storage​

ThingPark deployment uses dynamic provisioning to fulfill its storage needs. StorageClass providing expected storage will be created at Cluster wide resources step, either by using example manifests or by creating your own following sizing guidelines

Network requirements​

Inter Availability zone requirements​

While it is strongly recommended to deploy in three different geographical locations to mitigate the risk of accidents (fires) or natural disasters, the following requirements must be ensured between the different nodes of the high availability cluster:

  • Latency must be less than 10 milliseconds.
  • Inter-server bandwidth must be at least 1 Gbps.

Flows​

To perform the ThingPark Enterprise installation procedure, please make sure that the following flows are authorized.

Inbound flows to the Kubernetes cluster​

These ports are exposed through the Load Balancer provisioned by the ingress controller service.

From Base stations​
  • Primary and secondary network server
    • Protocol: IEC-104+TLS
    • Port(s): TCP/3001, TCP/3101
  • Software upgrade (download), RF region upgrade (download), Radio Scan (upload)
    • Protocol: SSH(SFTP)+TLS
    • Port(s): TCP/3002
  • Remote control (Reverse SSH)
    • Protocol: SSH v2 (secure)
    • Port(s): TCP/2022
tip

Bases stations should be allowed to connect to a DNS and an NTP server. These services are not provided by the ThingPark Enterprise instance.

From ThingPark Enterprise users​
  • HTTPS+TLS v1.2 (secure) GUI (TPE administration) and APIs (DX and BSS/OSS)
    • Protocol: HTTPS+TLS v1.2 (secure)
    • Port(s): TCP/443
  • Applicative DL link (Generic Application)
    • Protocol: HTTPS+TLS v1.2 (secure)
    • Port(s): TCP/443
From application servers​
  • Applicative DL link (Generic Application)
    • Protocol: HTTPS+TLS v1.2 (secure)
    • Port(s): TCP/443

Outbound flows from the kubernetes cluster​

To application servers​

The following flows should be open depending on the type of application servers you plan to use.

  • Generic Application / HTTP / Ginjer / Microsoft Teams
    • Protocol: HTTPS+TLS v1.2 (secure)
    • Port(s): Define by Connector configuration
  • Amazon Web Services IoT
    • Protocol: MQTT+TLS v1.2 (secure) MQTT+WS+TLS v1.2 (secure)
    • Port(s): TCP/8883, TCP/9883
  • Azure IoT Hub / Azure Event Hubs
    • Protocol: MQTT+TLS v1.2 (secure) HTTP+TLS v1.2 (secure) Secure AMQP
    • Port(s): TCP/8883, TCP/443, TCP/5671
  • IBM Watson IoT
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): TCP/8883
  • MQTT / ThingsBoard
    • Protocol: MQTT+TLS v1.2 (secure) MQTT+WS+TLS v1.2 (secure) MQTT
    • Port(s): TCP/8883, TCP/443, TCP/5671
  • ThingWorx
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): Define by Connector configuration
  • HERE Technologies
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): TCP/443
  • Cumulocity
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): TCP/443
  • SAP
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): TCP/443
  • Yandex
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): TCP/8883
  • GreenGrass
    • Protocol: MQTT+TLS v1.2 (secure)
    • Port(s): Define by Connector configuration
  • AMQP
    • Protocol: AMQP
    • Port(s): Define by Connector configuration
To external services​
  • Actility repositories (catalogs, BS images, documentations…)
    • Fqdn(s): repository.thingpark.com
    • Protocol: HTTPS+TLS v1.2 (secure)
    • Port(s): TCP/443
  • SMTP server to handle transactional email: user invitation, password lost, alarm notifications (optional)
    • Protocol: SMTP
    • Port(s): TCP/25, TCP/587, TCP/465
  • Alarm notifications (optional)
    • Protocol: SNMP v2
    • Port(s): UDP/162
  • OpenID Connect Identity server to delegate authentication (optional)
    • Protocol: HTTPS
    • Port(s): TCP/443

Deployment machine​

ThingPark enterprise deployment is managed on a remote machine. This machine must have access to the Kubernetes API of the targeted cluster, either directly or eventually through a bastion host.

The following extra requirements must be fulfilled on the deployment machine:

Outbound flows​

The following repositories must be accessible from the deployment machine:

  • https://repository.thingpark.com/: Actility Helm Charts repository
  • https://github.com/: Customization samples repository
  • https://raw.githubusercontent.com: Configuration repository

Backup storage​

Depending on your hosting provider, backup requirements are:

  • For Amazon

    • A S3 bucket to store on-demand, upgrade and schedule backups. Upgrade backups are mandatory.
    • To allow backup pull/push to the bucket, either:
      • An IAM User authorized to perform get/put to the bucket with an Access key ID/Secret access key
      • EKS Node Group configured to use an IAM role with an attached IAM policy allowed to perform get/put to the bucket

  • For Azure

    • An Azure Blob Container with an optional lifecycle management policy to manage backup retention
    • A Service Principal allowed to push Blob to the Container. The following information is required for backup configuration:
      • A SubscriptionID
      • A ClientId
      • A Secret
      • A TenantID

  • For other hosting options, a S3 compatible storage is required. Minio is the recommended way to provide the S3-compatible API

Required files for installation​

Optionally, you can deploy your own HTTPS certificate during the installation. In this case, ensure that the following files are ready to be used prior to installation:

  • The server certificate file (.cert file)
  • The certificate key file (.key file)
Last updated on
Copyright © 2024 Actility
On this page