[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-content-tech-news-der-woche-kw-18":3},"\u003Cp>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\u002FML 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.\u003C\u002Fp>\n\n\u003Ch2>Top-Story: Kubernetes v1.36 \"Haru\" — Workload-Aware Scheduling wird ernst\u003C\u002Fh2>\n\u003Cp>Am 22. April hat das Kubernetes-Release-Team \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">v1.36 \"Haru\" (ハル)\u003C\u002Fa> 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 \u003Cstrong>Workload-Aware Scheduling (WAS)\u003C\u002Fstrong> für AI\u002FML-Workloads.\u003C\u002Fp>\n\u003Cp>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\u002FML-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.\u003C\u002Fp>\n\u003Cp>Daneben sind zwei Features GA gegangen, die für Enterprise-Setups direkt relevant sind: \u003Cstrong>Fine-Grained Kubelet API Authorization\u003C\u002Fstrong> (24. April) erlaubt detaillierte Berechtigungssteuerung für die Kubelet-API über RBAC — vorbei mit dem groben \"alles oder nichts\". \u003Cstrong>User Namespaces Support\u003C\u002Fstrong> (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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fkubernetes.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Kubernetes 1.36 Release\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">CNCF Blog\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Vercel AI Gateway: Zero Data Retention als Team-Policy\u003C\u002Fh2>\n\u003Cp>Vercel hat Anfang April mit \u003Ca href=\"https:\u002F\u002Fvercel.com\u002Fblog\u002Fzdr-on-ai-gateway\" target=\"_blank\" rel=\"noopener noreferrer\">Zero Data Retention (ZDR) auf AI Gateway\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>Zusätzlich gibt es Request-Level-Controls wie \u003Cstrong>Disallow Prompt Training\u003C\u002Fstrong>. 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fvercel.com\u002Fblog\u002Fzdr-on-ai-gateway\" target=\"_blank\" rel=\"noopener noreferrer\">Vercel Blog: Zero Data Retention on AI Gateway\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fvercel.com\u002Fdocs\u002Fai-gateway\" target=\"_blank\" rel=\"noopener noreferrer\">Vercel AI Gateway Docs\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Cfigure>\n\u003Cimg src=\"\u002Fimages\u002Fblog\u002Fweekly-tech-news-kw18-supply-chain.webp\" alt=\"Macro-Aufnahme von OAuth-, Extensions- und Container-Tokens auf einem PCB — Supply-Chain-Risiko\" loading=\"lazy\">\n\u003C\u002Ffigure>\n\n\u003Ch2>Docker Sandboxes — microVM-Isolation für Agenten\u003C\u002Fh2>\n\u003Cp>Docker hat \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002Fdocker-sandboxes-run-agents-in-yolo-mode-safely\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Sandboxes\u003C\u002Fa> Ende März als neue Produkt-Linie vorgestellt und am 16. April die \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002Fwhy-microvms-the-architecture-behind-docker-sandboxes\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">microVM-Architektur dahinter\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>Im selben Atemzug hat Docker eine \u003Cstrong>Supply-Chain-Reaktion\u003C\u002Fstrong> dokumentiert: Ein malicious Image wurde unter dem Namen \u003Ccode>checkmarx\u002Fkics\u003C\u002Fcode> 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 (\u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Trivy\u002FKICS-Auswertung vom 23. April\u003C\u002Fa>). 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Docker Sandboxes\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.docker.com\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Docker Supply-Chain-Auswertung\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>GlassWorm — 73 weitere Sleeper-Extensions auf Open VSX\u003C\u002Fh2>\n\u003Cp>Sicherheitsberichte meldeten im April \u003Ca href=\"https:\u002F\u002Fthehackernews.com\" target=\"_blank\" rel=\"noopener noreferrer\">73 neue Sleeper-Extensions\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>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: \u003Cstrong>Drittanbieter-Code in der Editor-Umgebung ist genauso kritisch wie Drittanbieter-OAuth-Apps oder Drittanbieter-Container-Images\u003C\u002Fstrong>. Drei Vektoren, ein gemeinsames Auditing-Mindset.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fthehackernews.com\" target=\"_blank\" rel=\"noopener noreferrer\">The Hacker News\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fsocket.dev\" target=\"_blank\" rel=\"noopener noreferrer\">Socket.dev\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Windmill April-Update — Workspace-Forking, Service Accounts, Labels\u003C\u002Fh2>\n\u003Cp>\u003Ca href=\"https:\u002F\u002Fwww.windmill.dev\u002Fchangelog\" target=\"_blank\" rel=\"noopener noreferrer\">Windmill hat im April\u003C\u002Fa> einen großen Schub an Workspace- und CLI-Features ausgeliefert, der für jeden, der Workflow-Automation in seine AI-Stacks einbindet, relevant ist:\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Workspace-Forking inklusive Data Tables\u003C\u002Fstrong> ist dazugekommen — das macht es praktisch möglich, einen Produktiv-Workspace zu klonen, daran zu experimentieren und am Ende per \u003Ccode>wmill workspace merge\u003C\u002Fcode> zurück zu mergen. Klingt nach Git, fühlt sich auch so an. \u003Cstrong>Service Accounts\u003C\u002Fstrong> sind als Automation-Identitäten ohne Login-Pfad verfügbar — der saubere Weg, Windmill-Flows aus CI\u002FCD-Pipelines zu triggern, ohne ein Personen-Token zu missbrauchen. Dazu \u003Cstrong>Debounce-Nodes für Flows\u003C\u002Fstrong> (Event-Druck reduzieren), eine \u003Cstrong>unified \u003Ccode>wmill.yaml workspaces\u003C\u002Fcode> config\u003C\u002Fstrong> für die CLI, und \u003Cstrong>Labels auf Scripts\u002FFlows\u002FApps\u002FResources\u002FVariables\u002FSchedules\u002FTriggers\u003C\u002Fstrong> für Filterung. Wer mehrere parallele Workflow-Familien betreibt — etwa AI-Pipelines, ETL-Jobs und interne Automation — bekommt damit eine vernünftige Sortier-Schicht.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.windmill.dev\u002Fchangelog\" target=\"_blank\" rel=\"noopener noreferrer\">Windmill Changelog\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Hannover Messe 2026 — Physical AI als Leitkonzept\u003C\u002Fh2>\n\u003Cp>Vom 20. bis 24. April lief die \u003Ca href=\"https:\u002F\u002Fwww.hannovermesse.de\" target=\"_blank\" rel=\"noopener noreferrer\">Hannover Messe 2026\u003C\u002Fa> mit rund 2.900 Ausstellern aus über 50 Ländern unter dem Motto \"Think Tech Forward\". Der dominante Begriff: \u003Cstrong>Physical AI\u003C\u002Fstrong>. 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.\u003C\u002Fp>\n\u003Cp>Mehrere Unternehmen haben \u003Cstrong>humanoide Robotik mit konkreten Industrie-Anwendungsfällen\u003C\u002Fstrong> 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 \u003Ca href=\"https:\u002F\u002Fwww.egovernment.de\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">eGovernment-Berichterstattung\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Quelle:\u003C\u002Fstrong> \u003Ca href=\"https:\u002F\u002Fwww.hannovermesse.de\" target=\"_blank\" rel=\"noopener noreferrer\">Hannover Messe\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.egovernment.de\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">eGovernment\u003C\u002Fa> · \u003Ca href=\"https:\u002F\u002Fwww.heise.de\u002Fdeveloper\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">Heise Developer\u003C\u002Fa>\u003C\u002Fp>\n\n\u003Ch2>Kurz notiert\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Cstrong>GitLab Patch-Releases 18.11.1, 18.10.4 und 18.9.6\u003C\u002Fstrong> 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: \u003Ca href=\"https:\u002F\u002Fdocs.gitlab.com\u002Freleases\u002Fpatches\u002Fpatch-release-gitlab-18-11-1-released\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitLab Patch-Release\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>GitHub Engineering\u003C\u002Fstrong> hat \u003Cstrong>Claude Opus 4.7 GA in GitHub Copilot\u003C\u002Fstrong> ausgerollt (16. April), dazu den \u003Cstrong>\u003Ccode>gh skill\u003C\u002Fcode>-Command\u003C\u002Fstrong> für Agent-Skills-Discovery in der CLI und \u003Cstrong>Copilot Auto Model Selection GA\u003C\u002Fstrong>. Quelle: \u003Ca href=\"https:\u002F\u002Fgithub.blog\u002Fcategory\u002Fengineering\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">GitHub Blog (Engineering)\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>CNCF\u003C\u002Fstrong> warnt in einem Beitrag vom April: \u003Cstrong>\"Kubernetes Alone Is Not Enough to Secure LLM Workloads\"\u003C\u002Fstrong> — 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: \u003Ca href=\"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F\" target=\"_blank\" rel=\"noopener noreferrer\">CNCF Blog\u003C\u002Fa>.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Atlassian Rovo Dev\u003C\u002Fstrong> 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\u002FBitbucket bereits im Stack haben. Quelle: \u003Ca href=\"https:\u002F\u002Fwww.atlassian.com\u002Fblog\u002Fdevops\" target=\"_blank\" rel=\"noopener noreferrer\">Atlassian Blog (DevOps)\u003C\u002Fa>.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Ch2>Fazit\u003C\u002Fh2>\n\u003Cp>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\u002Fkics auf Docker Hub) und Daten-\u002FProvider-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.\u003C\u002Fp>\n\n\u003Cp>Wenn du Agent-Workflows in Produktion bringen willst, ohne dabei in Supply-Chain- oder Compliance-Fallen zu laufen — \u003Ca href=\"\u002Fde-at\u002Fcontact\">wir helfen gerne\u003C\u002Fa>. Mehr zur DSGVO-konformen Infrastruktur findest du im \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fagentic-engineering-dsgvo-konform-on-premise-stack\">Agentic-Engineering-Pillar\u003C\u002Fa> und im aktuellen \u003Ca href=\"\u002Fde-at\u002Fblog\u002Fdeepseek-v4-on-premise-dsgvo-konform\">DeepSeek-V4-On-Premise-Guide\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Cp>\u003Cem>Kuratiert von SEADEV Studios — jede Woche die wichtigsten Tech-News, eingeordnet für Entwickler und Entscheider.\u003C\u002Fem>\u003C\u002Fp>\n"]