Condividi tramite

Problemi noti: Operazioni di Azure IoT

  • Articolo

Questo articolo elenca i problemi noti per le operazioni IoT di Azure.

Problemi di distribuzione e disinstallazione

  • Se si preferisce non avere aggiornamenti eseguiti nel cluster senza fornire il consenso esplicito, è consigliabile disabilitare gli aggiornamenti arc quando si abilita il cluster. Ciò è dovuto al fatto che alcune estensioni di sistema vengono aggiornate automaticamente dall'agente Arc. Per disabilitare gli aggiornamenti, includere il --disable-auto-upgrade flag come parte del az connectedk8s connect comando .

  • Se la distribuzione ha esito negativo con l'errore "code":"LinkedAuthorizationFailed", significa che non si hanno le autorizzazioni Microsoft.Authorization/roleAssignments/write per il gruppo di risorse che contiene il cluster.

  • La modifica diretta delle risorse personalizzate SecretProviderClass e SecretSync nel cluster Kubernetes può interrompere il flusso dei segreti nelle operazioni di Azure IoT. Per le operazioni correlate ai segreti, usare l'interfaccia utente dell'esperienza operativa.

  • Durante e dopo la distribuzione delle operazioni di Azure IoT, è possibile che vengano visualizzati avvisi relativi Unable to retrieve some image pull secrets (regcred) ai log e agli eventi Kubernetes. Questi avvisi sono previsti e non influiscono sulla distribuzione e sull'uso delle operazioni di Azure IoT.

  • Se la distribuzione non riesce con il messaggio Error occurred while creating custom resources needed by system extensions, si è verificato un errore sporadico noto che verrà risolto in una versione futura. Come soluzione alternativa, usare il comando az iot ops delete con il --include-deps flag per eliminare le operazioni IoT di Azure dal cluster. Quando le operazioni di Azure IoT e le relative dipendenze vengono eliminate dal cluster, ripetere la distribuzione.

  • Se si distribuiscono le operazioni di Azure IoT in GitHub Codespaces, l'arresto e il riavvio di Codespace causano un This codespace is currently running in recovery mode due to a configuration error. problema. Attualmente, non esiste alcuna soluzione alternativa per il problema. Se è necessario un cluster che supporti l'arresto e il riavvio, scegliere una delle opzioni disponibili in Preparare il cluster Kubernetes abilitato per Azure Arc.

Broker MQTT

  • A volte, l'utilizzo della memoria del broker MQTT può diventare inaspettatamente elevato a causa di tentativi di rotazione dei certificati interni. Questo comporta errori come "impossibile connettere l'attività di caricamento della traccia all'endpoint di servizio di diagnostica" nei log. Il problema dovrebbe essere risolto nell'aggiornamento della patch successivo. Nel frattempo, come soluzione alternativa, riavviare ogni pod broker uno alla sola (incluso il servizio di diagnostica, il probe e il servizio di autenticazione), assicurandosi che ogni back-end venga ripristinato prima di procedere. In alternativa, ridistribuire le operazioni IoT di Azure con una durata1500h del certificato interna superiore o più.

    {
  "advanced": {
    "internalCerts": {
      "duration": "1500h",
      "renewBefore": "1h",
      "privateKey": {
        "algorithm": "Ec256",
        "rotationPolicy": "Always"
      }
    }
  }
}

  • Le risorse broker MQTT create nel cluster con Kubernetes non sono visibili portale di Azure. Questo problema è previsto perché la gestione dei componenti delle operazioni IoT di Azure con Kubernetes è in anteprima e la sincronizzazione delle risorse dal dispositivo perimetrale al cloud non è attualmente supportata.

  • Non è possibile aggiornare la risorsa Broker dopo la distribuzione iniziale. Non è possibile apportare modifiche di configurazione alla cardinalità, al profilo di memoria o al buffer del disco.

    Come soluzione alternativa, quando si distribuisce Operazioni di Azure IoT con il comando az iot ops init, è possibile includere il parametro --broker-config-file con un file di configurazione JSON per il broker MQTT. Per altre informazioni, vedere Advanced MQTT broker config e Configurare le impostazioni principali del broker MQTT.

  • Se un broker ha una sola replica back-end (backendChain.redundancyFactor è impostata su 1) l'aggiornamento delle operazioni di Azure IoT potrebbe non riuscire. Aggiornare le operazioni di Azure IoT solo se Broker ha più repliche back-end.

  • Anche se la diagnostica del broker MQTT genera dati di telemetria nel proprio argomento, è comunque possibile ricevere messaggi dalla verifica automatica quando si sottoscrive l'argomento #.

  • La distribuzione potrebbe non riuscire se i valori di cardinalità e profilo di memoria impostati sono troppo elevati per il cluster. Per risolvere questo problema, impostare il numero di repliche su 1 e usare un profilo di memoria più basso, ad esempio low.

  • Non pubblicare o sottoscrivere argomenti del probe di diagnostica che iniziano con azedge/dmqtt/selftest. La pubblicazione o la sottoscrizione a questi argomenti potrebbero influire sui controlli di probe o di auto-test, generando risultati non validi. I risultati non validi potrebbero essere elencati nei log del probe di diagnostica, nelle metriche o nei dashboard. Ad esempio, è possibile che il problema Verifica percorso non sia riuscita per l'evento probe con il tipo di operazione "Pubblica" nei log diagnostics-probe.

