Dela via

Säker MQTT-koordinatorkommunikation med BrokerListener

  • Artikel

Viktigt!

Den här sidan innehåller instruktioner för att hantera Azure IoT Operations-komponenter med hjälp av Kubernetes-distributionsmanifest, som finns i förhandsversion. Den här funktionen har flera begränsningar och bör inte användas för produktionsarbetsbelastningar.

Juridiska villkor för Azure-funktioner i betaversion, förhandsversion eller som av någon annan anledning inte har gjorts allmänt tillgängliga ännu finns i kompletterande användningsvillkor för Microsoft Azure-förhandsversioner.

En BrokerListener motsvarar en nätverksslutpunkt som exponerar asynkron meddelandekö för klienter över nätverket. Du kan ha en eller flera BrokerListener-resurser för varje broker, med flera portar och olika åtkomstkontroll på var och en.

Varje BrokerListener-port kan ha sina egna autentiserings- och auktoriseringsregler som definierar vem som kan ansluta på lyssnarporten och vilka åtgärder de kan utföra på koordinatorn. Du kan använda BrokerAuthentication - och BrokerAuthorization-resurser för att ange åtkomstkontrollprinciperna för varje lyssnarport. Med den här flexibiliteten kan du finjustera behörigheter och roller för dina MQTT-klienter baserat på deras behov och användningsfall.

Dricks

Standarddistributionen av MQTT-koordinator är en kluster-IP-tjänst som kräver att klienter ansluter till TLS och autentiserar med tjänstkontotoken. Klienter som ansluter utanför klustret behöver extra konfiguration innan de kan ansluta.

Mäklarlyssnare har följande egenskaper:

En lista över alla tillgängliga inställningar finns i API-referensen för koordinatorlyssnare.

Standard brokerlistener

När du distribuerar Azure IoT Operations skapar distributionen en BrokerListener-resurs med namnet default. Den här lyssnaren används för krypterad intern kommunikation mellan Azure IoT Operations-komponenter. Standardlyssnaren är en del av standardsynkron meddelandekö.

Varning

Undvik att störa intern Azure IoT Operations-kommunikation genom att hålla standardlyssningsverktyget oförändrat och dedikerat för internt bruk. Skapa en ny lyssnare för extern kommunikation. Om du behöver använda ClusterIp-tjänsten lägger du till fler portar i standardlyssningstjänsten utan att ändra någon av de befintliga inställningarna.

Så här visar eller redigerar du standardlyssnaren:

  1. I Azure Portal navigerar du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

    Skärmbild som använder Azure Portal för att visa Azure IoT Operations MQTT-konfiguration.

  3. Välj standardlyssnare i listan med koordinatorlyssnare.

    Skärmbild som använder Azure Portal för att visa eller redigera standardlyssnaren för asynkron meddelandekö.

  4. Granska lyssnarinställningarna, men undvik att ändra någon av de befintliga inställningarna. Skapa i stället en ny port och konfigurera den efter behov.

Undvik att ändra standardlyssnaren för asynkron meddelandekö

Om du vill förhindra att intern Azure IoT Operations-kommunikation störs ska standardlyssnaren vara oförändrad och dedikerad för intern användning. Skapa en ny lyssnare för extern kommunikation.

Eftersom standardsynkroniseringslyssnaren använder tjänsttypen ClusterIp, och du bara kan ha en lyssnare per tjänsttyp, lägger du till fler portar till standardlyssnaren utan att ändra någon av de befintliga inställningarna om du behöver använda ClusterIp-tjänsten.

Skapa nya koordinatorlyssnare

Om du vill skapa en ny lyssnare anger du följande inställningar:

  • Namn: Lyssnarens namn. Det här namnet är också Kubernetes-tjänstens namn om det inte åsidosätts.
  • Tjänsttyp: Typ av Kubernetes-tjänsten. Se Tjänsttyp.
  • Portar: Lista över portar som ska lyssnas på. Se Portar.
  • (Valfritt) Tjänstnamn: åsidosätt Kubernetes-tjänstens namn. Se Tjänstnamn.

Exempel: Skapa en ny lyssnare med två portar

