← Blog Cloud

Kubernetes (AKS) für IoT-Backends: mandantenfähige Architektur für Millionen von Geräten

📅 24. April 2026

Die meisten IoT-Backends beginnen auf Azure App Service. Für die ersten 10.000 Geräte ist das die richtige Wahl: verwaltet, günstig, schnell auslieferbar. Dann bindet ein Kunde an einem Wochenende 250.000 Sensoren ein, die Telemetrie geht von gleichmäßig zu spitzig über, das Team fügt einen Stream-Prozessor, drei weitere APIs, einen langlaufenden Export-Job und einen Reporting-Dienst hinzu. Plötzlich arbeitet App Service gegen Sie.

Dieser Artikel ist die Architektur, die wir bei FSS Technology einsetzen, wenn ein IoT-Produkt die Schwelle überschreitet, ab der Kubernetes sich rechnet. Er behandelt, wann von App Service zu migrieren ist, die AKS-Referenztopologie für IoT, die entscheidenden Mandantenfähigkeits-Entscheidungen, KEDA-gesteuertes Autoscaling auf Service Bus, den Observability-Stack, auf den wir uns standardisieren, GitOps mit Flux, Secret-Management mit Workload Identity, Wahl des Zeitreihenspeichers und die Kostenmuster, die die Plattform im Maßstab von Millionen Geräten nachhaltig halten. Er ergänzt die leichtgewichtigere Pipeline, die wir in unserem Artikel zur IoT-Datenpipeline beschreiben; dies ist, was danach kommt.

Wann App Service für IoT nicht mehr ausreicht

App Service ist ausgezeichnet, bis eines der Folgenden zutrifft:

  • Sie benötigen mehr als 30 Pläne über Regionen hinweg, um Workloads zu isolieren
  • Cold Starts bei Consumption Functions blockieren Echtzeitszenarien
  • Sie betreiben langlebige Stream-Prozessoren, die nicht in das Request/Response-Modell passen
  • Sie benötigen feingranulare CPU-zu-Speicher-Verhältnisse, die App-Service-Tiers nicht bieten
  • Netzwerkrichtlinien, Sidecars oder Service Mesh stehen auf der Roadmap
  • Mandantenisolation erfordert Compute-Grenzen pro Mandant, nicht nur Daten pro Mandant
  • Sie wünschen eine konsistente Parität zwischen lokaler Entwicklung und Produktion (Docker Compose zu Kubernetes ist näher als Docker Compose zu App Service)

Wenn Sie bei drei oder mehr davon nicken, ist AKS die nächste Station. Wenn nur bei einem, beheben Sie das Symptom und bleiben Sie, wo Sie sind. Kubernetes ist nicht kostenlos, und die betriebliche Steuer ist real. Planen Sie mindestens einen Ingenieur ein, der den Clusterbetrieb von Ende zu Ende verantwortet, bevor Sie sich festlegen; „jemand im DevOps wird das schon regeln“ ist kein Plan.

Referenz-AKS-Topologie für IoT

Der Cluster, den wir für produktive IoT-Workloads einsetzen, hat vier logische Ebenen, jede in ihrem eigenen Node Pool mit passenden VM-SKUs.

  • Ingest-Ebene: zustandslose Dienste, die Telemetrie von Azure IoT Hub, MQTT-Brokern und HTTP-Webhooks annehmen. Anfällig für Lastspitzen, latenzempfindlich. Betrieb auf D-Serie-VMs mit aktiviertem Cluster Autoscaler.
  • Verarbeitungsebene: Stream-Prozessoren, Anreicherung, Regel-Engines, Downsampling-Jobs. Durchsatzgebunden. Betrieb auf F-Serie-VMs (compute-optimiert).
  • API-Ebene: REST- und GraphQL-Endpunkte für Mandantenanwendungen, mobile Apps, Partnerintegrationen. Speicherausgewogen. Betrieb auf D-Serie mit HPA auf Basis der Anfragerate.
  • Telemetriespeicher-Ebene: nicht die Datenbank selbst, sondern die Gateway-Dienste, die mit Event Hubs, Azure Data Explorer, Blob und Cosmos DB sprechen. Betrieb auf D-Serie mit angebundenem Speicher mit hohen IOPS, falls lokales Puffern nötig ist.