Gestione della rete a più livelli di Azure IoT (anteprima)

  • Se il servizio Gestione rete a più livelli non ottiene un indirizzo IP durante l'esecuzione di K3S nell'host Ubuntu, reinstallare K3S senza traefik ingress controller usando l'opzione --disable=traefik .

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

    Per altre informazioni, vedere Networking | K3s.

  • Se le query DNS non vengono risolte nell'indirizzo IP previsto quando si usa il servizio CoreDNS in esecuzione a livello di rete figlio, eseguire l'aggiornamento a Ubuntu 22.04 e reinstallare K3S.

Connettore per OPC UA

  • Le definizioni di asset del Registro dispositivi di Azure consentono di usare i numeri nella sezione attributo, mentre il supervisore OPC prevede solo stringhe.

  • Quando si aggiunge un nuovo asset con un nuovo profilo endpoint asset al broker OPC UA e si attiva una riconfigurazione, la distribuzione dei opc.tcp pod cambia per contenere i nuovi montaggi segreti per nome utente e password. Se il nuovo montaggio non riesce per qualche motivo, il pod non viene riavviato e pertanto il flusso precedente per gli asset configurati correttamente si arresta.

  • Il nome soggetto e l'URI dell'applicazione devono corrispondere esattamente al certificato fornito. Poiché non è presente alcuna convalida incrociata, eventuali errori potrebbero causare il rifiuto del certificato dell'applicazione da parte dei server OPC UA.

  • Se si specifica un nuovo certificato di istanza dell'applicazione OPC UA non valido dopo un'installazione corretta di AIO, possono verificarsi errori di connessione. Per risolvere il problema, eliminare le istanze di Operazioni IoT di Azure e riavviare l'installazione.

Simulatore OPC PLC

Se si crea un endpoint di un asset per il simulatore OPC PLC, ma il simulatore OPC PLC non invia dati al broker MQTT, eseguire il comando seguente per impostare autoAcceptUntrustedServerCertificates=true per l'endpoint dell'asset:

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}}"}}'

Attenzione

Non usare questa configurazione negli ambienti di produzione o preproduzione. L'esposizione del cluster a Internet senza autenticazione appropriata potrebbe causare accessi non autorizzati e persino attacchi DDOS.

È possibile applicare patch a tutti gli endpoint dell'asset con il comando seguente:

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

Se il simulatore OPC PLC non invia dati al broker MQTT dopo aver creato un nuovo asset, riavviare il pod del simulatore OPC PLC. Il nome del pod è simile a aio-opc-opc.tcp-1-f95d76c54-w9v9c. Per riavviare il pod, usare lo strumento k9s per terminare il pod oppure eseguire il comando seguente:

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

Flussi di dati

  • Le risorse personalizzate del flusso di dati create nel cluster non sono visibili nell'interfaccia utente dell'esperienza operativa. Questo problema è previsto perché la gestione dei componenti delle operazioni IoT di Azure con Kubernetes è in anteprima e la sincronizzazione delle risorse dal dispositivo perimetrale al cloud non è attualmente supportata.

  • L'autenticazione X.509 per gli endpoint Kafka personalizzati non è ancora supportata.

  • La deserializzazione e la convalida dei messaggi con uno schema non sono ancora supportate. La specifica di uno schema nella configurazione di origine consente solo al portale dell'esperienza operativa di visualizzare l'elenco dei punti dati, ma i punti dati non vengono convalidati rispetto allo schema.

  • La creazione di un segreto X.509 nel portale dell'esperienza operativa comporta un segreto con dati codificati in modo non corretto. Per risolvere questo problema, creare i segreti su più righe tramite Azure Key Vault e quindi selezionarlo dall'elenco dei segreti nel portale dell'esperienza operativa.

  • Quando si connettono più istanze di operazioni IoT allo stesso spazio dei nomi MQTT di Griglia di eventi, possono verificarsi errori di connessione a causa di conflitti di ID client. Gli ID client sono attualmente derivati dai nomi delle risorse del flusso di dati e quando si usano modelli IaC (Infrastructure as Code) per la distribuzione, gli ID client generati possono essere identici. Come soluzione alternativa temporanea, aggiungere casualità ai nomi dei flussi di dati nei modelli di distribuzione.

  • Quando la connessione di rete viene interrotta, i flussi di dati possono riscontrare errori durante l'invio di messaggi a causa di un ID producer non corrispondente. Se si verifica questo problema, riavviare i pod del flusso di dati.

  • Quando si usano caratteri di controllo nelle intestazioni Kafka, è possibile che si verifichino disconnessioni. I caratteri di controllo nelle intestazioni Kafka, 0x01ad esempio , 0x020x03, 0x04 sono conformi a UTF-8, ma il broker MQTT operazioni IoT li rifiuta. Questo problema si verifica durante il processo del flusso di dati quando le intestazioni Kafka vengono convertite in proprietà MQTT usando un parser UTF-8. I pacchetti con caratteri di controllo potrebbero essere considerati non validi e rifiutati dal broker e causare errori del flusso di dati.