Det här exemplet visar hur du skapar en ny lyssnare med lastbalanserarens tjänsttyp. BrokerListener-resursen definierar två portar som accepterar MQTT-anslutningar från klienter.

  1. I Azure Portal navigerar du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

  3. Välj MQTT-koordinatorlyssnare för LoadBalancer>Create.

    Ange följande inställningar:

    Inställning Description
    Name Namnet på BrokerListener-resursen.
    Servicenamn Namnet på Kubernetes-tjänsten. Lämna tomt om du vill använda lyssnarnamnet som tjänstnamn.
    Typ av tjänst LoadBalancer har redan valts.

  4. Under Portar anger du följande inställningar för den första porten:

    Inställning beskrivning
    Port Ange 1883
    Autentisering Välj Ingen
    Auktorisering Välj Ingen
    Protokoll Välj MQTT
    TLS Lägg inte till

  5. Välj Lägg till portpost för att lägga till en andra port och ange följande inställningar:

    Inställning beskrivning
    Port Ange 8883
    Autentisering Välj standard
    Auktorisering Välj Ingen
    Protokoll Välj MQTT
    TLS Markera Lägga till

  6. I TLS-konfigurationsfönstret anger du följande inställningar:

    Inställning beskrivning
    TLS-läge Välj Automatisk
    Utfärdarens namn Ange azure-iot-operations-aio-certificate-issuer
    Typ av utfärdare Välj ClusterIssuer

    Låt andra inställningar vara kvar som standard och välj Använd.

  7. Välj Skapa lyssnare.

    Skärmbild som använder Azure Portal för att skapa MQTT-koordinator för lastbalanserarens lyssnare.

Typ av tjänst

Varje BrokerListener mappar till en Kubernetes-tjänst. Tjänsttypen avgör hur asynkron meddelandekö exponeras för nätverket. De tjänsttyper som stöds är:

  • ClusterIp: Exponerar asynkron meddelandekö på en klusterintern IP-adress. Klienter kan ansluta till asynkron meddelandekö inifrån klustret. Det här är standardtjänsttypen för standardlyssnaren.
  • NodePort: Exponerar asynkron meddelandekö på varje nods IP-adress på en statisk port. Klienter kan ansluta till asynkron meddelandekö utanför klustret. Den här tjänsttypen är användbar för utveckling och testning.
  • LoadBalancer: Exponerar koordinatorn externt. Tjänsten tilldelas en extern IP-adress som klienter kan använda för att ansluta till asynkron meddelandekö. Det här är den vanligaste tjänsttypen för produktionsdistributioner.

Endast en lyssnare per tjänsttyp

Endast en lyssnare per tjänsttyp tillåts. Om du behöver fler anslutningar av samma tjänsttyp lägger du till fler portar till den befintliga lyssnaren av den tjänsttypen.

Servicenamn

Tjänstnamnet är namnet på kubernetes-tjänsten som är associerad med asynkron meddelandekö. Om det inte anges används koordinatorlyssnarens namn som tjänstnamn. Tjänstnamnet måste vara unikt i namnområdet.

Dricks

För att förhindra hanteringskostnader rekommenderar vi att du lämnar tjänstnamnet tomt. Lyssnarnamnet är unikt och kan användas för att identifiera tjänsten. Använd endast tjänstnamnet som en åsidosättning när du inte kan namnge tjänsten efter lyssnaren.

Hamnar

Varje lyssnare kan ha flera portar och varje port kan ha egna inställningar för autentisering, auktorisering, protokoll och TLS.

Om du vill använda din egen autentiserings- eller auktoriseringsinställning för en port måste du skapa motsvarande resurser innan du använder den med en lyssnare. Mer information finns i Konfigurera MQTT-asynkron autentisering och Konfigurera Auktorisering för MQTT-asynkronisering.

Information om hur du använder TLS finns i Avsnittet Konfigurera TLS med automatisk certifikathantering eller Konfigurera TLS med manuell certifikathantering .

Använda samma port mellan lyssnare

Det går inte att använda samma portnummer för olika lyssnare. Varje portnummer måste vara unikt i Azure IoT Operations MQTT-koordinatorn.

Om du till exempel har en lyssnare med port 1883 kan du inte skapa en annan lyssnare med port 1883. På samma sätt använder standardlyssnaren port 18883, så du kan inte skapa en annan lyssnare med port 18883.

Stöd för WebSockets

Azure IoT Operations MQTT Broker stöder MQTT via WebSockets. Om du vill aktivera WebSockets anger du protokollet till WebSockets för porten.

Konfigurera TLS med automatisk certifikathantering

