Partager via

Problèmes connus : Opérations Azure IoT

  • Article

Cet article liste les problèmes connus d’Opérations Azure IoT.

Problèmes de déploiement et de désinstallation

  • Si vous préférez qu’aucune mise à jour ne soit faite dans votre cluster sans votre consentement explicite, vous devez désactiver les mises à jour Arc quand vous activez le cluster. Cela est dû au fait que certaines extensions système sont mises à jour automatiquement par l’agent Arc. Pour désactiver les mises à jour, incluez l’indicateur de --disable-auto-upgrade dans le cadre de la commande az connectedk8s connect.

  • Si votre déploiement échoue avec l’erreur "code":"LinkedAuthorizationFailed", cela signifie que vous n’avez pas d’autorisations Microsoft.Authorization/roleAssignments/write sur le groupe de ressources qui contient votre cluster.

  • La modification directe des ressources personnalisées SecretProviderClass et SecretSync dans votre cluster Kubernetes peut interrompre le flux de secrets dans Opérations Azure IoT. Pour les opérations liées aux secrets, utilisez l’interface utilisateur de l’expérience des opérations.

  • Pendant et après le déploiement d’Opérations Azure IoT, vous pouvez voir des avertissements de type Unable to retrieve some image pull secrets (regcred) dans les journaux et les événements Kubernetes. Ces avertissements sont attendus et n’affectent pas le déploiement et l’utilisation d’Opérations Azure IoT.

  • Si votre déploiement échoue avec le message Error occurred while creating custom resources needed by system extensions, vous avez rencontré une défaillance sporadique connue qui sera corrigée dans une prochaine version. Pour contourner ce problème, utilisez la commande az iot ops delete avec l’indicateur --include-deps pour supprimer Opérations Azure IoT de votre cluster. Une fois Opérations Azure IoT et ses dépendances supprimées de votre cluster, réessayez le déploiement.

Répartiteur MQTT

  • Les ressources d’Agent MQTT créées dans votre cluster avec Kubernetes ne sont pas visibles dans le portail Azure. Cela est normal, car la gestion des composants Opérations Azure IoT avec Kubernetes est en préversion, et la synchronisation des ressources de la périphérie vers le cloud n’est actuellement pas prise en charge.

  • Vous ne pouvez pas mettre à jour la ressource d’Agent après le déploiement initial. Vous ne pouvez pas apporter de modifications de configuration à la cardinalité, au profil de mémoire ni à la mémoire tampon de disque.

    Pour contourner ce problème, lors du déploiement d’Opérations Azure IoT avec la commande az iot ops init, vous pouvez inclure le paramètre --broker-config-file avec un fichier de configuration JSON pour l’Agent MQTT. Pour plus d’informations, consultez Configuration avancée de l’Agent MQTT et Configurer les paramètres principaux de l’Agent MQTT.

  • Si un Agent a un seul réplica de back-end (backendChain.redundancyFactor est défini sur 1) la mise à niveau d’Opérations Azure IoT peut échouer. Mettez à niveau Opérations Azure IoT seulement si l’Agent a plusieurs réplicas de back-end.

  • Même si les diagnostics de l’Agent MQTT produisent une télémétrie sur sa propre rubrique, il est possible que vous receviez quand même des messages de l’auto-test lorsque vous vous abonnez à la rubrique #.

  • Le déploiement peut échouer si les valeurs de cardinalité et de profil mémoire sont définies comme étant trop élevées pour le cluster. Pour résoudre ce problème, définissez le nombre de réplicas sur 1 et utilisez un profil de mémoire plus petit comme low.

  • Ne publiez pas de rubriques de sonde de diagnostic qui commencent par azedge/dmqtt/selftest et ne vous abonnez pas à ce type de rubriques. La publication de ces rubriques ou l’abonnement à ces rubriques peuvent affecter la sonde ou les vérifications d’auto-test, ce qui peut entraîner des résultats non valides. Les résultats non valides peuvent être listés dans les journaux, les métriques ou les tableaux de bord de la sonde de diagnostic. Par exemple, vous pouvez voir le problème La vérification du chemin a échoué pour l’événement de sonde avec le type d’opération « Publier » dans les journaux de la sonde de diagnostic.

Gestion de réseau en couches Azure IoT (préversion)

  • Si le service Gestion de réseau en couches n’obtient pas d’adresse IP lors de l’exécution de K3S sur un hôte Ubuntu, réinstallez K3S sans contrôleur d’entrée traefik en utilisant l’option --disable=traefik.

    curl -sfL https://get.k3s.io | sh -s - --disable=traefik --write-kubeconfig-mode 644

    Pour plus d’informations, consultez Mise en réseau | K3.

  • Si les requêtes DNS ne sont pas résolues en l’adresse IP attendue lors de l’utilisation du service CoreDNS exécuté au niveau du réseau enfant, effectuez une mise à niveau vers Ubuntu 22.04 et réinstallez K3S.

