Passer au contenu principal

Prérequis

Cluster Kubernetes​

Distributions Kubernetes et fournisseurs de services​

ThingPark Enterprise peut être déployé sur n'importe quel cluster Kubernetes fournissant les prérequis suivants. Des procédures et du matériel validés sont fournis dans cette documentation pour déployer sur les environnements d'hébergement suivants :

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

Pour déployer ThingPark Enterprise dans tout autre environnement d'hébergement, la procédure de déploiement doit être adaptée aux spécificités de l'environnement, par exemple pour fournir les exigences de stockage.

Versions supportées​

  • ThingPark Enterprise 8.0.1

    • 1,29
    • 1,30
    • 1,31

  • ThingPark Enterprise 8.0.2

    • 1,30
    • 1.32
    • 1.33

Autorisations​

Le déploiement de ThingPark Enterprise nécessite deux profils de Compte Kubernetes :

  • Un compte d'administrateur de cluster avec rôle cluster-admin permettant de déployer les ressources suivantes à l'échelle du cluster :
    • Classes de stockage,
    • Classes de priorité,
    • Classe d'accès,
    • Définitions de ressources personnalisées,
    • Roles de cluster/Liaisons de roles de cluster requis par les contrôleurs tiers
  • Un compte d'opérateur d'application pour gérer les ressources ThingPark Enterprise. Il doit avoir les permissions suivantes sur le namespace de déploiement :
    • Permissions ClusterRole admin,
    • Tous les verbes sur les ressources sous kafka.strimzi.io et psmdb.percona.com

Classe de Priorité​

Le déploiement de ThingPark nécessite 3 Classes de Priorité pour définir les décisions de planification de la charge de travail. Les Chartes Helm sont préréglées avec les noms de Classes de Priorité suivants :

  • thingpark-datapath: la classe de priorité correspondante doit être réglée avec la plus haute priorité
  • thingpark-data: la classe de priorité correspondante doit être réglée avec une priorité intermédiaire par rapport aux deux autres
  • thingpark-others: la classe de priorité correspondante doit être réglée avec une priorité inférieure
Info

Un manifeste est fourni pour créer des ressources PriorityClass avec des paramètres par défaut. La prochaine procédure d'installation vous permettra de choisir entre l'utilisation de celle-ci ou la configuration de votre propre PriorityClass.

Contrôleur d'entrée​

Si un contrôleur d'ingress-nginx fonctionne déjà sur le cluster Kubernetes, il doit ignorer les ressources d'Ingress définies avec la IngressClass ingress-tpe. De plus, sa Configuration Admission WebHook doit ignorer les ressources Ingress déployées sous l'espace de noms de déploiement ThingPark.

Stockage​

Le déploiement de ThingPark utilise une provisionnement dynamique pour satisfaire ses besoins de stockage. La StorageClass fournissant le stockage attendu sera créée à l'étape Ressources à l'échelle du cluster, soit en utilisant des manifests d'exemple, soit en créant les vôtres selon les lignes directrices de taille

Exigences réseau​

Exigences entre zones de Disponibilité​

Bien qu'il soit fortement recommandé de déployer dans trois emplacements géographiques différents pour réduire le risque d'accidents (incendies) ou de catastrophes naturelles, les exigences suivantes doivent être respectées entre les différents nœuds du cluster à haute disponibilité :

  • La latence doit être inférieure à 10 millisecondes.
  • La bande passante entre serveurs doit être d'au moins 1 Gbps.

Flux​

Pour effectuer la procédure d'installation de ThingPark Enterprise, assurez-vous que les flux suivants sont autorisés.

Flux entrants vers le cluster Kubernetes​

Ces ports sont exposés via le Load Balancer provisionné par le service de contrôleur d'entrée.

Des Passerelles​
  • Primaire et secondaire network server
    • Protocole : IEC-104+TLS
    • Port(s) : TCP/3001, TCP/3101
  • Mise à niveau du logiciel (téléchargement), mise à niveau de la RF region (téléchargement), Balayage radio (téléversement)
    • Protocole : SSH(SFTP)+TLS
    • Port(s) : TCP/3002
  • Contrôle à distance (SSH inversé)
    • Protocole : SSH v2 (sécurisé)
    • Port(s) : TCP/2022
astuce

Les passerelles doivent être autorisées à se connecter à un serveur DNS et un serveur NTP. Ces services ne sont pas fournis par l'instance ThingPark Enterprise.

De ThingPark Enterprise utilisateurs​
  • Interface graphique HTTPS+TLS v1.2 (sécurisé) (administration TPE) et API (DX et BSS/OSS)
    • Protocole : HTTPS+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443
  • Lien DL applicatif (Application générique)
    • Protocole : HTTPS+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443
