Udostępnij za pośrednictwem


Łączenie łącznika chmury mostka MQTT usługi Azure IoT MQQ w wersji zapoznawczej z innymi brokerami MQTT

Ważne

Usługa Azure IoT Operations Preview — włączona przez usługę Azure Arc jest obecnie dostępna w wersji zapoznawczej. Nie należy używać tego oprogramowania w wersji zapoznawczej w środowiskach produkcyjnych.

Zobacz Dodatkowe warunki użytkowania wersji zapoznawczych platformy Microsoft Azure, aby zapoznać się z postanowieniami prawnymi dotyczącymi funkcji platformy Azure, które są w wersji beta lub wersji zapoznawczej albo w inny sposób nie zostały jeszcze wydane jako ogólnie dostępne.

Możesz użyć mostka MQTT usługi Azure IoT W wersji zapoznawczej, aby nawiązać połączenie z usługą Azure Event Grid lub innymi brokerami MQTT. Mostkowanie MQTT to proces łączenia dwóch brokerów MQTT, dzięki czemu mogą wymieniać komunikaty.

  • Po połączeniu dwóch brokerów komunikaty publikowane na jednym brokerze są automatycznie przekazywane do drugiego i odwrotnie.
  • Mostkowanie MQTT pomaga utworzyć sieć brokerów MQTT komunikujących się ze sobą i rozszerzyć infrastrukturę MQTT przez dodanie dodatkowych brokerów zgodnie z potrzebami.
  • Mostkowanie MQTT jest przydatne w przypadku wielu lokalizacji fizycznych, udostępniania komunikatów MQTT i tematów między krawędzią a chmurą lub integracji protokołu MQTT z innymi systemami obsługi komunikatów.

Aby połączyć się z innym brokerem, usługa Azure IoT MQ musi znać adres URL punktu końcowego brokera zdalnego, wersję MQTT, sposób uwierzytelniania i tematy do mapowania. Aby zmaksymalizować możliwość komponowania i elastyczność w sposób natywny dla platformy Kubernetes, te wartości są konfigurowane jako niestandardowe zasoby Kubernetes (CRD) o nazwie MqttBridgeConnector i MqttBridgeTopicMap. W tym przewodniku opisano sposób tworzenia łącznika mostka MQTT przy użyciu tych zasobów.

  1. Utwórz plik YAML, który definiuje zasób MqttBridgeConnector . Możesz użyć przykładowego kodu YAML, ale pamiętaj, aby zmienić namespace element tak, aby był zgodny z adresem URL punktu końcowego usługi Azure IoT wdrożonym przez usługę Azure IoT MQ.remoteBrokerConnection.endpoint

  2. Utwórz plik YAML, który definiuje zasób MqttBridgeTopicMap . Możesz użyć przykładowego kodu YAML, ale pamiętaj, aby zmienić namespace element tak, aby był zgodny z wdrożonym elementem usługi Azure IoT MQ, oraz parametrem mqttBridgeConnectorRef , aby dopasować nazwę zasobu MqttBridgeConnector utworzonego we wcześniejszym kroku.

  3. Wdróż łącznik mostka MQTT i mapę tematu za pomocą polecenia kubectl apply -f <filename>.

    $ kubectl apply -f my-mqtt-bridge.yaml 
    mqttbridgeconnectors.mq.iotoperations.azure.com my-mqtt-bridge created
    $ kubectl apply -f my-topic-map.yaml
    mqttbridgetopicmaps.mq.iotoperations.azure.com my-topic-map created
    

Po wdrożeniu użyj polecenia kubectl get pods , aby sprawdzić, czy komunikaty zaczynają przepływać do i z punktu końcowego.

Konfigurowanie programu MqttBridgeConnector

Zasób MqttBridgeConnector definiuje łącznik mostka MQTT, który może komunikować się z brokerem zdalnym. W jego skład wchodzi następujący element:

  • Co najmniej jedno wystąpienie łącznika mostka MQTT. Każde wystąpienie jest kontenerem z uruchomionym łącznikiem mostka MQTT.
  • Połączenie brokera zdalnego.
  • Opcjonalne połączenie brokera lokalnego.