System-Pods (CoreDNS, kube-proxy, Ingress, Observability) leben in einem dedizierten System-Node-Pool mit mindestens drei Knoten für HA. Betreiben Sie System-Workloads niemals im selben Pool wie Anwendungs-Workloads; ein lauter Mandant sollte niemals in der Lage sein, Ingress zu verdrängen.

Muster: Azure IoT Hub plus AKS

IoT Hub bleibt das richtige Geräte-Gateway, selbst wenn der Rest des Backends auf AKS läuft. Es besitzt Geräteidentität, MQTT/AMQP-Protokollverarbeitung, Device-Twin-Zustand und den Aufruf direkter Methoden. AKS besitzt die Geschäftslogik.

Das Integrationsmuster:

  1. Geräte verbinden sich mit IoT Hub über MQTT 3.1.1 oder MQTT 5
  2. IoT Hub leitet Telemetrie an Event Hubs (Standard-Endpunkt) oder Service-Bus-Topics (gefilterte Routen)
  3. AKS-Workloads konsumieren aus Event Hubs mit dem EventProcessorClient und Checkpointing im Blob-Speicher
  4. Cloud-to-Device-Befehle fließen über IoT Hub via direkte Methoden oder Twin-Desired-Properties zurück
  5. AKS publiziert auf Service Bus für den Fan-out, mit Subscribern pro Mandant oder pro Feature

Dieses Muster ist die natürliche Erweiterung der einfacheren Architektur, die wir im oben verlinkten Artikel zur IoT-Datenpipeline beschreiben. Das Verarbeitungsmodell ist dasselbe; das Laufzeit-Substrat ist mächtiger, und die Grenzen pro Mandant werden durchsetzbar statt bloß angestrebt.

Mandantenfähigkeit: Namespace pro Mandant vs. Cluster pro Mandant

Dies ist die folgenreichste Architekturentscheidung, die Sie treffen werden. Beide Modelle funktionieren; die falsche Wahl wird Sie schmerzlich kosten.

Namespace pro Mandant

Vorteile: günstig, einfach zu betreiben, eine einzige Control Plane zum Upgraden, einfache mandantenübergreifende Analytik. Nachteile: geteilter Cluster-Wirkungsradius, Noisy-Neighbor-Risiko auf der Data Plane, schwieriger, strenge Compliance-Regime zu erfüllen, die Compute-Isolation verlangen, kubelet und apiserver werden zu geteilten Skalierungsengpässen.

Verwenden Sie dies, wenn Mandanten ähnlich groß sind, einander vertrauen (oder Ihnen vertrauen, die Isolation durchzusetzen) und der Wert betrieblicher Einfachheit strenge Isolation überwiegt. Wenden Sie NetworkPolicy, ResourceQuota, LimitRange und Pod Security Admission standardmäßig auf jeden Namespace an.

Cluster pro Mandant

Vorteile: harte Isolation, unabhängige Upgrade-Kadenz, SLOs pro Mandant, einfache Compliance-Geschichte. Nachteile: 5- bis 10-fache Betriebskosten, schwierigere mandantenübergreifende Features, Komplexität des Flottenmanagements (Azure Arc, Cluster API oder Fleet Manager werden zwingend).

Verwenden Sie dies, wenn Mandanten groß genug sind, um den Mehraufwand zu rechtfertigen (typischerweise je 50.000+ Geräte), oder wenn regulatorische Anforderungen es verlangen (Verteidigung, regulierte Pharma, bestimmte Behördenszenarien).

Der Hybrid, den wir üblicherweise einsetzen

Geteilter Cluster mit Namespace-pro-Mandant für den Long Tail, plus dedizierte Cluster für die wenigen großen Kunden, die harte Isolation brauchen oder wollen. Das funktioniert, weil der Plattformcode identisch ist; nur die Deployment-Topologie unterscheidet sich. GitOps macht die Duplizierung handhabbar.

Ingress mit NGINX und AGIC

Für internen Ost-West-Verkehr und Mandanten-Subdomains unter einem gemeinsamen Apex ist der NGINX Ingress Controller der pragmatische Standard: gut verstanden, schnell, unendlich anpassbar. Für Azure-natives Ingress mit WAF und Integration mit Azure Front Door ist der Application Gateway Ingress Controller (AGIC) die richtige Wahl.