Connecteur OPC UA

  • Les définitions de ressources de Registre de Dispositifs Azure vous permettent d’utiliser des nombres dans la section des attributs alors que le superviseur OPC attend seulement des chaînes.

  • Quand vous ajoutez une nouvelle ressource avec un nouveau profil de point de terminaison de ressources au répartiteur OPC UA et que vous déclenchez une reconfiguration, le déploiement des pods opc.tcp change pour prendre en charge les nouveaux montages de secrets pour le nom d’utilisateur et le mot de passe. Si le nouveau montage échoue pour une raison quelconque, le pod ne redémarre pas et l’ancien flux pour les ressources correctement configurées s’arrête donc aussi.

  • Le nom d’objet et l’URI de l’application doivent correspondre exactement au certificat fourni. Comme il n’y a pas de validation croisée, toutes les erreurs peuvent entraîner le rejet du certificat d’application par les serveurs OPC UA.

  • Si vous fournissez un nouveau certificat d’instance d’application OPC UA non valide après l’installation d’Opérations Azure IoT, vous pouvez obtenir des erreurs de connexion. Pour résoudre le problème, supprimez vos instances Opérations Azure IoT et redémarrez l’installation.

Simulateur OPC PLC

Si vous créez un point de terminaison de ressource pour le simulateur OPC PLC, mais que le simulateur OPC PLC n’envoie pas de données à l’Agent MQTT, exécutez la commande suivante afin de définir autoAcceptUntrustedServerCertificates=true pour le point de terminaison de ressource :

ENDPOINT_NAME=<name-of-you-endpoint-here>
kubectl patch AssetEndpointProfile $ENDPOINT_NAME \
-n azure-iot-operations \
--type=merge \
-p '{"spec":{"additionalConfiguration":"{\"applicationName\":\"'"$ENDPOINT_NAME"'\",\"security\":{\"autoAcceptUntrustedServerCertificates\":true}}"}}'

Attention

N’utilisez pas cette configuration dans des environnements de production ou de préproduction. En exposant votre cluster à Internet sans authentification appropriée, vous risquez de provoquer des accès non autorisés, voire de subir des attaques DDOS.

Vous pouvez patcher tous vos points de terminaison de ressource avec la commande suivante :

ENDPOINTS=$(kubectl get AssetEndpointProfile -n azure-iot-operations --no-headers -o custom-columns=":metadata.name")
for ENDPOINT_NAME in `echo "$ENDPOINTS"`; do \
kubectl patch AssetEndpointProfile $ENDPOINT_NAME \
   -n azure-iot-operations \
   --type=merge \
   -p '{"spec":{"additionalConfiguration":"{\"applicationName\":\"'"$ENDPOINT_NAME"'\",\"security\":{\"autoAcceptUntrustedServerCertificates\":true}}"}}'; \
done

Si le simulateur OPC PLC n’envoie pas de données à l’Agent MQTT une fois que vous avez créé une ressource, redémarrez le pod du simulateur OPC PLC. Le nom de pod ressemble à ceci : aio-opc-opc.tcp-1-f95d76c54-w9v9c. Pour redémarrer le pod, utilisez l’outil k9s pour le tuer ou exécutez la commande suivante :

kubectl delete pod aio-opc-opc.tcp-1-f95d76c54-w9v9c -n azure-iot-operations

Dataflows

  • Les ressources personnalisées de flux de données créées dans votre cluster ne sont pas visibles dans l’interface utilisateur de l’expérience des opérations. Cela est normal, car la gestion des composants Opérations Azure IoT avec Kubernetes est en préversion, et la synchronisation des ressources de la périphérie vers le cloud n’est actuellement pas prise en charge.

  • L’authentification X.509 pour les points de terminaison Kafka personnalisés n’est pas encore prise en charge.

  • La désérialisation et la validation des messages avec un schéma n’est pas encore prise en charge. La spécification d’un schéma dans la configuration source permet uniquement au portail d’expérience des opérations d’afficher la liste des points de données, mais les points de données ne sont pas validés par rapport au schéma.

  • La création d’un secret X.509 dans le portail d’expérience des opérations génère un secret avec des données mal encodées. Pour contourner ce problème, créez des secrets multilignes dans Azure Key Vault, puis sélectionnez-les dans la liste des secrets dans le portail d’expérience des opérations.

  • Quand vous connectez plusieurs instances Opérations IoT au même espace de noms MQTT Event Grid, des échecs de connexion peuvent se produire en raison de conflits d’ID client. Les ID client sont actuellement dérivés des noms de ressources de flux de données et, quand vous utilisez des modèles d’infrastructure en tant que code (IaC) pour le déploiement, les ID client générés peuvent être identiques. En guise de solution de contournement temporaire, ajoutez une caractéristique aléatoire aux noms de flux de données dans vos modèles de déploiement.