W poniższym przykładzie przedstawiono przykładową konfigurację mostkowania do brokera MQTT usługi Azure Event Grid. Używa przypisanej przez system tożsamości zarządzanej do uwierzytelniania i szyfrowania TLS.

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeConnector
metadata:
  name: my-mqtt-bridge
  namespace: azure-iot-operations
spec:
  image: 
    repository: mcr.microsoft.com/azureiotoperations/mqttbridge 
    tag: 0.4.0-preview
    pullPolicy: IfNotPresent
  protocol: v5
  bridgeInstances: 1
  clientIdPrefix: factory-gateway-
  logLevel: debug
  remoteBrokerConnection:
    endpoint: example.westeurope-1.ts.eventgrid.azure.net:8883
    tls:
      tlsEnabled: true
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

W poniższej tabeli opisano pola w zasobie MqttBridgeConnector :

Pole Wymagania opis
obraz Tak Obraz łącznika platformy Kafka. Możesz określić wartości pullPolicy, repositoryi tag obrazu. Prawidłowe wartości są wyświetlane w poprzednim przykładzie.
protokół Tak Wersja protokołu MQTT. Możliwe wartości to v5 i v3. Zobacz Obsługa protokołu MQTT w wersji 3.1.1.
bridgeInstances Nie. Liczba wystąpień łącznika mostka. Wartość domyślna to 1. Zobacz Liczba wystąpień.
clientIdPrefix Nie. Prefiks dynamicznie generowanego identyfikatora klienta. Wartość domyślna nie jest prefiksem. Zobacz Konfiguracja identyfikatora klienta.
logLevel Nie. Poziom dziennika. Możliwe wartości to debug i info. Wartość domyślna to info.
remoteBrokerConnection Tak Szczegóły połączenia z brokerem zdalnym do mostka. Zobacz Połączenie brokera zdalnego.
localBrokerConnection Nie. Szczegóły połączenia lokalnego brokera do mostka. Domyślnie jest wyświetlana wartość. Zobacz Połączenie brokera lokalnego.

Obsługa protokołu MQTT w wersji 3.1.1

Łącznik mostka można skonfigurować do używania protokołu MQTT w wersji 3.1.1 zarówno z lokalnym połączeniem brokera dla usługi Azure IoT MQ, jak i zdalnego połączenia brokera. Jednak spowoduje to przerwanie subskrypcji udostępnionych, jeśli broker zdalny nie obsługuje subskrypcji. Jeśli planujesz używać subskrypcji udostępnionych, pozostaw ją jako domyślną 5.

Liczba wystąpień

Aby uzyskać wysoką dostępność i skalę, skonfiguruj łącznik mostka MQTT do używania wielu wystąpień. Przepływ komunikatów i trasy są automatycznie zrównoważone między różnymi wystąpieniami.

spec:
  bridgeInstances: 2

Konfiguracja identyfikatora klienta

Usługa Azure IoT MQ generuje identyfikator klienta dla każdego klienta MqttBridgeConnector przy użyciu określonego prefiksu {clientIdPrefix}-{routeName}w formacie . Ten identyfikator klienta jest ważny dla usługi Azure IoT MQ, aby wyeliminować utratę komunikatów i uniknąć konfliktów lub kolizji z istniejącymi identyfikatorami klientów, ponieważ specyfikacja MQTT zezwala tylko na jedno połączenie na identyfikator klienta.

Jeśli na przykład clientIdPrefix: "client-"na mapie tematu znajdują się dwa routes identyfikatory klientów: client-route1 i client-route2.

Połączenie brokera zdalnego

Pole remoteBrokerConnection definiuje szczegóły połączenia, aby połączyć się z brokerem zdalnym. Zawiera następujące pola:

