6 min read · 12 sources

Datadog führt eine leichte Stufe ein, um die Host‑Überwachungskosten in Staging‑Umgebungen zu senken, während die Kubernetes‑Maintainer das Verhaltens‑Drift von Workloads endlich als upstream Test‑Bug behandeln. Gleichzeitig hat sich die Obergrenze für dauerhafte Ausführungen auf klassischen relationalen Engines dramatisch nach oben verschoben.

Wer in den letzten drei Jahren sekundäre Flotten auf Basis von reinen Metrik‑Daemons betrieben hat, um Agent‑Steuern zu vermeiden, oder jedes Mal eigene Test‑Matrizen neu aufgebaut hat, wenn ein EKS‑Minor‑Release ausgerollt wurde, findet heute konkrete upstream‑ und Plattform‑Updates.

Advisory Locks eliminierten eine kaskadierende Kontention‑Schleife und ermöglichten es 50 PostgreSQL‑Shards, sauber von 20 000 auf eine Million dauerhafte Workflows pro Sekunde zu skalieren.

Datadog teilt die Agent‑Kosten mit Infrastructure Basic

Source: datadoghq.com ↗

Datadog hat Infrastructure Basic veröffentlicht, eine Monitoring‑Option der unteren Stufe, die sich an nicht‑kritische Infrastruktur, interne Tools und Staging‑Instanzen richtet. Die Stufe betreibt den Standard‑Datadog‑Agent in einem abgespeckten Modus und sammelt grundlegende Host‑Telemetry: CPU, Speicherauslastung, Festplattennutzung, Festplatten‑I/O, Netzwerk‑Statistiken, System‑Uptime, System‑Load und einfachen Prozess‑Status.

Entscheidend ist, dass die unter Infrastructure Basic gesammelten Metriken eine Voll‑Auflösung‑Retention von 15 Monaten behalten, was den High‑Tier‑Plänen für die Jahres‑Kapazitäts‑Planung entspricht. Sie beinhaltet Standard‑Alert‑Profile und sofort einsatzbereite Dashboards sowie Integrationen mit Incident‑Plattformen wie PagerDuty und ServiceNow. Teams können Basic neben Pro‑ und Enterprise‑Agenten innerhalb derselben Organisation betreiben, sodass Operatoren nicht mehr separate Prometheus‑ oder Telegraf‑Stacks bereitstellen müssen, um bei Entwicklungs‑Boxen die Voll‑Suite‑Preise zu umgehen.

Kubernetes startet Workload Conformance Working Group

Source: kubernetes.io ↗

Jeder Kubernetes‑Operator kennt den Schmerz, wenn eine API‑Version ein Minor‑Upgrade überlebt, während das Laufzeit‑Verhalten des Workloads stillschweigend abnimmt. Upstream adressiert diese Lücke direkt mit der Workload Conformance Working Group.

Historisch validierten Kubernetes‑Conformance‑Tests, ob ein Infrastruktur‑Provider die Control‑Plane und API‑Spezifikationen korrekt implementiert hat. Sie garantierten nie, dass identische Pod‑Spezifikationen über Versionen hinweg identisch laufen während Node‑Drains, Netzwerk‑Wechsel oder Ressourcen‑Erschöpfung. Die neue Arbeitsgruppe erarbeitet eine Laufzeit‑Verhaltens‑Spezifikation über sieben Bereiche:

• Security‑Contexts und Privilegien‑Escalations‑Grenzen
• Workload‑Resilienz bei Node‑Störungen und Eviction
• Ressourcen‑Scheduling und cgroup‑Limits
• Netzwerk‑Namespace‑Routing und Service‑Auflösung
• CSI‑Volume‑Anbindung und Lebenszyklus‑Garantie
• Controller‑API‑Nutzungsmuster
• Standardisierte Laufzeit‑Observierbarkeit

Die WG plant, innerhalb von zwei bis drei Release‑Zyklen einen binären Test‑Harness für upstream CI zu veröffentlichen. Ziel ist einfach: kontinuierliche, reproduzierbare Conformance‑Tests, die Verhaltens‑Änderungen abfangen, bevor ein Upgrade den Traffic‑Routing oder die graceful‑Pod‑Termination in Produktion bricht.

Supabase Compute verlagert Agenten in die Datenbank‑Grenze

Source: supabase.com ↗

Supabase hat das private Alpha von Supabase Compute in us-west-2 angekündigt. Der Service stellt langlaufende Container neben verwalteten Datenbank‑Instanzen bereit und richtet sich an langlebige Aufgaben, die die Ausführungs‑Grenzen von Edge‑Functions überschreiten - etwa kontinuierliche Hintergrund‑Synchronisationen, benutzerdefinierte HTTP‑Endpoints und autonome Agenten.