Das Muster, das wir für IoT-Backends betreiben, ist AGIC am öffentlichen Rand für WAF- und DDoS-Abdeckung, NGINX im Cluster für Mandanten-Routing und TLS-Terminierung pro Subdomain. Cert-manager mit Let’s Encrypt für automatisierte Zertifikate, ExternalDNS für automatische Azure-DNS-Einträge.

KEDA-Skalierung auf Basis der Service-Bus-Warteschlangentiefe

Horizontal Pod Autoscaler auf CPU-Basis ist für IoT falsch. Rückstau zeigt sich nicht als CPU-Sättigung; er zeigt sich als wachsende Warteschlange. KEDA (Kubernetes Event-driven Autoscaling) liest die Warteschlange und skaliert entsprechend.

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: telemetry-processor-scaler
  namespace: tenant-acme
spec:
  scaleTargetRef:
    name: telemetry-processor
  pollingInterval: 15
  cooldownPeriod: 120
  minReplicaCount: 2
  maxReplicaCount: 60
  triggers:
  - type: azure-servicebus
    metadata:
      queueName: telemetry-ingest
      namespace: fss-prod-sb
      messageCount: "500"
    authenticationRef:
      name: keda-azure-auth
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-azure-auth
  namespace: tenant-acme
spec:
  podIdentity:
    provider: azure-workload
    identityId: a1b2c3d4-...

Die beiden Zahlen, die zählen: messageCount ist das Ziel pro Replica, nicht der Gesamtschwellenwert. Setzen Sie es auf Ihren Steady-State-Durchsatz einer einzelnen Replica, damit KEDA skaliert, um dieses Verhältnis zu halten. cooldownPeriod verhindert Flattern; 120 Sekunden sind ein vernünftiger Standard für IoT, wo Lastspitzen häufig sind.

Für Event Hubs (Telemetrie-Ingest) hat KEDA einen dedizierten Trigger, der auf Partition-Lag statt auf Warteschlangentiefe skaliert. Verwenden Sie ihn; CPU-basierte Skalierung bei Event-Hubs-Consumern ist immer falsch, weil der Consumer IO-gebunden am Broker ist.

Observability: Prometheus, Grafana, OpenTelemetry, Application Insights

Der Stack, auf den wir uns standardisieren, teilt die Verantwortung sauber auf:

  • Metriken: Prometheus scrapt Pods, kube-state-metrics und node-exporter. Langzeitspeicherung in Azure Monitor Managed Prometheus. Visualisierung in Azure Managed Grafana.
  • Logs: Container-Logs an Azure Monitor Container Insights, mit Aufbewahrungsrichtlinien pro Namespace. Anwendungslogs als JSON strukturiert, niemals als Freitext.
  • Traces: OpenTelemetry-SDK in jedem Dienst, OTLP-Exporter an Azure Monitor Application Insights. Sampling zu 100 Prozent bei Fehlern, 1 Prozent bei Erfolg.
  • Synthetisches Monitoring: Application-Insights-Verfügbarkeitstests gegen Mandanten-Subdomains, mit Sonden in mehreren Regionen.

Das Nicht-Verhandelbare: Jedes Log, jede Metrik und jeder Trace trägt die Mandanten-ID als Label oder Attribut. Ohne das können Sie die Frage „Wie geht es Mandant X gerade?“ nicht beantworten – und das ist die wichtigste Frage, wenn etwas brennt.

GitOps mit Flux oder ArgoCD

Manuelles kubectl apply in Produktion ist ein Kunstfehler. GitOps schließt die Schleife: Git ist die Quelle der Wahrheit, der Cluster gleicht sich selbst an Git ab, Drift ist unmöglich, weil er innerhalb von Minuten korrigiert wird.

Flux v2 ist die leichtgewichtigere Wahl und integriert sich über die GitOps-Erweiterung nativ mit AKS. ArgoCD hat eine reichhaltigere UI und bessere Multi-Cluster-Ergonomie. Beide funktionieren; wählen Sie nach Teampräferenz und bleiben Sie dabei.

Das Repo-Layout, das wir verwenden:

fleet/
  clusters/
    prod-weu/
      flux-system/
      infrastructure/    # ingress, cert-manager, KEDA, observability
      tenants/
        acme/
        contoso/
    prod-eus/
      ...
  apps/
    telemetry-processor/
      base/              # Helm chart or kustomize base
      overlays/
        prod/
        staging/
  charts/
    fss-iot-stack/       # umbrella Helm chart, see below