Pole Wymagania opis
endpoint Tak Adres URL punktu końcowego brokera zdalnego z portem. Na przykład example.westeurope-1.ts.eventgrid.azure.net:8883.
tls Tak Określa, czy połączenie jest szyfrowane przy użyciu protokołu TLS i zaufanego certyfikatu urzędu certyfikacji. Zobacz Obsługa protokołu TLS
uwierzytelnianie Tak Szczegóły uwierzytelniania usługi Azure IoT MQ do użycia z brokerem. Musi być jedną z następujących wartości: tożsamość zarządzana przypisana przez system lub X.509. Zobacz Uwierzytelnianie.
protokół Nie. Wartość ciągu definiująca używanie MQTT lub MQTT za pośrednictwem obiektów WebSocket. Możliwe wartości to mqtt i webSocket. Wartość domyślna to mqtt.

Uwierzytelnianie

Pole uwierzytelniania definiuje metodę uwierzytelniania dla usługi Azure IoT MQ do użycia z brokerem zdalnym. Zawiera następujące pola:

Pole Wymagania opis
systemAssignedManagedIdentity Nie. Uwierzytelnianie przy użyciu tożsamości zarządzanej przypisanej przez system. Zobacz Tożsamość zarządzana.
x509 Nie. Szczegóły uwierzytelniania przy użyciu certyfikatów X.509. Zobacz X.509.

Tożsamość zarządzana

Pole systemAssignedManagedIdentity zawiera następujące pola:

Pole Wymagania opis
audiencja Tak Odbiorcy tokenu. Wymagane w przypadku korzystania z tożsamości zarządzanej. W przypadku usługi Event Grid jest to https://eventgrid.azure.net.

Jeśli usługa Azure IoT MQ jest wdrażana jako rozszerzenie usługi Azure Arc, domyślnie pobiera tożsamość zarządzaną przypisania systemu. Należy użyć tożsamości zarządzanej dla usługi Azure IoT MQ do interakcji z zasobami platformy Azure, w tym brokera MQTT usługi Event Grid, ponieważ pozwala uniknąć zarządzania poświadczeniami i zachować wysoką dostępność.

Aby użyć tożsamości zarządzanej do uwierzytelniania za pomocą zasobów platformy Azure, najpierw przypisz odpowiednią rolę RBAC platformy Azure, na przykład EventGrid TopicSpaces Publisher do tożsamości zarządzanej usługi Azure IoT MQ dostarczonej przez usługę Arc.

Następnie określ i MQTTBridgeConnector z tożsamością zarządzaną jako metodę uwierzytelniania:

spec:
  remoteBrokerConnection:
    authentication:
      systemAssignedManagedIdentity:
        audience: https://eventgrid.azure.net

Jeśli używasz tożsamości zarządzanej, identyfikator klienta nie jest konfigurowalny i odpowiada identyfikatorowi zasobu usługi Azure IoT MQ rozszerzenia Azure Arc usługi Azure Resource Manager na platformie Azure.

Tożsamość zarządzana przypisana przez system jest dostarczana przez usługę Azure Arc. Certyfikat skojarzony z tożsamością zarządzaną musi być odnawiany co najmniej co 90 dni, aby uniknąć ręcznego procesu odzyskiwania. Aby dowiedzieć się więcej, zobacz Jak mogę adres wygasły zasoby platformy Kubernetes z obsługą usługi Azure Arc?

X.509

Pole x509 zawiera następujące pola:

Pole Wymagania opis
secretName Tak Wpis tajny kubernetes zawierający certyfikat klienta i klucz prywatny. Za pomocą usługi Azure Key Vault można zarządzać wpisami tajnymi dla usługi Azure IoT MQ zamiast wpisów tajnych platformy Kubernetes. Aby dowiedzieć się więcej, zobacz Zarządzanie wpisami tajnymi przy użyciu usługi Azure Key Vault lub wpisów tajnych platformy Kubernetes.

