Delen via

Bekende problemen: Azure IoT-bewerkingen

  • Artikel

Dit artikel bevat de bekende problemen voor Azure IoT-bewerkingen.

Problemen met implementeren en verwijderen

  • Als u liever geen updates voor uw cluster hebt uitgevoerd zonder expliciete toestemming te geven, moet u Arc-updates uitschakelen wanneer u het cluster inschakelt. Dit komt doordat sommige systeemextensies automatisch worden bijgewerkt door de Arc-agent. Als u updates wilt uitschakelen, neemt u de --disable-auto-upgrade vlag op als onderdeel van de az connectedk8s connect opdracht.

  • Als uw implementatie mislukt met de "code":"LinkedAuthorizationFailed" fout, betekent dit dat u geen machtigingen voor Microsoft.Authorization/roleAssignments/write hebt voor de resourcegroep die uw cluster bevat.

  • Door aangepaste resources voor SecretProviderClass en SecretSync rechtstreeks te bewerken in uw Kubernetes-cluster, kan de geheimenstroom in Azure IoT Operations worden verbroken. Gebruik de gebruikersinterface voor bewerkingen met betrekking tot geheimen voor alle bewerkingen met betrekking tot geheimen.

  • Tijdens en na het implementeren van Azure IoT-bewerkingen ziet u mogelijk waarschuwingen in Unable to retrieve some image pull secrets (regcred) de logboeken en Kubernetes-gebeurtenissen. Deze waarschuwingen worden verwacht en hebben geen invloed op de implementatie en het gebruik van Azure IoT-bewerkingen.

  • Als uw implementatie mislukt met het bericht Error occurred while creating custom resources needed by system extensions, is er een bekende sporadische fout opgetreden die in een toekomstige release wordt opgelost. Gebruik als tijdelijke oplossing de opdracht az iot ops delete met de --include-deps vlag om Azure IoT Operations uit uw cluster te verwijderen. Wanneer Azure IoT-bewerkingen en de bijbehorende afhankelijkheden uit uw cluster worden verwijderd, voert u de implementatie opnieuw uit.

  • Als u Azure IoT Operations implementeert in GitHub Codespaces, veroorzaakt het afsluiten en opnieuw opstarten van de Codespace een This codespace is currently running in recovery mode due to a configuration error. probleem. Er is momenteel geen tijdelijke oplossing voor het probleem. Als u een cluster nodig hebt dat ondersteuning biedt voor afsluiten en opnieuw opstarten, kiest u een van de opties in Uw Kubernetes-cluster met Azure Arc voorbereiden.

MQTT-broker

  • MQTT Broker-resources die in uw cluster zijn gemaakt met kubernetes, zijn niet zichtbaar in Azure Portal. Dit wordt verwacht omdat het beheren van Azure IoT Operations-onderdelen met Kubernetes in preview is en het synchroniseren van resources van de rand naar de cloud momenteel niet wordt ondersteund.

  • U kunt de Broker-resource niet bijwerken na de eerste implementatie. U kunt geen configuratiewijzigingen aanbrengen in kardinaliteit, geheugenprofiel of schijfbuffer.

    Als tijdelijke oplossing kunt u bij het implementeren van Azure IoT Operations met de opdracht az iot ops init de --broker-config-file parameter opnemen met een JSON-configuratiebestand voor de MQTT-broker. Zie Advanced MQTT Broker config and Configure core MQTT broker settings(Core MQTT Broker) voor meer informatie.

  • Als een Broker slechts één back-endreplica heeft (backendChain.redundancyFactor is ingesteld op 1) kan het upgraden van Azure IoT-bewerkingen mislukken. Voer alleen een upgrade uit van Azure IoT-bewerkingen als de broker meer dan één back-endreplica heeft.

  • Hoewel de diagnostische gegevens van de MQTT-broker telemetrie over een eigen onderwerp produceren, krijgt u mogelijk nog steeds berichten van de zelftest wanneer u zich abonneert op # onderwerp.

  • Implementatie kan mislukken als de kardinaliteit en geheugenprofielwaarden zijn ingesteld op te groot voor het cluster. Als u dit probleem wilt oplossen, stelt u het aantal replica's in 1 op en gebruikt u een kleiner geheugenprofiel, zoals low.

  • Publiceer of abonneer u niet op diagnostische testonderwerpen die beginnen met azedge/dmqtt/selftest. Het publiceren of abonneren op deze onderwerpen kan van invloed zijn op de test- of zelftestcontroles die resulteren in ongeldige resultaten. Ongeldige resultaten kunnen worden vermeld in diagnostische testlogboeken, metrische gegevens of dashboards. U ziet bijvoorbeeld dat het probleem padverificatie is mislukt voor de testgebeurtenis met het bewerkingstype Publiceren in de logboeken voor diagnostische tests.

