Compartir a través de

Protección de la comunicación de agente MQTT mediante BrokerListener

  • Artículo

Importante

En esta página se incluyen instrucciones para administrar componentes de Operaciones de IoT de Azure mediante manifiestos de implementación de Kubernetes, que se encuentra en versión preliminar. Esta característica se proporciona con varias limitacionesy no se debe usar para cargas de trabajo de producción.

Consulte Términos de uso complementarios para las versiones preliminares de Microsoft Azure para conocer los términos legales que se aplican a las características de Azure que se encuentran en la versión beta, en versión preliminar o que todavía no se han publicado para que estén disponibles con carácter general.

BrokerListener corresponde a un punto de conexión de red que expone el agente a los clientes a través de la red. Puede tener uno o varios recursos BrokerListener para cada agente, con varios puertos y control de acceso diferente en cada uno.

Cada puerto BrokerListener puede tener sus propias reglas de autenticación y autorización que definen quién puede conectarse en ese puerto del agente de escucha y qué acciones pueden realizar en el agente. Puede usar BrokerAuthentication y BrokerAuthorization recursos para especificar las directivas de control de acceso para cada puerto de escucha. Esta flexibilidad le permite ajustar los permisos y roles de los clientes MQTT en función de sus necesidades y casos de uso.

Sugerencia

La implementación predeterminada del corredor MQTT es un servicio IP de clúster que requiere que los clientes se conecten con TLS y se autentiquen con tokens de cuenta de servicio. Los clientes que se conectan desde fuera del clúster necesitan de configuración adicionales para poder conectarse.

Los agentes de escucha tienen las siguientes características:

Para obtener una lista de todas las opciones disponibles, consulte la Referencia de API de agente de escucha.

BrokerListener predeterminado

Al implementar operaciones de IoT de Azure, la implementación crea un recurso BrokerListener denominado default. Este agente de escucha se usa para la comunicación interna cifrada entre los componentes de operaciones de IoT de Azure. El agente de escucha predeterminado forma parte del agente predeterminado.

Precaución

Para evitar interrumpir la comunicación interna de operaciones de IoT de Azure, mantenga el agente de escucha predeterminado sin cambios y dedicado para su uso interno. Para la comunicación externa, crear un nuevo agente de escucha. Si necesita usar el servicio ClusterIp, agregue más puertos al agente de escucha predeterminado sin cambiar ninguna de las configuraciones existentes.

Para ver o editar el agente de escucha predeterminado:

  1. En Azure Portal, vaya a su instancia de IoT Hub.

  2. En Componentes, seleccione MQTT Broker.

    Captura de pantalla con Azure Portal para ver la configuración de MQTT de Operaciones de IoT de Azure.

  3. En la lista cliente de escucha del corredor, seleccione el cliente de escucha predeterminado.

    Captura de pantalla con Azure Portal para ver o editar el cliente de escucha del corredor predeterminado.

  4. Revise la configuración del agente de escucha, pero evite modificar cualquiera de las configuraciones existentes. En su lugar, cree un puerto y configúrelo según sea necesario.

Evitar modificar el agente de escucha de agente predeterminado

Para evitar la interrupción de la comunicación interna de operaciones de IoT de Azure, mantenga el agente de escucha predeterminado sin cambios y dedicado para su uso interno. Para la comunicación externa, crear un nuevo agente de escucha.

Dado que el agente de escucha predeterminado usa el tipo de servicio ClusterIp y puede tener solo un agente de escucha por tipo de servicio, agregue más puertos al cliente de escucha predeterminado sin cambiar ninguna de las configuraciones existentes si necesita usar el servicio ClusterIp.

Crear nuevos clientes de escucha del corredor

Para crear un nuevo agente de escucha, especifique la siguiente configuración:

  • Nombre: nombre del agente de escucha. Este nombre también es el nombre del servicio Kubernetes a menos que se invalide.
  • Tipo de servicio: tipo del servicio Kubernetes. Consulte Tipo de servicio.
  • Puertos: lista de puertos en los que se va a escuchar. Vea Puertos.
  • (Opcional) Nombre del servicio: invalide el nombre del servicio de Kubernetes. Consulte Nombre del servicio.

Ejemplo: Creación de un nuevo agente de escucha con dos puertos