Wiele brokerów MQTT, takich jak Event Grid, obsługuje uwierzytelnianie X.509. Mostek MQTT usługi Azure IoT może przedstawić certyfikat X.509 klienta i wynegocjować komunikację TLS. Użyj wpisu tajnego platformy Kubernetes do przechowywania certyfikatu klienta X.509, klucza prywatnego i pośredniego urzędu certyfikacji.

kubectl create secret generic bridge-client-secret \
--from-file=client_cert.pem=mqttbridge.pem \
--from-file=client_key.pem=mqttbridge.key \
--from-file=client_intermediate_certs.pem=intermediate.pem

I odwołuje się do niego za pomocą polecenia secretName:

spec:
  remoteBrokerConnection:
    authentication:
      x509:
        secretName: bridge-client-cert

Połączenie brokera lokalnego

Pole localBrokerConnection definiuje szczegóły połączenia, aby połączyć się z lokalnym brokerem.

Pole Wymagania opis
endpoint Tak Adres URL punktu końcowego brokera zdalnego z portem.
tls Tak Określa, czy połączenie jest szyfrowane przy użyciu protokołu TLS i zaufanego certyfikatu urzędu certyfikacji. Zobacz Obsługa protokołu TLS
uwierzytelnianie Tak Szczegóły uwierzytelniania usługi Azure IoT MQ do użycia z brokerem. Jedyną obsługiwaną metodą jest token konta usługi Kubernetes (SAT). Aby użyć sat, określ .kubernetes: {}

Domyślnie usługa IoT MQ jest wdrażana w przestrzeni nazw azure-iot-operations z włączonym protokołem TLS i uwierzytelnianiem SAT.

Następnie należy skonfigurować ustawienie połączenia lokalnego brokera MqttBridgeConnector, aby było zgodne. Wdrożenie YAML dla MqttBridgeConnector musi mieć localBrokerConnection taki sam poziom jak remoteBrokerConnection. Aby na przykład użyć protokołu TLS z uwierzytelnianiem SAT w celu dopasowania do domyślnego wdrożenia IoT MQ:

spec:
  localBrokerConnection:
    endpoint: aio-mq-dmqtt-frontend:8883
    tls:
      tlsEnabled: true
      trustedCaCertificateConfigMap: aio-ca-trust-bundle-test-only
    authentication:
      kubernetes: {}

trustedCaCertifcateNameOto element ConfigMap głównego urzędu certyfikacji usługi Azure IoT MQ, taki jak ConfigMap dla głównego urzędu certyfikacji brokera zdalnego. Domyślny główny urząd certyfikacji jest przechowywany w ConfigMap o nazwie aio-ca-trust-bundle-test-only.

Aby uzyskać więcej informacji na temat uzyskiwania głównego urzędu certyfikacji, zobacz Konfigurowanie protokołu TLS z automatycznym zarządzaniem certyfikatami w celu zabezpieczenia komunikacji MQTT.

Obsługa protokołu TLS

Pole tls definiuje konfigurację protokołu TLS dla połączenia zdalnego lub lokalnego brokera. Zawiera następujące pola:

Pole Wymagania opis
tlsEnabled Tak Niezależnie od tego, czy protokół TLS jest włączony, czy nie.
trustedCaCertificateConfigMap Nie. Certyfikat urzędu certyfikacji do zaufania podczas nawiązywania połączenia z brokerem. Wymagane, jeśli protokół TLS jest włączony.

Obsługa szyfrowania TLS jest dostępna zarówno dla połączeń zdalnych, jak i lokalnych brokerów.

  • W przypadku połączenia brokera zdalnego: jeśli protokół TLS jest włączony, jako odwołanie kubernetes ConfigMap należy określić zaufany certyfikat urzędu certyfikacji. W przeciwnym razie uzgadnianie protokołu TLS może zakończyć się niepowodzeniem, chyba że zdalny punkt końcowy jest powszechnie zaufany Certyfikat zaufanego urzędu certyfikacji znajduje się już w magazynie certyfikatów systemu operacyjnego. Na przykład usługa Event Grid używa powszechnie zaufanego katalogu głównego urzędu certyfikacji, dlatego określanie nie jest wymagane.
  • W przypadku lokalnego połączenia brokera (Azure IoT MQ): jeśli protokół TLS jest włączony dla odbiornika brokera usługi Azure IoT MQ, certyfikat urzędu certyfikacji, który wystawił certyfikat serwera odbiornika, powinien zostać określony jako dokumentacja narzędzia Kubernetes ConfigMap .

