Compartilhar via

Problemas conhecidos: Operações do Azure IoT

  • Artigo

Este artigo lista os problemas conhecidos das Operações do Azure IoT.

Problemas de implantação e desinstalação

  • Se você preferir não ter atualizações feitas no cluster sem dar consentimento explícito, desabilite as atualizações do Arc ao habilitar o cluster. Isso ocorre devido ao fato de que algumas extensões do sistema são atualizadas automaticamente pelo agente do Arc. Para desabilitar atualizações, inclua o sinalizador --disable-auto-upgrade como parte do comando az connectedk8s connect.

  • Quando a implantação falha com o erro "code":"LinkedAuthorizationFailed", isso significa que você não tem as permissões Microsoft.Authorization/roleAssignments/write no grupo de recursos que contém o cluster.

  • A edição direta dos recursos personalizados SecretProviderClass e SecretSync no cluster do Kubernetes pode interromper o fluxo de segredos nas Operações do Azure IoT. Para operações relacionadas a segredos, use a interface do usuário da experiência de operações.

  • Durante e depois de implantar as Operações do Azure IoT, você poderá ver avisos sobre Unable to retrieve some image pull secrets (regcred) nos logs e os eventos do Kubernetes. Esses avisos são esperados e não afetam a implantação e o uso das Operações do Azure IoT.

  • Se a sua implantação falhar com a mensagem Error occurred while creating custom resources needed by system extensions, você encontrou uma falha esporádica conhecida que será corrigida em uma versão futura. Como uma solução alternativa, use o comando az iot ops delete com o sinalizador --include-deps para excluir as Operações do Azure IoT do cluster. Quando as Operações do Azure IoT e suas dependências forem excluídas do cluster, repita a implantação.

  • Se você implantar as Operações do Azure IoT no GitHub Codespaces, desligar e reiniciar o Codespace causará um problema This codespace is currently running in recovery mode due to a configuration error.. Atualmente, não há solução alternativa para o problema. Se você precisar de um cluster compatível com desligamento e a reinicialização, escolha uma das opções em Preparar o cluster do Kubernetes habilitado para Azure Arc.

Agente MQTT

  • Os recursos do Agente MQTT criados em seu cluster usando o Kubernetes não são visíveis no portal do Azure. Isso é esperado porque o gerenciamento dos componentes das Operações do Azure IoT usando o Kubernetes está em versão prévia e não há suporte para sincronizar recursos da borda para a nuvem no momento.

  • Não é possível atualizar o recurso personalizado do Agente MQTT após a implantação inicial. Não é possível fazer alterações de configuração na cardinalidade, no perfil de memória ou no buffer de disco.

    Como uma solução alternativa, ao implantar o Operações do Azure IoT com o comando az iot ops init você pode incluir o parâmetro --broker-config-file com um arquivo de configuração JSON para o Agente MQTT. Para obter mais informações, confira Configuração avançada do Agente MQTT e Configurar as principais configurações do Agente MQTT.

  • Se um Agente tiver apenas uma réplica de back-end (backendChain.redundancyFactor está definida como 1), a atualização das Operações do Azure IoT poderá falhar. Somente atualize as Operações do Azure IoT se o Agente tiver mais de uma réplica de back-end.

  • Embora os diagnósticos do Agente MQTT produzam telemetria em seu próprio tópico, você talvez continue recebendo mensagens do autoteste quando fizer uma assinatura do tópico #.

  • A implantação poderá falhar se os valores de cardinalidade e perfil de memória forem definidos como grandes demais para o cluster. Para resolver esse problema, defina o número de réplicas como 1 e use um perfil de memória menor, como low.

  • Não publique ou assine os tópicos de investigação de diagnóstico que começam com azedge/dmqtt/selftest. A publicação ou assinatura desses tópicos pode afetar as verificações de investigação e de autoteste, resultando em resultados inválidos. Os resultados inválidos podem ser listados em logs de investigação de diagnóstico, métricas ou painéis. Por exemplo, talvez você veja o problema Falha na verificação de caminho para o evento de investigação com o tipo de operação ‘Publicar’ nos logs de investigação de diagnóstico.