Om du vill aktivera TLS med automatisk certifikathantering anger du TLS-inställningarna på en lyssnarport.

Verifiera installationen av cert-manager

Med automatisk certifikathantering använder du cert-manager för att hantera TLS-servercertifikatet. Som standard installeras cert-manager tillsammans med Azure IoT Operations redan i cert-manager namnområdet. Kontrollera installationen innan du fortsätter.

  1. Använd kubectl för att söka efter poddar som matchar cert-manager-appetiketterna.

    kubectl get pods --namespace cert-manager -l 'app in (cert-manager,cainjector,webhook)'

    NAME                                           READY   STATUS    RESTARTS       AGE
aio-cert-manager-64f9548744-5fwdd              1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-cainjector-6c7c546578-p6vgv   1/1     Running   4 (145m ago)   4d20h
aio-cert-manager-webhook-7f676965dd-8xs28      1/1     Running   4 (145m ago)   4d20h

  2. Om poddarna visas som redo och körs är cert-manager installerat och redo att användas.

Dricks

Kontrollera installationen ytterligare genom att kontrollera installationen av cert-manager-dokumentationen. Kom ihåg att använda cert-manager namnområdet.

Skapa en utfärdare för TLS-servercertifikatet

Utfärdarresursen cert-manager definierar hur certifikat utfärdas automatiskt. Cert-manager stöder flera typer av utfärdare internt. Den har också stöd för en extern utfärdartyp för att utöka funktioner utöver de utfärdare som stöds internt. MQTT-koordinator kan användas med alla typer av utfärdare av certifikathanterare.

Viktigt!

Under den första distributionen installeras Azure IoT Operations med en standardutfärdare för TLS-servercertifikat. Du kan använda den här utfärdaren för utveckling och testning. Mer information finns i Standardrotcertifikatutfärdare och utfärdare med Azure IoT-åtgärder. Stegen nedan krävs bara om du vill använda en annan utfärdare.

Metoden för att skapa utfärdaren skiljer sig beroende på ditt scenario. I följande avsnitt visas exempel som hjälper dig att komma igång.

CA-utfärdaren är användbar för utveckling och testning. Den måste konfigureras med ett certifikat och en privat nyckel som lagras i en Kubernetes-hemlighet.

Konfigurera rotcertifikatet som en Kubernetes-hemlighet

Om du har ett befintligt CA-certifikat skapar du en Kubernetes-hemlighet med CA-certifikatet och PEM-filerna för ca-nyckeln. Kör följande kommando för att importera CA-certifikatet som en Kubernetes-hemlighet och hoppa över nästa avsnitt.

kubectl create secret tls test-ca --cert tls.crt --key tls.key -n azure-iot-operations

Om du inte har något CA-certifikat kan cert-manager generera ett CA-certifikat åt dig. Att använda cert-manager för att generera ett CA-certifikat kallas bootstrapping för en CA-utfärdare med ett självsignerat certifikat.

  1. Börja med att skapa ca.yaml:

    apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: selfsigned-ca-issuer
  namespace: azure-iot-operations
spec:
  selfSigned: {}
---
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: selfsigned-ca-cert
  namespace: azure-iot-operations
spec:
  isCA: true
  commonName: test-ca
  secretName: test-ca
  issuerRef:
    # Must match Issuer name above
    name: selfsigned-ca-issuer
    # Must match Issuer kind above
    kind: Issuer
    group: cert-manager.io
  # Override default private key config to use an EC key
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA
    size: 256

  2. Skapa det självsignerade CA-certifikatet med följande kommando:

    kubectl apply -f ca.yaml

Cert-manager skapar ett CA-certifikat med dess standardvärden. Egenskaperna för det här certifikatet kan ändras genom att ändra certifikatspecifikationen. En lista över giltiga alternativ finns i cert-manager-dokumentationen .

Distribuera rotcertifikatet

I föregående exempel lagras CA-certifikatet i en Kubernetes-hemlighet med namnet test-ca. Certifikatet i PEM-format kan hämtas från hemligheten och lagras i en fil ca.crt med följande kommando:

kubectl get secret test-ca -n azure-iot-operations -o json | jq -r '.data["tls.crt"]' | base64 -d > ca.crt

Certifikatet måste distribueras och vara betrott av alla klienter. Använd till exempel --cafile flaggan för en mosquitto-klient.

Skapa utfärdare baserat på CA-certifikat