Container werden über das Supabase‑CLI (v2.120.0+) bereitgestellt, mit aktuellen Größenoptionen von 2 GB RAM / 1 vCPU oder 4 GB RAM / 2 vCPU. Dienste erben automatisch Projekt‑Secrets, Netzwerk‑Bindings und Log‑Drains. Für datenintensive Operationen vermeidet die physische Co‑Location TLS‑Handshakes über Regionen hinweg: interne Tests zeigten, dass Daten‑Agent‑Abfrage‑Latenzen von 65 ms über Regionen auf einen Median von 2,9 ms bei lokaler Compute‑Ausführung sanken. Autoscaling fehlt im Alpha, sodass Workloads für Evaluierungszwecke an statische Profile gebunden bleiben.

Skalierung von GitOps: Ein Argo CD‑Hub für 34 Cluster

Source: cloudnativenow.com ↗

Das Management von Multi‑Tenant‑Kubernetes via GitOps degeneriert häufig zu ausufernden Credential‑Stores und Cluster‑Konfigurations‑Drift. Ein Produktions‑Retrospektive von Nitish Mane zu managing 34 clusters with a single Argo CD hub beschreibt, wie das Flotten‑Wachstum über 22 AWS‑Accounts und ein Oracle‑Cloud‑Mandat gezähmt wird.

Die Einrichtung steuert 1 214 Argo CD Application‑Objekte, die aus 174 gemeinsam genutzten Helm‑Charts über eine zentrale Control‑Plane bezogen werden. Anstatt für jedes Ziel individuelle Manifeste zu embedden, reduziert sich das Cluster‑Onboarding auf einen knappen deklarativen Vertrag von etwa 20 YAML‑Schlüsseln. Kurzlebige Cross‑Account‑IAM‑Rollen übernehmen die Cluster‑Authentifizierung und eliminieren statische kubeconfig‑Tokens in der Control‑Plane. Durch die Kombination von Pre‑Merge‑CI‑Manifest‑Diffs mit expliziten Prune‑Schutzmechanismen verkürzte das Engineering‑Team die Onboarding‑Zeit von vier Arbeitstagen auf 1,7 Stunden, ohne das Risiko versehentlicher kaskadischer Löschungen.

Self‑Service‑Infrastructure via Backstage und Terraform

Source: spacelift.io ↗

Engineering‑Teams, die Plattform‑Self‑Service anbieten wollen, ohne ihre State‑Files für beliebige Änderungen zu öffnen, können sich Spacelift’s Blueprint für integrating Terraform with Spotify’s Backstage anschauen.

Die Architektur nutzt Backstage ausschließlich als Katalog‑Front‑End und Parameter‑Sammellayer. Wenn ein Entwickler über Backstage Software‑Templates eine RDS‑Datenbank oder einen S3‑Bucket anfordert, führt das Portal Terraform‑Befehle nicht direkt aus. Stattdessen erzeugt es einen Pull‑Request mit standardisiertem HCL gegen das Plattform‑Repository. Das Spacelift‑Plugin stellt den resultierenden spekulativen Plan und den Run‑Status innerhalb der Backstage‑UI dar. So bleibt Git das unveränderliche Audit‑Log, während State‑Management, Drift‑Detection und OPA‑Policy‑Evaluation der dedizierten CI/CD‑Pipeline überlassen werden.

DBOS benchmarked 1 000 000 dauerhafte Workflows pro Sekunde auf Postgres

Source: dbos.dev ↗

Der Aufbau dauerhafter, verteilter Ausführungs‑Engines erfordert meist dedizierte Koordinations‑Systeme wie Temporal oder spezialisierte Event‑Buses. DBOS zeigte, dass vanilla PostgreSQL über 1 000 000 Workflows pro Sekunde ausführen kann durch horizontales Sharding über 50 db.m7i.4xlarge AWS RDS‑Instanzen (je 16 vCPUs, 64 GB RAM).

Die Ingestion‑ und Execution‑Schicht setzte 48 gleichzeitige Worker pro Shard ein und verarbeitete 20 000 Workflow‑Operationen pro Sekunde pro Datenbank‑Node, wobei PgDog das Connection‑Pooling übernahm. Der primäre Engpass war eine kaskadierende Kontention‑Schleife: Sobald ein einzelner Postgres‑Node einen kurzen I/O‑Hickup erlitt, stockten Worker‑Prozesse, enqueueten redundante Dequeue‑Transaktionen und lösten massive Row‑Level‑Lock‑Kontention auf der Workflow‑Tabelle aus.

Ingenieure stabilisierten das System, indem sie Postgres‑Advisory‑Locks einsetzten, um gleichzeitige Dequeue‑Routinen zu drosseln. Mit strikt begrenzten Verbindungen skalierte der Durchsatz linear von 20 000 Writes auf einer einzelnen Instanz zu einer flachen 1 000 000 dauerhaften Ausführungen über die gesamte Flotte.