Gerenciamento de Rede em Camadas do Azure IoT (versão prévia)

  • Se o serviço Gerenciamento de Rede em Camadas não receber um endereço IP durante a execução do K3S no host do Ubuntu, reinstale o K3S sem controlador de entrada traefik usando a opção --disable=traefik.

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

    Para obter mais informações, consulte Rede | K3s.

  • Se as consultas DNS não resolverem para o endereço IP esperado ao usar o serviço CoreDNS em execução no nível da rede filho, atualize para o Ubuntu 22.04 e reinstale o K3S.

Conector para OPC UA

  • As definições de ativo do Registro de Dispositivo do Azure permitem que você use números na seção de atributo, enquanto o supervisor do OPC espera apenas cadeias de caracteres.

  • Quando você adiciona um novo ativo com um novo perfil de ponto de extremidade de ativo ao agente OPC UA e dispara uma reconfiguração, a implantação dos pods opc.tcp muda para acomodar as novas montagens secretas para nome de usuário e senha. Se a nova montagem falhar por algum motivo, o pod não será reiniciado e, portanto, o fluxo antigo dos ativos configurados corretamente também será interrompido.

  • O nome da entidade e o URI do aplicativo devem corresponder exatamente ao certificado fornecido. Como não há validação cruzada, qualquer erro pode fazer com que os servidores OPC UA rejeitem o certificado do aplicativo.

  • Fornecer um novo certificado inválido da instância do aplicativo OPC UA após uma instalação bem-sucedida de AIO pode levar a erros de conexão. Para resolver o problema, exclua suas instâncias das Operações do Azure IoT e reinicie a instalação.

Simulador de PLC OPC

Se você criar um ponto de extremidade de ativo para o simulador OPC PLC, mas o simulador OPC PLC não estiver enviando dados para o Agente MQTT, execute o seguinte comando para definir autoAcceptUntrustedServerCertificates=true para o ponto de extremidade do ativo:

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

Cuidado

Não use essa configuração em ambientes de produção ou pré-produção. Expor seu cluster à Internet sem uma autenticação adequada pode levar a acessos não autorizados e até a ataques DDoS.

Você pode corrigir todos os pontos de extremidade de ativos com o seguinte comando:

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 o simulador OPC PLC não estiver enviando dados para o Agente MQTT após você ter criado um novo ativo, reinicie o pod do simulador OPC PLC. O nome do pod se parece com aio-opc-opc.tcp-1-f95d76c54-w9v9c. Para reiniciar o pod, use a ferramenta k9s para eliminar o pod ou execute o seguinte comando:

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

Fluxos de dados

  • Os recursos personalizados de fluxo de dados criados em seu cluster não ficam visíveis na interface do usuário da experiência de operações. Isso é esperado porque o gerenciamento dos componentes das Operações do Azure IoT usando o Kubernetes está em versão prévia e não há suporte para sincronizar recursos da borda para a nuvem no momento.

  • A autenticação X.509 para pontos de extremidade personalizados do Kafka ainda não tem suporte.

  • Ainda não há suporte para desserializar e validar mensagens usando um esquema. Especificar um esquema na configuração de origem só permite que o portal de experiência de operações exiba a lista de pontos de dados, mas os pontos de dados não são validados em relação ao esquema.

  • A criação de um segredo X.509 no portal de experiência de operações resulta em um segredo com dados codificados incorretamente. Para contornar esse problema, crie segredo de várias linhas por meio do Azure Key Vault e selecione-o na lista de segredos no portal de experiência de operações.

  • Ao conectar várias instâncias de Operações IoT ao mesmo namespace do MQTT da Grade de Eventos, podem ocorrer falhas de conexão devido a conflitos de ID do cliente. As IDs do cliente são derivadas atualmente de nomes de recursos de fluxo de dados e, ao usar padrões de Infraestrutura como código (IaC) para implantação, as IDs de cliente geradas podem ser idênticas. Como uma solução alternativa temporária, adicione aleatoriedade aos nomes de fluxo de dados em seus modelos de implantação.

  • Quando a conexão de rede é interrompida, os Fluxos de Dados podem encontrar erros ao enviar mensagens devido a uma ID de produtor incompatível. Se você enfrentar esse problema, reinicie seus pods de Fluxos de Dados.