Problèmes connus : Opérations Azure IoT (préversion)
Important
Opérations Azure IoT (préversion) – activé parc Azure Arc est actuellement en PRÉVERSION. Vous ne devez pas utiliser ce logiciel en préversion dans des environnements de production.
Pour connaître les conditions juridiques qui s’appliquent aux fonctionnalités Azure en version bêta, en préversion ou plus généralement non encore en disponibilité générale, consultez l’Avenant aux conditions d’utilisation des préversions de Microsoft Azure.
Cet article liste les problèmes connus relatifs aux Opérations Azure IoT (préversion).
Problèmes de déploiement et de désinstallation
Vous devez utiliser la connexion interactive Azure CLI
az login
lorsque vous déployez Opérations Azure IoT. Si non, vous pouvez obtenir une erreur telle que ERREUR : AADSTS530003 : votre appareil doit être géré afin d’accéder à cette ressource.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.Pour résoudre ce problème, demandez les autorisations requises ou ajustez les étapes de votre déploiement comme suit :
- Si vous effectuez un déploiement avec un modèle Azure Resource Manager, définissez le paramètre
deployResourceSyncRules
surfalse
. - Si vous effectuez un déploiement avec Azure CLI, incluez l’indicateur
--disable-rsync-rules
avec la commande az iot ops init.
- Si vous effectuez un déploiement avec un modèle Azure Resource Manager, définissez le paramètre
Désinstallation de K3S : lorsque vous désinstallez de K3S sur Ubuntu en utilisant le script
/usr/local/bin/k3s-uninstall.sh
, vous pouvez rencontrer un problème dans lequel le script reste bloqué sur le démontage du pod NFS. Une solution de contournement pour ce problème consiste à exécuter la commande suivante avant d’exécuter le script de désinstallation :sudo systemctl stop k3s
.
Azure IoT MQ (préversion)
Vous ne pouvez accéder au déploiement par défaut qu’à l’aide du protocole Internet du cluster, du protocole TLS et d’un jeton de compte de service. Les clients en dehors du cluster ont besoin d’une configuration supplémentaire pour pouvoir se connecter.
Vous ne pouvez pas mettre à jour la ressource personnalisée broker 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.
Vous ne pouvez pas configurer la taille d’une mémoire tampon sauvegardée sur disque, sauf si votre classe de stockage choisie prend en charge cette option.
Même si le service de diagnostic de MQ IoT produit une télémétrie sur sa propre rubrique, il est possible que vous receviez des messages du self-service lorsque vous vous abonnez à la rubrique
#
.Certains clusters ayant des appels d’API Kubernetes lents peuvent entraîner des échecs de test Ping selftest :
Status {Failed}. Probe failed: Ping: 1/2
de la commandeaz iot ops check
en cours d’exécution.Vous pouvez rencontrer une erreur dans les journaux des événements KafkaConnector telle que
Invalid value: "mq-to-eventhub-connector-<token>--connectionstring": must be no more than 63 characters
. Vérifiez que votre nom KafkaConnector comporte 5 caractères maximum.Vous pouvez rencontrer des erreurs de délai d’expiration dans le connecteur Kafka et des journaux de connecteur Event Grid. Malgré cela, le connecteur continue de fonctionner et de transférer des messages.
Gestion du 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 trafeik 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.
Azure IoT OPC UA Broker (préversion)
Tous les
AssetEndpointProfiles
dans le cluster doivent être configurés avec le même certificat d’authentification de transport, sinon il est possible qu’OPC UA Broker montre un comportement aléatoire. Pour éviter ce problème lors de l’utilisation de l’authentification par transport, configurez tous les points de terminaison des ressources avec la même empreinte pour le certificat d’authentification par transport dans le portail Opérations Azure IoT (préversion).Si vous déployez un
AssetEndpointProfile
dans le cluster et qu’OPC UA Broker ne peut pas se connecter au point de terminaison configuré pendant la première tentative, OPC UA Broker ne réessaie jamais de se connecter.Pour contourner ce problème, commencez par corriger le problème de connexion. Ensuite, redémarrez tous les pods du cluster dont les noms commencent par « aio-opc-opc.tcp », ou supprimez
AssetEndpointProfile
et redéployez-le.
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 à IoT MQ Broker, exécutez la commande suivante pour 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 au répartiteur IoT MQ après votre création d’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
Processeur de données Azure IoT – Préversion
Si vous constatez des erreurs de déploiement avec des pods de processeur de données, assurez-vous que lorsque vous avez créé votre Azure Key Vault, vous avez choisi la stratégie d’accès Vault comme Modèle d’autorisation.
Si l’extension du processeur de données échoue à se désinstaller, exécutez les commandes suivantes, puis réessayez l’opération de désinstallation :
kubectl delete pod aio-dp-reader-worker-0 --grace-period=0 --force -n azure-iot-operations kubectl delete pod aio-dp-runner-worker-0 --grace-period=0 --force -n azure-iot-operations
Si les modifications que vous apportez à un pipeline ne sont pas appliquées aux messages, exécutez les commandes suivantes pour propager ces modifications :
kubectl rollout restart deployment aio-dp-operator -n azure-iot-operations kubectl rollout restart statefulset aio-dp-runner-worker -n azure-iot-operations kubectl rollout restart statefulset aio-dp-reader-worker -n azure-iot-operations
Il est possible qu’une perte momentanée de la communication avec les pods du répartiteur IoT MQ puisse suspendre le traitement des pipelines de données. Vous pouvez également constater des erreurs telles que
service account token expired
. Si cela a lieu, exécutez les commandes suivantes :kubectl rollout restart statefulset aio-dp-runner-worker -n azure-iot-operations kubectl rollout restart statefulset aio-dp-reader-worker -n azure-iot-operations
Si les données sont endommagées dans la table Microsoft Fabric Lakehouse dans laquelle votre pipeline de processeur de données écrit, assurez-vous qu’aucun autre processus n’écrit dans la table. Si vous écrivez dans la table Microsoft Fabric Lakehouse à partir de plusieurs sources, des données endommagées peuvent être présentes dans la table.
Azure IoT Akri préversion
Un problème sporadique risque d’entraîner le redémarrage du pod aio-opc-asset-discovery
avec l’erreur suivante dans les journaux : opcua@311 exception="System.IO.IOException: Failed to bind to address http://unix:/var/lib/akri/opcua-asset.sock: address already in use.
.
Pour contourner ce problème, procédez comme suit pour mettre à jour la spécification DaemonSet :
Recherchez la ressource personnalisée cible fournie par
orchestration.iotoperations.azure.com
avec un nom qui se termine par-ops-init-target
:kubectl get targets -n azure-iot-operations
Modifiez la configuration cible et recherchez le paramètre
spec.components.aio-opc-asset-discovery.properties.resource.spec.template.spec.containers.env
. Par exemple :kubectl edit target solid-zebra-97r6jr7rw43vqv-ops-init-target -n azure-iot-operations
Ajoutez les variables d’environnement suivantes à la section configuration
spec.components.aio-opc-asset-discovery.properties.resource.spec.template.spec.containers.env
:- name: ASPNETCORE_URLS value: http://+8443 - name: POD_IP valueFrom: fieldRef: fieldPath: "status.podIP"
Enregistrez vos modifications. La spécification finale ressemble à l’exemple suivant :
apiVersion: orchestrator.iotoperations.azure.com/v1 kind: Target metadata: name: <cluster-name>-target namespace: azure-iot-operations spec: displayName: <cluster-name>-target scope: azure-iot-operations topologies: ... version: 1.0.0.0 components: ... - name: aio-opc-asset-discovery type: yaml.k8s properties: resource: apiVersion: apps/v1 kind: DaemonSet metadata: labels: app.kubernetes.io/part-of: aio name: aio-opc-asset-discovery spec: selector: matchLabels: name: aio-opc-asset-discovery template: metadata: labels: app.kubernetes.io/part-of: aio name: aio-opc-asset-discovery spec: containers: - env: - name: ASPNETCORE_URLS value: http://+8443 - name: POD_IP valueFrom: fieldRef: fieldPath: status.podIP - name: DISCOVERY_HANDLERS_DIRECTORY value: /var/lib/akri - name: AKRI_AGENT_REGISTRATION value: 'true' image: >- edgeappmodel.azurecr.io/opcuabroker/discovery-handler:0.4.0-preview.3 imagePullPolicy: Always name: aio-opc-asset-discovery ports: ... resources: ... volumeMounts: ... volumes: ...
Préversion du portail Opérations Azure IoT
Si vous souhaitez vous connecter au portail Opérations Azure IoT, vous devez avoir un Microsoft Entra ID avec au moins des autorisations de contributeur pour le groupe de ressources contenant votre instance Kubernetes – Azure Arc. Vous ne pouvez pas vous connecter avec un compte Microsoft (MSA). Pour créer un compte dans votre tenant Azure :
- Connectez-vous au Portail Azure avec le même tenant et nom d’utilisateur utilisé pour déployer Opérations Azure IoT.
- Dans le Portail Azure, accédez à la section Microsoft Entra ID, sélectionnez Utilisateurs > + Nouvel utilisateur > Créer un utilisateur. Créez un utilisateur et notez le mot de passe. Vous en aurez besoin plus tard pour vous connecter.
- Dans le Portail Azure, accédez au groupe de ressources qui contient votre instance Kubernetes – Azure Arc. Sur la page Contrôle d’accès (IAM), sélectionnez + Ajouter > Ajouter une attribution de rôle.
- Sur la page Ajouter une attribution de rôle, sélectionnez Rôles Administrateur privilégiés. Sélectionnez ensuite Contributeur, puis Suivant.
- Sur la page Membres, ajoutez votre nouvel utilisateur au rôle.
- Sélectionnez Passer en revue et attribuer pour terminer la configuration du nouvel utilisateur.
Vous pouvez maintenant utiliser le nouveau compte d’utilisateur pour vous connecter au portail Opérations Azure IoT.
Commentaires
https://aka.ms/ContentUserFeedback.
Prochainement : Tout au long de l'année 2024, nous supprimerons progressivement les GitHub Issues en tant que mécanisme de retour d'information pour le contenu et nous les remplacerons par un nouveau système de retour d'information. Pour plus d’informations, voir:Soumettre et afficher des commentaires pour