Struktur der Helm-Values

Ein Umbrella-Helm-Chart für die Plattform mit einer Values-Struktur, die Overrides pro Mandant klein hält.

global:
  region: westeurope
  env: prod
  imageRegistry: fssprod.azurecr.io
  workloadIdentity:
    enabled: true
    clientId: ""
  observability:
    otlpEndpoint: https://otel.fss.cc

ingest:
  replicas: 3
  image:
    repository: fss/iot-ingest
    tag: 2.14.0
  resources:
    requests: { cpu: 250m, memory: 512Mi }
    limits:   { cpu: 1,    memory: 1Gi }
  iotHub:
    eventHubEndpoint: ""
    consumerGroup: ingest

processing:
  replicas: 4
  keda:
    enabled: true
    minReplicas: 4
    maxReplicas: 80
    queueName: telemetry-ingest
    targetMessageCount: 500

api:
  replicas: 2
  ingress:
    host: api.tenant.fss.cc
    tlsSecret: api-tls

storage:
  adx:
    cluster: fss-adx-weu
    database: telemetry
  cosmos:
    account: fss-cosmos-weu
    database: device-state

tenants:
  - name: acme
    deviceQuota: 250000
    overrides:
      processing:
        targetMessageCount: 1000

Die Form dieser Values ist ebenso wichtig wie der Inhalt: Jeder Parameter, der pro Mandant variiert, muss unter tenants[].overrides liegen, niemals über das Chart verstreut. Das ist es, was die Plattform wartbar hält, während die Mandantenzahl wächst. Paaren Sie das Chart mit einer Helmfile oder Flux-Kustomization, die Releases pro Mandant aus einer einzigen Quelle der Wahrheit rendert.

Secret-Management mit Azure Key Vault und Workload Identity

Das Einbinden von Verbindungszeichenfolgen als Kubernetes-Secrets über einfache Helm-Values ist das historische Antimuster. Der moderne Ansatz nutzt Azure Workload Identity plus den Secrets Store CSI Driver.

  1. Jeder Workload läuft als Kubernetes-ServiceAccount, verknüpft mit einer Azure Managed Identity
  2. Die Managed Identity hat abgegrenzte Berechtigungen auf einem Key Vault
  3. Secrets werden vom CSI-Treiber als Dateien eingebunden (oder mit Kubernetes-Secrets synchronisiert), mit automatischer Rotation
  4. Keine langlebigen Anmeldedaten liegen im Cluster, in Git oder in Pipelines

Kombiniert mit privaten Endpunkten auf dem Key Vault und IP-beschränktem Zugriff erfüllt dies selbst strenge Compliance-Prüfungen, ohne den Anwendungsteams betriebliche Komplexität aufzubürden.

Datenbankwahl für Zeitreihen

Azure Data Explorer (ADX)

Unser Standard für IoT-Telemetrie über 1 Milliarde Ereignisse pro Monat. ADX nimmt mit extremen Raten auf (wir haben nachhaltige 1,2 Millionen Ereignisse pro Sekunde auf einem bescheidenen Cluster gemessen), KQL ist ausgezeichnet für Zeitreihenanalytik, und es integriert sich nativ mit Event Hubs als Streaming-Quelle. Die Kosten skalieren mit Clustergröße und Aufbewahrung, nicht mit dem Abfragevolumen. Paaren Sie ADX mit materialisierten Views für die üblichen Dashboard-Abfragen; die First-Byte-Latenz bei einer 30-Tage-Aggregation sinkt von Sekunden auf zehner Millisekunden.

TimescaleDB

Die richtige Wahl, wenn Telemetrie in einem relationalen Speicher mit Fremdschlüsseln zu operativen Daten leben muss oder wenn SQL eine harte Anforderung für nachgelagerte Konsumenten ist. Betreiben Sie es auf Azure Database for PostgreSQL Flexible Server oder selbst gehostet auf AKS für volle Kontrolle. Hypertables und Continuous Aggregates decken die meisten Cold-Storage- und Downsampling-Bedürfnisse ab.

InfluxDB und andere

InfluxDB ist für kleinere Deployments unter 100 Millionen Ereignissen pro Monat in Ordnung. ClickHouse ist beim Durchsatz mit ADX konkurrenzfähig, erfordert aber mehr betriebliche Verantwortung. Cosmos DB mit dem Zeitreihenmuster funktioniert für Szenarien mit niedriger Kardinalität, wird im IoT-Maßstab aber schnell teuer.

