Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Esta referencia proporciona el consumo medido de recursos de línea base para Operaciones de IoT de Azure implementaciones inactivas (sin cargas de trabajo activas). Use estos perfiles para validar que el hardware cumple los requisitos mínimos y establecer líneas base de supervisión de recursos.
Visión general
Operaciones de IoT de Azure implementa varios componentes en varios espacios de nombres de Kubernetes. La superficie total de recursos depende de dos factores: el perfil de memoria del agente MQTT (que controla la asignación de memoria por pod) y la cardinalidad del agente (número de réplicas de front-end, particiones de back-end y factor de redundancia, que controla cuántos pods se implementan). Una mayor cardinalidad implica más pods, y un perfil de memoria más alto implica que cada pod utiliza más memoria.
Se midieron tres configuraciones en clústeres de nodo único inactivos (sin recursos conectados, sin flujos de datos activos, tráfico casi cero). Estos son números de línea base, no máximos. Las cargas de trabajo de producción aumentan significativamente el consumo:
| Configuration | Perfil de memoria | Cardinalidad | Memoria máxima del nodo | RSS máximo de espacio de nombres de Operaciones de IoT de Azure | RSS máximo de pods totales | Número de pods |
|---|---|---|---|---|---|---|
| Configuración A | Pequeño | 1 front-end 1 partición factor de redundancia 2 |
~4,979 MiB | ~1,298 MiB | ~5.409 MiB | 55 |
| Config. B | Bajo | 2 front-ends 2 particiones factor de redundancia 2 |
~5,130 MiB | ~1,559 MiB | ~5,695 MiB | 58 |
| Configuración de C | Medio | 2 front-ends 2 particiones factor de redundancia 2 |
~6.088 MiB | ~2.407 MiB | ~6,564 MiB | 58 |
Note
La diferencia entre la configuración A y la configuración B se debe tanto a una mayor cardinalidad (más pods de broker) como a un perfil de memoria diferente. La diferencia entre config B y Config C es puramente del perfil de memoria (misma cardinalidad, mismo número de pods). Consulte Ejemplos de despliegue en producción para ver escenarios preconfigurados.
Desglose del espacio de nombres
En la tabla siguiente se muestra la memoria RSS máxima por espacio de nombres en las tres configuraciones inactivas:
| Namespace | Configuración A, diminuta (MiB) | Configuración B, baja (MiB) | Configuración C, media (MiB) | Descripción |
|---|---|---|---|---|
| azure-iot-operations | 1,298 | 1,559 | 2,407 | Servicios principales de Operaciones de IoT de Azure (intermediario de mensajes, flujos de datos, conectores, observabilidad) |
| azure-arc | 1,964 | 1,985 | 1,990 | agentes y controladores de Azure Arc |
| cert-manager | 1,351 | 1,357 | 1,362 | Administración de certificados |
| gatekeeper-system | 338 | 338 | 350 | Aplicación de directivas |
| azure-extensions-usage-system | 279 | 277 | 278 | Operador de facturación |
| arc-workload-identity | 90 | 90 | 91 | Webhooks de identidad de carga de trabajo |
| azure-secret-store | 87 | 88 | 87 | Controlador de sincronización de secretos |
| Total | ~5.409 | ~5.695 | ~6,564 |
Note
- Azure Arc, cert-manager, gatekeeper y otros espacios de nombres de infraestructura consumen ~3,8-4,1 GB independientemente de la configuración del broker. Esta sobrecarga es el costo fijo de ejecutar un clúster habilitado para Arc con Operaciones de IoT de Azure.
-
Solo el
azure-iot-operationsespacio de nombres varía en función del perfil de memoria y de las opciones de cardinalidad, de ~1,3 GB (pequeño, cardinalidad mínima) a ~2,4 GB (mediano, cardinalidad más alta). - Prevea al menos 6 GB de memoria dedicados a la infraestructura de Operaciones de IoT de Azure en inactividad antes de tener en cuenta cualquier carga de trabajo.
Consumo de recursos del pod del broker MQTT
El bróker MQTT es el mayor componente variable. Las diferencias de memoria entre las configuraciones proceden del perfil de memoria (asignación por pod) y de la cardinalidad (número de pods). En la tabla siguiente se muestra RSS inactivo por pod. Estos números crecen con el tráfico:
| Pod | Configuración A, diminuta (MiB) | Configuración B, baja (MiB) | Configuración C, media (MiB) | Notas |
|---|---|---|---|---|
| aio-broker-frontend-0 | 29 | 33 | 169 | La memoria por pod escala con el perfil |
| aio-broker-frontend-1 | N/A | 33 | 169 | No está presente en la configuración A (una réplica de front-end) |
| aio-broker-backend-1-0 | 41 | 66 | 211 | La memoria por pod escala con el perfil |
| aio-broker-backend-1-1 | 41 | 65 | 210 | Réplica de factor de redundancia |
| aio-broker-backend-2-0 | N/A | 66 | 212 | No está presente en la configuración A (una partición) |
| aio-broker-backend-2-1 | N/A | 65 | 211 | No está presente en la configuración A (una partición) |
| aio-broker-health-manager-0 | 41 | 41 | 42 | Constante en todos los perfiles |
| aio-broker-operator-0 | 60 | 60 | 56 | Constante en todos los perfiles |
| aio-broker-diagnostics-probe-0 | 24 | 43 | 43 | |
| aio-broker-diagnostics-service-0 | 49 | 66 | 66 | |
| aio-broker-authentication-0 | 24 | 24 | 24 | Constante en todos los perfiles |
| aio-broker-webhook-0 | 33 | 35 | 32 | Constante en todos los perfiles |
Configuración del broker probada para cada perfil
| Configuración | Configuración A (diminuta) | Configuración B (baja) | Configuración C (media) |
|---|---|---|---|
| Réplicas de interfaz | 1 | 2 | 2 |
| Particiones del servidor | 1 | 2 | 2 |
| Factor de redundancia de back-end | 2 | 2 | 2 |
| Pods de broker totales | 10 | 13 | 13 |
| Memoria del front-end en reposo por pod | ~29 MiB | ~33 MiB | ~169 MiB |
| Memoria inactiva del back-end por pod | ~41 MiB | ~66 MiB | ~211 MiB |
| Tamaño máximo del mensaje | 4 MB | 16 MB | 64 MB |
Otro consumo de componentes de Operaciones de IoT de Azure
Estos componentes tienen un uso coherente de recursos inactivos independientemente del perfil de memoria o la cardinalidad:
| Componente | RSS máximo (MiB) | CPU máxima (núcleos) | Notas |
|---|---|---|---|
| adr-schema-registry (x2) | ~52 cada | 0,002 | Pods de registro de esquema |
| aio-akri-operator-0 | ~39 | 0.001 | Detección de dispositivos Akri |
| aio-akri-adr-service-0 | ~30 | 0.001 | Servicio Akri Azure Device Registry (ADR) |
| aio-dataflow-dev-0 | ~67 | 0,002 | Tiempo de ejecución del flujo de datos |
| aio-dataflow-operator-0 | ~56 | 0.001 | Operador de flujo de datos |
| aio-operator | ~114 | 0.003 | operador de Operaciones de IoT de Azure |
| aio-observability (x2) | ~125 cada uno | 0.005 | Colectores de OpenTelemetry |
| aio-observability-operator | ~106 | 0.003 | Operador de observabilidad |
| aio-observability-cluster-metrics-agent | ~114 | 0.004 | Agente de métricas |
| aio-wasm-graph-controller-0 | ~30 | 0.001 | Controlador de grafos WebAssembly (WASM) |
Consumo de CPU
El consumo de CPU es mínimo inactivo en todas las configuraciones probadas:
| Configuration | CPU máximo de espacio de nombres de Operaciones de IoT de Azure | CPU máximo de clúster total | % de nodo |
|---|---|---|---|
| Configuración A (diminuta) | 0,025 núcleos | 0,099 núcleos | 1,3 % |
| Configuración B (baja) | 0,044 núcleos | 0,104 núcleos | 1,3 % |
| Config C (Medio) | 0,048 núcleos | 0,093 núcleos | 1,2 % |
El uso de CPU es insignificante en estado inactivo. En carga de producción, cabe esperar un consumo de CPU significativamente mayor, proporcional al volumen de mensajes y al número de trabajos de front-end y back-end configurados.
Guía de ajuste de tamaño de hardware
En función de estas medidas de línea base inactivas, se aplican las siguientes recomendaciones mínimas de hardware para las implementaciones de un solo nodo. Los requisitos reales son mayores en el tráfico de producción:
| Perfil de memoria | RAM mínima (con margen) | RAM recomendada | Caso de uso |
|---|---|---|---|
| Diminuto | 8 GB | De 8 a 10 GB | Tráfico bajo, solo paquetes pequeños |
| Bajo | 10 GB | De 12 a 16 GB | Memoria limitada, paquetes pequeños |
| Medium | 12 GB | 16-32 GB | Moderación del tráfico y los tamaños de mensaje |
| High | 16 GB | Más de 32 GB | Alto rendimiento, mensajes grandes |
Important
Estas recomendaciones tienen en cuenta los ~4 GB de sobrecarga fija de la infraestructura (Azure Arc, cert-manager, gatekeeper), además de la huella variable de los componentes de Operaciones de IoT de Azure. Las cargas de trabajo de producción requieren un margen adicional para el almacenamiento en búfer de los mensajes MQTT, el procesamiento de flujo de datos y la actividad del conector OPC UA.