En este ejemplo se muestra cómo crear un nuevo agente de escucha con el tipo de servicio del equilibrador de carga. El recurso BrokerListener define dos puertos que aceptan conexiones MQTT de clientes.

  1. En Azure Portal, vaya a su instancia de IoT Hub.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione cliente de escucha de corredor MQTT para LoadBalancer>Crear.

    Escriba la siguiente configuración:

    Configuración Descripción
    Nombre Nombre del recurso BrokerListener.
    Nombre del servicio Nombre del servicio Kubernetes. Déjelo vacío para usar el nombre del cliente de escucha como nombre del servicio.
    Tipo de servicio. LoadBalancer ya seleccionado.

  4. En Puertos, escriba la siguiente configuración para el primer puerto:

    Configuración Descripción
    Port Escriba 1883
    Autenticación Elija Ninguno.
    Authorization Elija Ninguno.
    Protocolo Elegir MQTT
    TLS No agregue

  5. Seleccione Agregar entrada de puerto para agregar un segundo puerto y escriba la siguiente configuración:

    Configuración Descripción
    Port Escriba 8883
    Autenticación Elegir el valor predeterminado
    Autorización Elija Ninguno.
    Protocolo Elegir MQTT
    TLS Seleccione Agregar.

  6. En el panel configuración de TLS , escriba los valores siguientes:

    Configuración Descripción
    Modo TLS Elija Automático
    Nombre del emisor Escriba azure-iot-operations-aio-certificate-issuer.
    Tipo de emisor Elija ClusterIssuer

    Deje otra configuración como predeterminada y seleccione Aplicar.

  7. Seleccione Crear cliente de escucha.

    Captura de pantalla con Azure Portal para crear el corredor MQTT para el cliente de escucha del equilibrador de carga.

Tipo de servicio.

Cada BrokerListener se asigna a un Servicio de Kubernetes. El tipo de servicio determina cómo se expone el agente a la red. Los tipos de servicio admitidos son:

  • ClusterIp: expone el agente en una dirección IP interna del clúster. Los clientes pueden conectarse al agente desde el clúster. Este es el tipo de servicio predeterminado para el agente de escucha predeterminado.
  • NodePort: expone el agente en la dirección IP de cada nodo en un puerto estático. Los clientes pueden conectarse al agente desde fuera del clúster. Este tipo de servicio es útil para el desarrollo y las pruebas.
  • LoadBalancer: expone el agente externamente. Al servicio se le asigna una dirección IP externa que los clientes pueden usar para conectarse al agente. Este es el tipo de servicio más común para las implementaciones de producción.

Solo un agente de escucha por tipo de servicio

Solo se permite un agente de escucha por tipo de servicio. Si necesita más conectividad del mismo tipo de servicio, agregue más puertos al agente de escucha existente de ese tipo de servicio.

Nombre del servicio

El nombre del servicio es el nombre del servicio de Kubernetes asociado al agente. Si no se especifica, el nombre del agente de escucha se usa como nombre del servicio. El nombre del servicio debe ser único dentro del espacio de nombres.

Sugerencia

Para evitar la sobrecarga de administración, se recomienda dejar vacío el nombre del servicio. El nombre del agente de escucha es único y se puede usar para identificar el servicio. Use el nombre del servicio como invalidación solo cuando no pueda asignar un nombre al servicio después del agente de escucha.

Puertos

Cada agente de escucha puede tener varios puertos y cada puerto puede tener su propia configuración para la autenticación, autorización, protocolo y TLS.

Para usar su propia configuración de autenticación o autorización para un puerto, debe crear los recursos correspondientes antes de usarlos con un agente de escucha. Para obtener más información, consulte Configuración de la autenticación de agente MQTT y Configuración de la autorización del corredor MQTT.

Para usar TLS, consulte la sección Configuración de TLS con administración automática de certificados o Configuración de TLS con administración manual de certificados.

Uso del mismo puerto entre agentes de escucha

No se admite el uso del mismo número de puerto en diferentes agentes de escucha. Cada número de puerto debe ser único dentro del agente MQTT de Azure IoT Operations.

Por ejemplo, si tiene un agente de escucha mediante el puerto 1883, no puede crear otro agente de escucha con el puerto 1883. Del mismo modo, el agente de escucha predeterminado usa el puerto 18883, por lo que no puede crear otro agente de escucha con el puerto 18883.

Compatibilidad con WebSockets

El corredor MQTT de Operaciones de IoT de Azure admite MQTT a través de WebSockets. Para habilitar WebSockets, establezca el protocolo en WebSockets para el puerto.

Configuración de TLS con administración automática de certificados

Para habilitar TLS con administración automática de certificados, especifique la configuración de TLS en un puerto de escucha.

Compruebe la instalación de cert-manager