Gelaagd netwerkbeheer van Azure IoT (preview)

  • Als de gelaagde netwerkbeheerservice geen IP-adres krijgt tijdens het uitvoeren van K3S op Ubuntu-host, installeert u K3S opnieuw zonder toegangsbeheercontroller --disable=traefik via de optie.

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

    Zie Netwerken | voor meer informatie K3's.

  • Als DNS-query's niet worden omgezet in het verwachte IP-adres terwijl de CoreDNS-service wordt uitgevoerd op onderliggend netwerkniveau, voert u een upgrade uit naar Ubuntu 22.04 en installeert u K3S opnieuw.

Connector voor OPC UA

  • Met Azure Device Registry-assetdefinities kunt u getallen gebruiken in de kenmerksectie, terwijl opC-supervisor alleen tekenreeksen verwacht.

  • Wanneer u een nieuwe asset met een nieuw asseteindpuntprofiel toevoegt aan de OPC UA-broker en een herconfiguratie activeert, wordt de implementatie van de opc.tcp pods gewijzigd om de nieuwe geheime koppelingen voor gebruikersnaam en wachtwoord mogelijk te maken. Als de nieuwe koppeling om een of andere reden mislukt, wordt de pod niet opnieuw opgestart en wordt de oude stroom voor de correct geconfigureerde assets ook gestopt.

  • De onderwerpnaam en de toepassings-URI moeten exact overeenkomen met het opgegeven certificaat. Omdat er geen kruisvalidatie is, kunnen fouten ertoe leiden dat de OPC UA-servers het toepassingscertificaat weigeren.

  • Als u een nieuw ongeldig CERTIFICAAT voor een OPC UA-toepassingsexemplaren oplevert na een geslaagde installatie van AIO, kan dit leiden tot verbindingsfouten. U kunt het probleem oplossen door uw Azure IoT Operations-exemplaren te verwijderen en de installatie opnieuw te starten.

OPC PLC-simulator

Als u een asseteindpunt maakt voor de OPC PLC-simulator, maar de OPC PLC-simulator geen gegevens naar de MQTT-broker verzendt, voert u de volgende opdracht uit om in te stellen autoAcceptUntrustedServerCertificates=true voor het asseteindpunt:

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

Let op

Gebruik deze configuratie niet in productie- of preproductieomgevingen. Het blootstellen van uw cluster aan internet zonder de juiste verificatie kan leiden tot onbevoegde toegang en zelfs DDOS-aanvallen.

U kunt al uw asseteindpunten patchen met de volgende opdracht:

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

Als de OPC PLC-simulator geen gegevens naar de MQTT-broker verzendt nadat u een nieuwe asset hebt gemaakt, start u de OPC PLC-simulatorpod opnieuw. De podnaam ziet er als aio-opc-opc.tcp-1-f95d76c54-w9v9cvolgt uit. Als u de pod opnieuw wilt starten, gebruikt u het k9s hulpprogramma om de pod te beëindigen of voert u de volgende opdracht uit:

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

Gegevensstromen

  • Aangepaste resources voor gegevensstromen die in uw cluster zijn gemaakt, zijn niet zichtbaar in de gebruikersinterface van de bewerkingservaring. Dit wordt verwacht omdat het beheren van Azure IoT Operations-onderdelen met Kubernetes in preview is en het synchroniseren van resources van de rand naar de cloud momenteel niet wordt ondersteund.

  • X.509-verificatie voor aangepaste Kafka-eindpunten wordt nog niet ondersteund.

  • Het deserialiseren en valideren van berichten met behulp van een schema wordt nog niet ondersteund. Als u een schema in de bronconfiguratie opgeeft, kan de operations experience-portal alleen de lijst met gegevenspunten weergeven, maar worden de gegevenspunten niet gevalideerd op basis van het schema.

  • Het maken van een X.509-geheim in de operations experience-portal resulteert in een geheim met onjuist gecodeerde gegevens. Als u dit probleem wilt omzeilen, maakt u de geheimen met meerdere regels via Azure Key Vault en selecteert u deze in de lijst met geheimen in de operations experience-portal.

  • Wanneer u meerdere IoT Operations-exemplaren verbindt met dezelfde Event Grid MQTT-naamruimte, kunnen verbindingsfouten optreden vanwege conflicten met de client-id. Client-id's zijn momenteel afgeleid van resourcenamen voor gegevensstromen en wanneer u IaC-patronen (Infrastructure as Code) gebruikt voor implementatie, kunnen de gegenereerde client-id's identiek zijn. Als tijdelijke tijdelijke oplossing voegt u willekeurigheid toe aan de namen van de gegevensstromen in uw implementatiesjablonen.

  • Wanneer de netwerkverbinding wordt onderbroken, kunnen gegevensstromen fouten ondervinden bij het verzenden van berichten vanwege een niet-overeenkomende producer-id. Als u dit probleem ondervindt, start u de pods voor gegevensstromen opnieuw.