Łą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.
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
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 parametremmqttBridgeConnectorRef
, aby dopasować nazwę zasobu MqttBridgeConnector utworzonego we wcześniejszym kroku.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 , repository i 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: {}
trustedCaCertifcateName
Oto 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-topic
local-topic
lokalnego:
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 groupMinimumShareNumber
3:
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-topic
programu . 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.