Con la administración automática de certificados, se usa cert-manager para administrar el certificado de servidor TLS. De manera predeterminada, cert-manager ya está instalado junto con las Operaciones de IoT de Azure en el espacio de nombres cert-manager. Compruebe la instalación antes de continuar.

  1. Use kubectl para comprobar si los pods coinciden con las etiquetas de la aplicación cert-manager.

    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. Si ve que los pods se muestran como listos y en ejecución, cert-manager está instalado y listo para usarse.

Sugerencia

Para comprobar aún más la instalación, consulte la documentación de cert-manager para comprobar la instalación. Recuerde usar el espacio de nombres cert-manager.

Creación de un emisor para el certificado de servidor TLS

El recurso emisor cert-manager define cómo se emiten automáticamente los certificados. Cert-manager admite varios tipos de emisores de forma nativa. También admite un tipo de emisor externo para ampliar la funcionalidad más allá de los emisores admitidos de forma nativa. El broker MQTT puede utilizarse con cualquier tipo de emisor de cert-manager.

Importante

Durante la implementación inicial, las Operaciones de IoT de Azure se instala con un emisor predeterminado para los certificados de servidor TLS. Puede usar este emisor para desarrollo y pruebas. Para más información, consulte Entidad de certificación raíz predeterminada y emisor con Operaciones de loT de Azure. Los pasos siguientes solo son necesarios si desea usar otro emisor.

El enfoque para crear el emisor es diferente en función del escenario. En las secciones siguientes se enumeran ejemplos para ayudarle a empezar.

El emisor de CA es útil para el desarrollo y las pruebas. Debe configurarse con un certificado y una clave privada almacenadas en un secreto de Kubernetes.

Configuración del certificado raíz como un secreto de Kubernetes

Si tiene un certificado de entidad de certificación existente, cree un secreto de Kubernetes con el certificado de entidad de certificación y los archivos PEM de clave privada de entidad de certificación. Ejecute el siguiente comando para importar el certificado de entidad de certificación como un secreto de Kubernetes y omitir la sección siguiente.

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

Si no tiene un certificado CA, cert-manager puede generar un certificado CA raíz para usted. El uso de cert-manager para generar un certificado de entidad de certificación se conoce como arranque de un emisor CA con un certificado autofirmado.

  1. Empiece por crear 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. Cree el certificado CA con firma propia con el siguiente comando:

    kubectl apply -f ca.yaml

Cert-manager crea un certificado CA utilizando sus valores predeterminados. Las propiedades de este certificado pueden cambiarse modificando la especificación del certificado. Consulte Documentación de cert-manager para obtener una lista de opciones válidas.

Distribuir el certificado raíz

El ejemplo anterior almacena el certificado CA en un secreto de Kubernetes llamado test-ca. El certificado en formato PEM se puede recuperar del secreto y almacenar en un archivo ca.crt con el siguiente comando:

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

Todos los clientes deben distribuir y confiar en este certificado. Por ejemplo, use la marca --cafile para un cliente de mosquitto.

Crear emisor basado en certificado CA

Cert-manager necesita un emisor basado en el certificado CA generado o importado en el paso anterior. Cree el siguiente archivo como 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

Cree el emisor con el siguiente comando:

kubectl apply -f issuer-ca.yaml

El comando anterior crea un emisor para emitir certificados de servidor TLS. Anote el nombre y el tipo del emisor. En el ejemplo, el nombre es my-issuer y el tipo es Issuer. Estos valores se establecen en el recurso BrokerListener más adelante.

Habilitar la administración automática de certificados TLS para un puerto

A continuación se muestra un ejemplo de un recurso BrokerListener que habilita TLS en el puerto 8884 con administración automática de certificados.

  1. En Azure Portal, vaya a la instancia de operaciones de IoT.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione o cree un cliente de escucha. Solo puede crear un cliente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente.

  4. Puede agregar la configuración de TLS al cliente de escucha seleccionando TLS en un puerto existente o agregando un puerto nuevo.

    Recorte de pantalla con Azure Portal para crear el corredor MQTT para el cliente de escucha del equilibrador de carga con certificados TLS automáticos.

    Escriba la siguiente configuración:

    Configuración Descripción
    Nombre Nombre del recurso BrokerListener. Escriba aio-broker-loadbalancer-tls.
    Port Número de puerto en el que BrokerListener escucha las conexiones MQTT. Escriba 8884.
    Autenticación La referencia de recursos de autenticación.
    Authorization La referencia del recurso de autorización.
    TLS Selecciona el botón Agregar.
    Nombre del emisor Nombre del emisor del administrador de certificados. Necesario.
    Tipo de emisor Tipo de emisor de cert-manager. Necesario.
    Grupo de emisores Grupo del emisor de cert-manager. Necesario.
    Algoritmo de clave privada Algoritmo para la clave privada.
    Directiva de rotación de claves privadas Directiva para rotar la clave privada.
    Nombres DNS Nombres alternativos del firmante DNS para el certificado.
    Direcciones IP Direcciones IP de los nombres alternativos del firmante para el certificado.
    Nombre secreto Secreto de Kubernetes que contiene un certificado de cliente X.509.
    Duration Duración total del certificado de servidor TLS Por defecto, 90 días.
    Renovar antes Cuándo empezar a renovar el certificado.

  5. Seleccione Aplicar para guardar la configuración de TLS.

