
Während die AI-Welt diese Woche von DeepSeek V4 und Qwen 3.6 dominiert wurde, ist auf der Infrastrukturseite ähnlich viel passiert — und für alle, die produktiv KI-Workloads betreiben, wahrscheinlich relevanter. Kubernetes 1.36 macht Workload-Aware Scheduling für AI/ML sichtbar konkreter, Docker liefert mit Sandboxes eine neue Klasse von Agent-Isolation, Vercel schärft Datenrichtlinien im AI Gateway, und Hannover macht "Physical AI" zum Leitkonzept für den DACH-Industriebereich. Hier ist, was du in KW 18 mitnehmen solltest.
Top-Story: Kubernetes v1.36 "Haru" — Workload-Aware Scheduling wird ernst
Am 22. April hat das Kubernetes-Release-Team v1.36 "Haru" (ハル) ausgeliefert — 70 Enhancements, davon 18 stable, 25 beta, 25 alpha. Beigetragen haben 491 Personen aus 106 Unternehmen über einen 15-wöchigen Release-Zyklus. Das Headline-Feature ist Workload-Aware Scheduling (WAS) für AI/ML-Workloads.
Was WAS konkret macht: Kubernetes führt Alpha-Bausteine ein, mit denen zusammengehörige Pods stärker als eine logische Einheit geplant werden können — etwa über Workload- und PodGroup-APIs sowie Scheduling-Zyklen, die eine Gruppe gemeinsam betrachten. Für AI/ML-Workloads ist das relevant, weil Training- und Inference-Jobs oft nicht sinnvoll starten, wenn nur ein Teil der benötigten Pods Ressourcen bekommt. Bisher mussten Teams solche Muster typischerweise mit Volcano, Kueue oder eigenen Operators lösen. Mit v1.36 wandert zumindest der Kern dieser Idee sichtbar in den Kubernetes-Mainstream.
Daneben sind zwei Features GA gegangen, die für Enterprise-Setups direkt relevant sind: Fine-Grained Kubelet API Authorization (24. April) erlaubt detaillierte Berechtigungssteuerung für die Kubelet-API über RBAC — vorbei mit dem groben "alles oder nichts". User Namespaces Support (23. April) ist nach mehreren Release-Zyklen endlich GA und entkoppelt Container-User-IDs vom Host-Namespace. Wer Multi-Tenant-Cluster betreibt, sollte den User-Namespace-Pfad ab sofort einplanen.
Quelle: Kubernetes 1.36 Release · CNCF Blog
Vercel AI Gateway: Zero Data Retention als Team-Policy
Vercel hat Anfang April mit Zero Data Retention (ZDR) auf AI Gateway eine Änderung ausgerollt, die für produktive Agent-Setups sehr relevant ist: Teams können ZDR zentral aktivieren, sodass Requests nur noch über Provider mit ausgehandelten ZDR-Bedingungen geroutet werden.
Zusätzlich gibt es Request-Level-Controls wie Disallow Prompt Training. In Kombination mit teamweiten Policies reduziert das die typischen Fehler in Multi-Provider-Setups: keine manuell verteilten Opt-out-Flags pro Service, weniger Konfig-Drift zwischen Teams, und nachvollziehbare Enforcement-Metadaten pro Response.
Für DACH-Unternehmen ist das vor allem ein Governance-Thema: Wenn sensible Code- oder Dokumentdaten über mehrere Modellanbieter laufen, wird Datenkontrolle schnell unübersichtlich. Ein zentraler Gateway-Layer mit klaren Policies ist hier deutlich robuster als ad-hoc-Settings in einzelnen Anwendungen.
Quelle: Vercel Blog: Zero Data Retention on AI Gateway · Vercel AI Gateway Docs
Docker Sandboxes — microVM-Isolation für Agenten
Docker hat Sandboxes Ende März als neue Produkt-Linie vorgestellt und am 16. April die microVM-Architektur dahinter ausführlicher erklärt. Der Fokus: stärkere Isolation speziell für Agent-Workloads. Klassische Container-Isolation ist für Code-Execution-Szenarien — also Agenten, die fremden Code ausführen und Outputs zurückliefern — oft nicht die Sicherheitsgrenze, die Unternehmen für autonome Workflows haben wollen. Sandboxes positioniert Docker dort, wo bisher gVisor, Firecracker oder Kata Containers im Eigenbau eingesetzt wurden.
Im selben Atemzug hat Docker eine Supply-Chain-Reaktion dokumentiert: Ein malicious Image wurde unter dem Namen checkmarx/kics auf Docker Hub gepusht — Docker hat das Image quarantäniert und gemeinsam mit Socket und Checkmarx eine koordinierte Antwort gefahren. Das ist die zweite große Supply-Chain-Reaktion in zwei Quartalen (Trivy/KICS-Auswertung vom 23. April). Wer Container aus Public-Registries zieht, sollte das Trivy- oder KICS-Scanning-Setup heute vorhanden haben — und zusätzlich OAuth-App-Zugriffe regelmäßig auditieren.
Quelle: Docker Sandboxes · Docker Supply-Chain-Auswertung
GlassWorm — 73 weitere Sleeper-Extensions auf Open VSX
Sicherheitsberichte meldeten im April 73 neue Sleeper-Extensions auf Open VSX, die nach dem GlassWorm-Muster operieren sollen: Beim Install wirkt die Extension harmlos, der bösartige Payload wird erst später aktiviert. Das hebelt Security-Scanner aus, die vor allem auf Install-Zeit-Verhalten prüfen — und es folgt dem 72-Sleeper-Vorfall aus März.
Für DACH-Unternehmen, die VS Code oder ein VS-Code-Fork (Cursor, Windsurf) im Editor-Standard fahren, ist das ein direkter Handlungsanlass. Empfehlung: Editor-Extensions wie Browser-Extensions behandeln — Liste der erlaubten Quellen pflegen, Auto-Update-Verhalten prüfen, regelmäßige Reviews der installierten Extensions, idealerweise zentral verwaltet. Die übergreifende Logik: Drittanbieter-Code in der Editor-Umgebung ist genauso kritisch wie Drittanbieter-OAuth-Apps oder Drittanbieter-Container-Images. Drei Vektoren, ein gemeinsames Auditing-Mindset.
Quelle: The Hacker News · Socket.dev
Windmill April-Update — Workspace-Forking, Service Accounts, Labels
Windmill hat im April einen großen Schub an Workspace- und CLI-Features ausgeliefert, der für jeden, der Workflow-Automation in seine AI-Stacks einbindet, relevant ist:
Workspace-Forking inklusive Data Tables ist dazugekommen — das macht es praktisch möglich, einen Produktiv-Workspace zu klonen, daran zu experimentieren und am Ende per wmill workspace merge zurück zu mergen. Klingt nach Git, fühlt sich auch so an. Service Accounts sind als Automation-Identitäten ohne Login-Pfad verfügbar — der saubere Weg, Windmill-Flows aus CI/CD-Pipelines zu triggern, ohne ein Personen-Token zu missbrauchen. Dazu Debounce-Nodes für Flows (Event-Druck reduzieren), eine unified wmill.yaml workspaces config für die CLI, und Labels auf Scripts/Flows/Apps/Resources/Variables/Schedules/Triggers für Filterung. Wer mehrere parallele Workflow-Familien betreibt — etwa AI-Pipelines, ETL-Jobs und interne Automation — bekommt damit eine vernünftige Sortier-Schicht.
In unserer AI-OpenStack-Lösung nutzen wir Windmill als Workflow-Orchestrator zwischen vLLM, LiteLLM und den nachgelagerten Daten-Connectoren — die Forking-Logik macht das Testen neuer Pipeline-Versionen jetzt deutlich entspannter.
Quelle: Windmill Changelog
Hannover Messe 2026 — Physical AI als Leitkonzept
Vom 20. bis 24. April lief die Hannover Messe 2026 mit rund 2.900 Ausstellern aus über 50 Ländern unter dem Motto "Think Tech Forward". Der dominante Begriff: Physical AI. Statt KI nur als Software-Schicht zu zeigen, war sie breit als Bauteil von Maschinen, Fertigungsstraßen und Wartungssystemen sichtbar — die Schlagwort-Phase ist erkennbar vorbei, die Integrations-Phase läuft.
Mehrere Unternehmen haben humanoide Robotik mit konkreten Industrie-Anwendungsfällen gezeigt — weniger als Konzept-Studien, mehr als Vorboten für Logistik, Montage und Wartung. Aus DACH-Sicht spannender als die Hardware: Die Frage, wie diese Geräte trainiert, gewartet und im Tagesbetrieb gesteuert werden. Genau hier liegt für KMU-Industrie-Kunden der reale Hebel — nicht im Kauf des humanoiden Roboters, sondern im Aufbau einer Stack-Architektur, die solche Systeme mit Bestandsanlagen koppelt. Die eGovernment-Berichterstattung ergänzt: Parallel dazu liefen Formate rund um E-Government und Digitalisierung mit Schwerpunkt KI-Telefonie, Prozessautomatisierung und Dokumentenanalyse für Kommunen — der DACH-Behördensektor zieht hörbar nach.
Quelle: Hannover Messe · eGovernment · Heise Developer
Kurz notiert
- GitLab Patch-Releases 18.11.1, 18.10.4 und 18.9.6 sind am 22. April erschienen — Sicherheits- und Stability-Fixes für die Vorgänger-Versionen. Die nächste Major (18.12) ist Mitte Mai zu erwarten. Quelle: GitLab Patch-Release.
- GitHub Engineering hat Claude Opus 4.7 GA in GitHub Copilot ausgerollt (16. April), dazu den
gh skill-Command für Agent-Skills-Discovery in der CLI und Copilot Auto Model Selection GA. Quelle: GitHub Blog (Engineering). - CNCF warnt in einem Beitrag vom April: "Kubernetes Alone Is Not Enough to Secure LLM Workloads" — Threat-Model für Agent-Systeme ist fundamental anders. Wer LLM-Inference-Workloads naiv neben Webservices schedulet, hat eine Lücke im Risiko-Inventar. Quelle: CNCF Blog.
- Atlassian Rovo Dev hat im April eine ganze Welle an Posts produziert: Rovo Dev mit Claude Opus 4.7 in Atlassian-Kontext, Rovo Dev in Jira (Auto-Complete fürs Backlog), Rovo Chat in Bitbucket mit Pipeline-Verständnis. Atlassian positioniert Rovo als Full-Stack-Agent-Suite — direkt relevant für Teams, die Jira/Bitbucket bereits im Stack haben. Quelle: Atlassian Blog (DevOps).
Fazit
KW 18 hat zwei Verschiebungen sauber sichtbar gemacht: Erstens, die Container- und Cluster-Schicht zieht beim Thema KI nach — Kubernetes 1.36 mit Workload-Aware Scheduling und Docker mit microVM-Sandboxes machen aus dem bisher experimentellen "irgendwie laufen lassen" einen belastbareren Produktionspfad. Zweitens, das Supply-Chain- und Governance-Risiko ist breit geworden: Editor-Extensions (GlassWorm auf Open VSX), Container-Images (checkmarx/kics auf Docker Hub) und Daten-/Provider-Policies im Modell-Routing sind Bausteine derselben Risikofläche. Wer in den nächsten Quartalen Agent-Workflows in Produktion fährt, sollte diese Themen in einem gemeinsamen Audit-Inventar führen — inklusive OAuth-App-Review, statt getrennten Einzelmaßnahmen. Und Physical AI in Hannover war kein Marketing-Buzz, sondern der akzeptierte neue Aggregatzustand: KI verschwindet im Bauteil. Für DACH-Mittelstand und Industrie ist das die Story, die jetzt anschlussfähig wird.
Wenn du Agent-Workflows in Produktion bringen willst, ohne dabei in Supply-Chain- oder Compliance-Fallen zu laufen — wir helfen gerne. Mehr zur DSGVO-konformen Infrastruktur findest du im Agentic-Engineering-Pillar und im aktuellen DeepSeek-V4-On-Premise-Guide.
Kuratiert von SEADEV Studios — jede Woche die wichtigsten Tech-News, eingeordnet für Entwickler und Entscheider.