Cert-manager behöver en utfärdare baserat på ca-certifikatet som genererades eller importerades i det tidigare steget. Skapa följande fil som issuer-ca.yaml:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: my-issuer
  namespace: azure-iot-operations
spec:
  ca:
    # Must match secretName of generated or imported CA cert
    secretName: test-ca

Skapa utfärdaren med följande kommando:

kubectl apply -f issuer-ca.yaml

Föregående kommando skapar en utfärdare för utfärdande av TLS-servercertifikat. Anteckna utfärdarens namn och typ. I exemplet är my-issuer namnet och typen är Issuer. Dessa värden anges i BrokerListener-resursen senare.

Aktivera automatisk TLS-certifikathantering för en port

Följande är ett exempel på en BrokerListener-resurs som aktiverar TLS på port 8884 med automatisk certifikathantering.

  1. I Azure Portal går du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

  3. Välj eller skapa en lyssnare. Du kan bara skapa en lyssnare per tjänsttyp. Om du redan har en lyssnare av samma tjänsttyp kan du lägga till fler portar i den befintliga lyssnaren.

  4. Du kan lägga till TLS-inställningar i lyssnaren genom att välja TLS på en befintlig port eller genom att lägga till en ny port.

    Skärmbild som använder Azure Portal för att skapa MQTT-koordinator för lastbalanserarens lyssnare med automatiska TLS-certifikat.

    Ange följande inställningar:

    Inställning Description
    Name Namnet på BrokerListener-resursen. Ange aio-broker-loadbalancer-tls.
    Port Portnummer som BrokerListener lyssnar efter MQTT-anslutningar på. Ange 8884.
    Autentisering Referensen för autentiseringsresursen.
    Auktorisering Referensen för auktoriseringsresursen.
    TLS Välj knappen Lägg till.
    Utfärdarens namn Namnet på utfärdaren av certifikathanteraren. Obligatoriskt.
    Typ av utfärdare Typ av utfärdare av certifikathanteraren. Obligatoriskt.
    Utfärdargrupp Cert-manager-utfärdarens grupp. Obligatoriskt.
    Algoritm för privat nyckel Algoritm för den privata nyckeln.
    Roteringsprincip för privat nyckel Princip för att rotera den privata nyckeln.
    DNS-namn Alternativa NAMN på DNS-ämne för certifikatet.
    IP-adresser IP-adresser för certifikatets alternativa namn för certifikatet.
    Hemligt namn Kubernetes-hemlighet som innehåller ett X.509-klientcertifikat.
    Varaktighet Total livslängd för TLS-servercertifikatet Standardvärdet är 90 dagar.
    Förnya före När du ska börja förnya certifikatet.

  5. Välj Använd för att spara TLS-inställningarna.

När BrokerListener-resursen har konfigurerats skapar MQTT Broker automatiskt en ny tjänst med den angivna porten och TLS aktiverat.

Valfritt: Konfigurera servercertifikatparametrar

De enda obligatoriska parametrarna är utfärdarens namn och typ av utfärdare. Alla andra egenskaper för de genererade TLS-servercertifikaten väljs automatiskt. MQTT-asynkron meddelandekö tillåter dock att vissa egenskaper anpassas enligt samma syntax som certifikat för cert-manager. Du kan till exempel ange algoritmen för den privata nyckeln och rotationsprincipen. De här inställningarna finns under tls.certManagerCertificateSpec eller TLS-konfigurationsfönstret i Azure Portal.

En fullständig lista över de här inställningarna finns i Referens för Broker Listener CertManagerCertificateSpec API.

Verifiera distributionen

Använd kubectl för att kontrollera att tjänsten som är associerad med BrokerListener-resursen körs. I exemplet ovan är aio-broker-loadbalancer-tls tjänstnamnet och namnområdet är azure-iot-operations. Följande kommando kontrollerar tjänststatusen:

$ kubectl get service my-new-tls-listener -n azure-iot-operations
NAME                           TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
aio-broker-loadbalancer-tls    LoadBalancer   10.X.X.X        172.X.X.X     8884:32457/TCP   33s

Ansluta till asynkron meddelandekö med TLS

När servercertifikatet har konfigurerats är TLS aktiverat. Så här testar du med mosquitto:

mosquitto_pub -h $HOST -p 8884 -V mqttv5 -i "test" -t "test" -m "test" --cafile ca.crt

