Známé problémy: Operace Azure IoT

Článek
12/14/2024

Tento článek obsahuje seznam známých problémů s operacemi Azure IoT.

Problémy s nasazením a odinstalací

Pokud dáváte přednost tomu, aby se v clusteru neprojevily žádné aktualizace bez výslovného souhlasu, měli byste při povolení clusteru zakázat aktualizace Arc. Důvodem je skutečnost, že agent Arc automaticky aktualizuje některá systémová rozšíření. Pokud chcete zakázat aktualizace, zahrňte příznak --disable-auto-upgrade jako součást az connectedk8s connect příkazu.
Pokud vaše nasazení selže s chybou "code":"LinkedAuthorizationFailed" , znamená to, že nemáte oprávnění Microsoft.Authorization/roleAssignments/write ve skupině prostředků, která obsahuje váš cluster.
Přímé úpravy vlastních prostředků SecretProviderClass a SecretSync v clusteru Kubernetes můžou narušit tok tajných kódů v operacích Azure IoT. Pro všechny operace související s tajnými kódy použijte uživatelské rozhraní provozního prostředí.
Během a po nasazení operací Azure IoT se můžou v protokolech a událostech Kubernetes zobrazovat upozornění Unable to retrieve some image pull secrets (regcred) . Tato upozornění jsou očekávaná a nemají vliv na nasazení a použití operací Azure IoT.
Pokud vaše nasazení selže se zprávou Error occurred while creating custom resources needed by system extensions, došlo ke známému občasné chybě, která bude opravena v budoucí verzi. Jako alternativní řešení použijte příkaz az iot ops delete s příznakem --include-deps k odstranění operací Azure IoT z vašeho clusteru. Když se operace Azure IoT a jeho závislosti odstraní z vašeho clusteru, zkuste nasazení zopakovat.

Zprostředkovatel MQTT

Prostředky zprostředkovatele MQTT vytvořené ve vašem clusteru pomocí Kubernetes nejsou viditelné na webu Azure Portal. Očekává se, že správa komponent operací Azure IoT pomocí Kubernetes je ve verzi Preview a synchronizace prostředků z hraničních zařízení do cloudu se v současné době nepodporuje.
Po počátečním nasazení nemůžete aktualizovat prostředek zprostředkovatele. Nemůžete provádět změny konfigurace kardinality, profilu paměti nebo vyrovnávací paměti.

Jako alternativní řešení můžete při nasazování operací Azure IoT pomocí příkazu az iot ops init zahrnout --broker-config-file parametr s konfiguračním souborem JSON pro zprostředkovatele MQTT. Další informace najdete v tématu Pokročilá konfigurace zprostředkovatele MQTT a Konfigurace základního nastavení zprostředkovatele MQTT.
Pokud má zprostředkovatel pouze jednu back-endovou repliku (backendChain.redundancyFactor je nastavená na 1), může selhat upgrade operací Azure IoT. Upgradujte pouze operace Azure IoT, pokud má zprostředkovatel více než jednu back-endovou repliku.
I když diagnostika zprostředkovatele MQTT vytváří telemetrii podle vlastního tématu, můžete při přihlášení k # odběru tématu stále dostávat zprávy z vlastního testu.
Nasazení může selhat, pokud jsou hodnoty kardinality a profilu paměti nastavené tak, aby byly pro cluster příliš velké. Pokud chcete tento problém vyřešit, nastavte počet replik na 1 menší profil paměti, například low.
Nepublikujte ani se přihlaste k odběru témat diagnostických testů, která začínají azedge/dmqtt/selftest. Publikování nebo přihlášení k odběru těchto témat může mít vliv na testy nebo kontroly samoobslužného testu, což vede k neplatným výsledkům. Neplatné výsledky můžou být uvedené v protokolech diagnostických testů, metrikách nebo řídicích panelech. Například u události sondy s typem operace Publish v protokolech diagnostiky se může zobrazit neúspěšné ověření cesty k problému.

Azure IoT Layered Network Management (Preview)