Una vez configurado el recurso BrokerListener, el broker MQTT crea automáticamente un nuevo servicio con el puerto especificado y TLS habilitado.

Opcional: Configurar parámetros de certificado de servidor

Los únicos parámetros necesarios son el nombre del emisor y el tipo de emisor. Todas las demás propiedades de los certificados de servidor TLS generados se eligen automáticamente. Sin embargo, el corredor MQTT permite personalizar determinadas propiedades siguiendo la misma sintaxis que los Certificados cert-manager. Por ejemplo, puede especificar el algoritmo de clave privada y la directiva de rotación. Estas opciones se encuentran en tls.certManagerCertificateSpec o en el panel configuración de TLS en Azure Portal.

Para obtener una lista completa de estas opciones de configuración, consulte referencia de la API de agente de escucha de Broker CertManagerCertificateSpec.

Comprobación de la implementación

Use kubectl para comprobar que el servicio asociado al recurso BrokerListener se está ejecutando. En el ejemplo anterior, el nombre del servicio es aio-broker-loadbalancer-tls y el espacio de nombres es azure-iot-operations. El comando siguiente comprueba el estado del servicio:

$ 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

Conexión al agente con TLS

Una vez configurado el certificado de servidor, TLS está habilitado. Para probar con mosquitto:

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

El argumento--cafile habilita TLS en el cliente mosquitto y especifica que el cliente debe confiar en todos los certificados de servidor emitidos por el archivo especificado. Debe especificar un archivo que contenga el emisor del certificado de servidor TLS configurado.

Reemplace por $HOST el host adecuado:

  • Si se conecta desde dentro del mismo clúster, reemplace por el nombre de servicio especificado (my-new-tls-listener por ejemplo) o el servicio CLUSTER-IP.
  • Si se conecta desde fuera del clúster, el servicio EXTERNAL-IP.

Recuerde especificar métodos de autenticación si es necesario.

Entidad de certificación raíz predeterminada y emisor

Para ayudarle a empezar, operaciones de IoT de Azure se implementa con un certificado de entidad de certificación de "inicio rápido" predeterminado y un emisor para certificados de servidor TLS. Puede usar este emisor para desarrollo y pruebas. Para obtener más información, consulte Entidad de certificación raíz predeterminada y emisor para certificados TLS de servidor.

Para la producción, debe configurar un emisor de CA con un certificado de una CA de confianza, como se describe en las secciones anteriores.

Configuración de TLS con administración manual de certificados

Para configurar manualmente el corredor MQTT para que use un certificado TLS específico, especifíquelo en un recurso BrokerListener con una referencia a un secreto de Kubernetes e impleméntelo mediante kubectl. En este artículo se muestra un ejemplo que configura TLS con certificados autofirmados para las pruebas.

Creación de una entidad de certificación con la CLI de Step

Step es un administrador de certificados que puede ayudarle a ponerse en marcha rápidamente cuando vaya a crear y administrar su propia entidad de certificación (CA) privada.

  1. Instale la CLI de Step y cree un certificado y una clave de entidad de certificación raíz.

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

  2. Cree un certificado y una clave de entidad de certificación intermedia firmados por la entidad de certificación raíz.

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

Creación de un certificado de servidor

Use la CLI de Step para crear un certificado de servidor a partir del firmado por la entidad de certificación intermedia.

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

Aquí, mqtts-endpoint y localhost son los nombres alternativos del firmante (SAN) para el front-end del corredor MQTT en Kubernetes y los clientes locales, respectivamente. Para conectarse a través de Internet, agregue un --san con una dirección IP externa. Las marcas --no-password --insecure se usan para la realización de pruebas a fin de omitir las solicitudes de contraseña y deshabilitar la protección de contraseñas para la clave privada debido a que se almacena en un secreto de Kubernetes. En producción, use una contraseña y almacene la clave privada en una ubicación segura, como Azure Key Vault.

Requisitos del algoritmo de clave de certificado

Se admiten claves EC y RSA, pero todos los certificados de la cadena deben usar el mismo algoritmo de clave. Si importa sus propios certificados de CA, asegúrese de que el certificado de servidor use el mismo algoritmo de clave que las entidades de certificación.