Podczas określania zaufanego urzędu certyfikacji należy utworzyć obiekt ConfigMap zawierający publiczną eliksir urzędu certyfikacji i określić nazwę mapy konfiguracji we trustedCaCertificateConfigMap właściwości . Na przykład:

kubectl create configmap client-ca-configmap --from-file ~/.step/certs/root_ca.crt

Konfigurowanie MqttBridgeTopicMap

Zasób MqttBridgeTopicMap definiuje mapowanie tematu między lokalnymi i zdalnymi brokerami. Należy go używać wraz z zasobem MqttBridgeConnector . W jego skład wchodzi następujący element:

  • Nazwa zasobu MqttBridgeConnector do połączenia.
  • Lista tras do mostkowania.
  • Opcjonalna konfiguracja subskrypcji udostępnionej.

MqttBridgeConnector może używać wielu połączonych z nim map MqttBridgeTopicMap. Po wdrożeniu zasobu MqttBridgeConnector operator usługi Azure IoT MQ rozpoczyna skanowanie przestrzeni nazw dla dowolnego połączonego z nim obiektu MqttBridgeTopicMaps i automatyczne zarządzanie przepływem komunikatów między wystąpieniami MqttBridgeConnector. Następnie po wdrożeniu MqttBridgeTopicMap jest połączony z MqttBridgeConnector. Każdy obiekt MqttBridgeTopicMap może być połączony tylko z jednym MqttBridgeConnector.

W poniższym przykładzie przedstawiono konfigurację MqttBridgeTopicMap na potrzeby mostkowania komunikatów z tematu zdalnego do tematu remote-topiclocal-topiclokalnego:

apiVersion: mq.iotoperations.azure.com/v1beta1
kind: MqttBridgeTopicMap
metadata:
  name: my-topic-map
  namespace: azure-iot-operations 
spec:
  mqttBridgeConnectorRef: my-mqtt-bridge
  routes:
    - direction: remote-to-local
      name: first-route
      qos: 0
      source: remote-topic
      target: local-topic
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: group1
    - direction: local-to-remote
      name: second-route
      qos: 1
      source: local-topic
      target: remote-topic

W poniższej tabeli opisano pola w zasobie MqttBridgeTopicMap:

Pola Wymagania opis
mqttBridgeConnectorRef Tak MqttBridgeConnector Nazwa zasobu do połączenia.
routes Tak Lista tras do mostkowania. Aby uzyskać więcej informacji, zobacz Trasy.

Trasy

MqttBridgeTopicMap może mieć wiele tras. Pole routes definiuje listę tras. Zawiera następujące pola:

Pola Wymagania opis
kierunek Tak Kierunek przepływu komunikatów. Może to być remote-to-local lub local-to-remote. Aby uzyskać więcej informacji, zobacz Kierunek.
name Tak Nazwa trasy.
qos Nie. Jakość usług MQTT (QoS). Wartość domyślna to 1.
source Tak Źródłowy temat MQTT. Może mieć symbole wieloznaczne, takie jak # i +. Zobacz Symbole wieloznaczne w temacie źródłowym.
target Nie. Docelowy temat MQTT. Nie można mieć symboli wieloznacznych. Jeśli nie zostanie określony, będzie on taki sam jak źródło. Zobacz Temat źródła odwołania w elemencie docelowym.
sharedSubscription Nie. Konfiguracja subskrypcji udostępnionej. Aktywuje skonfigurowaną liczbę klientów na potrzeby dodatkowej skali. Aby uzyskać więcej informacji, zobacz Subskrypcje udostępnione.

Kierunek

