AKS Artifact Streaming: schnellere Pods, nur per Tag

Robin Werber, Azure und Kubernetes bei Pexon Consulting | 11 Min. Lesezeit | 10.09.2026

TL;DR

AKS Artifact Streaming holt von ACR zuerst die Layer, die der Pod zum Start braucht. OverlayBD macht daraus ein Blockgerät. Große Images und Scale-Events werden schneller bereit. Pull nur per Tag, nicht per Digest. Wer GitOps auf Digest fährt, hat den Feature-Schnitt. Die AKS-Implementierung bleibt die Money-Page.

Welche Query welche URL behält

Kein zweiter Head auf AKS-Beratung, kein zweiter DORA-Text.

Microsoft-Übersicht: Artefaktstreaming auf AKS. Pexon-Meinung: Feature für Cold-Start und Scale, kein Ersatz für Image-Hygiene und kein Freibrief gegen Digest.

Wie OverlayBD den Pull ändert

Klassisch lädt kubelet alle Layer, dann startet der Container. AKS Artifact Streaming löst den Tag auf eine Streaming-Variante auf, die Runtime liest Blöcke nach Bedarf. Wer nur einen Teil des Images nutzt, zieht nur diesen Teil.

Das hilft Java- und C#-Images, die beim Start nicht die ganze Welt brauchen, und Deployments über Regionen hinweg gegen eine Registry. Es hilft nicht, wenn der Prozess eine große Datei sofort liest. Microsoft: Datei über 30 GB als Volume mounten, nicht als Layer backen. Sonst lastet das den Node.

Sie können Original und Streaming-Artefakt parallel in ACR halten. Soft Delete löscht beide, im Portal sehen Sie oft nur das Original. Wer Restore übt, muss das wissen, bevor der Auditor den letzten Restore-Test datiert. Nach dem Abschalten des Features bleiben beide Artefakte erreichbar. Starten können Sie Streaming auf ausgewählten Repos oder Tags, nicht nur auf einer neuen Registry.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo
spec:
  template:
    spec:
      containers:
        - name: app
          # Streaming greift nur, wenn der Pull ein Tag ist
          image: myacr.azurecr.io/app:1.19.4
          # image: myacr.azurecr.io/app@sha256:...  # kein Artifact Streaming

Digest-Pins in GitOps bleiben der Nachweis, wer wann welches Bit deployed hat. AKS Artifact Streaming und immutable Digests schließen sich in der aktuellen Doku aus. Das ist der Production-Gap, nicht die OverlayBD-Technik.

Peer-to-Peer auf den Nodes ist ein anderes Muster. OverlayBD streamt von ACR. Wer P2P erwartet, misst den falschen Pfad.

Tag versus Digest: der eigentliche Architekturkonflikt

GitOps hat in regulierten Clustern den Digest durchgesetzt, weil der Tag lügt. :1.19.4 kann heute ein anderes Manifest sein als gestern. AKS Artifact Streaming will genau diesen Tag, weil nur der Tag auf die Streaming-Variante auflöst.

Das ist kein Bug in der Doku. Es ist die Produktgrenze. Wer Streaming in Prod will, braucht eine bewusste Ausnahme: welche Repos, welche Tags, wer das Tag bewegt, welcher Promotion-Pfad vom Build zum Cluster. Sonst gewinnt :latest wieder, nur mit besserer Ready-Zeit.

Für DORA und interne Revision bleibt der Change-Nachweis Apply, PR und Restore. Der DORA-Landing-Zone-Text hält diesen Head. Dieser Blog erklärt den Pull, nicht die Akte.

Upgrade-Kanäle und Node-OS bleiben ebenfalls woanders. Die sitzen im AKS-Upgrade-Artikel. Streaming verkürzt den Image-Pull. Es patched den Cluster nicht.

Pexon-Meinung: drei Sätze, die in der Architekturentscheidung zählen

1. Messt Time-to-Ready vor und nach dem Flag, auf dem Image, das Sie wirklich fahren. Demo-Images lügen. Ein 80-MB-Alpine zeigt keinen Gewinn. Ein 1,8-GB-Java-Image mit Scale auf 40 Pods schon, wenn der Prozess nicht die ganze Datei beim Start liest.
2. Tag-Pull in Prod ist der alte Bug, den GitOps gerade geschlossen hat. Wenn Sie Streaming wollen, dokumentieren Sie die Ausnahme. Ohne Ausnahme bleibt Digest der Standard, und das Feature bleibt aus.
3. Große Dateien gehören aufs Volume. OverlayBD rettet kein Image, das 30 GB beim Start liest. Das ist Image-Hygiene, nicht ein Registry-Schalter.

Multi-Region gegen eine zentrale ACR ist der zweite sinnvolle Fall: weniger Voll-Replikat, kürzere Wartezeit. Es ersetzt kein Design für den Ausfall der Registry. Wenn ACR weg ist, streamt nichts. Replica und Pull-through bleiben Architektur, Streaming bleibt Start-Hebel.

Was wir in den ersten 90 Minuten messen

Kein Feature-Flag ohne Zahl. Wir nehmen ein reales Workload-Image aus ACR, nicht hello-world. Wir deployen einmal per Digest (Baseline, Streaming tot) und einmal per Tag mit Streaming. Gemessen wird Time-to-Ready, nicht Time-to-Scheduled. Parallel: Node-IO, ob der Prozess große Dateien sofort öffnet, ob Soft-Delete-Restore beide Artefakte kennt.

Danach die Governance-Frage, die der Cluster-Owner beantworten muss: Welches Repo darf Tag-Pull? Wer signed das Tag? Wie kommt das Tag von CI in Git, ohne dass jemand :latest in die Default-YAML schreibt? Wenn diese drei Antworten fehlen, bleibt AKS Artifact Streaming ein Lab-Schalter.

Genau den Sprung von „Feature an“ zu „Cluster, der das trägt“ macht nicht dieser Artikel. Der sitzt auf der Money-Page.

Production-Gap: Tag-Stream ja, Digest-Gate nein

Häufig gestellte Fragen

Geht AKS Artifact Streaming mit Image-Digest?

Nein. Die aktuelle Doku: nur Pull per Tag. Digest löst nicht auf die Streaming-Variante.

Ersetzt Streaming eine Replica der Registry in jeder Region?

Es reduziert die Wartezeit gegen eine zentrale ACR. Es ersetzt kein Design für Ausfall der Registry.

Ist das dasselbe wie Peer-to-Peer auf den Nodes?

Nein. OverlayBD streamt von ACR. Node-lokaler P2P ist ein anderes Muster.

Sollen regulierte Cluster das Feature einschalten?

Nur mit dokumentierter Ausnahme zum Digest. Ohne die Ausnahme bleibt GitOps der Standard.

Zählt Streaming als Performance-Nachweis für DORA?

Als Betriebshebel ja. Als Audit-Beleg für Change brauchen Sie weiter Apply, PR und Restore. Das gehört nicht auf diese URL.

Kann ich Original und Streaming-Artefakt gleichzeitig halten?

Ja. Microsoft erlaubt beides in ACR. Soft Delete löscht beide, das Portal zeigt oft nur das Original. Restore-Tests müssen das abdecken.

Nächster Schritt

Verwandte Themen