Des serveurs d'applications​
  • Lien DL applicatif (Application générique)
    • Protocole : HTTPS+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443

Flux sortants du cluster Kubernetes​

Aux serveurs d'applications​

Les flux suivants doivent être ouverts en fonction du type de serveurs d'applications que vous prévoyez d'utiliser.

  • Application Générique / HTTP / Ginjer / Microsoft Teams
    • Protocole : HTTPS+TLS v1.2 (sécurisé)
    • Port(s) : Définir par la configuration du Connecteur
  • Amazon Web Services IoT
    • Protocole : MQTT+TLS v1.2 (sécurisé) MQTT+WS+TLS v1.2 (sécurisé)
    • Port(s) : TCP/8883, TCP/9883
  • Azure IoT Hub / Azure Event Hubs
    • Protocole : MQTT+TLS v1.2 (sécurisé) HTTP+TLS v1.2 (sécurisé) AMQP sécurisé
    • Port(s) : TCP/8883, TCP/443, TCP/5671
  • IBM Watson IoT
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : TCP/8883
  • MQTT / ThingsBoard
    • Protocole : MQTT+TLS v1.2 (sécurisé) MQTT+WS+TLS v1.2 (sécurisé) MQTT
    • Port(s) : TCP/8883, TCP/443, TCP/5671
  • ThingWorx
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : Définir par la configuration du Connecteur
  • HERE Technologies
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443
  • Cumulocity
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443
  • SAP
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443
  • Yandex
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : TCP/8883
  • GreenGrass
    • Protocole : MQTT+TLS v1.2 (sécurisé)
    • Port(s) : Définir par la configuration du Connecteur
  • AMQP
    • Protocole : AMQP
    • Port(s) : Définir par la configuration du Connecteur
Vers des services externes​
  • Dépôts Actility (catalogues, images BS, documentations...)
    • Fqdn(s) : repository.thingpark.com
    • Protocole : HTTPS+TLS v1.2 (sécurisé)
    • Port(s) : TCP/443
  • SMTP server to handle transactional email: user invitation, password lost, alarm notifications (optional)
    • Protocole : SMTP
    • Port(s) : TCP/25, TCP/587, TCP/465
  • Alarm notifications (optional)
    • Protocole : SNMP v2
    • Port(s) : UDP/162
  • Serveur d'identité OpenID Connect pour déléguer l'authentification (optionnel)
    • Protocole : HTTPS
    • Port(s) : TCP/443

Machine de déploiement​

Le déploiement de ThingPark Enterprise est géré sur une machine distante. Cette machine doit avoir accès à l'API Kubernetes du cluster ciblé, soit directement, soit éventuellement par un bastion.

Les exigences supplémentaires suivantes doivent être remplies sur la machine de déploiement :

Flux sortants​

Les dépôts suivants doivent être accessibles depuis la machine de déploiement :

  • https://repository.thingpark.com/ : dépôt de chartes Helm Actility
  • https://github.com/ : dépôt d'échantillons de customisation
  • https://raw.githubusercontent.com : dépôt de configuration

Stockage de sauvegarde​

Selon votre fournisseur d'hébergement, les exigences de sauvegarde sont :

  • Pour Amazon

    • Un Bucket S3 pour stocker les sauvegardes à la demande, de mise à niveau et planifiées. Les sauvegardes de mise à niveau sont obligatoires.
    • Pour permettre le tirage/pousse de sauvegardes vers le bucket, soit :
      • Un Utilisateur IAM autorisé à effectuer des opérations get/put sur le bucket avec un ID de clé d'accès/idée d'accès secret
      • Groupe de nœuds EKS configuré pour utiliser un rôle IAM avec une politique IAM attachée autorisée à effectuer des opérations get/put sur le bucket

  • Pour Azure

    • Un conteneur Azure Blob avec une politique de gestion du cycle de vie optionnelle pour gérer la rétention des sauvegardes
    • Un Principal de Service autorisé à pousser un Blob vers le Conteneur. Les informations suivantes sont requises pour la configuration de sauvegarde :
      • Un SubscriptionID
      • Un ClientId
      • Un Secret
      • Un TenantID

  • Pour d'autres options d'hébergement, un stockage compatible S3 est requis. Minio est le moyen recommandé de fournir l'API compatible S3

Fichiers requis pour l'installation​

Optionnellement, vous pouvez déployer votre propre certificat HTTPS lors de l'installation. Dans ce cas, assurez-vous que les fichiers suivants sont prêts à être utilisés avant l'installation :

  • Le fichier de certificat serveur (fichier .cert)
  • Le fichier de clé de certificat (fichier .key)
Dernière mise à jour sur
Copyright © 2025 Actility
Sur cette page