Pokud služba Správa vrstvené sítě při spouštění K3S na hostiteli Ubuntu nezíská IP adresu, přeinstalujte K3S bez kontroleru příchozího přenosu dat traefik pomocí této --disable=traefik možnosti.
```
curl -sfL https://get.k3s.io | sh -s - --disable=traefik --write-kubeconfig-mode 644
```
Další informace naleznete v tématu Sítě | K3s.
Pokud se dotazy DNS nepřeloží na očekávanou IP adresu při používání služby CoreDNS spuštěné na úrovni podřízené sítě, upgradujte na Ubuntu 22.04 a znovu nainstalujte K3S.

Konektor pro OPC UA

Definice prostředků služby Azure Device Registry umožňují použít čísla v části atributu, zatímco správce OPC očekává pouze řetězce.
Když přidáte nový prostředek s novým profilem koncového bodu prostředku do zprostředkovatele OPC UA a aktivujete rekonfiguraci, nasazení opc.tcp podů se změní tak, aby vyhovovalo novým tajným klíčům pro uživatelské jméno a heslo. Pokud se nové připojení z nějakého důvodu nezdaří, pod se nerestartuje, a proto se zastaví i starý tok pro správně nakonfigurované prostředky.
Název subjektu a identifikátor URI aplikace musí přesně odpovídat zadanému certifikátu. Vzhledem k tomu, že neexistuje křížové ověření, mohly by jakékoli chyby způsobit, že servery OPC UA odmítnou certifikát aplikace.
Poskytnutí nového neplatného certifikátu instance aplikace OPC UA po úspěšné instalaci AIO může vést k chybám připojení. Pokud chcete tento problém vyřešit, odstraňte instance operací Azure IoT a restartujte instalaci.

Simulátor OPC PLC

Pokud vytvoříte koncový bod prostředku pro simulátor OPC PLC, ale simulátor OPC PLC neodesílá data do zprostředkovatele MQTT, spusťte následující příkaz, který nastaví autoAcceptUntrustedServerCertificates=true koncový bod prostředku:

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

Upozornění

Tuto konfiguraci nepoužívejte v produkčním ani předprodukčním prostředí. Zveřejnění clusteru na internet bez správného ověřování může vést k neoprávněnému přístupu a dokonce útokům DDOS.

Všechny koncové body prostředku můžete opravit pomocí následujícího příkazu:

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

Pokud simulátor OPC PLC po vytvoření nového prostředku neodesílá data do zprostředkovatele MQTT, restartujte pod simulátorU OPC PLC. Název podu vypadá nějak aio-opc-opc.tcp-1-f95d76c54-w9v9ctakto. Pokud chcete pod restartovat, ukončete ho pomocí k9s nástroje nebo spusťte následující příkaz:

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

Datové toky

Vlastní prostředky toku dat vytvořené v clusteru se nezobrazují v uživatelském rozhraní provozního prostředí. Očekává se, že správa komponent operací Azure IoT pomocí Kubernetes je ve verzi Preview a synchronizace prostředků z hraničních zařízení do cloudu se v současné době nepodporuje.
Ověřování X.509 pro vlastní koncové body Kafka se zatím nepodporuje.
Deserializace a ověřování zpráv pomocí schématu se zatím nepodporuje. Zadání schématu ve zdrojové konfiguraci umožňuje portálu provozního prostředí zobrazit pouze seznam datových bodů, ale datové body nejsou ověřeny vůči schématu.

Vytvoření tajného kódu X.509 na portálu provozního prostředí vede k tajnému kódu s nesprávně zakódovanými daty. Pokud chcete tento problém obejít, vytvořte víceřádkové tajné kódy prostřednictvím služby Azure Key Vault a pak ho vyberte ze seznamu tajných kódů na portálu provozního prostředí.
Při připojování více instancí operací IoT ke stejnému oboru názvů Event Grid MQTT může dojít k selhání připojení kvůli konfliktům ID klienta. ID klientů se v současné době odvozují z názvů prostředků toku dat a při použití vzorů infrastruktury jako kódu (IaC) pro nasazení můžou být vygenerovaná ID klientů identická. Jako dočasné alternativní řešení přidejte do názvů toků dat v šablonách nasazení náhodnost.

Sdílet prostřednictvím