Importación de cadena del certificado raíz como secreto de Kubernetes

  1. Cree una cadena de certificados de servidor completa, donde el orden de los certificados es importante: el certificado de servidor es el primero del archivo, el intermedio es el segundo.

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

  2. Cree un secreto de Kubernetes con la cadena de certificados de servidor y la clave de servidor mediante kubectl.

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

Habilitar la administración manual de certificados TLS para un puerto

A continuación se muestra un ejemplo de un recurso BrokerListener que habilita TLS en el puerto 8884 con la administración manual de certificados.

  1. En Azure Portal, vaya a su instancia de IoT Hub.

  2. En Componentes, seleccione MQTT Broker.

  3. Seleccione o cree un cliente de escucha. Solo puede crear un cliente de escucha por tipo de servicio. Si ya tiene un cliente de escucha del mismo tipo de servicio, puede agregar más puertos al cliente de escucha existente. Para seguir el ejemplo, especifique el nombre del servicio de escucha como mqtts-endpoint.

  4. Puede agregar la configuración de TLS al cliente de escucha seleccionando TLS en un puerto existente o agregando un puerto nuevo.

    Recorte de pantalla con Azure Portal para crear el corredor MQTT para el cliente de escucha del equilibrador de carga con certificados TLS manuales.

    Escriba la siguiente configuración:

    Configuración Descripción
    Port Número de puerto en el que BrokerListener escucha las conexiones MQTT. Necesario.
    Autenticación La referencia de recursos de autenticación.
    Authorization La referencia del recurso de autorización.
    TLS Selecciona el botón Agregar.
    Nombre secreto Secreto de Kubernetes que contiene un certificado de cliente X.509.

  5. Seleccione Aplicar para guardar la configuración de TLS.

Conexión al agente con TLS

Para probar la conexión TLS con el cliente mosquitto, publique un mensaje y pase el certificado de CA raíz en el parámetro --cafile.

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

Recuerde especificar el nombre de usuario, la contraseña etc. Si la autenticación del corredor MQTT está habilitada.

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

Sugerencia

Para usar localhost, el puerto debe estar disponible en la máquina host. Por ejemplo, kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations. Con algunas distribuciones de Kubernetes como K3d, puede agregar un puerto reenviado con k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer.

Nota:

Para conectarse al agente, debe distribuir la raíz de confianza, también conocida como agrupación de confianza, a todos los clientes. En este caso, la raíz de confianza es la CA raíz autofirmada creada por la CLI paso a paso. La distribución de la raíz de confianza es necesaria para que el cliente compruebe la cadena de certificados del servidor. Si los clientes MQTT son cargas de trabajo en el clúster de Kubernetes, también debe crear un ConfigMap con la entidad de certificación raíz y montarlo en el pod.

Uso de una dirección IP externa para el certificado de servidor

Para conectarse con TLS a través de Internet, el certificado de servidor del corredor MQTT debe tener su nombre de host externo o su dirección IP como SAN. En producción, este suele ser un nombre DNS o una dirección IP conocida. Sin embargo, durante la fase de desarrollo/pruebas, es posible que no sepa qué nombre de host o dirección IP externa se ha asignado antes de la implementación. Para resolverlo, implemente primero el agente de escucha sin el certificado de servidor, cree el certificado de servidor y el secreto con la dirección IP externa e importe el secreto al agente de escucha.

Si intenta implementar el cliente de escucha TLS de ejemplo manual-tls-listener pero el secreto de Kubernetes al que se hace referencia server-cert-secret no existe, se crea el servicio asociado, pero los pods no se inician. El servicio se crea porque el operador necesita reservar la dirección IP externa para el cliente de escucha.

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

Sin embargo, se espera este comportamiento mientras importamos el certificado de servidor. Los registros del administrador de mantenimiento mencionan que el corredor MQTT está esperando el certificado de servidor.

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.

Nota:

Por lo general, en un sistema distribuido, los registros de los pods no son deterministas y se deben usar con precaución. La forma correcta para mostrar información como esta es a través de eventos de Kubernetes y del estado de los recursos personalizados, que se encuentra en el trabajo pendiente. Considere el paso anterior como solución temporal.

Aunque los pods del front-end no estén en uso, la dirección IP externa ya está disponible.

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

A partir de aquí, siga los mismos pasos que antes para crear un certificado de servidor con esta dirección IP externa en --san y cree el secreto de Kubernetes de la misma forma. Una vez creado el secreto, este se importa automáticamente en el cliente de escucha.

Contenido relacionado