Argumentet --cafile aktiverar TLS på mosquitto-klienten och anger att klienten ska lita på alla servercertifikat som utfärdats av den angivna filen. Du måste ange en fil som innehåller utfärdaren av det konfigurerade TLS-servercertifikatet.

Ersätt $HOST med lämplig värd:

  • Om du ansluter inifrån samma kluster ersätter du med det tjänstnamn som anges (my-new-tls-listener i exempel) eller tjänsten CLUSTER-IP.
  • Om du ansluter utanför klustret, tjänsten EXTERNAL-IP.

Kom ihåg att ange autentiseringsmetoder om det behövs.

Standardrotcertifikatutfärdare och utfärdare

För att hjälpa dig att komma igång distribueras Azure IoT Operations med standardcertifikatutfärdaren "snabbstart" och utfärdare för TLS-servercertifikat. Du kan använda den här utfärdaren för utveckling och testning. Mer information finns i Standardrotcertifikatutfärdare och utfärdare för TLS-servercertifikat.

För produktion måste du konfigurera en CA-utfärdare med ett certifikat från en betrodd certifikatutfärdare enligt beskrivningen i föregående avsnitt.

Konfigurera TLS med manuell certifikathantering

Om du vill konfigurera MQTT-asynkron meddelandekö manuellt för att använda ett specifikt TLS-certifikat anger du det i en BrokerListener-resurs med en referens till en Kubernetes-hemlighet och distribuerar den med kubectl. Den här artikeln visar ett exempel som konfigurerar TLS med självsignerade certifikat för testning.

Skapa certifikatutfärdare med Steg CLI

Steg är en certifikathanterare som snabbt kan komma igång när du skapar och hanterar din egen privata certifikatutfärdare.

  1. Installera Step CLI och skapa ett certifikat och nyckel för rotcertifikatutfärdare (CA).

    step certificate create --profile root-ca "Example Root CA" root_ca.crt root_ca.key

  2. Skapa ett mellanliggande CA-certifikat och en nyckel signerad av rotcertifikatutfärdare.

    step certificate create --profile intermediate-ca "Example Intermediate CA" intermediate_ca.crt intermediate_ca.key \
--ca root_ca.crt --ca-key root_ca.key

Skapa servercertifikat

Använd Step CLI för att skapa ett servercertifikat från den signerade av den mellanliggande certifikatutfärdare.

step certificate create mqtts-endpoint mqtts-endpoint.crt mqtts-endpoint.key \
--profile leaf \
--not-after 8760h \
--san mqtts-endpoint \
--san localhost \
--ca intermediate_ca.crt --ca-key intermediate_ca.key \
--no-password --insecure

Här, mqtts-endpoint och localhost är de alternativa namnen för MQTT-mäklarens klientdel i Kubernetes respektive lokala klienter. Om du vill ansluta via Internet lägger du till en --san med en extern IP-adress. Flaggorna --no-password --insecure används för testning för att hoppa över lösenordsprompter och inaktivera lösenordsskydd för den privata nyckeln eftersom den lagras i en Kubernetes-hemlighet. För produktion använder du ett lösenord och lagrar den privata nyckeln på en säker plats som Azure Key Vault.

Krav för certifikatnyckelalgoritmer

Både EC- och RSA-nycklar stöds, men alla certifikat i kedjan måste använda samma nyckelalgoritm. Om du importerar dina egna CA-certifikat kontrollerar du att servercertifikatet använder samma nyckelalgoritm som certifikatutfärdarna.

Importera servercertifikatkedjan som en Kubernetes-hemlighet

  1. Skapa en fullständig servercertifikatkedja, där ordningen på certifikaten är viktig: servercertifikatet är det första i filen, mellanliggande är det andra.

    cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.crt

  2. Skapa en Kubernetes-hemlighet med servercertifikatkedjan och servernyckeln med kubectl.

    kubectl create secret tls server-cert-secret -n azure-iot-operations \
--cert server_chain.crt \
--key mqtts-endpoint.key

Aktivera manuell TLS-certifikathantering för en port