Jeśli na przykład kierunek to local-to-remote, usługa Azure IoT MQ publikuje wszystkie komunikaty w określonym temacie lokalnym do tematu zdalnego:

routes:
  - direction: local-to-remote
    name: "send-alerts"
    source: "alerts"
    target: "factory/alerts"

Jeśli kierunek jest odwrócony, usługa Azure IoT MQ odbiera komunikaty z brokera zdalnego. W tym miejscu element docelowy zostanie pominięty, a wszystkie komunikaty z tematu commands/factory dotyczącego brokera zdalnego są publikowane lokalnie w tym samym temacie.

routes:
  - direction: remote-to-local
    name: "receive-commands"
    source: "commands/factory"

Symbole wieloznaczne w temacie źródłowym

Aby połączyć się z tematami niestatycznymi, użyj symboli wieloznacznych, aby zdefiniować, jak wzorce tematów powinny być dopasowane i reguła tłumaczenia nazwy tematu. Aby na przykład połączyć wszystkie komunikaty we wszystkich podtopach w obszarze telemetry, użyj wieloznacznego # symbolu wieloznacznego:

routes:
  - direction: local-to-remote
    name: "wildcard-source"
    source: "telemetry/#"
    target: "factory/telemetry"

W przykładzie, jeśli komunikat zostanie opublikowany w dowolnym temacie w obszarze telemetry, na przykład telemetry/furnace/temperature, usługa Azure IoT MQ publikuje go w zdalnym brokerze mostkowanym w temacie statycznymfactory/telemetry.

W przypadku symboli wieloznacznych tematu jednopoziomowego użyj zamiast tego polecenia + , na przykład telemetry/+/temperature.

Łącznik mostka MQTT musi znać dokładny temat w docelowym brokerze zdalnym lub Azure IoT MQ bez żadnych niejednoznaczności. Symbole wieloznaczne są dostępne tylko w ramach tematu source .

Temat źródłowy odwołania w elemencie docelowym

Aby odwoływać się do całego tematu źródłowego, całkowicie pomiń konfigurację tematu docelowego w trasie. Obsługiwane są symbole wieloznaczne.

Na przykład każdy komunikat opublikowany w temacie my-topic/#, na przykład my-topic/foo lub my-topic/bar, są łączone z brokerem zdalnym w tym samym temacie:

routes:
  - direction: local-to-remote
    name: "target-same-as-source"
    source: "my-topic/#"
    # No target

Inne metody odwołania do tematu źródłowego nie są obsługiwane.

Subskrypcje udostępnione

Pole sharedSubscription definiuje konfigurację subskrypcji udostępnionej dla trasy. Zawiera następujące pola:

Pola Wymagania opis
groupMinimumShareNumber Tak Liczba klientów do użycia w ramach subskrypcji udostępnionej.
groupName Tak Nazwa udostępnionej grupy subskrypcji.

Subskrypcje udostępnione ułatwiają usłudze Azure IoT MQ tworzenie większej liczby klientów dla mostka MQTT. Dla każdej trasy można skonfigurować inną subskrypcję udostępnioną. Usługa Azure IoT MQ subskrybuje komunikaty z tematu źródłowego i wysyła je do jednego klienta naraz przy użyciu działania okrężnego. Następnie klient publikuje komunikaty do brokera mostkowego.

Jeśli na przykład skonfigurujesz trasę z udostępnioną subskrypcją i ustawisz jako groupMinimumShareNumber3:

routes:
    - direction: local-to-remote
      qos: 1
      source: "shared-sub-topic"
      target: "remote/topic"
      sharedSubscription:
        groupMinimumShareNumber: 3
        groupName: "sub-group"

Mostek MQTT usługi Azure IoT MQTT tworzy trzech klientów subskrybentów niezależnie od liczby wystąpień. Tylko jeden klient pobiera każdy komunikat z $share/sub-group/shared-sub-topicprogramu . Następnie ten sam klient publikuje komunikat do zdalnego brokera mostkowego w temacie remote/topic. Następny komunikat przechodzi do następnego klienta.