Muster zur Kostenoptimierung

Fünf Hebel bewegen die Rechnung mehr als alles andere.

  1. Richtig dimensionierte Node Pools: F-Serie für Compute, D-Serie für ausgewogen, E-Serie für speicherlastig. Das Mischen von SKUs über Pools hinweg reduziert Überprovisionierung.
  2. Spot-Node-Pools für zustandslose Verarbeitung: KEDA-gesteuerte Verarbeitungsebenen laufen hervorragend auf Spot mit 60 bis 80 Prozent Kostenreduktion. Halten Sie stets eine Nicht-Spot-Baseline für Resilienz vor.
  3. Reserved Instances und Savings Plans: 1-Jahres- und 3-Jahres-Verpflichtungen für den Baseline-Node-Pool. Typischerweise 30 bis 40 Prozent Ersparnis.
  4. Gestufter Telemetriespeicher: heiß in ADX für 30 Tage, warm als Parquet im Blob für 1 Jahr, kalt im Archiv-Blob darüber hinaus. ADX-External-Tables machen die kalte Ebene bei Bedarf abfragbar.
  5. Egress-Disziplin: Halten Sie den Verkehr in der Region, nutzen Sie private Endpunkte, um öffentliche Egress-Gebühren zu vermeiden, bündeln Sie nachgelagerte Schreibvorgänge, um Kosten pro Operation zu senken.

Für eine typische mandantenfähige IoT-Plattform, die 1 bis 2 Millionen Geräte bedient, senken diese Muster kombiniert die Run-Rate gegenüber einem naiven Deployment um etwa die Hälfte. Wir sehen stationäre monatliche Kosten im Bereich von 12.000 bis 22.000 EUR für diesen Maßstab, dominiert von ADX und Egress, nicht von Compute.

Checkliste für operative Exzellenz

  • Cluster Autoscaler aktiviert mit sinnvollem Min und Max pro Pool
  • Pod Disruption Budgets auf jedem Workload
  • Liveness-, Readiness- und Startup-Probes korrekt unterschieden
  • NetworkPolicy als Default-Deny mit expliziten Allow-Regeln
  • Image-Scanning in der CI, Image-Signierung mit Notation, Admission Control mit Ratify oder Kyverno
  • Backup zustandsbehafteter Workloads mit Velero, getestete Wiederherstellungen vierteljährlich
  • Disaster-Recovery-Runbook mit dokumentiertem RTO und RPO pro Mandanten-Tier

Keines davon ist optional im Maßstab, den dieser Artikel voraussetzt. Die Muster, die wir über unsere umfassendere DevOps-Praxis und die Cloud-Grundlagen, die wir Kunden anbieten, hinweg anwenden, sind um sie herum gebaut. Dieselbe Control Plane betreibt die Backends hinter YIS und OMNIYON; die Muster sind unter echter Flottenlast feldgetestet.

Alles zusammengeführt

AKS ist kein Allheilmittel; es ist ein Substrat, das – mit Disziplin eingesetzt – einer IoT-Plattform erlaubt, von einem Mandanten auf Hunderte und von Tausenden Geräten auf Millionen zu skalieren, ohne das Backend neu zu schreiben. Die Muster in diesem Artikel (Trennung der Ingest-Ebene, KEDA auf Warteschlangentiefe, GitOps, Workload Identity, ADX für Telemetrie, gestufter Speicher und Spot für die Verarbeitung) machen den Unterschied zwischen einem funktionierenden Kubernetes-Cluster und einem betrieblichen Albtraum.

Wenn Sie ein IoT-Produkt betreiben, das App Service entwachsen ist, oder wenn Sie eine neue Plattform entwerfen, die vom ersten Tag an skalieren muss, kann das Team von FSS Cloud Infrastructure AKS-basierte IoT-Backends von Ende zu Ende architektieren, bereitstellen und betreiben. Wir haben diesen Stack für Hospitality-Gruppen, Marineflotten und Industriebetreiber ausgeliefert, und wir bieten ihn als verwaltete Plattform oder als einmaliges Projekt an, um Ihr Team in die Produktion zu bringen. Sprechen Sie mit uns über eine einwöchige Architekturprüfung, bevor Sie sich auf einen Weg festlegen.