Följande är ett exempel på en BrokerListener-resurs som aktiverar TLS på port 8884 med manuell certifikathantering.

  1. I Azure Portal navigerar du till din IoT Operations-instans.

  2. Under Komponenter väljer du MQTT Broker.

  3. Välj eller skapa en lyssnare. Du kan bara skapa en lyssnare per tjänsttyp. Om du redan har en lyssnare av samma tjänsttyp kan du lägga till fler portar i den befintliga lyssnaren. Om du vill följa exemplet anger du lyssnartjänstens namn som mqtts-endpoint.

  4. Du kan lägga till TLS-inställningar i lyssnaren genom att välja TLS på en befintlig port eller genom att lägga till en ny port.

    Skärmbild som använder Azure Portal för att skapa MQTT-koordinator för lastbalanserarens lyssnare med manuella TLS-certifikat.

    Ange följande inställningar:

    Inställning beskrivning
    Port Portnummer som BrokerListener lyssnar efter MQTT-anslutningar på. Obligatoriskt.
    Autentisering Referensen för autentiseringsresursen.
    Auktorisering Referensen för auktoriseringsresursen.
    TLS Välj knappen Lägg till.
    Hemligt namn Kubernetes-hemlighet som innehåller ett X.509-klientcertifikat.

  5. Välj Använd för att spara TLS-inställningarna.

Ansluta till asynkron meddelandekö med TLS

Om du vill testa TLS-anslutningen med mosquitto-klienten publicerar du ett meddelande och skickar rotcertifikatutfärdarcertifikatet i parametern --cafile.

mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt

Kom ihåg att ange användarnamn, lösenord osv. om MQTT-asynkron autentisering är aktiverat.

Client my-client sending CONNECT
Client my-client received CONNACK (0)
Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
Client my-client sending DISCONNECT

Dricks

Om du vill använda localhost måste porten vara tillgänglig på värddatorn. Exempel: kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations Med vissa Kubernetes-distributioner som K3d kan du lägga till en vidarebefordrad port med k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Kommentar

För att ansluta till koordinatorn måste du distribuera roten av förtroende, även kallat förtroendepaket, till alla klienter. I det här fallet är roten av förtroende den självsignerade rotcertifikatutfärdare som skapats av Step CLI. Distribution av roten av förtroende krävs för att klienten ska kunna verifiera servercertifikatkedjan. Om dina MQTT-klienter är arbetsbelastningar i Kubernetes-klustret måste du också skapa en ConfigMap med rotcertifikatutfärdaren och montera den i podden.

Använda extern IP-adress för servercertifikatet

Om du vill ansluta med TLS via Internet måste MQTT-koordinatorns servercertifikat ha sitt externa värdnamn eller IP-adress som SAN. I produktion är detta vanligtvis ett DNS-namn eller en välkänd IP-adress. Men under utveckling/testning kanske du inte vet vilket värdnamn eller extern IP-adress som tilldelas före distributionen. Lös detta genom att distribuera lyssnaren utan servercertifikatet först, skapa servercertifikatet och hemligheten med den externa IP-adressen och importera hemligheten till lyssnaren.

Om du försöker distribuera TLS-exempellyssnaren manual-tls-listener men den refererade Kubernetes-hemligheten server-cert-secret inte finns skapas den associerade tjänsten, men poddarna startar inte. Tjänsten skapas eftersom operatorn måste reservera den externa IP-adressen för lyssnaren.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

Det här beteendet förväntas dock när vi importerar servercertifikatet. Hälsohanterarens loggar nämner att MQTT-koordinatorn väntar på servercertifikatet.

kubectl logs -l app=health-manager -n azure-iot-operations

...
<6>2023-11-06T21:36:13.634Z [INFO] [1] - Server certificate server-cert-secret not found. Awaiting creation of secret.

Kommentar

I ett distribuerat system är poddloggar vanligtvis inte deterministiska och bör användas med försiktighet. Det rätta sättet att visa information som den här är genom Kubernetes-händelser och anpassad resursstatus, som finns i kvarvarande uppgifter. Tänk på föregående steg som en tillfällig lösning.

Även om klientdelspoddarna inte är igång är den externa IP-adressen redan tillgänglig.

kubectl get svc mqtts-endpoint -n azure-iot-operations

NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
mqtts-endpoint         LoadBalancer   10.X.X.X        172.X.X.X     8885:30674/TCP      1m15s

Härifrån följer du samma steg som tidigare för att skapa ett servercertifikat med den här externa IP-adressen i --san och skapa Kubernetes-hemligheten på samma sätt. När hemligheten har skapats importeras den automatiskt till lyssnaren.

Relaterat innehåll