Ułatwia to zrównoważenie ruchu komunikatów dla mostu między wieloma klientami przy użyciu różnych identyfikatorów. Jest to przydatne, jeśli broker bridged ogranicza liczbę komunikatów, które może wysyłać każdy klient.

Obsługa brokera MQTT usługi Azure Event Grid

Aby zminimalizować zarządzanie poświadczeniami, użycie tożsamości zarządzanej przypisanej przez system i kontroli dostępu opartej na rolach platformy Azure jest zalecanym sposobem łączenia usługi Azure IoT MQQ z funkcją brokera MQTT usługi Azure Event Grid.

Aby zapoznać się z kompleksowego samouczka, zobacz Samouczek: konfigurowanie mostka MQTT między usługą Azure IoT MQ w wersji zapoznawczej i usługą Azure Event Grid.

Nawiązywanie połączenia z brokerem MQTT usługi Event Grid przy użyciu tożsamości zarządzanej

Najpierw użyj polecenia az k8s-extension show, znajdź identyfikator podmiotu zabezpieczeń dla rozszerzenia usługi Azure IoT MQ Arc. Zanotuj wartość wyjściową elementu identity.principalId, która powinna wyglądać następująco: abcd1234-5678-90ab-cdef-1234567890ab.

az k8s-extension show --resource-group <RESOURCE_GROUP> --cluster-name <CLUSTER_NAME> --name mq --cluster-type connectedClusters --query identity.principalId -o tsv

Następnie użyj interfejsu wiersza polecenia platformy Azure, aby przypisać role do tożsamości zarządzanej rozszerzenia usługi Azure IoT MQ Arc. Zastąp <MQ_ID> element identyfikatorem podmiotu zabezpieczeń znalezionym w poprzednim kroku. Aby na przykład przypisać rolę wydawcy EventGrid TopicSpaces:

az role assignment create --assignee <MQ_ID> --role 'EventGrid TopicSpaces Publisher' --scope /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.EventGrid/namespaces/<EVENT_GRID_NAMESPACE>

Napiwek

Aby zoptymalizować zasady najniższych uprawnień, można przypisać rolę do przestrzeni tematu zamiast całej przestrzeni nazw usługi Event Grid. Aby dowiedzieć się więcej, zobacz Event Grid RBAC and Topic spaces (Przestrzenie tematów i kontroli dostępu opartej na rolach usługi Event Grid).

Na koniec utwórz element MQTTBridgeConnector i wybierz tożsamość zarządzaną jako metodę uwierzytelniania. Utwórz MqttBridgeTopicMaps i wdróż mostek MQTT za pomocą polecenia kubectl.

Maksymalna liczba sesji klienta na nazwę uwierzytelniania

Jeśli bridgeInstances ustawiono wartość wyższą niż 1, skonfiguruj konfigurację brokera >MQTT usługi Event Grid Maksymalna liczba sesji klienta na nazwę uwierzytelniania, aby odpowiadała liczbie wystąpień. Ta konfiguracja zapobiega problemom, takim jak przekroczono limit przydziału 151.

Limit połączeń

Jeśli korzystanie z tożsamości zarządzanej nie jest możliwe, podczas projektowania konfiguracji zachowaj limity dla brokera MQTT usługi Event Grid. W momencie publikowania limit wynosi 100 komunikatów na sekundę dla połączenia. Aby zwiększyć przepływność mostka MQTT, użyj subskrypcji udostępnionych, aby zwiększyć liczbę klientów obsługujących każdą trasę.

Mostek z innego brokera do wersji zapoznawczej usługi Azure IoT MQ

Usługa Azure IoT MQQ jest zgodnym brokerem MQTT, a inni brokerzy mogą połączyć się z nim przy użyciu odpowiednich poświadczeń uwierzytelniania i autoryzacji. Zobacz na przykład dokumentację mostka MQTT dla technologii HiveMQ, VerneMQ, EMQX i Mosquitto.