+-------------------------------------------------------------+
|                      DBOS Worker Fleet                      |
|           (PgDog Connection Pooling & Advisory Locks)       |
+-------------------------------------------------------------+
        |                    |                    |
        v                    v                    v
+----------------+   +----------------+   +----------------+
| RDS Instance 1 |   | RDS Instance 2 |   | RDS Instance 50|
| 20k ops/sec    |   | 20k ops/sec    |   | 20k ops/sec    |
+----------------+   +----------------+   +----------------+
        |                    |                    |
        +--------------------+--------------------+
                             |
                 1,000,000 Workflows / sec

Die Rest‑Risiken bei GitHub Actions pwn‑Requests

Source: wiz.io ↗

Wiz veröffentlichte eine Analyse zum Stand der pull_request_target‑Vulnerabilities nach GitHubs Plattform‑Härtungs‑Rollout. GitHub hat mehrere unsichere Defaults adressiert: actions/checkout@v7 blockiert standardmäßig das Checkout untrusted Fork‑Heads, Token‑Cache‑Kontrollen sind nun read‑only, und Sicherheitspatches wurden auf Checkout‑Tags v2 bis v6 zurückportiert. Am 2. Dezember wird GitHub eine Standard‑Richtlinie durchsetzen, die die Nutzung von pull_request_target in öffentlichen Repositories vollständig blockiert.

Gefährliche Ausweichmöglichkeiten bleiben jedoch:

• Unveränderliches Commit‑Pinning: Teams, die Aktionen auf vollständige Commit‑SHAs vor dem Juli 2026‑Backport festlegen, erhalten das gepatchte Checkout‑Verhalten nicht.
• Alternative Trigger: Angreifer zielen auf Pipelines, die durch issue_comment oder workflow_run ausgelöst werden und weiterhin Schreibrechte sowie Zugriff auf Repo‑Secrets besitzen, ohne die Beschränkungen von pull_request_target.
• Private Repositories: Der geplante Block am 2. Dezember betrifft nur öffentliche Repositories. Interne Unternehmens‑Organisationen bleiben gegenüber interner lateraler Bewegung über geforkte Repos exponiert.

Das Auditing von CI‑Konfigurationen auf manuelle Git‑Checkouts oder nachgelagerte Auswertungen untrusted Expressions wie ${{ github.event.comment.body }} bleibt verpflichtend.

Automation und Isolation kurz gefasst

Source: github.blog ↗

• GitHub Agentic Workflows GA: GitHubs Agentic Workflows sind jetzt allgemein verfügbar. Die Plattform lässt Ingenieure task‑orientierte Coding‑Agenten in Repository‑Markdown‑Dokumenten definieren, die zu GitHub Actions YAML kompiliert werden. Das System unterstützt selbstgehostete Action Runner Controller (ARC) Deployments, Docker‑in‑Docker‑Isolation und Netzwerk‑Egress‑Sandboxing, um automatisierte CI‑Debug‑Agenten zu isolieren.
• AWS EKS Fargate Interna: Ein Deep‑Dive in die EKS Fargate‑Architektur zerlegt das Single‑Pod‑Isolation‑Modell. Statt Pods auf gemeinsam genutzten Multi‑Tenant‑Instanzen zu packen, nutzt Fargate einen eigenen mutierenden Admission‑Webhook, der geplante Pods zu einem internen Scheduler umleitet. Der Scheduler stellt eine microVM mit einer dedizierten Elastic Network Interface (ENI) bereit, die direkt dem Kunden‑VPC zugewiesen wird und so Node‑Level‑Noisy‑Neighbour‑ sowie Container‑Breakout‑Risiken an der Hypervisor‑Grenze eliminiert.
• OpenTelemetry GenAI Conventions: Splunks Beitrag zur Standardisierung von AI‑Observability zeigt, dass OpenTelemetry‑GenAI‑Conventions als gemeinsames Format für LLM‑Evaluation entstehen. Die Standardisierung von Conversation‑Spans, Token‑Tracking und Latenz‑Metriken unter OpenTelemetry verhindert Vendor‑Lock‑In bei kommerziellen Inference‑Endpoints.
• Macro: Das Open‑Source‑Projekt Macro veröffentlichte seinen SolidJS‑ und Rust‑Code. Aufbauend auf einer einheitlichen bidirektionalen Graph‑Datenbank verknüpft es Nachrichten, Dokumentation, Ticketing und Tasks in einem traversierbaren Schema, das automatisierten Assistenten vollständigen Kontext ohne mehrere SaaS‑Integrationen liefert.
• DeepTutor: Die Open‑Source‑Engine DeepTutor brachte Version 1.7.0 heraus, fügte modulare Installationen, resumable Vector‑Embeddings für lange Dokumente und native Gemini‑Speech‑Streaming hinzu und stellt lokale Orchestrierungs‑Komponenten für multimodale interne Trainings‑Umgebungen bereit.