{ "version": "https://jsonfeed.org/version/1.1", "title": "Industry News | ayedo", "home_page_url": "https://ayedo.de/", "feed_url": "https://ayedo.de/news/", "description": "Aktuelle Nachrichten aus der Cloud-Native, Kubernetes und DevOps Welt. Automatisch aggregiert und auf Deutsch zusammengefasst.", "icon": "https://ayedo.de/ayedo-logo-color.png", "favicon": "https://ayedo.de/ayedo-logo-color.png", "authors": [ { "name": "Fabian Peter", "url": "https://www.linkedin.com/in/derfabianpeter/" } ], "language": "de", "items": [{ "id": "https://ayedo.de/news/building-a-cluster-aware-ai-agent-with-kubernetes-argo-cd-and-gitops/", "url": "https://ayedo.de/news/building-a-cluster-aware-ai-agent-with-kubernetes-argo-cd-and-gitops/", "title": "Erstellung eines clusterbewussten KI-Agenten mit Kubernetes, Argo CD und GitOps", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer Artikel beschreibt die Implementierung eines clusterbewussten KI-Agenten innerhalb eines \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clusters\u003c/a\u003e, der ohne externe Cloud-Dienste betrieben wird. Der Agent verwendet lokale Daten und ein Large Language Model (LLM), um spezifische Diagnosen und Analysen durchzuführen, während die gesamte CI/CD-Pipeline durch GitHub Actions und \u003ca href=\"/kubernetes/\"\u003eArgo CD\u003c/a\u003e gesteuert wird.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung eines clusterbewussten KI-Agenten stellt einen innovativen Ansatz dar, um KI-Funktionalitäten direkt innerhalb eines \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clusters\u003c/a\u003e zu implementieren. Im Gegensatz zu herkömmlichen „AI for Kubernetes“-Tools, die externe SaaS-Dienste nutzen, bleibt hier alle Daten im Cluster. Der Agent beobachtet den aktuellen Zustand des Clusters über die Kubernetes-API und nutzt ein lokales LLM, um fundierte Entscheidungen zu treffen.\u003c/p\u003e\n\u003cp\u003eDie Architektur des Systems besteht aus zwei Hauptkomponenten: einer CI/CD-Kette und der Kubernetes-Laufzeitumgebung. Auf der Laufzeitseite bedient ein Ollama-Pod ein lokal gehostetes Mistral 7B Modell, während ein FastAPI-Pod die HTTP-API des Agenten und die Benutzeroberfläche bereitstellt. Ein PersistentVolumeClaim speichert die Modellgewichte, um wiederholte Downloads zu vermeiden. Der Agent ist so konzipiert, dass er nur Leserechte auf Cluster-Ressourcen hat, was bedeutet, dass er keine Änderungen am Cluster vornehmen kann.\u003c/p\u003e\n\u003cp\u003eDie CI/CD-Pipeline wird durch Änderungen im Git-Repository ausgelöst, die GitHub Actions aktivieren, um ein Multi-Architektur-Image zu erstellen. Der \u003ca href=\"/kubernetes/\"\u003eArgo CD\u003c/a\u003e Image Updater überwacht Docker Hub auf neue Tags und aktualisiert die kustomization.yaml im Repository, was schließlich zu einer Aktualisierung des Clusters führt. Diese Entkopplung der Komponenten sorgt dafür, dass GitHub Actions und Argo CD unabhängig voneinander arbeiten können, während sie dennoch eine einheitliche Quelle der Wahrheit bewahren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung eines clusterbewussten KI-Agenten bietet mehrere Vorteile für Plattformingenieure. Die Möglichkeit, live Cluster-Daten zu lesen und zu analysieren, führt zu präziseren und umsetzbaren Diagnosen. Der Agent unterscheidet sich grundlegend von einem typischen LLM, das lediglich auf trainierten Daten basiert. Während ein LLM allgemeine Antworten liefern kann, bietet der Agent spezifische Informationen, die auf dem aktuellen Zustand des Clusters basieren.\u003c/p\u003e\n\u003cp\u003eDie Verwendung von GitOps für die Verwaltung von Prompts, Modellwahl und RBAC ermöglicht eine vollständige Nachvollziehbarkeit und Auditing der Agentenaktivitäten. Diese Transparenz kann die Sicherheits- und \u003ca href=\"/compliance/\"\u003eCompliance-Anforderungen\u003c/a\u003e in vielen Organisationen unterstützen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung eines clusterbewussten KI-Agenten innerhalb von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e zeigt das Potenzial für verbesserte Effizienz und Sicherheit bei der Nutzung von KI in Cloud-Umgebungen. Zukünftige Entwicklungen könnten die Integration weiterer KI-Funktionalitäten und eine Erweiterung des Modells zur Unterstützung komplexerer Anwendungsfälle umfassen.\u003c/p\u003e\n", "summary": "TL;DR Der Artikel beschreibt die Implementierung eines clusterbewussten KI-Agenten innerhalb eines Kubernetes-Clusters, der ohne externe Cloud-Dienste betrieben wird. Der Agent verwendet lokale Daten und ein Large Language Model (LLM), um spezifische Diagnosen und Analysen durchzuführen, während die gesamte CI/CD-Pipeline durch GitHub Actions und Argo CD gesteuert wird.\nHauptinhalt Die Entwicklung eines clusterbewussten KI-Agenten stellt einen innovativen Ansatz dar, um KI-Funktionalitäten direkt innerhalb eines Kubernetes-Clusters zu implementieren. Im Gegensatz zu herkömmlichen „AI for Kubernetes“-Tools, die externe SaaS-Dienste nutzen, bleibt hier alle Daten im Cluster. Der Agent beobachtet den aktuellen Zustand des Clusters über die Kubernetes-API und nutzt ein lokales LLM, um fundierte Entscheidungen zu treffen.\n", "image": "https://ayedo.de/building-a-cluster-aware-ai-agent-with-kubernetes-argo-cd-and-gitops.png", "date_published": "2026-06-25T11:25:00Z", "date_modified": "2026-06-25T11:25:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","software-delivery","development","docker"], "language": "de" },{ "id": "https://ayedo.de/news/spotlight-on-wg-device-management/", "url": "https://ayedo.de/news/spotlight-on-wg-device-management/", "title": "Im Fokus: WG Device Management", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie zunehmende Nutzung von KI, Edge- und Telekommunikationsanwendungen auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e erfordert eine verbesserte Hardwareverwaltung. Die Device Management Working Group hat das Dynamic Resource Allocation (DRA)-Projekt entwickelt, das nun in den allgemeinen verfügbaren Status übergegangen ist und eine strukturierte Herangehensweise an die Verwaltung spezialisierter Hardware bietet.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Device Management Working Group wurde gegründet, um die Konfiguration, den Austausch und die Zuweisung von spezialisierten Hardwarekomponenten wie GPUs, TPUs und FPGAs in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Umgebungen zu optimieren. Traditionell wurde die Hardwareverwaltung in Kubernetes über die Device Plugin API abgewickelt, die jedoch als unzureichend angesehen wird, da sie Geräte als undurchsichtige Ganzzahlen behandelt. Dies bedeutet, dass Nutzer lediglich angeben können, wie viele GPUs sie benötigen, ohne spezifische Anforderungen an die Hardware oder deren Verknüpfung zu formulieren.\u003c/p\u003e\n\u003cp\u003eDas DRA-Projekt hat sich als Antwort auf diese Herausforderungen entwickelt und bietet eine strukturierte Methode zur Verwaltung von Hardware-Ressourcen. Es gliedert den Prozess in vier Phasen: Modellierung, Anforderung, Planung und Aktivierung. In der Modellierungsphase verwenden Anbieter die ResourceSlice API, um die detaillierten Fähigkeiten und Kapazitäten ihrer Hardware zu kommunizieren. In der Anforderungsphase definieren Nutzer ihre spezifischen Hardwarebedürfnisse über die ResourceClaim API. Die Planungsphase ermöglicht es dem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Scheduler, die Anforderungen der Workloads intelligent mit den verfügbaren Hardware-Ressourcen abzugleichen. Schließlich wird in der Aktivierungsphase der „Handshake“ durchgeführt, um das Gerät für die Nutzung durch das Pod vorzubereiten und zu sichern.\u003c/p\u003e\n\u003cp\u003eDie Co-Vorsitzenden der Working Group, Kevin Klues von NVIDIA, Patrick Ohly von Intel und John Belamaric von Google, haben gemeinsam an der Entwicklung von DRA gearbeitet. Sie betonen, dass die Notwendigkeit für diese Verbesserungen durch die Herausforderungen bei der Nutzung von externen Beschleunigern entstanden ist. Der Übergang von einer einfachen Integer-Darstellung zu einem strukturierten Modell ermöglicht eine präzisere und flexiblere Nutzung von Hardware-Ressourcen in Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung von DRA könnte tiefgreifende Auswirkungen auf die Art und Weise haben, wie \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Cluster konfiguriert und verwaltet werden. Die Möglichkeit, spezialisierte Hardware granular zu beschreiben und zu verwalten, könnte die Effizienz und Leistung von Anwendungen, die auf diese Ressourcen angewiesen sind, erheblich steigern. Zudem könnte die verbesserte Planung und Zuweisung von Ressourcen die Komplexität verringern und die Autoskalierung von Anwendungen erleichtern.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Aspekt ist die Interoperabilität der neuen APIs mit bestehenden Kubernetes-Architekturen. Die erfolgreiche Integration von DRA wird davon abhängen, wie gut die Community diese neuen Ansätze annimmt und implementiert.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Fortschritte im Bereich des Device Managements, insbesondere durch das DRA-Projekt, markieren einen wichtigen Schritt in der Evolution von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e als Plattform für moderne, hardwareintensive Anwendungen. Die Entwicklungen in diesem Bereich werden weiterhin beobachtet, da sie potenziell die Effizienz und Flexibilität von Cloud-nativen Architekturen erheblich verbessern können.\u003c/p\u003e\n", "summary": "TL;DR Die zunehmende Nutzung von KI, Edge- und Telekommunikationsanwendungen auf Kubernetes erfordert eine verbesserte Hardwareverwaltung. Die Device Management Working Group hat das Dynamic Resource Allocation (DRA)-Projekt entwickelt, das nun in den allgemeinen verfügbaren Status übergegangen ist und eine strukturierte Herangehensweise an die Verwaltung spezialisierter Hardware bietet.\nHauptinhalt Die Device Management Working Group wurde gegründet, um die Konfiguration, den Austausch und die Zuweisung von spezialisierten Hardwarekomponenten wie GPUs, TPUs und FPGAs in Kubernetes-Umgebungen zu optimieren. Traditionell wurde die Hardwareverwaltung in Kubernetes über die Device Plugin API abgewickelt, die jedoch als unzureichend angesehen wird, da sie Geräte als undurchsichtige Ganzzahlen behandelt. Dies bedeutet, dass Nutzer lediglich angeben können, wie viele GPUs sie benötigen, ohne spezifische Anforderungen an die Hardware oder deren Verknüpfung zu formulieren.\n", "image": "https://ayedo.de/spotlight-on-wg-device-management.png", "date_published": "2026-06-24T18:00:00Z", "date_modified": "2026-06-24T18:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/from-awareness-to-engineered-accessibility-in-open-source/", "url": "https://ayedo.de/news/from-awareness-to-engineered-accessibility-in-open-source/", "title": "Von Bewusstsein zu geplanter Zugänglichkeit in Open Source", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Diskussion um Zugänglichkeit im Open-Source-Bereich hat sich weiterentwickelt, von individueller Anpassung hin zu einem systematischen Ansatz, der kognitive Barrieren im Design adressiert. Die Neurodiversity-Community hat sich darauf konzentriert, die Herausforderungen neurodivergenter Mitwirkender zu identifizieren und Lösungen zu entwickeln, die die Zusammenarbeit verbessern und die Inklusion fördern.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDas Open-Source-Ökosystem bietet die Möglichkeit, dass jeder jederzeit beitragen kann, doch in der Praxis stoßen viele auf unsichtbare Barrieren. Diese Barrieren entstehen durch Annahmen in der Dokumentation, Kommunikationsnormen und Governance-Strukturen, die nicht für alle Benutzergruppen geeignet sind. Die Neurodiversity-Community hat sich gebildet, um neurodivergente Mitwirkende und deren Verbündete zu unterstützen und auf die Herausforderungen aufmerksam zu machen, die diese Barrieren mit sich bringen.\u003c/p\u003e\n\u003cp\u003eIn den vergangenen Jahren hat sich die Diskussion um Zugänglichkeit in der \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Community\u003c/a\u003e von einer individuellen Perspektive hin zu einem systematischen Ansatz gewandelt. Bei der KubeCon + CloudNativeCon North America 2025 in Atlanta wurden grundlegende Konzepte zur Neurodiversität in Engineering-Teams vorgestellt. Der Fokus lag darauf, wie kognitive Unterschiede wie ADHS, Autismus und Dyslexie in verteilten Engineering-Umgebungen sichtbar werden können. Es wurde betont, dass asynchrone Kommunikationsmuster, wie schriftliche Spezifikationen und strukturierte RFCs, als potenzielle Gleichmacher fungieren können, wenn klare Erwartungen an Reaktionszeiten und Tonfall definiert sind.\u003c/p\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon Europe 2026 in Amsterdam brachte eine weitere Vertiefung der Diskussion. Der Fokus lag hier auf dem Aufbau von Peer-Mentorship-Netzwerken, die erfahrene neurodivergente Maintainer mit neuen Mitwirkenden verbinden, um praktische Ansätze zur Bewältigung von Stress und zur Verbesserung der Zusammenarbeit zu teilen. Zudem wurden \u0026ldquo;Wie man mit mir arbeitet\u0026rdquo;-Leitfäden gefördert, um soziale Unsicherheiten in verteilten Teams zu reduzieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung von Zugänglichkeit im Open-Source-Bereich wird zunehmend als architektonische Verantwortung betrachtet, die von allen Beteiligten getragen werden muss. Die Implementierung von strukturierten Unterstützungsmechanismen und klaren Kommunikationsrichtlinien kann nicht nur die Inklusion fördern, sondern auch die Qualität und Effizienz von Projekten steigern. Indem die Community ein Umfeld schafft, das unterschiedliche kognitive Stile anerkennt und fördert, können innovative Problemlösungen und neue Perspektiven in den Entwicklungsprozess integriert werden. Die Nutzung von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e kann dabei helfen, diese Ziele zu erreichen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Veränderungen in der Diskussion um Zugänglichkeit im Open-Source-Bereich zeigen, dass ein systematischer Ansatz notwendig ist, um kognitive Barrieren abzubauen. Die fortlaufende Entwicklung und Implementierung solcher Strategien wird entscheidend sein, um eine inklusivere und produktivere Community zu schaffen.\u003c/p\u003e\n", "summary": "TL;DR Die Diskussion um Zugänglichkeit im Open-Source-Bereich hat sich weiterentwickelt, von individueller Anpassung hin zu einem systematischen Ansatz, der kognitive Barrieren im Design adressiert. Die Neurodiversity-Community hat sich darauf konzentriert, die Herausforderungen neurodivergenter Mitwirkender zu identifizieren und Lösungen zu entwickeln, die die Zusammenarbeit verbessern und die Inklusion fördern.\nHauptinhalt Das Open-Source-Ökosystem bietet die Möglichkeit, dass jeder jederzeit beitragen kann, doch in der Praxis stoßen viele auf unsichtbare Barrieren. Diese Barrieren entstehen durch Annahmen in der Dokumentation, Kommunikationsnormen und Governance-Strukturen, die nicht für alle Benutzergruppen geeignet sind. Die Neurodiversity-Community hat sich gebildet, um neurodivergente Mitwirkende und deren Verbündete zu unterstützen und auf die Herausforderungen aufmerksam zu machen, die diese Barrieren mit sich bringen.\n", "image": "https://ayedo.de/from-awareness-to-engineered-accessibility-in-open-source.png", "date_published": "2026-06-24T11:32:00Z", "date_modified": "2026-06-24T11:32:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/what-is-an-sbom-and-why-cant-you-ship-without-one/", "url": "https://ayedo.de/news/what-is-an-sbom-and-why-cant-you-ship-without-one/", "title": "Was ist ein SBOM (und warum kannst du ohne keinen Release versenden)?", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareartefakts und spielt eine entscheidende Rolle in der Sicherheit der Software-Lieferkette. Trotz der erkannten Vorteile in der Schwachstellenbewältigung haben viele Organisationen Schwierigkeiten bei der Erstellung von SBOMs. Regulierungen machen SBOMs zunehmend zu einer Voraussetzung für den Softwarevertrieb.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eEin SBOM ist eine strukturierte Auflistung aller Komponenten, Bibliotheken und Module, die in einem Softwareartefakt enthalten sind. Bei \u003ca href=\"/kubernetes/\"\u003econtainerisierten Anwendungen\u003c/a\u003e, wie beispielsweise einem auf Alpine Linux basierenden Containerbild, sind zahlreiche Systempakete und deren Abhängigkeiten beteiligt. Ein SBOM beantwortet die grundlegende Frage, welche Software tatsächlich in der Produktion läuft. Es erfasst die gesamte Abhängigkeitsstruktur und enthält wichtige Metadaten zu jeder Komponente, wie Version, Lizenz und Herkunft.\u003c/p\u003e\n\u003cp\u003eEin gut strukturiertes SBOM umfasst mehrere Kategorien von Metadaten für jede Komponente:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eKomponentenidentität\u003c/strong\u003e: Name, Version und Anbieter der Software (z.B. openssl 3.1.4, verwaltet vom OpenSSL-Projekt).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLizenzierung\u003c/strong\u003e: Art der Lizenz, die die Weiterverbreitung und Nutzung regelt (z.B. MIT, Apache 2.0, GPL).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAbhängigkeitsbeziehungen\u003c/strong\u003e: Wie Komponenten voneinander abhängen, einschließlich direkter und transformativer Abhängigkeiten.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEindeutige Identifikatoren\u003c/strong\u003e: Paket-URLs oder SWID-Tags, die eine Kreuzreferenzierung mit Schwachdatenbanken ermöglichen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrüfziffern und Hashes\u003c/strong\u003e: Kryptographische Hashes, die bestätigen, dass die Komponente nicht verändert wurde.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie Daten werden unter Verwendung offener Standards, hauptsächlich SPDX oder CycloneDX, strukturiert, um maschinenlesbar und interoperabel zu sein.\u003c/p\u003e\n\u003cp\u003eSBOMs sind besonders wichtig für die Sicherheit der Software-Lieferkette. Bei der Offenlegung von Schwachstellen, wie der Log4Shell-Sicherheitsanfälligkeit, konnten Organisationen mit aktuellen SBOMs schnell identifizieren, welche Images betroffen waren. Ohne SBOMs mussten Teams oft manuell Abhängigkeiten verfolgen, was zeitaufwendig und fehleranfällig ist.\u003c/p\u003e\n\u003cp\u003eEin SBOM ermöglicht eine schnellere Reaktion auf Sicherheitsvorfälle. Bei der Entdeckung einer neuen CVE (Common Vulnerability and Exposure) kann sofort ermittelt werden, wo das Unternehmen exponiert ist. Dies geschieht durch den Abgleich des betroffenen Pakets und der Version mit der SBOM-Bibliothek, was die Reaktionszeit erheblich verkürzt. In Kombination mit kontinuierlichem Schwachstellenscanning wird dieser Prozess weiter automatisiert.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung von SBOMs wird durch neue regulatorische Vorgaben vorangetrieben. In den USA hat die Executive Order 14028 Anforderungen für SBOMs für Software, die an Bundesbehörden verkauft wird, festgelegt. Dies zeigt, dass SBOMs nicht nur eine bewährte Praxis, sondern zunehmend auch eine gesetzliche Anforderung werden. Organisationen, die SBOMs in ihrem Entwicklungs- und Bereitstellungsprozess integrieren, können nicht nur ihre Sicherheitslage verbessern, sondern auch \u003ca href=\"/compliance/\"\u003eCompliance-Anforderungen\u003c/a\u003e erfüllen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von SBOMs in den Softwareentwicklungsprozess ist entscheidend für die Sicherheit und Transparenz in der Software-Lieferkette. Angesichts der zunehmenden regulatorischen Anforderungen wird die Fähigkeit, SBOMs effektiv zu generieren und zu verwalten, für Unternehmen von zentraler Bedeutung sein.\u003c/p\u003e\n", "summary": "TL;DR Ein Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareartefakts und spielt eine entscheidende Rolle in der Sicherheit der Software-Lieferkette. Trotz der erkannten Vorteile in der Schwachstellenbewältigung haben viele Organisationen Schwierigkeiten bei der Erstellung von SBOMs. Regulierungen machen SBOMs zunehmend zu einer Voraussetzung für den Softwarevertrieb.\nHauptinhalt Ein SBOM ist eine strukturierte Auflistung aller Komponenten, Bibliotheken und Module, die in einem Softwareartefakt enthalten sind. Bei containerisierten Anwendungen, wie beispielsweise einem auf Alpine Linux basierenden Containerbild, sind zahlreiche Systempakete und deren Abhängigkeiten beteiligt. Ein SBOM beantwortet die grundlegende Frage, welche Software tatsächlich in der Produktion läuft. Es erfasst die gesamte Abhängigkeitsstruktur und enthält wichtige Metadaten zu jeder Komponente, wie Version, Lizenz und Herkunft.\n", "image": "https://ayedo.de/what-is-an-sbom-and-why-cant-you-ship-without-one.png", "date_published": "2026-06-23T16:48:20Z", "date_modified": "2026-06-23T16:48:20Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","software-delivery","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/agent-auth-a-lawyers-day-in-court/", "url": "https://ayedo.de/news/agent-auth-a-lawyers-day-in-court/", "title": "Agent Auth: Ein Tag im Gericht für Anwälte", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAgenten in KI-Systemen benötigen eine ausgeklügelte Authentifizierung und Autorisierung, um im Namen von Benutzern zu agieren. Die Implementierung einer Agentenplattform erfordert starke Identitätsverwaltung, Delegationstokens und die Durchsetzung von Richtlinien, um die Sicherheit und Nachvollziehbarkeit der Aktionen zu gewährleisten.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eKünstliche Intelligenz (KI) Agenten können als erweiterte Mikroservices betrachtet werden, die zusätzliche Anforderungen an Authentifizierung, Richtlinien und Beobachtbarkeit stellen. Diese Agenten agieren im Namen verschiedener Benutzer, was eine präzise Identitätsverwaltung erfordert. Die Identität des Agenten sowie die Identität des Benutzers, für den der Agent tätig ist, müssen klar definiert und verifiziert werden.\u003c/p\u003e\n\u003cp\u003eEin anschauliches Beispiel zur Veranschaulichung dieser Konzepte ist die Analogie zu einem Anwalt, der einen Mandanten vor Gericht vertritt. Der Anwalt muss zunächst seine Identität nachweisen, was der Agentenidentität entspricht. Anschließend muss er darlegen, für wen er tätig ist, was der Identität des Mandanten entspricht. Der Anwalt präsentiert dann Dokumente, die seine Berechtigung zur Vertretung des Mandanten in diesem speziellen Fall belegen. In Agentensystemen erfolgt dies häufig durch ein On-Behalf-Of (OBO) Token, das Informationen über die Identität des Mandanten, die Identität des Agenten sowie die delegierten Berechtigungen und den Umfang der Delegation enthält.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus ist es entscheidend, dass die Agenten nicht nur über gültige Delegationen verfügen, sondern dass auch die angeforderten Aktionen den geltenden Richtlinien entsprechen. Dies erfordert eine umfassende \u003ca href=\"/compliance/\"\u003eRichtlinieneinhaltung\u003c/a\u003e, um sicherzustellen, dass die Berechtigungen nicht missbraucht werden.\u003c/p\u003e\n\u003cp\u003eUm diese Komplexität zu bewältigen, benötigt eine Agentenplattform eine robuste Infrastruktur, die folgende Funktionen bereitstellt:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEtablierung starker Agentenidentitäten\u003c/li\u003e\n\u003cli\u003eÜbertragung von Mandantenidentitäten über Anfragen hinweg\u003c/li\u003e\n\u003cli\u003eAusgabe und Validierung von Delegationstokens\u003c/li\u003e\n\u003cli\u003eDurchsetzung von Autorisierungsrichtlinien und -bereichen\u003c/li\u003e\n\u003cli\u003eBereitstellung von Nachverfolgbarkeit und Audit-Protokollen für Agentenaktionen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEin KI-natives Gateway spielt hierbei eine zentrale Rolle. Anstatt dass jeder Agent unabhängig Identitätspropagation, Delegationsüberprüfung, Richtlinieneinhaltung und Auditing implementiert, können diese Funktionen zentralisiert werden. Das Agenten-Gateway und das Mesh agieren als zentrale Stelle, die sicherstellt, dass Identitäten verifiziert, Delegationen gültig, Richtlinien durchgesetzt und Aktionen nachvollziehbar sind.\u003c/p\u003e\n\u003cp\u003eDurch die Kombination mit bestehenden Technologien wie SPIFFE, cert-manager, Istio und agentgateway kann eine Agentenplattform geschaffen werden, die es Agenten ermöglicht, sich auf die Geschäftslogik zu konzentrieren, während die Plattform sich um Identität, Delegation, Richtlinieneinhaltung und Beobachtbarkeit kümmert. Eine solche Plattform könnte auch in einer \u003ca href=\"/kubernetes/\"\u003ecloud-native\u003c/a\u003e Umgebung implementiert werden, um die Flexibilität und Skalierbarkeit zu erhöhen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung einer Agentenplattform erfordert nicht nur technisches Fachwissen, sondern auch ein tiefes Verständnis für Sicherheitsarchitekturen. Starke Identitätsmanagement- und Authentifizierungsmechanismen sind entscheidend, um die Integrität und Sicherheit der Agenteninteraktionen zu gewährleisten. Zudem müssen Richtlinien dynamisch verwaltet und anpassbar sein, um den sich ständig ändernden Anforderungen gerecht zu werden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung von Agenten in KI-Systemen erfordert eine präzise Authentifizierung und Autorisierung, um die Sicherheit und Nachvollziehbarkeit zu gewährleisten. Zukünftige Entwicklungen könnten weitere Optimierungen in der Interoperabilität und Effizienz der Agentenplattformen ermöglichen.\u003c/p\u003e\n", "summary": "TL;DR Agenten in KI-Systemen benötigen eine ausgeklügelte Authentifizierung und Autorisierung, um im Namen von Benutzern zu agieren. Die Implementierung einer Agentenplattform erfordert starke Identitätsverwaltung, Delegationstokens und die Durchsetzung von Richtlinien, um die Sicherheit und Nachvollziehbarkeit der Aktionen zu gewährleisten.\nHauptinhalt Künstliche Intelligenz (KI) Agenten können als erweiterte Mikroservices betrachtet werden, die zusätzliche Anforderungen an Authentifizierung, Richtlinien und Beobachtbarkeit stellen. Diese Agenten agieren im Namen verschiedener Benutzer, was eine präzise Identitätsverwaltung erfordert. Die Identität des Agenten sowie die Identität des Benutzers, für den der Agent tätig ist, müssen klar definiert und verifiziert werden.\n", "image": "https://ayedo.de/agent-auth-a-lawyers-day-in-court.png", "date_published": "2026-06-23T11:00:00Z", "date_modified": "2026-06-23T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","security","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/building-jaegers-clickhouse-backend-8-6x-compression-on-10-million-spans/", "url": "https://ayedo.de/news/building-jaegers-clickhouse-backend-8-6x-compression-on-10-million-spans/", "title": "Aufbau von Jaegers ClickHouse-Backend: 8,6× Kompression bei 10 Millionen Spans", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Integration von ClickHouse in Jaeger v2.18.0 ermöglicht eine effiziente Speicherung und Abfrage von Tracedaten mit einer beeindruckenden Kompression von 8,6×. ClickHouse, als spaltenorientierte OLAP-Datenbank, bietet hohe Schreibgeschwindigkeiten und schnelle analytische Abfragen, was insbesondere für die Überwachung komplexer Microservices von Bedeutung ist.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eJaeger, eine verteilte Tracing-Plattform der \u003ca href=\"https://cncf.io/\"\u003eCloud Native Computing Foundation\u003c/a\u003e (CNCF), hat mit der Version 2.18.0 die Unterstützung für \u003ca href=\"/kubernetes/\"\u003eClickHouse\u003c/a\u003e eingeführt. Diese Entscheidung basiert auf den wiederholten Anfragen der Nutzer nach einer leistungsfähigen Speicherlösung für Tracedaten. ClickHouse ist speziell für die Anforderungen von Telemetrie und Big Data ausgelegt, indem es große, append-only Schreibströme effizient verarbeiten und komplexe analytische Aggregationen in Millisekunden durchführen kann.\u003c/p\u003e\n\u003cp\u003eDie Hauptproblematik beim Tracing besteht darin, große Mengen semi-strukturierter Ereignisdaten zu speichern und diese schnell nach verschiedenen Dimensionen zu durchsuchen. Bisherige Lösungen wie Cassandra und Elasticsearch haben ihre Dienste geleistet, bringen jedoch hohe operationale Kosten und Komplexität beim Skalieren mit sich. ClickHouse hingegen bietet eine spaltenorientierte Speicherung, die sich besonders gut für die repetitiven Muster von Tracedaten eignet. Diese Wiederholungen, wie etwa häufige Dienstnamen und Statuscodes, werden durch die spaltenorientierte Struktur optimal komprimiert.\u003c/p\u003e\n\u003cp\u003eEin bemerkenswerter Vorteil von ClickHouse ist die signifikante Kompression der Tracedaten. In Benchmarks wurde ein Kompressionsverhältnis von 8,6× auf der Spans-Tabelle erreicht, was vor allem auf die Wiederholung von Werten in den Spalten zurückzuführen ist. Diese Effizienz ermöglicht es, Tracedaten nicht nur zu speichern, sondern auch in Echtzeit zu analysieren. Jaeger v2.18.0 bietet nun native ClickHouse-Methoden zur Leistungsüberwachung, die es Teams erlauben, zentrale Gesundheits- und Leistungsmetriken direkt aus ihren Tracedaten zu generieren, ohne auf externe Metrik-Pipelines angewiesen zu sein.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung des Schemas für ClickHouse war eine komplexe Aufgabe, da es optimiert werden musste für die häufigsten Abfragemuster von Jaeger, wie die Suche nach Trace-IDs, Service- und Operationsnamen sowie Zeitbereichsabfragen. Die Wahl des Primärschlüssels ist entscheidend, da dieser nicht nur die Sortierreihenfolge auf der Festplatte definiert, sondern auch die Effizienz der Abfragen beeinflusst. Es standen zwei Strategien zur Auswahl: eine Optimierung für die Rückgabe von Traces oder eine Optimierung für Suchanfragen. Letztendlich wurde die Entscheidung getroffen, den Primärschlüssel nach (service_name, name, start_time) zu sortieren, um die Suchperformance zu verbessern, was jedoch die Rückgabe von Traces beeinträchtigen kann.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus wurde das Schema so gestaltet, dass es den Anforderungen des \u003ca href=\"/compliance/\"\u003eOpenTelemetry-Datenmodells\u003c/a\u003e entspricht, was zusätzliche Anpassungen erforderte. Diese Entscheidungen sind in einem detaillierten Dokument festgehalten, das die Architekturentscheidungen für die Implementierung von ClickHouse in Jaeger beschreibt.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von ClickHouse in Jaeger stellt einen bedeutenden Fortschritt für die Speicherung und Analyse von Tracedaten dar. Mit dieser neuen Architektur können Teams ihre Microservices effektiver überwachen und die Effizienz ihrer Datenanalysen erheblich steigern. Die kontinuierliche Entwicklung und Optimierung dieser Technologien wird entscheidend sein, um den steigenden Anforderungen an die Überwachung komplexer Systeme gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Die Integration von ClickHouse in Jaeger v2.18.0 ermöglicht eine effiziente Speicherung und Abfrage von Tracedaten mit einer beeindruckenden Kompression von 8,6×. ClickHouse, als spaltenorientierte OLAP-Datenbank, bietet hohe Schreibgeschwindigkeiten und schnelle analytische Abfragen, was insbesondere für die Überwachung komplexer Microservices von Bedeutung ist.\nHauptinhalt Jaeger, eine verteilte Tracing-Plattform der Cloud Native Computing Foundation (CNCF), hat mit der Version 2.18.0 die Unterstützung für ClickHouse eingeführt. Diese Entscheidung basiert auf den wiederholten Anfragen der Nutzer nach einer leistungsfähigen Speicherlösung für Tracedaten. ClickHouse ist speziell für die Anforderungen von Telemetrie und Big Data ausgelegt, indem es große, append-only Schreibströme effizient verarbeiten und komplexe analytische Aggregationen in Millisekunden durchführen kann.\n", "image": "https://ayedo.de/building-jaegers-clickhouse-backend-8-6x-compression-on-10-million-spans.png", "date_published": "2026-06-23T11:00:00Z", "date_modified": "2026-06-23T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","development","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/telemetry-that-matters-designing-sustainable-high-impact-observability-pipelines/", "url": "https://ayedo.de/news/telemetry-that-matters-designing-sustainable-high-impact-observability-pipelines/", "title": "Telemetrie, die zählt: Nachhaltige, wirkungsvolle Observability-Pipelines entwerfen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie zunehmende Komplexität von Systemarchitekturen führt zu einer Überflutung mit Telemetriedaten, die oft nicht sinnvoll genutzt werden. Um nachhaltige und effektive Observability-Pipelines zu schaffen, sollten Teams gezielt definieren, welche Metriken notwendig sind, um die Systemgesundheit zu überwachen und Vorfälle schnell zu analysieren. Der Übergang zu einem \u003ca href=\"/kubernetes/\"\u003eObservability-Mesh\u003c/a\u003e und die Abwägung zwischen automatischer und manueller Instrumentierung sind entscheidend für den Erfolg.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eCloud-native\u003c/a\u003e Gemeinschaft steht vor der Herausforderung, dass die Erfassung von Telemetriedaten oft zu einer Überflutung mit Informationen führt, die nicht alle von Bedeutung sind. Historisch gesehen war die Strategie, alles zu instrumentieren und später herauszufiltern, weit verbreitet. Studien zeigen jedoch, dass etwa 50 % der gesammelten Metriken niemals abgefragt oder genutzt werden. Diese unkontrollierte Datensammlung führt nicht nur zu höheren Speicherkosten, sondern auch zu einer erhöhten Komplexität und Belastung für die Ingenieure, insbesondere während aktiver Vorfälle.\u003c/p\u003e\n\u003cp\u003eEin oft übersehener Aspekt ist die „grüne“ Observability. Jede gespeicherte, indizierte und verarbeitete Metrik verbraucht Ressourcen, was nicht nur Kosten verursacht, sondern auch den ökologischen Fußabdruck der Cloud-nativen Plattformen erhöht. Daher ist es wichtig, Observability als ein zentrales Designkriterium von Anfang an zu betrachten. Teams sollten klar definieren, wie ein gesundes System aussieht und welche Signale erforderlich sind, um strukturelle Abweichungen zu erkennen, bevor Code in die Produktion geht.\u003c/p\u003e\n\u003cp\u003eIm Falle eines Produktionsvorfalls ist es entscheidend, nicht alle Daten zu betrachten, sondern gezielt die Informationen zu finden, die notwendig sind, um die Auswirkungen auf die Nutzer schnell zu bewerten und die Ursache zu lokalisieren. Moderne Frameworks wie \u003ca href=\"/kubernetes/\"\u003eOpenTelemetry\u003c/a\u003e helfen dabei, diese Datenpunkte in zentrale Signale zu organisieren: Traces, Metriken, Logs und Profile. Anstatt diese Elemente isoliert zu betrachten, bewegt sich die Gemeinschaft hin zu einem Observability-Mesh, in dem Metriken direkt auf Traces verweisen, Traces relevante Logs einbetten und Logs auf Ressourcenprofile zurückgreifen. Diese Vernetzung reduziert den Aufwand für Kontextwechsel erheblich.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Erzeugung und Verarbeitung dieser Daten erfordert standardisierte Schichten, einschließlich semantischer Konventionen für einheitliche Labels, API-Einstiegspunkte und offene Protokolle wie OTLP. Bei der Instrumentierung von Anwendungen müssen Teams zwischen automatischer und manueller Instrumentierung abwägen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eZero-Code Instrumentierung\u003c/strong\u003e ermöglicht eine schnelle Erfassung von Telemetriedaten ohne Änderungen am Quellcode. Diese Methode eignet sich besonders für schnelle Rollouts oder unzugängliche Drittanbieter-Software, birgt jedoch das Risiko, unmanagebare Datenmengen zu generieren, wenn sie nicht richtig konfiguriert ist.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eManuelle Instrumentierung\u003c/strong\u003e gibt Ingenieuren die Kontrolle, um Tracing präzise um spezifische Geschäftslogik zu modellieren. Diese Methode ermöglicht eine kohärente Erzählung über Kausalität, ist jedoch zeitaufwendig und kann komplex sein.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung nachhaltiger Observability-Pipelines erfordert ein gezieltes Vorgehen bei der Datensammlung und -verarbeitung. Ein bewusster Umgang mit Telemetriedaten kann nicht nur die Effizienz steigern, sondern auch die Umweltbelastung verringern. Der Fokus auf ein Observability-Mesh und die richtige Wahl zwischen automatischer und manueller Instrumentierung werden entscheidend für den zukünftigen Erfolg in der Cloud-nativen Entwicklung sein.\u003c/p\u003e\n", "summary": "TL;DR Die zunehmende Komplexität von Systemarchitekturen führt zu einer Überflutung mit Telemetriedaten, die oft nicht sinnvoll genutzt werden. Um nachhaltige und effektive Observability-Pipelines zu schaffen, sollten Teams gezielt definieren, welche Metriken notwendig sind, um die Systemgesundheit zu überwachen und Vorfälle schnell zu analysieren. Der Übergang zu einem Observability-Mesh und die Abwägung zwischen automatischer und manueller Instrumentierung sind entscheidend für den Erfolg.\nHauptinhalt Die Cloud-native Gemeinschaft steht vor der Herausforderung, dass die Erfassung von Telemetriedaten oft zu einer Überflutung mit Informationen führt, die nicht alle von Bedeutung sind. Historisch gesehen war die Strategie, alles zu instrumentieren und später herauszufiltern, weit verbreitet. Studien zeigen jedoch, dass etwa 50 % der gesammelten Metriken niemals abgefragt oder genutzt werden. Diese unkontrollierte Datensammlung führt nicht nur zu höheren Speicherkosten, sondern auch zu einer erhöhten Komplexität und Belastung für die Ingenieure, insbesondere während aktiver Vorfälle.\n", "image": "https://ayedo.de/telemetry-that-matters-designing-sustainable-high-impact-observability-pipelines.png", "date_published": "2026-06-22T11:00:00Z", "date_modified": "2026-06-22T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","operations","software-delivery","development","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/kubecon-cloudnativecon-openinfra-summit-and-pytorch-conference-unite-in-china-to-scale-ai/", "url": "https://ayedo.de/news/kubecon-cloudnativecon-openinfra-summit-and-pytorch-conference-unite-in-china-to-scale-ai/", "title": "KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference vereinen sich in China, um KI zu skalieren", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference finden vom 7. bis 9. September 2026 im Shanghai International Convention Center statt. Diese Veranstaltung vereint führende Open-Source-Communities, um die Integration von \u003ca href=\"/kubernetes/\"\u003eCloud-Native\u003c/a\u003e Infrastrukturen mit KI-Workflows zu fördern und die Entwicklung von produktionstauglicher KI zu standardisieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie bevorstehende Veranstaltung in Shanghai stellt ein bedeutendes Ereignis dar, da sie die erste gemeinsame Konferenz von KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference ist. Diese Zusammenkunft zielt darauf ab, die wachsende Nachfrage nach der Integration von Cloud-Native-Plattformen mit KI-Modell-Workflows zu adressieren. China spielt eine zentrale Rolle in der Open-Source-Entwicklung und ist der zweitgrößte Beitragende zu CNCF-Projekten weltweit.\u003c/p\u003e\n\u003cp\u003eDie Veranstaltung wird von der \u003ca href=\"/kubernetes/\"\u003eCloud Native Computing Foundation\u003c/a\u003e (CNCF), der OpenInfra Foundation und der PyTorch Foundation organisiert. Diese Organisationen bündeln ihre Expertise, um eine Plattform zu schaffen, die die gesamte Open-Source-Infrastruktur abdeckt. Jonathan Bryce, der Geschäftsführer der CNCF und der OpenInfra Foundation, betont die Notwendigkeit, die verschiedenen Schichten der Infrastruktur zusammenzubringen, um den neuen Anforderungen gerecht zu werden, die KI-Workloads an Hardware und Nutzungsmuster stellen.\u003c/p\u003e\n\u003cp\u003eEin zentrales Ziel der Konferenz ist es, eine nahtlose Integration der verschiedenen Komponenten zu ermöglichen. Dies reicht von der Virtualisierung und Speicherung über Kubernetes bis hin zu den Trainings- und Inferenzframeworks von PyTorch. Durch diese Integration sollen KI-Workloads nicht nur experimentell, sondern auch portabel, skalierbar und betrieblich zuverlässig sein.\u003c/p\u003e\n\u003cp\u003eMark Collier, Geschäftsführer der PyTorch Foundation, hebt hervor, dass moderne KI-Infrastrukturen für das Training, die Inferenz und eine Vielzahl von KI-Beschleunigern entscheidend sind. Die Zusammenarbeit zwischen den Communities ist notwendig, um KI-Lösungen in großem Maßstab zu realisieren und von der Forschung in die Produktion zu überführen.\u003c/p\u003e\n\u003cp\u003eDie zweitägige technische Agenda umfasst zahlreiche Tracks, die von einem unabhängigen Programmkomitee kuratiert wurden. Diese Tracks konzentrieren sich auf spezielle Bereiche wie KI-Infrastruktur, Plattformengineering und Hardwareunterstützung. Keynotes und Breakout-Sessions bieten Einblicke in reale Fallstudien, die zeigen, wie führende Unternehmen Produktionsumgebungen skalieren und die betriebliche Zuverlässigkeit aufrechterhalten.\u003c/p\u003e\n\u003cp\u003eZu den hervorgehobenen Tracks gehören Themen wie der gesamte KI-Lebenszyklus, von der Modellierung mit PyTorch bis hin zu agentischen Workflows, sowie die Bereitstellung von Cloud-Infrastruktur und Virtualisierung für leistungsstarkes KI-Computing. Weitere Sessions befassen sich mit der Orchestrierung von KI-Workloads in \u003ca href=\"/kubernetes/\"\u003ecloud-nativen\u003c/a\u003e Umgebungen mithilfe von Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Veranstaltung wird die Zusammenarbeit zwischen Entwicklern und Technikern fördern, um die Herausforderungen der KI-Integration in Cloud-Native-Umgebungen anzugehen. Die behandelten Themen werden sowohl die technologische Entwicklung als auch die betriebliche Implementierung von KI-Lösungen in Unternehmen vorantreiben. Die Integration von OpenStack, Kubernetes und PyTorch wird als Schlüssel zur Realisierung effizienter und skalierbarer KI-Anwendungen angesehen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference 2026 in Shanghai stellt einen wichtigen Schritt in der Weiterentwicklung von KI-gestützten Cloud-Native-Lösungen dar. Die enge Zusammenarbeit der verschiedenen Open-Source-Communities wird entscheidend sein, um die Herausforderungen der nächsten Generation von KI-Workloads erfolgreich zu meistern.\u003c/p\u003e\n", "summary": "TL;DR Die KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference finden vom 7. bis 9. September 2026 im Shanghai International Convention Center statt. Diese Veranstaltung vereint führende Open-Source-Communities, um die Integration von Cloud-Native Infrastrukturen mit KI-Workflows zu fördern und die Entwicklung von produktionstauglicher KI zu standardisieren.\nHauptinhalt Die bevorstehende Veranstaltung in Shanghai stellt ein bedeutendes Ereignis dar, da sie die erste gemeinsame Konferenz von KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference ist. Diese Zusammenkunft zielt darauf ab, die wachsende Nachfrage nach der Integration von Cloud-Native-Plattformen mit KI-Modell-Workflows zu adressieren. China spielt eine zentrale Rolle in der Open-Source-Entwicklung und ist der zweitgrößte Beitragende zu CNCF-Projekten weltweit.\n", "image": "https://ayedo.de/kubecon-cloudnativecon-openinfra-summit-and-pytorch-conference-unite-in-china-to-scale-ai.png", "date_published": "2026-06-18T20:31:13Z", "date_modified": "2026-06-18T20:31:13Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","automation","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/flipkart-wins-cncf-end-user-case-study-contest-for-kubernetes-and-chaos-engineering-scale/", "url": "https://ayedo.de/news/flipkart-wins-cncf-end-user-case-study-contest-for-kubernetes-and-chaos-engineering-scale/", "title": "Flipkart gewinnt CNCF End User Fallstudienwettbewerb für Kubernetes und Chaos Engineering Skalierung", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eFlipkart, Indiens größte E-Commerce-Plattform, hat den CNCF End User Case Study Contest 2026 gewonnen, indem sie eine maßgeschneiderte Chaos-Engineering-Plattform auf Basis von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und LitmusChaos entwickelte. Diese Lösung verbessert die Zuverlässigkeit von Microservices und ermöglicht proaktive Fehleranalysen, insbesondere während hoher Verkehrsspitzen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eFlipkart wurde für seine innovative Arbeit im Bereich Reliability Engineering ausgezeichnet, die auf einer zentralen, skalierbaren Chaos-Engineering-Plattform basiert. Diese Plattform nutzt die \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Infrastruktur sowie das CNCF-Projekt LitmusChaos, um die Komplexität des Betriebs von Hunderten von miteinander verbundenen Microservices zu bewältigen. Vor dem Hintergrund bevorstehender hoher Verkehrsspitzen, insbesondere während der festlichen Verkaufszeiten, führte das Unternehmen etwa 90 % seiner Chaos-Experimente in Staging-Umgebungen durch.\u003c/p\u003e\n\u003cp\u003eDie Auswahl von LitmusChaos fiel auf die benutzerfreundliche Oberfläche, die robuste Erweiterbarkeit und die automatisierten Resilienzprüfungen. Flipkart entwickelte vier maßgeschneiderte Erweiterungen für LitmusChaos, darunter eine hybride Multi-Tenant-Architektur und ein DaemonSet-basiertes Hochverfügbarkeitsmodell, um parallele Injektionen durchzuführen. Diese Anpassungen ermöglichten eine dynamische Zielauswahl und die Unterstützung von Legacy-Systemen.\u003c/p\u003e\n\u003cp\u003eDie Implementierung dieser Chaos-Engineering-Praktiken führte zu einem signifikanten Wandel in der Unternehmenskultur von Flipkart. Der Fokus verlagerte sich von reaktiven Maßnahmen hin zu einem systematischen Ansatz zur Behandlung von Systemausfällen. Dies geschah durch die Nutzung geübter Fehlerszenarien als Grundlage für aktualisierte Incident-Runbooks, was die Effizienz und Zuverlässigkeit der gesamten Infrastruktur erhöhte.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie technische Lösung von Flipkart verdeutlicht die Bedeutung von proaktiven Fehleranalysen in modernen Microservices-Architekturen. Durch die Integration von Chaos-Engineering in den Entwicklungsprozess können Unternehmen potenzielle Schwachstellen identifizieren und beheben, bevor sie zu kritischen Problemen führen. Die fünf zurückgegebenen Beiträge an das LitmusChaos-Projekt haben zudem zur Verbesserung der Open-Source-Community beigetragen, indem sie Herausforderungen wie Datenbankindizes und Workflow-Konfigurationen adressierten.\u003c/p\u003e\n\u003cp\u003eDie Verwendung eines DaemonSets zur Durchführung von parallelen Injektionen zeigt, wie Unternehmen bestehende \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Ressourcen optimieren können, um Engpässe zu vermeiden und die Betriebseffizienz zu steigern. Diese Ansätze sind besonders relevant für Unternehmen, die große digitale Infrastrukturen betreiben und sich auf hohe Verfügbarkeiten während Spitzenzeiten vorbereiten müssen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eFlipkarts Erfolg im CNCF End User Case Study Contest unterstreicht die Relevanz von Chaos-Engineering in der \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Entwicklung. Zukünftig plant das Unternehmen, automatisierte Chaos-Tests in seine CI/CD-Pipelines zu integrieren, was die Resilienz und Zuverlässigkeit ihrer Software weiter steigern wird.\u003c/p\u003e\n", "summary": "TL;DR Flipkart, Indiens größte E-Commerce-Plattform, hat den CNCF End User Case Study Contest 2026 gewonnen, indem sie eine maßgeschneiderte Chaos-Engineering-Plattform auf Basis von Kubernetes und LitmusChaos entwickelte. Diese Lösung verbessert die Zuverlässigkeit von Microservices und ermöglicht proaktive Fehleranalysen, insbesondere während hoher Verkehrsspitzen.\nHauptinhalt Flipkart wurde für seine innovative Arbeit im Bereich Reliability Engineering ausgezeichnet, die auf einer zentralen, skalierbaren Chaos-Engineering-Plattform basiert. Diese Plattform nutzt die Kubernetes Infrastruktur sowie das CNCF-Projekt LitmusChaos, um die Komplexität des Betriebs von Hunderten von miteinander verbundenen Microservices zu bewältigen. Vor dem Hintergrund bevorstehender hoher Verkehrsspitzen, insbesondere während der festlichen Verkaufszeiten, führte das Unternehmen etwa 90 % seiner Chaos-Experimente in Staging-Umgebungen durch.\n", "image": "https://ayedo.de/flipkart-wins-cncf-end-user-case-study-contest-for-kubernetes-and-chaos-engineering-scale.png", "date_published": "2026-06-18T06:00:00Z", "date_modified": "2026-06-18T06:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","operations","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/expanding-care-passing-cks-can-now-extend-your-cka-certification/", "url": "https://ayedo.de/news/expanding-care-passing-cks-can-now-extend-your-cka-certification/", "title": "CARE erweitern: CKS bestehen kann jetzt Ihre CKA-Zertifizierung verlängern", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAb dem 18. Juni wird die erfolgreiche Absolvierung oder Rezertifizierung der Certified \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Security Specialist (CKS) Prüfung automatisch die Zertifizierung als Certified \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Administrator (CKA) verlängern oder wiederherstellen. Diese Änderung vereinfacht den Zertifizierungsprozess für Fachkräfte, die sich von der Kubernetes-Administration in Sicherheitsrollen weiterentwickeln.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eCloud Native\u003c/a\u003e Computing Foundation (CNCF) hat das CARE-Programm (Certification Advancement \u0026amp; Recertification Experience) eingeführt, um zertifizierten Fachleuten zu helfen, ihre Qualifikationen aktuell zu halten und gleichzeitig den Lernprozess zu fördern. Das Programm soll den Zertifizierungsprozess erleichtern, indem es die Notwendigkeit reduziert, separate Erneuerungszyklen für verschiedene Zertifikate zu verwalten.\u003c/p\u003e\n\u003cp\u003eMit der aktuellen Änderung wird die CKA-Zertifizierung automatisch aktualisiert, wenn ein Kandidat die CKS-Prüfung besteht oder sich rezertifiziert. Dies gilt unabhängig davon, ob die CKA-Zertifizierung noch aktiv ist oder bereits abgelaufen ist. Ein erfolgreicher CKS-Test kann somit die Gültigkeit beider Zertifikate aufrechterhalten.\u003c/p\u003e\n\u003cp\u003eDie CKS-Prüfung baut direkt auf dem Wissen und den praktischen Fähigkeiten auf, die in der CKA-Prüfung behandelt werden. Kandidaten, die sich auf die CKS-Prüfung vorbereiten, müssen fundierte Kenntnisse in der \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e -Administration nachweisen, um Cluster, Workloads, Netzwerke und Laufzeitumgebungen zu sichern. Daher wird das Bestehen der CKS-Prüfung als starkes Signal angesehen, dass ein Kandidat weiterhin die grundlegenden Kubernetes-Administrationsfähigkeiten demonstriert, die durch die CKA repräsentiert werden.\u003c/p\u003e\n\u003cp\u003eFür Fachkräfte, die mehrere Kubernetes-Zertifizierungen gleichzeitig aufrechterhalten möchten, bietet diese Änderung eine vereinfachte Handhabung. Die Möglichkeit, die CKA-Zertifizierung durch das Bestehen oder die Rezertifizierung der CKS-Prüfung zu verlängern, reduziert den Verwaltungsaufwand und die damit verbundenen Friktionen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Integration von CKS und CKA in den Zertifizierungsprozess spiegelt die tatsächliche Entwicklung der Fähigkeiten von Kubernetes-Profis wider. Viele Fachkräfte beginnen mit der CKA-Zertifizierung und bewegen sich dann in sicherheitsorientierte Rollen. Die Anerkennung dieser Entwicklung durch die Zertifizierungsprogramme ist entscheidend, um die Relevanz und den Wert der Zertifizierungen aufrechtzuerhalten.\u003c/p\u003e\n\u003cp\u003eKandidaten, deren CKA-Zertifizierung kurz vor dem Ablauf steht oder bereits abgelaufen ist, können durch das Bestehen der CKS-Prüfung ihre CKA-Zertifizierung wiederherstellen oder verlängern. Es sind keine zusätzlichen Schritte erforderlich, wenn sie sich bereits auf die CKS-Prüfung vorbereiten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Anpassungen im CARE-Programm zeigen eine klare Reaktion auf das Feedback der Community und zielen darauf ab, den Zertifizierungsprozess für Kubernetes-Profis zu optimieren. Die CNCF wird das Programm weiterhin basierend auf den Erfahrungen der Nutzer weiterentwickeln, um den Bedürfnissen der Fachkräfte in der Cloud-Native- und \u003ca href=\"/kubernetes/\"\u003eDevOps\u003c/a\u003e -Welt gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Ab dem 18. Juni wird die erfolgreiche Absolvierung oder Rezertifizierung der Certified Kubernetes Security Specialist (CKS) Prüfung automatisch die Zertifizierung als Certified Kubernetes Administrator (CKA) verlängern oder wiederherstellen. Diese Änderung vereinfacht den Zertifizierungsprozess für Fachkräfte, die sich von der Kubernetes-Administration in Sicherheitsrollen weiterentwickeln.\nHauptinhalt Die Cloud Native Computing Foundation (CNCF) hat das CARE-Programm (Certification Advancement \u0026amp; Recertification Experience) eingeführt, um zertifizierten Fachleuten zu helfen, ihre Qualifikationen aktuell zu halten und gleichzeitig den Lernprozess zu fördern. Das Programm soll den Zertifizierungsprozess erleichtern, indem es die Notwendigkeit reduziert, separate Erneuerungszyklen für verschiedene Zertifikate zu verwalten.\n", "image": "https://ayedo.de/expanding-care-passing-cks-can-now-extend-your-cka-certification.png", "date_published": "2026-06-18T04:50:00Z", "date_modified": "2026-06-18T04:50:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","security","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/cncf-welcomes-new-silver-members-as-global-demand-for-cloud-native-infrastructure-grows/", "url": "https://ayedo.de/news/cncf-welcomes-new-silver-members-as-global-demand-for-cloud-native-infrastructure-grows/", "title": "CNCF begrüßt neue Silbermitglieder, während die globale Nachfrage nach Cloud Native Infrastruktur wächst", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Cloud Native Computing Foundation (CNCF) hat 14 neue Silbermitglieder und zwei Silber-Endbenutzer aufgenommen, was die wachsende Akzeptanz von \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Technologien\u003c/a\u003e und deren Bedeutung für Plattformengineering und KI-Anwendungen verdeutlicht. Der Beitritt neuer Mitglieder zeigt, dass 98 % der Organisationen Cloud-Native-Techniken übernommen haben, was diese Technologien zum globalen Standard für Unternehmensinfrastrukturen macht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie CNCF hat kürzlich 14 neue Silbermitglieder sowie zwei Silber-Endbenutzer in ihr Ökosystem aufgenommen. Diese Entwicklung unterstreicht das zunehmende Interesse und die Nachfrage nach \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Infrastrukturen\u003c/a\u003e, insbesondere im Kontext von Plattformengineering und KI-Workloads. Die neuen Mitglieder kommen aus verschiedenen Bereichen, darunter Plattformengineering, KI-Infrastruktur, Managed-[Kubernetes]-Diensten, Finanztechnologie und Unternehmenssoftware. Diese Vielfalt spiegelt wider, wie Organisationen skalierbare Cloud-Native-Plattformen entwickeln, um moderne Anwendungen und KI-Workloads zu unterstützen.\u003c/p\u003e\n\u003cp\u003eZu den neuen Silbermitgliedern gehören Unternehmen wie Actualyze AI, das Lösungen zur Verwaltung und Skalierung von KI in Unternehmen anbietet, und Amoniac OÜ, das sich auf Kubernetes-gesteuerte Infrastrukturen spezialisiert hat. Breqwatr bietet Managed-Dienste für OpenStack, Ceph und Kubernetes an, während cloudscale.ch als Schweizer IaaS-Anbieter den Fokus auf digitale Souveränität und Open Source legt. Fongcon Technology aus Taiwan bringt Erfahrung in der Bereitstellung von KI- und Hochleistungsrecheninfrastrukturen mit, insbesondere mit NVIDIA-GPU-Systemen und Kubernetes-basierten Plattformdiensten.\u003c/p\u003e\n\u003cp\u003eWeitere Mitglieder wie InfrOS und Nimtech konzentrieren sich auf die Verbesserung von Infrastruktur und Plattformentwicklung, wobei InfrOS eine kontinuierliche Validierung und Benchmarking von Architekturdesigns bietet. Raydian Cloud ist ein Managed Services Provider, der umfassende Unterstützung für AI- und Kubernetes-Umgebungen bietet und mit führenden Cloud-Anbietern zusammenarbeitet. Solanica bietet eine Kubernetes-native Steuerungslösung für automatisierte Datenbankbereitstellung und -verwaltung an, während SourceFuse AI Unternehmen bei der Entwicklung und Modernisierung von \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Software\u003c/a\u003e unterstützt.\u003c/p\u003e\n\u003cp\u003eZusätzlich zu den neuen Silbermitgliedern hat die CNCF zwei neue Silber-Endbenutzer aufgenommen. Lovable ist eine Plattform, die es Nutzern ermöglicht, mit Hilfe von KI vollständige Anwendungen und Websites zu erstellen. Diese Plattform zieht monatlich über 600 Millionen Besuche an und wird von führenden Unternehmen wie HubSpot, Microsoft und Uber genutzt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Aufnahme neuer Mitglieder in die CNCF zeigt die wachsende Bedeutung von Cloud-Native-Technologien, insbesondere im Hinblick auf die Unterstützung von KI-Infrastrukturen. Die Tatsache, dass 98 % der Organisationen Cloud-Native-Techniken übernommen haben, deutet auf einen Paradigmenwechsel in der Art und Weise hin, wie Unternehmen ihre IT-Infrastruktur gestalten. Die neuen Mitglieder bringen spezifische Expertise in Schlüsselbereichen, die für die Entwicklung und den Betrieb moderner Anwendungen entscheidend sind, was die Innovationskraft und Skalierbarkeit in der Cloud-Native-Welt weiter vorantreibt.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie kontinuierliche Erweiterung des CNCF-Ökosystems und die hohe Akzeptanz von Cloud-Native-Technologien sind klare Indikatoren für die zukünftige Entwicklung der IT-Infrastruktur. Die Integration neuer Mitglieder wird die Innovationskraft in der Branche weiter stärken und neue Möglichkeiten für Unternehmen schaffen, ihre digitalen Transformationen voranzutreiben.\u003c/p\u003e\n", "summary": "TL;DR Die Cloud Native Computing Foundation (CNCF) hat 14 neue Silbermitglieder und zwei Silber-Endbenutzer aufgenommen, was die wachsende Akzeptanz von Cloud-Native-Technologien und deren Bedeutung für Plattformengineering und KI-Anwendungen verdeutlicht. Der Beitritt neuer Mitglieder zeigt, dass 98 % der Organisationen Cloud-Native-Techniken übernommen haben, was diese Technologien zum globalen Standard für Unternehmensinfrastrukturen macht.\nHauptinhalt Die CNCF hat kürzlich 14 neue Silbermitglieder sowie zwei Silber-Endbenutzer in ihr Ökosystem aufgenommen. Diese Entwicklung unterstreicht das zunehmende Interesse und die Nachfrage nach Cloud-Native-Infrastrukturen, insbesondere im Kontext von Plattformengineering und KI-Workloads. Die neuen Mitglieder kommen aus verschiedenen Bereichen, darunter Plattformengineering, KI-Infrastruktur, Managed-[Kubernetes]-Diensten, Finanztechnologie und Unternehmenssoftware. Diese Vielfalt spiegelt wider, wie Organisationen skalierbare Cloud-Native-Plattformen entwickeln, um moderne Anwendungen und KI-Workloads zu unterstützen.\n", "image": "https://ayedo.de/cncf-welcomes-new-silver-members-as-global-demand-for-cloud-native-infrastructure-grows.png", "date_published": "2026-06-18T03:30:00Z", "date_modified": "2026-06-18T03:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","software-as-a-service","operations","development"], "language": "de" },{ "id": "https://ayedo.de/news/cncf-and-slashdata-report-confirms-india-as-one-of-the-largest-cloud-native-communities-with-2-25-million-developers/", "url": "https://ayedo.de/news/cncf-and-slashdata-report-confirms-india-as-one-of-the-largest-cloud-native-communities-with-2-25-million-developers/", "title": "CNCF- und SlashData-Bericht bestätigt Indien als eine der größten Cloud-Native-Communities mit 2,25 Millionen Entwicklern", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eIndien hat sich als eine der größten \u003ca href=\"/kubernetes/\"\u003eCloud-Native\u003c/a\u003e Communities etabliert, mit geschätzten 2,25 Millionen Entwicklern, die etwa 11% der globalen Gesamtzahl ausmachen. Die hybride Cloud-Nutzung erreicht 44%, was über dem globalen Durchschnitt liegt, während die Rolle von Cloud-Native-Technologien in der KI-Entwicklung zunehmend an Bedeutung gewinnt.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie aktuelle Analyse zur Cloud-Native-Entwicklung in Indien zeigt, dass das Land eine signifikante Rolle im globalen Cloud-Native-Ökosystem spielt. Der Bericht, der auf Daten von über 12.500 Entwicklern aus 100 Ländern basiert, hebt hervor, dass Indien etwa 2,25 Millionen Cloud-Native-Entwickler beherbergt, was es zu einer der am schnellsten wachsenden Gemeinschaften weltweit macht.\u003c/p\u003e\n\u003cp\u003eEin bemerkenswerter Trend ist die wachsende Akzeptanz von hybriden Cloud-Lösungen, die mit 44% die globale Durchschnittszahl von 34% übersteigt. Diese Entwicklung wird durch eine junge Entwicklerpopulation unterstützt, von der 70% unter 35 Jahre alt sind. Dies steht im Gegensatz zum globalen Durchschnitt, bei dem nur 39% der Entwickler in dieser Altersgruppe sind.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Ergebnis des Berichts ist die zunehmende Relevanz von Plattformengineering, das die Nutzung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e in Indien vorantreibt. Bei Backend-Entwicklern liegt die Kubernetes-Nutzung bei 42%, was die \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e Nutzung von 39% übertrifft. Diese Umkehrung des globalen Trends deutet darauf hin, dass indische Entwickler zunehmend auf verwaltete Kubernetes-Dienste setzen, wodurch Kubernetes als primäre Schnittstelle zu Cloud-Native-Technologien fungiert.\u003c/p\u003e\n\u003cp\u003eZusätzlich zeigt der Bericht, dass 71% der Backend-Entwickler mindestens eine Cloud-Native-Technologie oder -Praxis verwenden, jedoch nur 52% als vollständig Cloud-Native klassifiziert werden können. Dies deutet darauf hin, dass viele Organisationen noch in den frühen Phasen der Cloud-Native-Reife sind und ihre modernen Infrastrukturpraktiken weiter ausbauen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Ergebnisse des Berichts verdeutlichen, dass die indische Cloud-Native-Community nicht nur in der Anzahl der Entwickler, sondern auch in der Art und Weise, wie Cloud-Technologien angenommen werden, heraussticht. Die Kombination aus wachsender hybrider Cloud-Nutzung, zunehmender Kubernetes-Akzeptanz und der Integration von KI in Cloud-Native-Umgebungen positioniert Indien als Vorreiter in der technologischen Innovation.\u003c/p\u003e\n\u003cp\u003eDie hohe Anzahl junger Entwickler, die mit Cloud-Native-Technologien vertraut sind, könnte langfristig die Entwicklung und Implementierung von neuen Cloud-Lösungen in Indien beschleunigen. Unternehmen, die in diesem Umfeld tätig sind, sollten die Trends in der Cloud-Native-Entwicklung in Indien genau beobachten, um von den dortigen Innovationen und Best Practices zu profitieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eIndien zeigt sich als ein dynamischer Markt für Cloud-Native-Technologien, der durch eine junge, technikaffine Entwicklergemeinschaft geprägt ist. Die fortschreitende Hybrid-Cloud-Akzeptanz und die Integration von KI in Cloud-Native-Umgebungen könnten bedeutende Auswirkungen auf die globale Cloud-Landschaft haben.\u003c/p\u003e\n", "summary": "TL;DR Indien hat sich als eine der größten Cloud-Native Communities etabliert, mit geschätzten 2,25 Millionen Entwicklern, die etwa 11% der globalen Gesamtzahl ausmachen. Die hybride Cloud-Nutzung erreicht 44%, was über dem globalen Durchschnitt liegt, während die Rolle von Cloud-Native-Technologien in der KI-Entwicklung zunehmend an Bedeutung gewinnt.\nHauptinhalt Die aktuelle Analyse zur Cloud-Native-Entwicklung in Indien zeigt, dass das Land eine signifikante Rolle im globalen Cloud-Native-Ökosystem spielt. Der Bericht, der auf Daten von über 12.500 Entwicklern aus 100 Ländern basiert, hebt hervor, dass Indien etwa 2,25 Millionen Cloud-Native-Entwickler beherbergt, was es zu einer der am schnellsten wachsenden Gemeinschaften weltweit macht.\n", "image": "https://ayedo.de/cncf-and-slashdata-report-confirms-india-as-one-of-the-largest-cloud-native-communities-with-2-25-million-developers.png", "date_published": "2026-06-18T03:30:00Z", "date_modified": "2026-06-18T03:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","cloud","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/docker-content-trust-retirement-and-migration-guidance/", "url": "https://ayedo.de/news/docker-content-trust-retirement-and-migration-guidance/", "title": "Docker Content Trust: Ruhestand und Migrationsleitfaden", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDocker Content Trust (DCT) und der Notary v1-Dienst werden vollständig eingestellt. Diese Entscheidung basiert auf der geringen Nutzung und der Abkehr von veralteten Technologien hin zu modernen, standardbasierten Signaturwerkzeugen. Nutzer, die DCT aktiv verwenden, sollten ihre Workflows anpassen und auf alternative Lösungen umsteigen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDocker Content Trust (DCT) wurde vor einem Jahrzehnt eingeführt, um die Integrität und den Publisher von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e–Images zu verifizieren. Es basierte auf The Update Framework und dem Notary v1-Projekt. Allerdings wird der Notary v1-Code nicht mehr gewartet, und die Nutzung von DCT ist in den letzten Jahren drastisch gesunken, da weniger als 0,05 % der Docker Hub-Pulls auf DCT zurückgreifen. Die Entscheidung zur vollständigen Stilllegung von DCT und dem Notary v1-Dienst wurde bereits im Juli 2025 angekündigt und wird nun umgesetzt.\u003c/p\u003e\n\u003cp\u003eDie Rücknahme von DCT erfolgt schrittweise, um den betroffenen Nutzern Zeit zu geben, ihre Systeme anzupassen. Die ersten Phasen beinhalten geplante Ausfallzeiten, in denen Schreiboperationen unterbrochen werden, gefolgt von Leseoperationen. Die vollständige Abschaltung ist für den 8. Dezember 2026 geplant.\u003c/p\u003e\n\u003cp\u003eFür die meisten Anwender, die DCT nicht aktiv nutzen, ändert sich nichts. DCT war eine optionale Funktion, und Standard-Image-Pulls berührten den Notary-Dienst nicht. Nutzer, die DCT konfiguriert haben, sollten sich jedoch mit den Änderungen vertraut machen. Dies betrifft insbesondere diejenigen, die Umgebungsvariablen wie \u003ccode\u003eDOCKER_CONTENT_TRUST=1\u003c/code\u003e gesetzt haben, oder die Docker-Befehle wie \u003ccode\u003edocker trust sign\u003c/code\u003e oder \u003ccode\u003edocker trust inspect\u003c/code\u003e verwenden.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Entscheidung, DCT abzulehnen, ist Teil eines größeren Trends in der \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e–Ökosystem, in dem standardisierte, OCI-native Signaturwerkzeuge wie Sigstore/Cosign und das Notary-Projekt Notation bevorzugt werden. Diese modernen Tools ermöglichen es, Signaturen direkt neben den Images in kompatiblen Registries zu speichern, ohne eine separate Vertrauensinfrastruktur zu benötigen. Diese Entwicklung wird von großen Anbietern unterstützt, die bereits die Unterstützung für DCT eingestellt haben, wie Microsoft im Azure Container Registry und Harbor.\u003c/p\u003e\n\u003cp\u003eNutzer, die von der DCT-Rücknahme betroffen sind, sollten folgende Schritte in Betracht ziehen:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eDeaktivierung von DCT\u003c/strong\u003e: Um sicherzustellen, dass Image-Pulls weiterhin funktionieren, sollte DCT deaktiviert werden. Dies kann durch das Setzen der Umgebungsvariable \u003ccode\u003eDOCKER_CONTENT_TRUST=0\u003c/code\u003e erfolgen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVerwendung von Image-Digests\u003c/strong\u003e: Anstelle von Tags, die sich ändern können, sollten Nutzer Image-Digests verwenden, um die Konsistenz der abgerufenen Inhalte zu gewährleisten. Dies stellt sicher, dass die exakte Version des Images abgerufen wird.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie vollständige Stilllegung von Docker Content Trust markiert einen wichtigen Schritt in der Weiterentwicklung der Container-Sicherheitspraktiken. Nutzer sollten die Gelegenheit nutzen, um auf modernere, standardisierte Tools umzusteigen, um ihre Workflows zukunftssicher zu gestalten.\u003c/p\u003e\n", "summary": "TL;DR Docker Content Trust (DCT) und der Notary v1-Dienst werden vollständig eingestellt. Diese Entscheidung basiert auf der geringen Nutzung und der Abkehr von veralteten Technologien hin zu modernen, standardbasierten Signaturwerkzeugen. Nutzer, die DCT aktiv verwenden, sollten ihre Workflows anpassen und auf alternative Lösungen umsteigen.\nHauptinhalt Docker Content Trust (DCT) wurde vor einem Jahrzehnt eingeführt, um die Integrität und den Publisher von Container–Images zu verifizieren. Es basierte auf The Update Framework und dem Notary v1-Projekt. Allerdings wird der Notary v1-Code nicht mehr gewartet, und die Nutzung von DCT ist in den letzten Jahren drastisch gesunken, da weniger als 0,05 % der Docker Hub-Pulls auf DCT zurückgreifen. Die Entscheidung zur vollständigen Stilllegung von DCT und dem Notary v1-Dienst wurde bereits im Juli 2025 angekündigt und wird nun umgesetzt.\n", "image": "https://ayedo.de/docker-content-trust-retirement-and-migration-guidance.png", "date_published": "2026-06-16T18:33:29Z", "date_modified": "2026-06-16T18:33:29Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/docker-joins-the-athena-coalition-a-cross-industry-collaboration-for-supply-chain-security/", "url": "https://ayedo.de/news/docker-joins-the-athena-coalition-a-cross-industry-collaboration-for-supply-chain-security/", "title": "Docker tritt der Athena-Koalition bei: eine branchenübergreifende Zusammenarbeit für die Sicherheit der Lieferkette", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDocker hat der Athena-Koalition beigetreten, einer branchenübergreifenden Initiative zur Verbesserung der Sicherheit in der Software-Lieferkette. Angesichts der steigenden Bedrohungen durch KI-gestützte Angriffe setzt Docker auf sichere Standardlösungen und enge Zusammenarbeit innerhalb des Ökosystems.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDocker hat eine neue Initiative ins Leben gerufen, um die Sicherheit der Software-Lieferkette zu stärken. Die Athena-Koalition wurde gegründet, um eine koordinierte Verteidigung gegen die wachsenden Bedrohungen durch KI-gesteuerte Sicherheitsanfälligkeiten zu ermöglichen. In einer Zeit, in der Angreifer zunehmend KI nutzen, um Schwachstellen schneller zu identifizieren und auszunutzen, ist es für Unternehmen entscheidend, ihre Sicherheitsstrategien zu überdenken und anzupassen.\u003c/p\u003e\n\u003cp\u003eDie Geschwindigkeit, mit der Sicherheitsanfälligkeiten entdeckt und ausgenutzt werden, hat sich erheblich verkürzt. Früher benötigte es Monate bis Jahre, um kritische Schwachstellen in weit verbreiteten Open-Source-Projekten zu finden. Heute können KI-Modelle wie Anthropic\u0026rsquo;s Mythos diese Schwachstellen in einem Bruchteil der Zeit aufspüren. Dies hat zur Folge, dass die Zeitspanne zwischen der Entdeckung einer Schwachstelle und ihrer Ausnutzung von Jahren auf Stunden geschrumpft ist.\u003c/p\u003e\n\u003cp\u003eUm dieser Herausforderung zu begegnen, verfolgt Docker einen zweigleisigen Ansatz: Zum einen werden Produkte entwickelt, die von Anfang an sicher und transparent sind. Zum anderen wird eine tiefgreifende Zusammenarbeit innerhalb des Ökosystems angestrebt, um Informationen und Signale zu teilen. Docker betont, dass kein einzelner Anbieter das gesamte Bild sieht und dass Kunden am besten geschützt sind, wenn Technologien in der Lieferkette zusammenarbeiten.\u003c/p\u003e\n\u003cp\u003eIm Rahmen dieser Strategie investiert Docker in drei Hauptbereiche:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eIsolierte Ausführung für Agenten\u003c/strong\u003e: Docker Sandboxes ermöglichen es, KI-Coding-Agenten in isolierten Micro-VMs auszuführen, wodurch potenzielle Bedrohungen von Kompromittierungen in Abhängigkeiten vom Host und anderen Workloads ferngehalten werden.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eVertrauenswürdige Open-Source-Basis\u003c/strong\u003e: Docker Hardened Images bieten minimalistische, sicherheitsoptimierte Images, die mit einem hohen Maß an Vertrauenswürdigkeit und Transparenz erstellt werden. Diese Bilder sind unter Apache 2.0 lizenziert und bieten eine sichere Grundlage für Entwickler.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRegulierte Zugriffe auf Tools\u003c/strong\u003e: Der Docker MCP-Katalog und das Gateway gewährleisten, dass Agenten auf eine vertrauenswürdige und gehärtete Sammlung von Servern zugreifen können, wobei zentrale Richtlinien und Protokolle zur Überwachung der Zugriffe implementiert sind.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eZusätzlich arbeitet Docker mit anderen Unternehmen und Organisationen zusammen, um Sicherheitsvorfälle wie den axios-Komplex zu analysieren und die Auswirkungen solcher Angriffe zu minimieren. Der Austausch von Informationen in Echtzeit ist entscheidend, um die Auswirkungen von Sicherheitsvorfällen zu begrenzen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Teilnahme an der Athena-Koalition stellt für Docker eine strategische Positionierung dar, um die Resilienz des Open-Source-Ökosystems zu stärken. Durch den Austausch von Erkenntnissen und die Koordination von Reaktionen auf Sicherheitsanfälligkeiten soll die gesamte Software-Lieferkette robuster gegen Angriffe werden. Die Implementierung von sicheren Standards und die Förderung einer gemeinschaftlichen Verteidigungsstrategie sind entscheidend, um den Herausforderungen der modernen Bedrohungslandschaft zu begegnen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Mitgliedschaft in der Athena-Koalition ermöglicht es Docker, aktiv an der Verbesserung der Sicherheit in der Software-Lieferkette teilzunehmen. Die Kombination aus innovativen Sicherheitslösungen und einer engen Zusammenarbeit mit anderen Akteuren im Ökosystem wird als Schlüssel angesehen, um den wachsenden Bedrohungen durch KI-gestützte Angriffe effektiv zu begegnen.\u003c/p\u003e\n\u003cp\u003eZusätzlich wird die Bedeutung von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e und \u003ca href=\"/kubernetes/\"\u003eCloud-Native\u003c/a\u003e Technologien in diesem Kontext hervorgehoben, um die Sicherheit und Effizienz in der Software-Lieferkette weiter zu verbessern.\u003c/p\u003e\n", "summary": "TL;DR Docker hat der Athena-Koalition beigetreten, einer branchenübergreifenden Initiative zur Verbesserung der Sicherheit in der Software-Lieferkette. Angesichts der steigenden Bedrohungen durch KI-gestützte Angriffe setzt Docker auf sichere Standardlösungen und enge Zusammenarbeit innerhalb des Ökosystems.\nHauptinhalt Docker hat eine neue Initiative ins Leben gerufen, um die Sicherheit der Software-Lieferkette zu stärken. Die Athena-Koalition wurde gegründet, um eine koordinierte Verteidigung gegen die wachsenden Bedrohungen durch KI-gesteuerte Sicherheitsanfälligkeiten zu ermöglichen. In einer Zeit, in der Angreifer zunehmend KI nutzen, um Schwachstellen schneller zu identifizieren und auszunutzen, ist es für Unternehmen entscheidend, ihre Sicherheitsstrategien zu überdenken und anzupassen.\n", "image": "https://ayedo.de/docker-joins-the-athena-coalition-a-cross-industry-collaboration-for-supply-chain-security.png", "date_published": "2026-06-15T16:24:29Z", "date_modified": "2026-06-15T16:24:29Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","development","cloud-native","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/spotlight-on-sig-storage/", "url": "https://ayedo.de/news/spotlight-on-sig-storage/", "title": "Im Fokus: SIG Storage", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eSIG Storage ist eine spezielle Interessengruppe innerhalb des \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Projekts, die sich mit der Bereitstellung und Verwaltung von persistentem Speicher für \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003eanwendungen beschäftigt. Die Gruppe arbeitet an wichtigen Funktionen wie Volume Group Snapshot und Changed Block Tracking, um die Datenintegrität und Effizienz bei der Datensicherung zu verbessern.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eSIG Storage hat sich als zentrale Anlaufstelle für die Herausforderungen der Speicherung in Kubernetes etabliert. Die Gruppe wurde gegründet, um die Anforderungen an persistente Daten zu adressieren, da Kubernetes ursprünglich für stateless Anwendungen konzipiert wurde. Mit der zunehmenden Nutzung von stateful Workloads entstand der Bedarf nach einer spezialisierten Gruppe, die sich mit den damit verbundenen Speicherproblemen auseinandersetzt.\u003c/p\u003e\n\u003cp\u003eXing Yang, Co-Vorsitzender von SIG Storage und Software-Ingenieur bei VMware, erläutert, dass die Gruppe Standards für die Integration von Speicheranbietern in Kubernetes definiert. Dies geschieht durch die Entwicklung der \u003ca href=\"/kubernetes/\"\u003eContainer Storage Interface\u003c/a\u003e (CSI), die es Drittanbietern ermöglicht, ihre eigenen Plugins unabhängig von der Kubernetes-Kernarchitektur zu erstellen und zu verwalten. Dies hat die Integration von Speicherlösungen in Kubernetes erheblich vereinfacht.\u003c/p\u003e\n\u003cp\u003eZu den aktuellen Projekten von SIG Storage gehören mehrere bedeutende Funktionen, die darauf abzielen, die Datensicherheit und -verwaltung zu verbessern. Eine der herausragendsten Entwicklungen ist das Volume Group Snapshot, das eine konsistente Momentaufnahme mehrerer PersistentVolumes ermöglicht. Diese Funktion wurde in Kubernetes v1.36 in den Status „General Availability“ überführt und stellt sicher, dass Datenintegrität für Anwendungen gewährleistet ist, die auf mehrere Volumes angewiesen sind.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Feature ist das Changed Block Tracking (CBT), das ebenfalls in Kubernetes v1.36 in den Beta-Status überführt wurde. CBT ermöglicht effiziente, inkrementelle Backups, indem nur die Datenblöcke übertragen werden, die sich seit der letzten Sicherung geändert haben. Dies reduziert die Menge an zu übertragenden Daten erheblich und verbessert somit die Effizienz der Datensicherung.\u003c/p\u003e\n\u003cp\u003eZusätzlich wird die Container Object Storage Interface (COSI) entwickelt, die eine standardisierte Schnittstelle für die Bereitstellung und Nutzung von Objektspeicher in Kubernetes bietet. COSI zielt darauf ab, die Nutzung von Objektspeicher in Kubernetes-Anwendungen zu vereinfachen und zu standardisieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Arbeit von SIG Storage hat weitreichende Implikationen für die Kubernetes-Community und die Nutzung von \u003ca href=\"/kubernetes/\"\u003eCloud-native\u003c/a\u003e Architekturen. Die Einführung von CSI hat die Art und Weise revolutioniert, wie Speicherlösungen in Kubernetes integriert werden, indem es eine modulare und erweiterbare Architektur ermöglicht. Die neuen Funktionen wie Volume Group Snapshot und CBT sind entscheidend für Unternehmen, die auf Datenintegrität und Effizienz in ihrer Cloud-Infrastruktur angewiesen sind. Diese Entwicklungen unterstützen nicht nur die Verwaltung von Daten, sondern auch die Einhaltung von Best Practices in der Datensicherung und -wiederherstellung.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eSIG Storage spielt eine entscheidende Rolle bei der Weiterentwicklung der Speicherlösungen in Kubernetes. Die laufenden Projekte und die Einführung neuer Funktionen werden die Nutzung von Kubernetes für stateful Anwendungen weiter verbessern und die Integration von Speicherlösungen vereinfachen. Die Gruppe wird weiterhin an innovativen Lösungen arbeiten, um den sich wandelnden Anforderungen der Cloud-native Landschaft gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR SIG Storage ist eine spezielle Interessengruppe innerhalb des Kubernetes-Projekts, die sich mit der Bereitstellung und Verwaltung von persistentem Speicher für Containeranwendungen beschäftigt. Die Gruppe arbeitet an wichtigen Funktionen wie Volume Group Snapshot und Changed Block Tracking, um die Datenintegrität und Effizienz bei der Datensicherung zu verbessern.\nHauptinhalt SIG Storage hat sich als zentrale Anlaufstelle für die Herausforderungen der Speicherung in Kubernetes etabliert. Die Gruppe wurde gegründet, um die Anforderungen an persistente Daten zu adressieren, da Kubernetes ursprünglich für stateless Anwendungen konzipiert wurde. Mit der zunehmenden Nutzung von stateful Workloads entstand der Bedarf nach einer spezialisierten Gruppe, die sich mit den damit verbundenen Speicherproblemen auseinandersetzt.\n", "image": "https://ayedo.de/spotlight-on-sig-storage.png", "date_published": "2026-06-15T00:00:00Z", "date_modified": "2026-06-15T00:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/news/docker-hardened-images-enhanced-vulnerability-scanning-with-docker-and-aikido/", "url": "https://ayedo.de/news/docker-hardened-images-enhanced-vulnerability-scanning-with-docker-and-aikido/", "title": "Docker gehärtete Images mit verbessertem Schwachstellenscan durch Docker und Aikido", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDocker hat die Schwachstellenscans für \u003ca href=\"https://www.docker.com/\"\u003eDocker Hardened Images\u003c/a\u003e (DHI) durch die Integration mit Aikido verbessert. Diese neue Funktion filtert automatisch nicht ausnutzbare Schwachstellen heraus, wodurch Entwickler sich auf relevante Sicherheitsprobleme konzentrieren können. DHI bietet eine geringere Angriffsfläche und schnellere Patches, was in der heutigen schnelllebigen Softwareentwicklung von entscheidender Bedeutung ist.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit dem Anstieg von Schwachstellenmeldungen (CVEs) sehen sich moderne Entwicklungsteams einer enormen Flut an Sicherheitsproblemen gegenüber. Die Geschwindigkeit, mit der Software entwickelt wird, hat zugenommen, da KI-gestützte Tools Code schneller generieren und dabei zahlreiche Abhängigkeiten einbeziehen. Dies führt dazu, dass jede Basis-Image, die verwendet wird, potenziell neue CVEs in die Warteschlange bringt. Vor diesem Hintergrund gewinnen \u003ca href=\"https://www.docker.com/\"\u003eDocker Hardened Images\u003c/a\u003e an Bedeutung, da sie speziell entwickelt wurden, um eine minimale und geprüfte Basis für Anwendungen zu bieten.\u003c/p\u003e\n\u003cp\u003eDocker Hardened Images sind oft distroless und enthalten nur die Software, die für den jeweiligen Arbeitslast erforderlich ist. Dies reduziert die Angriffsfläche und ermöglicht schnellere Sicherheitsupdates. Allerdings können traditionelle Schwachstellenscanner Schwierigkeiten haben, diese Images korrekt zu analysieren, da sie keine Paketmanager oder Shells enthalten. Dies führt häufig zu Fehlalarmen und zu einer Überlastung der Entwickler mit irrelevanten Sicherheitsmeldungen.\u003c/p\u003e\n\u003cp\u003eDie Integration von Aikido in den Schwachstellenscan für DHI schließt diese Lücke. DHI veröffentlicht nun signierte VEX-Bestätigungen zusammen mit jedem Image. Aikido nutzt diese Bestätigungen, um während der Analyse nicht ausnutzbare CVEs herauszufiltern. Dies ermöglicht es den Teams, sich auf die tatsächlich relevanten Sicherheitsprobleme zu konzentrieren.\u003c/p\u003e\n\u003cp\u003eUm DHI mit Aikido zu scannen, sind drei Voraussetzungen erforderlich: ein aktives Aikido-Konto, Zugang zu Docker Hardened Images und ein Docker Hub Personal Access Token mit Lesezugriff. Nach der Verbindung des Docker Hub mit Aikido erkennt das System automatisch die DHI und scannt diese ohne zusätzliche Konfiguration.\u003c/p\u003e\n\u003cp\u003eDer Scanprozess folgt einer klaren technischen Spezifikation: Zunächst wird das DHI-Basisimage identifiziert, gefolgt von der Katalogisierung der Komponenten durch Abruf des signierten SBOM (Software Bill of Materials). Anschließend werden die Komponenten mit den verfügbaren Schwachstellenfeeds abgeglichen. Über die VEX-Bestätigungen von Docker werden dann alle als gelöst markierten Befunde unterdrückt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie VEX-Statusanzeigen, die in Aikido sichtbar sind, bieten eine klare Übersicht über den Zustand der Schwachstellen. Die Statusanzeigen umfassen \u0026ldquo;Fixed\u0026rdquo;, \u0026ldquo;Not Affected\u0026rdquo;, \u0026ldquo;Under Investigation\u0026rdquo; und \u0026ldquo;Affected\u0026rdquo;. Dies ermöglicht eine schnelle Beurteilung, ob ein Image tatsächlich verwundbar ist oder nicht. Die Benutzeroberfläche von Aikido konzentriert sich darauf, die Anzahl der anzuzeigenden CVEs erheblich zu reduzieren, sodass nur die relevanten Sicherheitsprobleme angezeigt werden.\u003c/p\u003e\n\u003cp\u003eDurch diese Integration wird der Scanprozess effizienter, da Teams nicht mehr durch irrelevante Informationen abgelenkt werden. Die Möglichkeit, Schwachstellen schnell zu identifizieren und zu priorisieren, ist für die Sicherheit und \u003ca href=\"https://www.compliance.com/\"\u003eCompliance\u003c/a\u003e von Anwendungen von großer Bedeutung.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Verbesserung der Schwachstellenscans für Docker Hardened Images durch die Integration mit Aikido stellt einen bedeutenden Fortschritt in der Sicherheitsarchitektur dar. Die Automatisierung der Filterung irrelevanter Schwachstellen ermöglicht es Entwicklungsteams, ihre Ressourcen effektiver zu nutzen und sich auf die wesentlichen Sicherheitsaspekte zu konzentrieren.\u003c/p\u003e\n", "summary": "TL;DR Docker hat die Schwachstellenscans für Docker Hardened Images (DHI) durch die Integration mit Aikido verbessert. Diese neue Funktion filtert automatisch nicht ausnutzbare Schwachstellen heraus, wodurch Entwickler sich auf relevante Sicherheitsprobleme konzentrieren können. DHI bietet eine geringere Angriffsfläche und schnellere Patches, was in der heutigen schnelllebigen Softwareentwicklung von entscheidender Bedeutung ist.\nHauptinhalt Mit dem Anstieg von Schwachstellenmeldungen (CVEs) sehen sich moderne Entwicklungsteams einer enormen Flut an Sicherheitsproblemen gegenüber. Die Geschwindigkeit, mit der Software entwickelt wird, hat zugenommen, da KI-gestützte Tools Code schneller generieren und dabei zahlreiche Abhängigkeiten einbeziehen. Dies führt dazu, dass jede Basis-Image, die verwendet wird, potenziell neue CVEs in die Warteschlange bringt. Vor diesem Hintergrund gewinnen Docker Hardened Images an Bedeutung, da sie speziell entwickelt wurden, um eine minimale und geprüfte Basis für Anwendungen zu bieten.\n", "image": "https://ayedo.de/docker-hardened-images-enhanced-vulnerability-scanning-with-docker-and-aikido.png", "date_published": "2026-06-11T12:00:00Z", "date_modified": "2026-06-11T12:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/5-software-supply-chain-security-best-practices-for-development-teams/", "url": "https://ayedo.de/news/5-software-supply-chain-security-best-practices-for-development-teams/", "title": "5 Best Practices zur Sicherheit der Software-Lieferkette für Entwicklungsteams", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit der Software-Lieferkette gewinnt für Entwicklungsteams zunehmend an Bedeutung, da die Angriffsfläche kontinuierlich wächst. Fünf bewährte Praktiken helfen Teams, ihre \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e -basierten Workloads zu schützen: Verwendung vertrauenswürdiger Inhalte, Sicherung der Build-Pipeline, Verifizierung vor der Bereitstellung, Zugangskontrollen und kontinuierliche Überwachung.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit der Software-Lieferkette stellt eine Herausforderung dar, insbesondere in der heutigen Zeit, in der Angriffe auf Open-Source-Software und Drittanbieter stetig zunehmen. Um diese Risiken zu minimieren, sollten Entwicklungsteams konkrete, wiederholbare Maßnahmen ergreifen. Die folgenden fünf Best Practices sind darauf ausgelegt, Teams beim Aufbau und Versand von \u003ca href=\"/kubernetes/\"\u003econtainerbasierten\u003c/a\u003e Anwendungen zu unterstützen.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eVerwendung vertrauenswürdiger Inhalte\u003c/strong\u003e: Der erste Schritt besteht darin, minimalistische und verifizierte Basisbilder auszuwählen. Jedes Container-Image erbt die Sicherheitslage seines Basisbildes. Daher ist es wichtig, Basisbilder zu wählen, die regelmäßig gewartet werden und vollständige Software-Bill-of-Materials (SBOM) sowie kryptografische Signaturen enthalten. Minimalistische Bilder reduzieren die Angriffsfläche, indem sie unnötige Komponenten entfernen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSicherung der Build-Pipeline\u003c/strong\u003e: Die Provenienz von Builds sollte durch kryptografische Attestierungen gesichert werden. Dies bedeutet, dass jede Artefakt-Bereitstellung dokumentiert werden muss, um die Quelle, das Build-System und die Umgebungsintegrität zu garantieren. Die Implementierung des SLSA-Frameworks (Supply Chain Levels for Software Artifacts) hilft dabei, die Integrität der Builds zu gewährleisten.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eVerifizierung vor der Bereitstellung\u003c/strong\u003e: Vor der Bereitstellung sollten alle Abhängigkeiten auf ihre Integrität überprüft werden. Dies geschieht durch das Festlegen von Abhängigkeiten auf genaue Versionen und durch das Verwenden von Lock-Dateien, die in der Continuous Integration (CI) überprüft werden. Wenn eine Abhängigkeit nicht mit dem festgelegten Hash übereinstimmt, sollte der Build fehlschlagen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eZugangskontrollen und Richtlinien\u003c/strong\u003e: Die Implementierung von richtliniengesteuerten Zugangskontrollen über Registries und Pipelines ist entscheidend, um sicherzustellen, dass nur vertrauenswürdige Artefakte in die Produktionsumgebung gelangen. Diese Kontrollen sollten in die CI/CD-Pipeline integriert werden.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eKontinuierliche Überwachung\u003c/strong\u003e: Die Überwachung der Software-Lieferkette sollte ein fortlaufender Prozess sein. Teams sollten in der Lage sein, potenzielle Sicherheitsvorfälle in Echtzeit zu erkennen und darauf zu reagieren, um die Integrität der Software-Lieferkette zu schützen.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung dieser Best Practices erfordert eine enge Zusammenarbeit zwischen Entwicklung und Sicherheit. Die Verwendung von minimalen Basisbildern und die Sicherstellung der Integrität durch kryptografische Mechanismen sind entscheidend, um die Angriffsfläche zu verringern. Die Einführung von SLSA-Standards kann dazu beitragen, die Vertrauenswürdigkeit der Builds zu erhöhen, während die kontinuierliche Überwachung sicherstellt, dass potenzielle Bedrohungen zeitnah erkannt werden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit der Software-Lieferkette sollte als fortlaufender Prozess betrachtet werden, der in den gesamten Entwicklungszyklus integriert ist. Durch die Anwendung dieser Best Practices können Entwicklungsteams ihre Resilienz gegenüber modernen Bedrohungen erheblich steigern.\u003c/p\u003e\n", "summary": "TL;DR Die Sicherheit der Software-Lieferkette gewinnt für Entwicklungsteams zunehmend an Bedeutung, da die Angriffsfläche kontinuierlich wächst. Fünf bewährte Praktiken helfen Teams, ihre Container -basierten Workloads zu schützen: Verwendung vertrauenswürdiger Inhalte, Sicherung der Build-Pipeline, Verifizierung vor der Bereitstellung, Zugangskontrollen und kontinuierliche Überwachung.\nHauptinhalt Die Sicherheit der Software-Lieferkette stellt eine Herausforderung dar, insbesondere in der heutigen Zeit, in der Angriffe auf Open-Source-Software und Drittanbieter stetig zunehmen. Um diese Risiken zu minimieren, sollten Entwicklungsteams konkrete, wiederholbare Maßnahmen ergreifen. Die folgenden fünf Best Practices sind darauf ausgelegt, Teams beim Aufbau und Versand von containerbasierten Anwendungen zu unterstützen.\n", "image": "https://ayedo.de/5-software-supply-chain-security-best-practices-for-development-teams.png", "date_published": "2026-06-08T19:54:40Z", "date_modified": "2026-06-08T19:54:40Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["security","docker","development","kubernetes","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/what-is-ai-governance-frameworks-principles-and-best-practices/", "url": "https://ayedo.de/news/what-is-ai-governance-frameworks-principles-and-best-practices/", "title": "Was ist AI Governance? Rahmenwerke, Prinzipien und Best Practices", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAI-Governance umfasst die Rahmenwerke, Richtlinien und Kontrollen, die Organisationen benötigen, um künstliche Intelligenz (KI) verantwortungsbewusst zu entwickeln, einzusetzen und zu überwachen. Angesichts der zunehmenden Autonomie von KI-Agenten ist eine effektive Governance entscheidend, um Risiken zu minimieren, Compliance-Anforderungen zu erfüllen und das Vertrauen der Stakeholder zu stärken.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eAI-Governance ist ein umfassendes System, das die Verantwortlichkeiten und Standards für den Umgang mit künstlicher Intelligenz innerhalb einer Organisation definiert. Es regelt, wie KI-Modelle entwickelt, implementiert und überwacht werden, um sicherzustellen, dass sie den geschäftlichen Zielen, rechtlichen Vorgaben und ethischen Standards entsprechen. Die Governance umfasst technische Sicherheitsmaßnahmen wie Modellüberwachung und Zugriffsrichtlinien sowie organisatorische Prozesse wie Überprüfungsgremien und Risikobewertungen.\u003c/p\u003e\n\u003cp\u003eMit der zunehmenden Autonomie von KI-Agenten in der Produktion müssen Governance-Rahmen auch Aspekte wie Sicherheit im laufenden Betrieb, Zugriffssteuerung und spezifische Aufsicht über die Agenten berücksichtigen. Organisationen, die Governance frühzeitig in ihre Entwicklungsabläufe integrieren, sind besser aufgestellt, um KI sicher zu skalieren und sich an sich ändernde Vorschriften anzupassen.\u003c/p\u003e\n\u003cp\u003eDie Bedeutung von AI-Governance ist in der heutigen Zeit besonders offensichtlich, da viele Unternehmen KI in verschiedenen Bereichen wie Personalwesen, Finanzmodellierung und Kundenservice einsetzen. Fehlende Governance kann schwerwiegende Folgen haben, wie etwa die Diskriminierung qualifizierter Bewerber durch voreingenommene Algorithmen oder Sicherheitsrisiken bei der Verarbeitung sensibler Daten. Governance hilft, diese Risiken zu minimieren, indem sie Test-, Überwachungs- und Überprüfungsprozesse etabliert, die Probleme frühzeitig erkennen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung eines effektiven AI-Governance-Rahmens erfordert ein tiefes Verständnis der relevanten gesetzlichen Rahmenbedingungen, wie dem EU AI Act und dem NIST AI Risk Management Framework. Diese Vorschriften schaffen durchsetzbare Standards, die Organisationen einhalten müssen. Die Governance-Praxis sollte daher auch die Entwicklung transparenter KI-Modelle und klarer Datenhandhabungsrichtlinien umfassen, um das Vertrauen von Kunden und Partnern zu gewinnen.\u003c/p\u003e\n\u003cp\u003eEin gut gestalteter Governance-Rahmen ermöglicht es Unternehmen, KI-Initiativen in einem wiederholbaren und prüfbaren Prozess zu steuern, wodurch unkoordinierte Risiken vermieden werden. Studien zeigen, dass Unternehmen, die eine aktive Rolle des oberen Managements in der AI-Governance fördern, signifikant höhere Geschäftsergebnisse aus ihren KI-Investitionen erzielen können.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eIn Anbetracht der fortschreitenden Integration von KI in Geschäftsprozesse ist die Etablierung robuster Governance-Strukturen unerlässlich. Organisationen, die AI-Governance proaktiv angehen, werden besser in der Lage sein, die Herausforderungen und Chancen der KI-Nutzung zu meistern.\u003c/p\u003e\n\u003cp\u003eZusätzlich sollten Unternehmen auch die Prinzipien von \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e und \u003ca href=\"/compliance/\"\u003eDSGVO\u003c/a\u003e in ihre Governance-Strategien integrieren, um rechtliche Risiken zu minimieren.\u003c/p\u003e\n", "summary": "TL;DR AI-Governance umfasst die Rahmenwerke, Richtlinien und Kontrollen, die Organisationen benötigen, um künstliche Intelligenz (KI) verantwortungsbewusst zu entwickeln, einzusetzen und zu überwachen. Angesichts der zunehmenden Autonomie von KI-Agenten ist eine effektive Governance entscheidend, um Risiken zu minimieren, Compliance-Anforderungen zu erfüllen und das Vertrauen der Stakeholder zu stärken.\nHauptinhalt AI-Governance ist ein umfassendes System, das die Verantwortlichkeiten und Standards für den Umgang mit künstlicher Intelligenz innerhalb einer Organisation definiert. Es regelt, wie KI-Modelle entwickelt, implementiert und überwacht werden, um sicherzustellen, dass sie den geschäftlichen Zielen, rechtlichen Vorgaben und ethischen Standards entsprechen. Die Governance umfasst technische Sicherheitsmaßnahmen wie Modellüberwachung und Zugriffsrichtlinien sowie organisatorische Prozesse wie Überprüfungsgremien und Risikobewertungen.\n", "image": "https://ayedo.de/what-is-ai-governance-frameworks-principles-and-best-practices.png", "date_published": "2026-06-05T18:39:35Z", "date_modified": "2026-06-05T18:39:35Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/identity-and-access-management-whitepaper/", "url": "https://ayedo.de/news/identity-and-access-management-whitepaper/", "title": "Identitäts- und Zugriffsmanagement-Whitepaper", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eIdentitäts- und Zugriffsmanagement (IAM) wird in \u003ca href=\"/kubernetes/\"\u003ecloud-nativen\u003c/a\u003e Architekturen zunehmend wichtig, da traditionelle Sicherheitsansätze den dynamischen Anforderungen nicht mehr gerecht werden. Ein aktuelles Whitepaper bietet praktische Leitlinien zur Implementierung von IAM in cloud-nativen Umgebungen, einschließlich Authentifizierung, Autorisierung und Sicherheitsarchitekturen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit der zunehmenden Verbreitung von cloud-nativen Architekturen, die durch verteilte, dynamische und automatisierte Komponenten geprägt sind, wird Identität zum neuen Sicherheitsperimeter. Die herkömmlichen Methoden zur Authentifizierung und Autorisierung stoßen an ihre Grenzen, insbesondere bei kurzlebigen Workloads, der Kommunikation zwischen Diensten und den Anforderungen an Zero-Trust-Sicherheitsmodelle.\u003c/p\u003e\n\u003cp\u003eDas Whitepaper zum Identitäts- und Zugriffsmanagement bietet wertvolle Einblicke für Architekten, Plattformingenieure, Sicherheitsexperten und Anwendungsentwickler, die IAM in cloud-nativen Umgebungen implementieren möchten. Es wird erläutert, warum IAM eine grundlegende Rolle für die Sicherheit in cloud-nativen Systemen spielt und welche modernen Standards zur Authentifizierung von Benutzern und Workloads eingesetzt werden sollten.\u003c/p\u003e\n\u003cp\u003eEin zentrales Thema des Whitepapers ist die Unterscheidung zwischen perimeterbasierten Architekturen und Zero-Trust-Architekturen. Es wird beschrieben, wann welche Architekturform am besten geeignet ist, um den Sicherheitsanforderungen gerecht zu werden. Zudem werden Best Practices für die Autorisierung unter Verwendung von Policy Enforcement Points (PEP) und Policy Decision Points (PDP) vorgestellt.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Aspekt ist die Rolle von SPIFFE (Secure Production Identity Framework for Everyone), das eine sichere Identität für Workloads und die Authentifizierung zwischen Diensten ermöglicht. Das Whitepaper bietet auch Referenzmuster zur Sicherung sowohl zustandsbehafteter als auch zustandsloser Workloads, was für die Entwicklung robuster und sicherer cloud-nativer Systeme von Bedeutung ist.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung von IAM in cloud-nativen Umgebungen erfordert ein tiefes Verständnis der aktuellen Sicherheitsstandards und -praktiken. Die Verwendung von Zero-Trust-Architekturen kann helfen, Sicherheitslücken zu schließen, indem jeder Zugriff auf Ressourcen als potenziell unsicher betrachtet wird, unabhängig von der Herkunft. Die Integration von SPIFFE zur Identitätsverwaltung ermöglicht eine sichere Kommunikation zwischen Mikroservices und steigert die Resilienz der Anwendungen.\u003c/p\u003e\n\u003cp\u003eDie Best Practices für die Autorisierung, die im Whitepaper dargelegt werden, können dazu beitragen, die Angriffsfläche zu reduzieren und die Einhaltung von Sicherheitsrichtlinien zu gewährleisten. Die Referenzmuster bieten wertvolle Ansätze, um sowohl zustandsbehaftete als auch zustandslose Workloads in cloud-nativen Umgebungen effektiv zu sichern.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDas Whitepaper zu Identitäts- und Zugriffsmanagement bietet umfassende und praxisnahe Leitlinien für die Implementierung von IAM in modernen cloud-nativen Architekturen. Die Erkenntnisse sind entscheidend für die Gewährleistung von Sicherheit und \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e in einer zunehmend komplexen IT-Landschaft.\u003c/p\u003e\n", "summary": "TL;DR Identitäts- und Zugriffsmanagement (IAM) wird in cloud-nativen Architekturen zunehmend wichtig, da traditionelle Sicherheitsansätze den dynamischen Anforderungen nicht mehr gerecht werden. Ein aktuelles Whitepaper bietet praktische Leitlinien zur Implementierung von IAM in cloud-nativen Umgebungen, einschließlich Authentifizierung, Autorisierung und Sicherheitsarchitekturen.\nHauptinhalt Mit der zunehmenden Verbreitung von cloud-nativen Architekturen, die durch verteilte, dynamische und automatisierte Komponenten geprägt sind, wird Identität zum neuen Sicherheitsperimeter. Die herkömmlichen Methoden zur Authentifizierung und Autorisierung stoßen an ihre Grenzen, insbesondere bei kurzlebigen Workloads, der Kommunikation zwischen Diensten und den Anforderungen an Zero-Trust-Sicherheitsmodelle.\n", "image": "https://ayedo.de/identity-and-access-management-whitepaper.png", "date_published": "2026-06-04T18:23:17Z", "date_modified": "2026-06-04T18:23:17Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","security","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/hardened-images-explained-fewer-cves-smaller-attack-surface/", "url": "https://ayedo.de/news/hardened-images-explained-fewer-cves-smaller-attack-surface/", "title": "Härtung von Images erklärt: Weniger CVEs, kleinere Angriffsfläche", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHärtung von \u003ca href=\"/kubernetes/\"\u003eContainer-Images\u003c/a\u003e reduziert die Angriffsfläche erheblich, indem nur notwendige Laufzeitkomponenten beibehalten werden. Dies verringert die Anzahl der bekannten Schwachstellen und verbessert die Sicherheit durch kontinuierliche Wartung und verifizierbare Metadaten.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIn modernen \u003ca href=\"/kubernetes/\"\u003eContainer-Umgebungen\u003c/a\u003e stellen Sicherheitsteams häufig fest, dass die Mehrheit der bekannten Schwachstellen nicht aus dem Anwendungscode selbst, sondern aus überflüssigen Paketen stammt, die mit dem Basis-Image ausgeliefert werden. Diese Pakete, darunter Shells, Compiler und Debugging-Tools, erhöhen die Angriffsfläche und stellen ein erhebliches Sicherheitsrisiko dar. Die Härtung von Images zielt darauf ab, dieses Problem an der Wurzel zu packen, indem sie speziell entwickelte Basis-Images bereitstellt, die auf die erforderlichen Laufzeitkomponenten einer Anwendung beschränkt sind.\u003c/p\u003e\n\u003cp\u003eHärtete Images sind so konzipiert, dass sie nur die unbedingt notwendigen Komponenten enthalten und kontinuierlich aktualisiert werden. Sie sind mit verifizierbaren Metadaten ausgestattet, die es Sicherheitsteams ermöglichen, den Inhalt und die Herkunft des Images nachzuvollziehen. Dadurch wird das Risiko, das von unnötigen Paketen ausgeht, signifikant reduziert.\u003c/p\u003e\n\u003cp\u003eEin typisches allgemeines Basis-Image kann Hunderte von installierten Paketen enthalten, von denen eine Containeranwendung oft nur 20 bis 30 tatsächlich benötigt. Die restlichen Pakete sind überflüssig und stellen potenzielle Angriffsflächen dar. Sicherheits-Scanner identifizieren diese Pakete als Schwachstellen, auch wenn sie von der Anwendung nicht verwendet werden. Dies führt zu einem Signal-Rausch-Problem, bei dem echte Sicherheitsbedrohungen in einer Flut von irrelevanten Warnungen untergehen.\u003c/p\u003e\n\u003cp\u003eDie Härtung von Images umfasst mehrere Aspekte. Die Minimierung ist dabei der sichtbarste Teil, aber nicht der einzige. Ein gehärtetes Image ist auch kontinuierlich gewartet und unabhängig verifizierbar. Es werden keine Shells, Paketmanager oder Debugging-Tools mitgeliefert; nur die Laufzeitkomponenten, die für die Funktion der Anwendung erforderlich sind, bleiben erhalten. Dies führt zu einer drastisch kleineren Anzahl von CVEs (Common Vulnerabilities and Exposures) im Vergleich zu allgemeinen Basis-Images.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eHärtete Images werden nicht nur einmalig erstellt, sondern kontinuierlich gewartet. Eine einmalige Härtung führt dazu, dass das Image schnell veraltet ist, da neue Schwachstellen in den verwendeten Paketen auftreten können. Die besten gehärteten Images werden regelmäßig rebuilt, um sicherzustellen, dass alle Sicherheitsupdates und Patches zeitnah integriert werden. Dies erfordert ein aktives Monitoring der verwendeten Softwareprojekte und eine klare Wartungsstrategie.\u003c/p\u003e\n\u003cp\u003eZusätzlich beinhalten gehärtete Images verifizierbare Metadaten, wie Software Bills of Materials (SBOMs), die alle Pakete, Versionen und Abhängigkeiten auflisten. Solche Metadaten sind entscheidend für die Einhaltung von Best Practices in der Lieferkette und unterstützen die Sicherheitsüberprüfungen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Härtung von \u003ca href=\"/kubernetes/\"\u003eContainer-Images\u003c/a\u003e ist ein wesentlicher Schritt zur Verbesserung der Sicherheit in \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Umgebungen. Durch die Reduzierung der Angriffsfläche und die kontinuierliche Wartung können Unternehmen ihre Sicherheitslage signifikant stärken und das Risiko von Sicherheitsvorfällen minimieren.\u003c/p\u003e\n", "summary": "TL;DR Härtung von Container-Images reduziert die Angriffsfläche erheblich, indem nur notwendige Laufzeitkomponenten beibehalten werden. Dies verringert die Anzahl der bekannten Schwachstellen und verbessert die Sicherheit durch kontinuierliche Wartung und verifizierbare Metadaten.\nHauptinhalt In modernen Container-Umgebungen stellen Sicherheitsteams häufig fest, dass die Mehrheit der bekannten Schwachstellen nicht aus dem Anwendungscode selbst, sondern aus überflüssigen Paketen stammt, die mit dem Basis-Image ausgeliefert werden. Diese Pakete, darunter Shells, Compiler und Debugging-Tools, erhöhen die Angriffsfläche und stellen ein erhebliches Sicherheitsrisiko dar. Die Härtung von Images zielt darauf ab, dieses Problem an der Wurzel zu packen, indem sie speziell entwickelte Basis-Images bereitstellt, die auf die erforderlichen Laufzeitkomponenten einer Anwendung beschränkt sind.\n", "image": "https://ayedo.de/hardened-images-explained-fewer-cves-smaller-attack-surface.png", "date_published": "2026-06-04T17:02:51Z", "date_modified": "2026-06-04T17:02:51Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","kubernetes","security","cloud-native","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/securing-ci-cd-for-an-open-source-project-controlling-who-runs-what/", "url": "https://ayedo.de/news/securing-ci-cd-for-an-open-source-project-controlling-who-runs-what/", "title": "CI/CD für ein Open-Source-Projekt absichern: Kontrolle darüber, wer was ausführt", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eCilium hat Maßnahmen ergriffen, um die Sicherheit seiner CI/CD-Pipeline zu erhöhen und die Risiken bei der Nutzung von Open-Source-Software zu minimieren. Die wichtigsten Kontrollen umfassen Einschränkungen bei Workflow-Auslösern, zwei Phasen bei der Codeausführung, SHA-pinning von Abhängigkeiten und die Signierung von Releases. Diese Praktiken sind für jedes Open-Source-Projekt von Bedeutung und können auf ähnliche CI/CD-Umgebungen angewendet werden.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIn den letzten zwölf Monaten gab es mehrere bedeutende Sicherheitsvorfälle in der Open-Source-Lieferkette, die auf die Verwundbarkeit von CI/CD-Umgebungen hinweisen. Angriffe auf Pakete in Repositories wie npm und PyPI haben dazu geführt, dass bösartige Software in ansonsten legitime Releases eingeschleust wurde. Diese Vorfälle verdeutlichen die Notwendigkeit, Open-Source-Projekte gegen solche Bedrohungen abzusichern, insbesondere für Projekte wie Cilium, das in der Netzwerkebene von Millionen von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Pods eingesetzt wird.\u003c/p\u003e\n\u003cp\u003eCilium hat verschiedene Sicherheitsmaßnahmen implementiert, um sicherzustellen, dass nur autorisierte Personen Builds auslösen und dass der ausgeführte Code sicher ist. Eine zentrale Komponente ist Ariane, ein In-House-Tool, das die Ausführung von CI-Workflows aus PR-Kommentaren steuert. Nur Mitglieder der Organisation mit überprüften Berechtigungen können CI-Workflows auslösen, und die erlaubten Workflows sind in einer Konfigurationsdatei festgelegt.\u003c/p\u003e\n\u003cp\u003eUm zu gewährleisten, dass nur vertrauenswürdiger Code ausgeführt wird, verwendet Cilium ein zweistufiges Checkout-Verfahren für Pull-Requests. Dabei wird der vertrauenswürdige Code aus dem Basis-Branch geladen, während der Code des PR-Kopfes lediglich als \u003ca href=\"/kubernetes/\"\u003eDocker\u003c/a\u003e-Build-Kontext dient und nicht als Skript ausgeführt wird.\u003c/p\u003e\n\u003cp\u003eDie Überprüfung von CI-Änderungen erfolgt durch die CODEOWNERS-Datei, die sicherstellt, dass Änderungen im Verzeichnis .github/ von einem sicherheitsfokussierten CI-Team überprüft werden. Zudem werden alle Abhängigkeiten, die in CI verwendet werden, durch SHA-Pinning gesichert, was bedeutet, dass jede verwendete Referenz auf einen spezifischen Commit verweist.\u003c/p\u003e\n\u003cp\u003eEin weiteres Sicherheitsmerkmal ist die Verwendung von vendored Go-Abhängigkeiten, die sicherstellen, dass alle Abhängigkeiten überprüft und im vendor/-Verzeichnis gespeichert werden. Dies reduziert das Risiko, dass ein gehacktes oder typosquatted Modul unentdeckt bleibt.\u003c/p\u003e\n\u003cp\u003eDie CI-Umgebung ist von Produktionsumgebungen isoliert, sodass CI-Anmeldeinformationen nur auf Entwicklungs-Tags zugreifen können. Produktionsanmeldeinformationen sind in einer geschützten Umgebung gespeichert, die eine Genehmigung durch einen Maintainer erfordert.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung dieser Sicherheitsmaßnahmen erfordert eine sorgfältige Planung und kontinuierliche Überwachung. Die Verwendung von SHA-Pinning und vendored Abhängigkeiten bietet eine zusätzliche Sicherheitsebene, die in vielen Projekten noch nicht standardmäßig implementiert ist. Die Isolation von CI- und Produktionsanmeldeinformationen ist entscheidend, um das Risiko einer Kompromittierung zu minimieren.\u003c/p\u003e\n\u003cp\u003eDie Herausforderungen, die Cilium noch zu bewältigen hat, umfassen das Fehlen von SLSA-Provenienz, die Notwendigkeit einer PR-Zeit-Abhängigkeitsüberprüfung und die Implementierung von govulncheck in CI. Diese Aspekte sind wichtig, um die Sicherheitsstandards weiter zu erhöhen und die Integrität der Software zu gewährleisten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Sicherheitspraktiken von Cilium bieten wertvolle Einblicke in die Absicherung von CI/CD-Pipelines für Open-Source-Projekte. Die kontinuierliche Verbesserung und Anpassung dieser Maßnahmen wird entscheidend sein, um zukünftigen Bedrohungen in der Software-Lieferkette proaktiv zu begegnen.\u003c/p\u003e\n", "summary": "TL;DR Cilium hat Maßnahmen ergriffen, um die Sicherheit seiner CI/CD-Pipeline zu erhöhen und die Risiken bei der Nutzung von Open-Source-Software zu minimieren. Die wichtigsten Kontrollen umfassen Einschränkungen bei Workflow-Auslösern, zwei Phasen bei der Codeausführung, SHA-pinning von Abhängigkeiten und die Signierung von Releases. Diese Praktiken sind für jedes Open-Source-Projekt von Bedeutung und können auf ähnliche CI/CD-Umgebungen angewendet werden.\nHauptinhalt In den letzten zwölf Monaten gab es mehrere bedeutende Sicherheitsvorfälle in der Open-Source-Lieferkette, die auf die Verwundbarkeit von CI/CD-Umgebungen hinweisen. Angriffe auf Pakete in Repositories wie npm und PyPI haben dazu geführt, dass bösartige Software in ansonsten legitime Releases eingeschleust wurde. Diese Vorfälle verdeutlichen die Notwendigkeit, Open-Source-Projekte gegen solche Bedrohungen abzusichern, insbesondere für Projekte wie Cilium, das in der Netzwerkebene von Millionen von Kubernetes-Pods eingesetzt wird.\n", "image": "https://ayedo.de/securing-ci-cd-for-an-open-source-project-controlling-who-runs-what.png", "date_published": "2026-06-04T11:00:00Z", "date_modified": "2026-06-04T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","docker","software-delivery","security"], "language": "de" },{ "id": "https://ayedo.de/news/inspektor-gadget-results-from-the-first-security-audit/", "url": "https://ayedo.de/news/inspektor-gadget-results-from-the-first-security-audit/", "title": "Inspektor Gadget: Ergebnisse des ersten Sicherheitsaudits", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eInspektor Gadget, ein auf eBPF basierendes Toolkit für die Überwachung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und Linux-Hosts, hat erfolgreich ein unabhängiges Sicherheitsaudit abgeschlossen. Die Ergebnisse zeigen drei identifizierte Schwachstellen, die alle behoben wurden, sowie Empfehlungen zur weiteren Härtung der Software.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eInspektor Gadget ist ein Open-Source-Toolkit, das eBPF nutzt, um Daten in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Clustern und auf Linux-Hosts zu sammeln und zu analysieren. Es ermöglicht die Verwaltung, Bereitstellung und Ausführung von „Gadgets“ – eBPF-Programmen, die als OCI-Images verpackt sind. Dies ermöglicht eine nahtlose Verteilung und Ausführung dieser Images über verschiedene konforme Werkzeuge und Registries hinweg. Für Teams, die \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e in Produktionsumgebungen betreiben, bietet Inspektor Gadget eine tiefgehende Einsicht in die Betriebsabläufe, ohne dass die üblichen Einschränkungen wie das Neubauen von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e-Images oder das Einfügen von Sidecars erforderlich sind. eBPF-Programme werden zur Laufzeit in den Kernel geladen, um Syscalls, Netzwerkaktivitäten und Dateizugriffe sicher zu beobachten, während die Anwendungen unverändert weiterlaufen.\u003c/p\u003e\n\u003cp\u003eDie Notwendigkeit eines Sicherheitsaudits ergibt sich aus der Tatsache, dass Inspektor Gadget mit Root-Rechten auf Knoten arbeitet. Eine unabhängige Überprüfung der Sicherheitslage ist daher ein logischer Schritt, um das Vertrauen in das Tool zu stärken. Das Audit wurde von der Open Source Technology Improvement Fund (OSTIF) koordiniert und von Shielder durchgeführt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDas Audit umfasste eine Kombination aus Bedrohungsmodellierung, manuellem Quellcode-Review, dynamischen Tests in Laborumgebungen, statischer Analyse mit Tools wie Semgrep und GoSec sowie KI-unterstützter Codeüberprüfung. Die Forscher erstellten drei Testumgebungen, die die reale Bereitstellung von Inspektor Gadget simulierten: eine lokale Linux-Host-Bereitstellung, eine Remote-Daemon-Bereitstellung und eine \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Bereitstellung auf Minikube.\u003c/p\u003e\n\u003cp\u003eWährend des Audits wurden drei Schwachstellen identifiziert, von denen keine als kritisch oder hoch eingestuft wurde. Zwei Schwachstellen hatten mittlere Schweregrade:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eBefehlsinjektion\u003c/strong\u003e in der Bildbauphase, die durch nicht korrekt escape-te Benutzereingaben in Makefiles verursacht wurde (CVE-2026-24905). Diese Schwachstelle wurde in der Version v0.48.1 behoben.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDenial of Service\u003c/strong\u003e durch Event-Fluten, bei dem ein bösartiger \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e den eBPF-Ringpuffer überfluten konnte, was dazu führte, dass das System Ereignisse von anderen Containern stillschweigend verwirft. Diese Schwachstelle wurde in der Version v0.50.1 behoben.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eEine dritte Schwachstelle mit niedrigem Schweregrad betraf unsanitized ANSI-Escape-Sequenzen in der Spaltenausgabe (CVE-2026-25996), die in der Version v0.49.1 behoben wurde.\u003c/p\u003e\n\u003cp\u003eZusätzlich wurden sechs Empfehlungen zur Härtung des Projekts ausgesprochen, um die Angriffsfläche im Laufe der Zeit zu reduzieren. Dazu gehören die Durchsetzung von TLS für TCP-Listener, die Überprüfung von externen Abhängigkeiten in CI/CD-Pipelines sowie die Implementierung einer \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Namespace-Blockliste.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Ergebnisse des Sicherheitsaudits von Inspektor Gadget bestätigen die Sicherheitsmaßnahmen des Projekts und bieten wertvolle Empfehlungen zur weiteren Härtung. Die Behebung der identifizierten Schwachstellen und die Umsetzung der Empfehlungen können dazu beitragen, die Sicherheit und Zuverlässigkeit des Tools in Produktionsumgebungen zu erhöhen.\u003c/p\u003e\n", "summary": "TL;DR Inspektor Gadget, ein auf eBPF basierendes Toolkit für die Überwachung von Kubernetes und Linux-Hosts, hat erfolgreich ein unabhängiges Sicherheitsaudit abgeschlossen. Die Ergebnisse zeigen drei identifizierte Schwachstellen, die alle behoben wurden, sowie Empfehlungen zur weiteren Härtung der Software.\nHauptinhalt Inspektor Gadget ist ein Open-Source-Toolkit, das eBPF nutzt, um Daten in Kubernetes-Clustern und auf Linux-Hosts zu sammeln und zu analysieren. Es ermöglicht die Verwaltung, Bereitstellung und Ausführung von „Gadgets“ – eBPF-Programmen, die als OCI-Images verpackt sind. Dies ermöglicht eine nahtlose Verteilung und Ausführung dieser Images über verschiedene konforme Werkzeuge und Registries hinweg. Für Teams, die Kubernetes in Produktionsumgebungen betreiben, bietet Inspektor Gadget eine tiefgehende Einsicht in die Betriebsabläufe, ohne dass die üblichen Einschränkungen wie das Neubauen von Container-Images oder das Einfügen von Sidecars erforderlich sind. eBPF-Programme werden zur Laufzeit in den Kernel geladen, um Syscalls, Netzwerkaktivitäten und Dateizugriffe sicher zu beobachten, während die Anwendungen unverändert weiterlaufen.\n", "image": "https://ayedo.de/inspektor-gadget-results-from-the-first-security-audit.png", "date_published": "2026-06-03T23:01:00Z", "date_modified": "2026-06-03T23:01:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","development","compliance"], "language": "de" },{ "id": "https://ayedo.de/news/what-is-software-supply-chain-security/", "url": "https://ayedo.de/news/what-is-software-supply-chain-security/", "title": "Was ist die Sicherheit der Software-Lieferkette?", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit der Software-Lieferkette ist entscheidend, um alle Komponenten und Prozesse, die an der Erstellung und Bereitstellung von Software beteiligt sind, zu schützen. Angesichts der steigenden Anzahl bösartiger Pakete in Open-Source-Repositories müssen Organisationen ihre Vertrauensentscheidungen über Abhängigkeiten und \u003ca href=\"/kubernetes/\"\u003eContainer-Images\u003c/a\u003e aktiv überdenken, um Sicherheitsrisiken zu minimieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit der Software-Lieferkette bezieht sich auf den Schutz aller Elemente, die an der Entwicklung und Bereitstellung von Software beteiligt sind, einschließlich Quellcode, Abhängigkeiten, Build-Systeme, Artefakt-Registrierungen und Produktionsinfrastrukturen. Diese Disziplin geht über die traditionelle Anwendungssicherheit hinaus, die sich hauptsächlich auf den selbst geschriebenen Code konzentriert. Stattdessen umfasst sie alles, was mit dem Code in Berührung kommt, bevor er in die Produktion geht, insbesondere in \u003ca href=\"/kubernetes/\"\u003econtainerbasierten\u003c/a\u003e Bereitstellungspipelines.\u003c/p\u003e\n\u003cp\u003eDie Dringlichkeit der Software-Lieferkettensicherheit wird durch einen grundlegenden Wandel in der Softwareentwicklung verstärkt. Moderne Anwendungen bestehen häufig aus bestehenden Komponenten anstelle von neu geschriebenem Code. Ein typisches Container-Image kann Hunderte von Paketen enthalten, von denen jedes seine eigene Abhängigkeitsstruktur und Aktualisierungsfrequenz hat. Dies führt zu einer Vielzahl von Vertrauensentscheidungen, die oft implizit getroffen werden, ohne dass eine gründliche Überprüfung stattfindet.\u003c/p\u003e\n\u003cp\u003eAngreifer nutzen diese Vertrauensproblematik aus, indem sie weit verbreitete Pakete kompromittieren, um Zugang zu Tausenden von nachgelagerten Organisationen zu erhalten. Techniken wie Dependency Confusion, Typosquatting und die Übernahme von Maintainer-Konten sind gängige Methoden, die in den Werkzeugkasten von Angreifern aufgenommen wurden. Die Auswirkungen solcher Angriffe können weitreichend sein und sich durch alle Organisationen ziehen, die die betroffenen Komponenten verwenden.\u003c/p\u003e\n\u003cp\u003eDie Einführung von Containern hat die Angriffsurface erheblich verändert. Container sind unveränderliche Software-Artefakte, die Anwendungscode zusammen mit Betriebssystemabhängigkeiten und Konfiguration bündeln. Diese Unveränderlichkeit bietet einen Sicherheitsvorteil, da genau das getestet wird, was auch bereitgestellt wird. Allerdings bedeutet dies auch, dass jede Schwachstelle in einem Container-Image direkt in die Produktion gelangt, es sei denn, es erfolgt eine aktive Überprüfung und Aktualisierung.\u003c/p\u003e\n\u003cp\u003eEin zentraler Punkt in der Software-Lieferkette ist die \u003ca href=\"/kubernetes/\"\u003eContainer-Registrierung\u003c/a\u003e, in der Images gespeichert und verteilt werden. Wenn ein Angreifer ein manipuliertes Image in eine Registrierung einschleust oder eine Bereitstellungspipeline dazu bringt, ein nicht verifiziertes Image zu ziehen, kann die Kompromittierung ohne Aktivierung von Sicherheitskontrollen auf Code-Ebene in die Produktion gelangen. Daher sind die Sicherheit der Registrierungen, das Signieren von Images und die Pull-Richtlinien entscheidende Aspekte der Lieferkettensicherheit, die mit der Containerisierung an Bedeutung gewonnen haben.\u003c/p\u003e\n\u003cp\u003eZusätzlich verschärfen regulatorische Anforderungen die Notwendigkeit für Unternehmen, sich mit der Sicherheit der Software-Lieferkette auseinanderzusetzen. Bestimmungen, wie das Executive Order 14028 zur Verbesserung der Cybersicherheit in den USA, verlangen von Softwareanbietern, bestimmte Sicherheitsstandards in ihren Lieferketten zu erfüllen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eEine effektive Strategie zur Sicherstellung der Software-Lieferkettensicherheit sollte auf vertrauenswürdigem Inhalt basieren, einschließlich verifizierter Images, signierter Artefakte und Software-Bill-of-Materials (SBOMs), die in jeder Phase der Pipeline durchgesetzt werden. Die Behandlung der Lieferkettensicherheit als Infrastrukturdisziplin, anstatt nur als \u003ca href=\"/compliance/\"\u003eCompliance-Anforderung\u003c/a\u003e, ermöglicht es Organisationen, Bedrohungen frühzeitig zu erkennen und schneller darauf zu reagieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit der Software-Lieferkette wird zunehmend zu einem zentralen Anliegen für Unternehmen, die moderne Software entwickeln und bereitstellen. Angesichts der wachsenden Komplexität der Softwarelandschaft ist es unerlässlich, proaktive Maßnahmen zu ergreifen, um Sicherheitsrisiken zu minimieren und das Vertrauen in Softwarekomponenten zu stärken.\u003c/p\u003e\n", "summary": "TL;DR Die Sicherheit der Software-Lieferkette ist entscheidend, um alle Komponenten und Prozesse, die an der Erstellung und Bereitstellung von Software beteiligt sind, zu schützen. Angesichts der steigenden Anzahl bösartiger Pakete in Open-Source-Repositories müssen Organisationen ihre Vertrauensentscheidungen über Abhängigkeiten und Container-Images aktiv überdenken, um Sicherheitsrisiken zu minimieren.\nHauptinhalt Die Sicherheit der Software-Lieferkette bezieht sich auf den Schutz aller Elemente, die an der Entwicklung und Bereitstellung von Software beteiligt sind, einschließlich Quellcode, Abhängigkeiten, Build-Systeme, Artefakt-Registrierungen und Produktionsinfrastrukturen. Diese Disziplin geht über die traditionelle Anwendungssicherheit hinaus, die sich hauptsächlich auf den selbst geschriebenen Code konzentriert. Stattdessen umfasst sie alles, was mit dem Code in Berührung kommt, bevor er in die Produktion geht, insbesondere in containerbasierten Bereitstellungspipelines.\n", "image": "https://ayedo.de/what-is-software-supply-chain-security.png", "date_published": "2026-06-03T18:24:39Z", "date_modified": "2026-06-03T18:24:39Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","development","cloud-native","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/how-to-secure-ai-agents-a-practical-overview-for-development-teams/", "url": "https://ayedo.de/news/how-to-secure-ai-agents-a-practical-overview-for-development-teams/", "title": "Wie man AI Agents sichert: Ein praktischer Überblick für Entwicklungsteams", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Sicherheit von AI-Agenten erfordert einen neuen Ansatz, da diese autonom agieren und somit neue Angriffsflächen schaffen. Wichtige Sicherheitsmaßnahmen umfassen die Isolierung der Ausführungsumgebung, die Kontrolle des Zugriffs auf Tools, das Management von Identitäten und Berechtigungen sowie die Überwachung der Agenten im Betrieb.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eAI-Agenten gewinnen zunehmend an Bedeutung in der Softwareentwicklung, stellen jedoch auch neue Sicherheitsherausforderungen dar. Traditionelle Sicherheitspraktiken sind oft nicht ausreichend, um die Autonomie und das Verhalten dieser Agenten zu schützen. Ein Bericht zeigt, dass 45 % der Unternehmen Schwierigkeiten haben, die Sicherheit ihrer Agentenwerkzeuge zu gewährleisten. Dies liegt daran, dass Agenten dynamisch Entscheidungen treffen, welche Tools sie verwenden und wie sie Aktionen verknüpfen – ein Verhalten, das von herkömmlichen Sicherheitsmodellen nicht erfasst wird.\u003c/p\u003e\n\u003cp\u003eDie Sicherheitsstrategie für AI-Agenten sollte sich auf vier wesentliche Bereiche konzentrieren:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAusführungsisolation\u003c/strong\u003e: Agenten sollten in isolierten, temporären Umgebungen betrieben werden, um den Zugriff auf das Host-System und andere Agenten zu verhindern. Dies kann durch den Einsatz von Micro-VMs, gehärteten \u003ca href=\"/kubernetes/\"\u003eContainern\u003c/a\u003e oder speziellen Sandboxes erreicht werden. Diese Isolation schützt vor potenziellen Sicherheitslücken im Agenten selbst und ermöglicht eine schnellere und sicherere Ausführung.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eZugriffskontrolle auf Tools\u003c/strong\u003e: Es ist entscheidend, den Zugriff auf externe Systeme und Tools zu steuern. Agenten sollten nur die spezifischen Tools und APIs verwenden dürfen, die sie für ihre aktuelle Aufgabe benötigen. Dies minimiert die Angriffsfläche und verhindert, dass ein kompromittierter Agent unbefugte Aktionen durchführen kann.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eIdentitäts- und Berechtigungsmanagement\u003c/strong\u003e: Die Verwaltung der Identitäten und Berechtigungen von Agenten ist entscheidend, um sicherzustellen, dass sie nur die notwendigen Rechte haben. Dies erfordert ein dynamisches Berechtigungsmanagement, bei dem Agenten nur zu dem Zeitpunkt Zugriff auf Tools erhalten, wenn sie diese tatsächlich benötigen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eÜberwachung im laufenden Betrieb\u003c/strong\u003e: Eine kontinuierliche Überwachung der Aktivitäten von Agenten ist unerlässlich, um verdächtige oder unerwünschte Aktionen frühzeitig zu erkennen. Dies kann durch den Einsatz von Monitoring-Tools geschehen, die in der Lage sind, das Verhalten der Agenten in Echtzeit zu analysieren.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung dieser Sicherheitsmaßnahmen erfordert eine sorgfältige Planung und möglicherweise auch eine Anpassung bestehender Infrastrukturen. Beispielsweise könnte der Einsatz von \u003ca href=\"/kubernetes/\"\u003eContainer-Technologien\u003c/a\u003e oder Micro-VMs zusätzliche Ressourcen erfordern, bietet jedoch den Vorteil einer höheren Sicherheit durch Isolation. Zudem müssen Organisationen sicherstellen, dass ihre Netzwerkkontrollen ausreichend sind, um unbefugte Zugriffe zu verhindern, und dass ihre Identitätsmanagementsysteme flexibel genug sind, um dynamische Berechtigungen zu unterstützen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Sicherstellung der Sicherheit von AI-Agenten ist eine komplexe Herausforderung, die neue Strategien und Technologien erfordert. Mit der richtigen Herangehensweise können Organisationen jedoch die Vorteile dieser autonomen Systeme nutzen, während sie gleichzeitig die Sicherheitsrisiken minimieren.\u003c/p\u003e\n", "summary": "TL;DR Die Sicherheit von AI-Agenten erfordert einen neuen Ansatz, da diese autonom agieren und somit neue Angriffsflächen schaffen. Wichtige Sicherheitsmaßnahmen umfassen die Isolierung der Ausführungsumgebung, die Kontrolle des Zugriffs auf Tools, das Management von Identitäten und Berechtigungen sowie die Überwachung der Agenten im Betrieb.\nHauptinhalt AI-Agenten gewinnen zunehmend an Bedeutung in der Softwareentwicklung, stellen jedoch auch neue Sicherheitsherausforderungen dar. Traditionelle Sicherheitspraktiken sind oft nicht ausreichend, um die Autonomie und das Verhalten dieser Agenten zu schützen. Ein Bericht zeigt, dass 45 % der Unternehmen Schwierigkeiten haben, die Sicherheit ihrer Agentenwerkzeuge zu gewährleisten. Dies liegt daran, dass Agenten dynamisch Entscheidungen treffen, welche Tools sie verwenden und wie sie Aktionen verknüpfen – ein Verhalten, das von herkömmlichen Sicherheitsmodellen nicht erfasst wird.\n", "image": "https://ayedo.de/how-to-secure-ai-agents-a-practical-overview-for-development-teams.png", "date_published": "2026-06-02T16:11:02Z", "date_modified": "2026-06-02T16:11:02Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","development","security","cloud-native","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/cloud-native-is-now-ai-native-engineering-production-ready-ai/", "url": "https://ayedo.de/news/cloud-native-is-now-ai-native-engineering-production-ready-ai/", "title": "Cloud-native ist jetzt AI-native: Produktionstaugliche KI entwickeln", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Diskussion über die Integration von KI in produktive Umgebungen zeigt, dass \u003ca href=\"/kubernetes/\"\u003ecloud-native\u003c/a\u003e Prinzipien entscheidend sind, um AI-native Computing zu ermöglichen. Wesentliche Komponenten sind eine reife, vendor-neutrale Infrastruktur, integrierte Sicherheit und aktive Community-Beiträge. Die Herausforderungen beim Skalieren von KI-Workloads erfordern Anpassungen in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e, um den speziellen Anforderungen dieser Technologien gerecht zu werden.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eAuf der KubeCon + CloudNativeCon Europe wurde eine Expertenrunde einberufen, um die Herausforderungen und Möglichkeiten der Integration von KI in cloud-native Umgebungen zu erörtern. Die Panelisten kamen überein, dass für die Produktionsbereitschaft von KI drei zentrale Elemente erforderlich sind: eine ausgereifte Plattform, Sicherheit von Anfang an und aktive Mitwirkung an der Community.\u003c/p\u003e\n\u003cp\u003eDie Produktionsbereitschaft für KI wird erreicht, wenn Organisationen einen mehrdimensionalen Reifegrad der Plattform erfüllen. Ein entscheidendes Signal dafür ist die Übereinstimmung mit dem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e AI Conformance Programm, das essentielle Grundlagen für das Training und die Bereitstellung von KI-Anwendungen in großem Maßstab definiert.\u003c/p\u003e\n\u003cp\u003eDie Plattformreife umfasst die Bereitstellung robuster Unterstützung für Forschungsteams und Python-Nutzer, die spezialisierte Umgebungen benötigen. Sicherheitsaspekte müssen von Beginn an priorisiert werden, insbesondere für autonome Agenten, um sicherzustellen, dass diese in einem kontrollierten Rahmen operieren. Zudem sollten Unternehmen über die bloße Nutzung von Werkzeugen hinaus aktiv zur Weiterentwicklung innerhalb der CNCF Special Interest Groups (SIGs) beitragen.\u003c/p\u003e\n\u003cp\u003eDie Skalierung von KI-Workloads stellt eine größere Herausforderung dar als die von herkömmlichen Mikrodiensten, da KI-Workloads oft wie große Monolithen agieren. Diese Herausforderung ergibt sich aus der Notwendigkeit, mehrdimensionale Matrizen im Speicher über zahlreiche Client-Knoten hinweg zu initialisieren. Standard-\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e ist nicht für die enge Kopplung ausgelegt, die für solche hochleistungsfähigen Berechnungen erforderlich ist.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie cloud-native Community arbeitet aktiv daran, Kubernetes für hochleistungsfähige Berechnungen zu optimieren, ohne unflexible Architekturen zu schaffen. Zu den wichtigen Initiativen gehören:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003ePod Groups (Workload API)\u003c/strong\u003e: Diese Initiative behandelt Gruppen von Pods als einzelne Fehlerdomänen, was die Nähe und Zuverlässigkeit für die großflächige Initialisierung von KI-Matrizen gewährleistet.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eDynamic Resource Allocation (DRA)\u003c/strong\u003e: DRA integriert spezialisierte Chips und GPUs in den Kubernetes-Scheduler, um Hardwareanforderungen effizient zu verwalten und das Training sowie die Bereitstellung von KI zu optimieren.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eInference Gateways\u003c/strong\u003e: Diese nutzen Gateway API-Standards, um effiziente KI-Gateways zu erstellen, die bei der Verwaltung von Anfragen und der Bereitstellung von Antworten für komplexe generative Modelle helfen.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie Rolle der Ingenieure verändert sich durch den Einfluss von KI. Prototyping ersetzt zunehmend die traditionelle Produktanforderungsdokumentation, wobei Produktmanager mit KI-generierten Prototypen beginnen. Dies führt jedoch zu einem Engpass bei der Überprüfung, da die Menge an generiertem Code eine menschliche Überprüfung erfordert. Zukünftig wird eine agentische SRE (Site Reliability Engineering) angestrebt, bei der KI-Agenten bei der Ursachenanalyse und Problemlösung unterstützen, während Menschen weiterhin in entscheidenden Entscheidungen involviert bleiben.\u003c/p\u003e\n\u003cp\u003eDie Sicherheit der KI-Lieferkette erfordert eine erweiterte Betrachtung, die über herkömmliche \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e -Scans hinausgeht und die Integrität der Modell-Lieferkette sowie die Risiken nicht-deterministischer Ausgaben in den Fokus rückt. Die Community konzentriert sich auf zwei Hauptsicherheitsinitiativen: die Implementierung konsistenter Bewertungsrahmen (Evals) vor der Bereitstellung von Modellen und die Entwicklung offener Standards zur Zitierung, um gegen Risiken wie Remote-Code-Ausführung zu schützen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von KI in cloud-native Umgebungen erfordert ein Umdenken in der Infrastruktur und den Sicherheitsprotokollen. Zukünftige Entwicklungen sollten auf offenen, interoperablen und vendor-neutralen Standards basieren, um die Skalierung und Sicherheit von KI-Anwendungen zu gewährleisten.\u003c/p\u003e\n", "summary": "TL;DR Die Diskussion über die Integration von KI in produktive Umgebungen zeigt, dass cloud-native Prinzipien entscheidend sind, um AI-native Computing zu ermöglichen. Wesentliche Komponenten sind eine reife, vendor-neutrale Infrastruktur, integrierte Sicherheit und aktive Community-Beiträge. Die Herausforderungen beim Skalieren von KI-Workloads erfordern Anpassungen in Kubernetes, um den speziellen Anforderungen dieser Technologien gerecht zu werden.\nHauptinhalt Auf der KubeCon + CloudNativeCon Europe wurde eine Expertenrunde einberufen, um die Herausforderungen und Möglichkeiten der Integration von KI in cloud-native Umgebungen zu erörtern. Die Panelisten kamen überein, dass für die Produktionsbereitschaft von KI drei zentrale Elemente erforderlich sind: eine ausgereifte Plattform, Sicherheit von Anfang an und aktive Mitwirkung an der Community.\n", "image": "https://ayedo.de/cloud-native-is-now-ai-native-engineering-production-ready-ai.png", "date_published": "2026-06-02T11:00:00Z", "date_modified": "2026-06-02T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","security","development","cloud"], "language": "de" },{ "id": "https://ayedo.de/news/mumbai-maha-mahotsav-kubecon-cloudnativecon-india-edition/", "url": "https://ayedo.de/news/mumbai-maha-mahotsav-kubecon-cloudnativecon-india-edition/", "title": "Mumbai Maha Mahotsav – KubeCon + CloudNativeCon Indien-Ausgabe", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon India 2026 findet am 18. und 19. Juni im Jio World Convention Centre in Mumbai statt. Die Veranstaltung bringt Fachleute und Technologen aus der Open-Source- und \u003ca href=\"/kubernetes/\"\u003eCloud-Native-Community\u003c/a\u003e zusammen und hebt die Bedeutung von Cloud-Native-Technologien in einer der dynamischsten Städte Indiens hervor.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMumbai, bekannt als die Stadt der Träume, ist der Austragungsort der KubeCon + CloudNativeCon India 2026. Diese Konferenz vereint Entwickler, Ingenieure und Entscheidungsträger aus der \u003ca href=\"/kubernetes/\"\u003eCloud-Native-\u003c/a\u003e und Open-Source-Community, um aktuelle Trends und Technologien zu diskutieren. Die Wahl von Mumbai als Veranstaltungsort spiegelt die technologische Innovationskraft der Stadt wider, die als Zentrum für Banken, Börsen und digitale Plattformen gilt.\u003c/p\u003e\n\u003cp\u003eDie Konferenz findet im Jio World Convention Centre statt, einem der modernsten Veranstaltungsorte Asiens. Die Veranstaltung bietet eine Plattform für den Austausch von Wissen und Erfahrungen im Bereich Cloud-Native-Technologien, die in Mumbai stark mit den Anforderungen des realen Betriebs verbunden sind. Dies umfasst unter anderem die Handhabung von Finanztransaktionen, die Skalierung von Streaming-Diensten und die Unterstützung von Logistiknetzwerken, die rund um die Uhr operieren.\u003c/p\u003e\n\u003cp\u003eDie Stadt bietet eine Vielzahl von Verkehrsanbindungen, die es den Teilnehmern erleichtern, sich fortzubewegen. Neben dem gut funktionierenden U-Bahn-System sind auch lokale Züge und Busse verfügbar. Für die Anreise zum Veranstaltungsort wird empfohlen, ausreichend Zeit einzuplanen, um Staus zu vermeiden.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Bedeutung von Cloud-Native-Technologien in Mumbai wird durch die hohe Nachfrage nach Verfügbarkeit, Beobachtbarkeit und Automatisierung in der Infrastruktur unterstrichen. Die Stadt ist ein Paradebeispiel für eine Umgebung, in der technologische Lösungen entwickelt werden, um den Herausforderungen eines dynamischen Marktes zu begegnen. Die Präzision und Effizienz, die in den lokalen Lieferketten und im öffentlichen Verkehrssystem zu beobachten sind, könnten als Modell für IT-Betriebsabläufe dienen.\u003c/p\u003e\n\u003cp\u003eDie Konferenz wird auch die Möglichkeit bieten, neue Ansätze für die Implementierung von \u003ca href=\"/kubernetes/\"\u003eDevOps-Praktiken\u003c/a\u003e zu erkunden, die für die Verbesserung der Effizienz und Reaktionsfähigkeit in der Softwareentwicklung entscheidend sind.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon India 2026 bietet eine wichtige Gelegenheit für Fachleute, sich über die neuesten Entwicklungen im Bereich Cloud-Native-Technologien auszutauschen und die Innovationskraft von Mumbai zu erleben. Die Veranstaltung wird voraussichtlich einen bedeutenden Einfluss auf die zukünftige Entwicklung der IT-Branche in der Region haben.\u003c/p\u003e\n", "summary": "TL;DR Die KubeCon + CloudNativeCon India 2026 findet am 18. und 19. Juni im Jio World Convention Centre in Mumbai statt. Die Veranstaltung bringt Fachleute und Technologen aus der Open-Source- und Cloud-Native-Community zusammen und hebt die Bedeutung von Cloud-Native-Technologien in einer der dynamischsten Städte Indiens hervor.\nHauptinhalt Mumbai, bekannt als die Stadt der Träume, ist der Austragungsort der KubeCon + CloudNativeCon India 2026. Diese Konferenz vereint Entwickler, Ingenieure und Entscheidungsträger aus der Cloud-Native- und Open-Source-Community, um aktuelle Trends und Technologien zu diskutieren. Die Wahl von Mumbai als Veranstaltungsort spiegelt die technologische Innovationskraft der Stadt wider, die als Zentrum für Banken, Börsen und digitale Plattformen gilt.\n", "image": "https://ayedo.de/mumbai-maha-mahotsav-kubecon-cloudnativecon-india-edition.png", "date_published": "2026-06-02T11:00:00Z", "date_modified": "2026-06-02T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","automation","kubernetes","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/from-kubernetes-dashboard-to-headlamp-understanding-the-transition/", "url": "https://ayedo.de/news/from-kubernetes-dashboard-to-headlamp-understanding-the-transition/", "title": "Vom Kubernetes Dashboard zu Headlamp: Die Transition verstehen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDas \u003ca href=\"https://kubernetes.io/\"\u003eKubernetes\u003c/a\u003e Dashboard wurde archiviert und durch \u003ca href=\"https://headlamp.dev/\"\u003eHeadlamp\u003c/a\u003e ersetzt, das eine verbesserte Benutzeroberfläche für Kubernetes bietet. Headlamp erweitert die Funktionalitäten des Dashboards um Multi-Cluster-Sichtbarkeit, anwendungszentrierte Ansichten und eine erweiterbare Plugin-Architektur, während es gleichzeitig die vertrauten Arbeitsabläufe beibehält.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://kubernetes.io/\"\u003eKubernetes\u003c/a\u003e Dashboard war für viele Nutzer der erste Zugang zu Kubernetes und bot eine einfache visuelle Darstellung von Clustern, Ressourcen und Arbeitslasten. Es diente als wichtiges Hilfsmittel für Entwickler und Operatoren, um sich im Kubernetes-Ökosystem zurechtzufinden. Mit der Archivierung des Kubernetes Dashboards wird Headlamp als neue Benutzeroberfläche eingeführt, die auf den bestehenden Funktionen aufbaut und diese erweitert.\u003c/p\u003e\n\u003cp\u003eHeadlamp bewahrt die Klarheit der visuellen Darstellung und fügt gleichzeitig moderne Funktionen hinzu, die den heutigen Anforderungen an Kubernetes entsprechen. Dazu gehören die Möglichkeit, mehrere Cluster gleichzeitig zu überwachen, anwendungszentrierte Ansichten zu nutzen, die Benutzeroberfläche durch Plugins zu erweitern und flexible Bereitstellungsoptionen sowohl im Cluster als auch lokal zu nutzen.\u003c/p\u003e\n\u003cp\u003eDie Migration von Kubernetes Dashboard zu Headlamp wird als nahtlos beschrieben. Viele der gewohnten Arbeitsabläufe bleiben erhalten, was den Übergang erleichtert. Nutzer können weiterhin Workloads wie Pods, Deployments und Services einfach finden und inspizieren. Die Navigation zwischen Namespaces und Clustern wurde optimiert, was insbesondere bei der Arbeit mit mehreren Umgebungen von Vorteil ist.\u003c/p\u003e\n\u003cp\u003eDas Editieren und Interagieren mit Ressourcen bleibt ebenfalls unverändert. Nutzer können Manifestdateien direkt in der Benutzeroberfläche basierend auf ihren Berechtigungen anzeigen und bearbeiten. Alle Aktionen folgen den Standard-RBAC-Richtlinien von Kubernetes, sodass alle zuvor möglichen Aktionen auch in Headlamp verfügbar sind.\u003c/p\u003e\n\u003cp\u003eEin wesentlicher Fortschritt von Headlamp ist die verbesserte Darstellung von Beziehungen zwischen Ressourcen. Neben Listenansichten bietet Headlamp visuelle Darstellungen, die aufzeigen, wie Workloads, Services und Konfigurationen miteinander verbunden sind. Dies ermöglicht es Nutzern, den Kontext besser zu verstehen, ohne die zugrunde liegenden Workloads zu verändern.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eHeadlamp ermöglicht die Verwaltung von Multi-Cluster-Umgebungen aus einer einzigen Benutzeroberfläche, was insbesondere für Teams von Vorteil ist, die mehrere \u003ca href=\"https://kubernetes.io/\"\u003eKubernetes\u003c/a\u003e Cluster betreiben. Die neue Funktionalität, Projekte zu nutzen, bietet anwendungszentrierte Ansichten, die es einfacher machen, zusammengehörige Workloads und Ressourcen zu gruppieren. Dies verbessert die Nachverfolgbarkeit von Änderungen und die Fehlersuche.\u003c/p\u003e\n\u003cp\u003eZusätzlich kann Headlamp durch Plugins erweitert werden, die gängige Arbeitsabläufe direkt in die Benutzeroberfläche integrieren. Dies reduziert die Notwendigkeit, zwischen verschiedenen Tools zu wechseln, und sorgt für einen konsistenten Arbeitskontext. Ein Beispiel ist das Flux-Plugin, das GitOps-Workflows in Headlamp integriert und es Teams ermöglicht, den Anwendungsstatus zusammen mit den Kubernetes-Ressourcen zu sehen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eHeadlamp stellt eine bedeutende Weiterentwicklung des Kubernetes Dashboards dar, indem es die Benutzerfreundlichkeit verbessert und gleichzeitig die gewohnten Arbeitsabläufe beibehält. Die neuen Funktionen und die Erweiterbarkeit durch Plugins bieten eine solide Grundlage für die zukünftige Entwicklung und Nutzung von \u003ca href=\"https://kubernetes.io/\"\u003eKubernetes\u003c/a\u003e in komplexen Umgebungen.\u003c/p\u003e\n", "summary": "TL;DR Das Kubernetes Dashboard wurde archiviert und durch Headlamp ersetzt, das eine verbesserte Benutzeroberfläche für Kubernetes bietet. Headlamp erweitert die Funktionalitäten des Dashboards um Multi-Cluster-Sichtbarkeit, anwendungszentrierte Ansichten und eine erweiterbare Plugin-Architektur, während es gleichzeitig die vertrauten Arbeitsabläufe beibehält.\nHauptinhalt Kubernetes Dashboard war für viele Nutzer der erste Zugang zu Kubernetes und bot eine einfache visuelle Darstellung von Clustern, Ressourcen und Arbeitslasten. Es diente als wichtiges Hilfsmittel für Entwickler und Operatoren, um sich im Kubernetes-Ökosystem zurechtzufinden. Mit der Archivierung des Kubernetes Dashboards wird Headlamp als neue Benutzeroberfläche eingeführt, die auf den bestehenden Funktionen aufbaut und diese erweitert.\n", "image": "https://ayedo.de/from-kubernetes-dashboard-to-headlamp-understanding-the-transition.png", "date_published": "2026-06-01T18:00:00Z", "date_modified": "2026-06-01T18:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","software-delivery","digital-sovereignty","platform"], "language": "de" },{ "id": "https://ayedo.de/news/what-is-sandbox-security/", "url": "https://ayedo.de/news/what-is-sandbox-security/", "title": "Was ist Sandbox-Sicherheit?", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eSandbox-Sicherheit ist entscheidend, um die Isolation von Prozessen in Cloud-Umgebungen zu gewährleisten. Sie umfasst Richtlinien und Mechanismen, die verhindern, dass untrusted Prozesse ihre Grenzen überschreiten, insbesondere im Kontext von KI-Agenten, die in Produktionsumgebungen Code ausführen. Effektive Sandbox-Sicherheit kombiniert Prozessisolierung, Systemaufruffilterung, Netzwerksegmentierung und Ressourcenlimits.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eSandbox-Sicherheit stellt sicher, dass die Isolation von Prozessen in einer Sandbox tatsächlich funktioniert und nicht durch Sicherheitslücken gefährdet wird. Diese Sicherheitsmaßnahmen sind besonders relevant, da KI-Agenten zunehmend Code in produktiven Umgebungen ausführen. Ein unzureichend gesicherter Sandbox-Bereich kann gefährlich sein, da er theoretische Isolation bietet, aber in der Praxis durch Schwachstellen gefährdet ist.\u003c/p\u003e\n\u003cp\u003eFür Entwickler und Plattformingenieure bedeutet dies, dass sie konkrete Entscheidungen treffen müssen, wie etwa welche Systemaufrufe ein Agent ausführen darf, ob ein Prozess auf das Netzwerk zugreifen kann und wie viel Speicher oder CPU er nutzen darf. Diese Entscheidungen sind keine abstrakten Fragen, sondern erfordern spezifische Konfigurationen und Audits.\u003c/p\u003e\n\u003cp\u003eDie fünf Kernkomponenten der Sandbox-Sicherheit sind:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eProzessisolierung\u003c/strong\u003e: Diese Komponente gewährleistet, dass der Code innerhalb einer Sandbox keinen Zugriff auf Prozesse im Host-System oder in anderen Sandboxes hat. In Linux wird dies durch Kernel-Namensräume erreicht, die Prozess-IDs, Netzwerk-Schnittstellen und Dateisysteme in separate Bereiche partitionieren. Eine unsachgemäße Konfiguration kann jedoch dazu führen, dass ein Prozess ungewollt auf andere Prozesse zugreifen kann.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSystemaufruffilterung\u003c/strong\u003e: Diese Maßnahme beschränkt, welche Kernel-Funktionen ein sandboxed Prozess aufrufen kann. In Linux wird dies häufig durch seccomp-Profile umgesetzt, die eine reduzierte Angriffsfläche bieten. Für sicherheitskritische Anwendungen sind maßgeschneiderte seccomp-Profile empfehlenswert, um den Zugriff auf nur die notwendigen Systemaufrufe zu gewähren.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eNetzwerksegmentierung\u003c/strong\u003e: Eine Sandbox, die uneingeschränkten Zugriff auf externe Systeme hat, ist schwerer zu schützen. Durch die Einschränkung der Netzwerkverbindungen kann verhindert werden, dass ein kompromittierter Agent Daten nach außen überträgt oder auf interne Dienste zugreift, die nicht vorgesehen sind.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eRessourcenlimits und -quoten\u003c/strong\u003e: Um Angriffe durch Ressourcenerschöpfung zu verhindern, ist es wichtig, Limits für CPU und Speicher festzulegen. Dies schützt die Sandbox vor übermäßiger Belastung und potenziellen Denial-of-Service-Angriffen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eLaufzeitüberwachung\u003c/strong\u003e: Diese Komponente ermöglicht es, die Aktivitäten innerhalb der Sandbox in Echtzeit zu überwachen und auf verdächtige Verhaltensweisen zu reagieren. Laufzeitüberwachung ist entscheidend, um schnell auf Sicherheitsvorfälle reagieren zu können.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung von Sandbox-Sicherheit erfordert ein tiefes Verständnis der zugrunde liegenden Technologien und der spezifischen Anforderungen der Anwendungen. Die Kombination der verschiedenen Sicherheitsmechanismen sorgt dafür, dass ein Versagen in einem Bereich nicht die gesamte Sandbox gefährdet. Die richtige Konfiguration und regelmäßige Audits sind entscheidend, um die Sicherheitsrichtlinien auf dem neuesten Stand zu halten und potenzielle Schwachstellen zu identifizieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eIn einer zunehmend komplexen IT-Landschaft wird Sandbox-Sicherheit immer wichtiger, insbesondere mit dem Aufkommen von KI-Agenten in produktiven Umgebungen. Die Implementierung robuster Sicherheitsrichtlinien und -mechanismen ist entscheidend, um die Integrität und Sicherheit von \u003ca href=\"/cloud-native/\"\u003eCloud-nativen\u003c/a\u003e Anwendungen zu gewährleisten.\u003c/p\u003e\n", "summary": "TL;DR Sandbox-Sicherheit ist entscheidend, um die Isolation von Prozessen in Cloud-Umgebungen zu gewährleisten. Sie umfasst Richtlinien und Mechanismen, die verhindern, dass untrusted Prozesse ihre Grenzen überschreiten, insbesondere im Kontext von KI-Agenten, die in Produktionsumgebungen Code ausführen. Effektive Sandbox-Sicherheit kombiniert Prozessisolierung, Systemaufruffilterung, Netzwerksegmentierung und Ressourcenlimits.\nHauptinhalt Sandbox-Sicherheit stellt sicher, dass die Isolation von Prozessen in einer Sandbox tatsächlich funktioniert und nicht durch Sicherheitslücken gefährdet wird. Diese Sicherheitsmaßnahmen sind besonders relevant, da KI-Agenten zunehmend Code in produktiven Umgebungen ausführen. Ein unzureichend gesicherter Sandbox-Bereich kann gefährlich sein, da er theoretische Isolation bietet, aber in der Praxis durch Schwachstellen gefährdet ist.\n", "image": "https://ayedo.de/what-is-sandbox-security.png", "date_published": "2026-06-01T15:51:31Z", "date_modified": "2026-06-01T15:51:31Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/coding-agent-horror-stories-the-rm-rf-incident/", "url": "https://ayedo.de/news/coding-agent-horror-stories-the-rm-rf-incident/", "title": "Coding-Agent-Horrorgeschichten: Der rm -rf ~/ Vorfall", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin Vorfall mit einem KI-Coding-Agenten führte dazu, dass ein Entwickler seine gesamte Home-Verzeichnis auf einem Mac unwiderruflich löschte. Der Fehler beruhte auf einer fehlerhaften Eingabe, bei der ein einfaches Kommando mit einem nachgestellten Slash die gesamte Datenstruktur des Benutzers löschte. Diese Vorfälle verdeutlichen die Notwendigkeit von Sicherheitsmaßnahmen wie \u003ca href=\"/kubernetes/\"\u003eDocker-Sandboxes\u003c/a\u003e, um derartige katastrophale Fehler zu verhindern.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIm Dezember 2025 berichtete ein Entwickler über einen schwerwiegenden Vorfall, bei dem ein KI-Coding-Agent namens Claude Code das Kommando \u003ccode\u003erm -rf tests/ patches/ plan/ ~/\u003c/code\u003e ausführte. Der nachgestellte Slash (\u003ccode\u003e~/\u003c/code\u003e) führte dazu, dass das gesamte Home-Verzeichnis des Entwicklers gelöscht wurde, was massive Datenverluste zur Folge hatte. Der Entwickler hatte Claude Code beauftragt, alte Repositorys zu bereinigen, ohne die potenziellen Risiken des Kommandos zu berücksichtigen.\u003c/p\u003e\n\u003cp\u003eDas Problem liegt in der Funktionsweise des Unix-Befehls \u003ccode\u003e~\u003c/code\u003e, der als Platzhalter für das Home-Verzeichnis des Benutzers fungiert. In Kombination mit \u003ccode\u003erm -rf\u003c/code\u003e, das Dateien rekursiv und ohne Bestätigung löscht, führte dies zu einem katastrophalen Datenverlust. Innerhalb von Sekunden waren wichtige Verzeichnisse wie Desktop, Dokumente, Downloads und sogar die Keychain, die für die Authentifizierung in verschiedenen Anwendungen nötig ist, unwiderruflich gelöscht.\u003c/p\u003e\n\u003cp\u003eDieser Vorfall ist nicht isoliert. Ein ähnlicher Vorfall wurde bereits im Oktober 2025 dokumentiert, als ein Entwickler meldete, dass Claude Code versuchte, Dateien auf einem Ubuntu-System zu löschen, und dabei Tausende von „Permission denied“-Meldungen erzeugte. Auch hier führte das Kommando zu einem massiven Datenverlust, da die Berechtigungen des Agenten nicht korrekt überprüft wurden.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Vorfälle verdeutlichen eine kritische Schwachstelle in der Architektur von KI-Coding-Agenten: Sie führen Befehle im Kontext des Benutzers aus, ohne ausreichende Sicherheitsvorkehrungen, um katastrophale Fehler zu verhindern. Die Verwendung von Flags wie \u003ccode\u003e--dangerously-skip-permissions\u003c/code\u003e verstärkt das Risiko, da diese die Sicherheitsmechanismen des Systems umgehen können.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eDocker-Sandboxes\u003c/a\u003e bieten eine mögliche Lösung, indem sie eine isolierte Umgebung schaffen, die solche Fehler auf der Ausführungsebene eindämmt. Durch die Implementierung von Docker-Sandboxen können Entwickler sicherstellen, dass die Auswirkungen von fehlerhaften Befehlen in einem geschützten Raum bleiben, wodurch der Verlust kritischer Daten minimiert wird.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Vorfälle mit KI-Coding-Agenten verdeutlichen die dringende Notwendigkeit, Sicherheitsmaßnahmen zu implementieren, um Datenverluste zu verhindern. Die Einführung von isolierten Ausführungsumgebungen wie \u003ca href=\"/kubernetes/\"\u003eDocker-Sandboxes\u003c/a\u003e könnte eine effektive Strategie sein, um die Risiken, die mit der Verwendung von KI in der Softwareentwicklung verbunden sind, zu minimieren.\u003c/p\u003e\n", "summary": "TL;DR Ein Vorfall mit einem KI-Coding-Agenten führte dazu, dass ein Entwickler seine gesamte Home-Verzeichnis auf einem Mac unwiderruflich löschte. Der Fehler beruhte auf einer fehlerhaften Eingabe, bei der ein einfaches Kommando mit einem nachgestellten Slash die gesamte Datenstruktur des Benutzers löschte. Diese Vorfälle verdeutlichen die Notwendigkeit von Sicherheitsmaßnahmen wie Docker-Sandboxes, um derartige katastrophale Fehler zu verhindern.\nHauptinhalt Im Dezember 2025 berichtete ein Entwickler über einen schwerwiegenden Vorfall, bei dem ein KI-Coding-Agent namens Claude Code das Kommando rm -rf tests/ patches/ plan/ ~/ ausführte. Der nachgestellte Slash (~/) führte dazu, dass das gesamte Home-Verzeichnis des Entwicklers gelöscht wurde, was massive Datenverluste zur Folge hatte. Der Entwickler hatte Claude Code beauftragt, alte Repositorys zu bereinigen, ohne die potenziellen Risiken des Kommandos zu berücksichtigen.\n", "image": "https://ayedo.de/coding-agent-horror-stories-the-rm-rf-incident.png", "date_published": "2026-06-01T13:00:00Z", "date_modified": "2026-06-01T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","development","operations"], "language": "de" },{ "id": "https://ayedo.de/news/dynamic-configuration-for-cloud-native-swift-services/", "url": "https://ayedo.de/news/dynamic-configuration-for-cloud-native-swift-services/", "title": "Dynamische Konfiguration für cloudnative Swift-Dienste", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Swift-Konfigurationsbibliothek bietet eine strukturierte Lösung für die Verwaltung von Konfigurationen in cloud-nativen Swift-Diensten, die auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e basieren. Sie ermöglicht eine klare Priorisierung von Konfigurationsquellen, unterstützt Hot Reloading von Konfigurationen und garantiert konsistente Zustände während der Laufzeit.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIn der modernen Softwareentwicklung werden Swift-Dienste zunehmend in cloud-nativen Infrastrukturen betrieben, die auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e basieren. Diese Umgebungen nutzen Technologien wie ConfigMaps, \u003ca href=\"/kubernetes/\"\u003econtainer\u003c/a\u003eisierte Workloads und deklarative Bereitstellungen. Während Projekte wie Prometheus und OpenTelemetry zur Standardisierung der Beobachtbarkeit in verteilten Systemen beigetragen haben, blieb die Konfigurationsverwaltung in Swift-Anwendungen oft unstrukturiert und ad hoc.\u003c/p\u003e\n\u003cp\u003eSwift wird aktiv zur Entwicklung von Produktionsdiensten auf Linux eingesetzt und profitiert von modernen Funktionen wie sicherer Nebenläufigkeit und hohen Leistungsmerkmalen. In der Praxis erfolgt die Konfiguration häufig durch das manuelle Auslesen von Umgebungsvariablen oder das Parsen von Dateien im YAML- oder JSON-Format. Diese Methoden sind jedoch nur für einfache Anwendungsfälle geeignet und führen zu mehreren betrieblichen Herausforderungen. Dazu gehören das Fehlen eines einheitlichen Modells zur Priorisierung von Konfigurationsquellen und mögliche Inkonsistenzen während der Laufzeit, wenn Konfigurationen neu geladen werden.\u003c/p\u003e\n\u003cp\u003eUm diese Lücken zu schließen, wurde die Swift-Konfiguration entwickelt. Sie bietet ein schichtbares Anbieter-Modell mit expliziten Prioritätsregeln, eine dateibasierte Hot-Reloading-Funktion für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-ConfigMap-Volumes und unveränderliche Konfigurations-Snapshots, die sicherstellen, dass Leser während Laufzeitaktualisierungen eine konsistente Sicht auf die Konfiguration erhalten.\u003c/p\u003e\n\u003cp\u003eDie Swift-Konfigurationsbibliothek trennt die Konfigurationserfassung von der Bereitstellung. Ein \u003ccode\u003eConfigReader\u003c/code\u003e nimmt eine geordnete Liste von Typen entgegen, die dem \u003ccode\u003eConfigProvider\u003c/code\u003e-Protokoll entsprechen. Der erste Anbieter, der einen Wert für einen bestimmten Schlüssel bereitstellt, hat Vorrang. Dies ermöglicht eine explizite Zusammenstellung der Prioritätskette.\u003c/p\u003e\n\u003cp\u003eIn Produktionsumgebungen ist es üblich, Anbieter mit der höchsten Priorität zuerst zu stapeln. CLI-Argumente haben Vorrang vor Umgebungsvariablen, die wiederum durch eine \u003ccode\u003e.env\u003c/code\u003e-Datei überschrieben werden können. In-Memory-Defaults dienen als Fallback. Diese explizite Priorisierung ermöglicht eine einfache Anpassung und Umordnung der Quellen.\u003c/p\u003e\n\u003cp\u003eFür dynamische Werte, die zur Laufzeit aktualisiert werden müssen, wie z. B. Feature-Flags oder Verbindungspoolgrößen, steht der \u003ccode\u003eReloadingFileProvider\u003c/code\u003e zur Verfügung. Dieser Anbieter überwacht eine Datei auf Änderungen und liefert konsistente Snapshots bei jeder Aktualisierung. In \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e kann eine ConfigMap als Volume gemountet werden, und der \u003ccode\u003eReloadingFileProvider\u003c/code\u003e kümmert sich um das Neuladen.\u003c/p\u003e\n\u003cp\u003eDie Swift-Konfiguration unterstützt sowohl YAML- als auch JSON-Anbieter, und die Community hat bereits einen TOML-Reader entwickelt. Dies ermöglicht eine erweiterbare und anpassbare Konfigurationsverwaltung.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Verwendung der Swift-Konfigurationsbibliothek verbessert die Effizienz der Konfigurationsverwaltung in cloud-nativen Anwendungen erheblich. Die explizite Priorisierung und die Möglichkeit des Hot Reloadings reduzieren die Wahrscheinlichkeit von Inkonsistenzen und erhöhen die Stabilität der Dienste. Die Trennung von Lesern und Anbietern fördert eine klare Architektur und erleichtert die Wartung und Erweiterung der Konfiguration.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung der Swift-Konfigurationsbibliothek stellt einen bedeutenden Fortschritt in der Verwaltung von Konfigurationen in cloud-nativen Swift-Diensten dar. Zukünftige Entwicklungen könnten die Integration weiterer Konfigurationsformate und die Verbesserung der Benutzerfreundlichkeit weiter vorantreiben.\u003c/p\u003e\n", "summary": "TL;DR Die Swift-Konfigurationsbibliothek bietet eine strukturierte Lösung für die Verwaltung von Konfigurationen in cloud-nativen Swift-Diensten, die auf Kubernetes basieren. Sie ermöglicht eine klare Priorisierung von Konfigurationsquellen, unterstützt Hot Reloading von Konfigurationen und garantiert konsistente Zustände während der Laufzeit.\nHauptinhalt In der modernen Softwareentwicklung werden Swift-Dienste zunehmend in cloud-nativen Infrastrukturen betrieben, die auf Kubernetes basieren. Diese Umgebungen nutzen Technologien wie ConfigMaps, containerisierte Workloads und deklarative Bereitstellungen. Während Projekte wie Prometheus und OpenTelemetry zur Standardisierung der Beobachtbarkeit in verteilten Systemen beigetragen haben, blieb die Konfigurationsverwaltung in Swift-Anwendungen oft unstrukturiert und ad hoc.\n", "image": "https://ayedo.de/dynamic-configuration-for-cloud-native-swift-services.png", "date_published": "2026-06-01T11:00:00Z", "date_modified": "2026-06-01T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","operations","software-delivery","development"], "language": "de" },{ "id": "https://ayedo.de/news/building-a-cloud-native-internal-developer-platform-with-kubernetes-gitops-and-supply-chain-security/", "url": "https://ayedo.de/news/building-a-cloud-native-internal-developer-platform-with-kubernetes-gitops-and-supply-chain-security/", "title": "Aufbau einer cloud-nativen internen Entwicklerplattform mit Kubernetes, GitOps und Versorgungskettensicherheit", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer Aufbau einer cloud-nativen internen Entwicklerplattform (IDP) auf Basis von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und CNCF-Tools ermöglicht eine konsistente und sichere Softwarebereitstellung. Durch die Integration von Infrastructure as Code (IaC), GitOps und Sicherheitsmechanismen werden zentrale Herausforderungen moderner Softwareentwicklung adressiert.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung moderner Software wird zunehmend durch die Plattform, auf der sie läuft, und nicht mehr ausschließlich durch den Anwendungscode eingeschränkt. Eine cloud-native IDP, die auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und Tools des CNCF-Ökosystems basiert, bietet eine Lösung für häufige betriebliche Herausforderungen. Dazu zählen Deployment-Inkonsistenzen, fehlende Infrastrukturversionierung, unsichere CI/CD-Pipelines und ineffiziente Skalierungsstrategien. Diese Plattform verfolgt einen deklarativen, automatisierten und richtliniengesteuerten Ansatz, um diese Lücken zu schließen.\u003c/p\u003e\n\u003cp\u003eDie Designprinzipien der Plattform orientieren sich an den Richtlinien der CNCF. Dazu gehören:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDeklarative Infrastruktur\u003c/strong\u003e: Alle Ressourcen sind versionskontrolliert und reproduzierbar.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGitOps-basierte Bereitstellung\u003c/strong\u003e: Git fungiert als einzige Quelle der Wahrheit für den Cluster.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eUnveränderliche Infrastruktur\u003c/strong\u003e: Manuelle Änderungen an laufenden Systemen sind ausgeschlossen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSicherheitsorientiertes Design\u003c/strong\u003e: Sicherheitsaspekte werden in der gesamten Pipeline berücksichtigt.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBeobachtbarkeit als Kernfunktion\u003c/strong\u003e: Diese ist nicht optional, sondern integraler Bestandteil der Plattform.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eModularer Aufbau\u003c/strong\u003e: Die Trennung von Infrastruktur-, Plattform- und Anwendungsschichten reduziert die Komplexität.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie Architektur der Plattform ist in drei logische Schichten unterteilt: Infrastruktur, Plattform und Anwendung. Diese Schichten sind klar voneinander getrennt, um Wartungsaufwand zu minimieren. Die Infrastruktur-Schicht übernimmt die Bereitstellung aller Cloud-Ressourcen über Terraform, einschließlich virtueller Netzwerke, \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e und Identitätsmanagement.\u003c/p\u003e\n\u003cp\u003eDie Plattform-Schicht nutzt \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und CNCF-Tools, die deklarativ installiert und verwaltet werden. Wichtige Komponenten sind Argo CD für die kontinuierliche Überwachung, Istio als Service-Mesh, Prometheus für Metriken und Grafana für Visualisierungen.\u003c/p\u003e\n\u003cp\u003eDie Anwendungsschicht besteht aus containerisierten Microservices, die unabhängig deploybar sind. Dies ermöglicht eine flexible und effiziente Verwaltung der Dienste.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDer Implementierungsprozess der Plattform folgt einem mehrstufigen Bereitstellungsworkflow, der eine strikte Trennung zwischen Anwendungsbau, Sicherheitsvalidierung und Infrastrukturprovisionierung vorsieht. Zunächst werden grundlegende Komponenten wie ein Container-Image-Registry und ein Terraform-Backend bereitgestellt. Anschließend wird die Anwendungspipeline aktiviert, die bei jedem Commit in den Anwendungsrepositories ausgelöst wird. Diese Pipeline umfasst Schritte wie den Codebau, Tests, Sicherheitsanalysen und die Erstellung sowie Veröffentlichung von Container-Images.\u003c/p\u003e\n\u003cp\u003eDurch den Einsatz von Tools wie Trivy zur Schwachstellensuche und Cosign zur Bildsignierung wird sichergestellt, dass nur verifizierte und sichere Artefakte in die Plattform gelangen. Diese Maßnahmen tragen zur Verbesserung der Sicherheitslage und der Betriebseffizienz bei.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung einer cloud-nativen IDP auf Basis von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und CNCF-Tools stellt einen bedeutenden Fortschritt in der Softwarebereitstellung dar. Durch die Kombination von Automatisierung, Sicherheitsmechanismen und modularer Architektur wird eine robuste und skalierbare Plattform geschaffen, die den Anforderungen moderner Softwareentwicklung gerecht wird.\u003c/p\u003e\n", "summary": "TL;DR Der Aufbau einer cloud-nativen internen Entwicklerplattform (IDP) auf Basis von Kubernetes und CNCF-Tools ermöglicht eine konsistente und sichere Softwarebereitstellung. Durch die Integration von Infrastructure as Code (IaC), GitOps und Sicherheitsmechanismen werden zentrale Herausforderungen moderner Softwareentwicklung adressiert.\nHauptinhalt Die Entwicklung moderner Software wird zunehmend durch die Plattform, auf der sie läuft, und nicht mehr ausschließlich durch den Anwendungscode eingeschränkt. Eine cloud-native IDP, die auf Kubernetes und Tools des CNCF-Ökosystems basiert, bietet eine Lösung für häufige betriebliche Herausforderungen. Dazu zählen Deployment-Inkonsistenzen, fehlende Infrastrukturversionierung, unsichere CI/CD-Pipelines und ineffiziente Skalierungsstrategien. Diese Plattform verfolgt einen deklarativen, automatisierten und richtliniengesteuerten Ansatz, um diese Lücken zu schließen.\n", "image": "https://ayedo.de/building-a-cloud-native-internal-developer-platform-with-kubernetes-gitops-and-supply-chain-security.png", "date_published": "2026-05-29T11:00:00Z", "date_modified": "2026-05-29T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","security","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/news/the-kubernetes-integration-tax-prometheus-cilium-and-production-reality/", "url": "https://ayedo.de/news/the-kubernetes-integration-tax-prometheus-cilium-and-production-reality/", "title": "Die Kubernetes-Integrationskosten: Prometheus, Cilium und die Realität in der Produktion", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Integration mehrerer CNCF-Projekte in Produktionsumgebungen kann erhebliche versteckte Kosten verursachen, die als \u0026ldquo;Integration Tax\u0026rdquo; bezeichnet werden. Diese Kosten entstehen nicht nur durch die Installation und Anpassung der Tools, sondern vor allem durch die notwendige Verbindung und Interaktion der verschiedenen Komponenten. Eine nachhaltige Lösung zur Reduzierung dieser Kosten ist die Implementierung eines GitOps-Ansatzes mit einer klaren Trennung der Repositories.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Herausforderungen bei der Integration von CNCF-Projekten in \u003ca href=\"/kubernetes/\"\u003eKubernetes-Umgebungen\u003c/a\u003e sind vielfältig und oft unerwartet. Ein Beispiel ist die Interaktion zwischen Prometheus und Cilium, bei der Monitoring-Daten aufgrund fehlender ServiceMonitors in Prometheus nicht angezeigt werden. Solche Probleme verdeutlichen die \u0026ldquo;Integration Tax\u0026rdquo;, die den Großteil der Zeit der Plattformteams in Anspruch nimmt. Statt sich auf die individuellen Projekte zu konzentrieren, müssen Teams oft viel Zeit damit verbringen, sicherzustellen, dass die verschiedenen Komponenten miteinander kommunizieren.\u003c/p\u003e\n\u003cp\u003eIn der CNCF-Landschaft gibt es etwa 250 Projekte, wobei die meisten Produktionsumgebungen auf einen Kernstapel von 20 bis 30 \u003ca href=\"/kubernetes/\"\u003ecloud-nativen\u003c/a\u003e Tools setzen. Zu diesen gehören Prometheus für Monitoring, ArgoCD für GitOps, Cilium für Netzwerkmanagement und andere. Die Installation dieser Tools ist der erste Schritt, doch die eigentliche Herausforderung liegt im \u0026ldquo;Wiring\u0026rdquo; – der Integration der Tools, um eine reibungslose Kommunikation zu gewährleisten.\u003c/p\u003e\n\u003cp\u003eEin konkretes Beispiel ist der Konflikt zwischen cert-manager und Ingress-Controllern. Der HTTP-01 ACME Challenge von cert-manager erfordert, dass ein Token über HTTP bereitgestellt wird. Wenn jedoch der Ingress-Controller eine globale HTTP-zu-HTTPS-Umleitung erzwingt, schlägt die Validierung stillschweigend fehl. Dies führt zu abgelaufenen TLS-Zertifikaten, die erst bemerkt werden, wenn Kunden Warnungen in ihren Browsern sehen. Eine Lösung besteht darin, DNS-01-Challenges zu verwenden, was jedoch spezifische IAM-Berechtigungen erfordert, die nicht standardmäßig in Helm-Charts konfiguriert sind.\u003c/p\u003e\n\u003cp\u003eEin weiteres Beispiel ist das Zusammenspiel von Prometheus und kubelet. kubelet stellt Metriken auf mehreren Endpunkten bereit, die identische Zeitstempel für denselben Prozess ausgeben. Dies führt zu doppelten Proben und einer erhöhten Alarmierung, die oft schwer zu diagnostizieren ist. Die Lösung erfordert spezifische Anpassungen, die nicht offensichtlich sind, wenn man nur die Dokumentation der Projekte betrachtet.\u003c/p\u003e\n\u003cp\u003eDie Einführung des Cluster API (CAPI) hat die Art und Weise revolutioniert, wie Kubernetes-Cluster über verschiedene Cloud-Anbieter hinweg bereitgestellt werden. CAPI ermöglicht es, Cluster als Kubernetes-native Ressourcen zu verwalten, wodurch die Abhängigkeit von den spezifischen CLI-Tools der Cloud-Anbieter entfällt. Dies erleichtert auch die Durchführung von Upgrades und das Disaster Recovery, da die gesamte Cluster-Konfiguration aus dem Git-Zustand wiederhergestellt werden kann.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung eines GitOps-Ansatzes mit einer klaren Trennung der Repositories hat sich als effektive Methode zur Reduzierung der Integrationskosten erwiesen. Ein dediziertes Plattform-Repository, das über 100 Helm-Charts mit getesteten Standardkonfigurationen enthält, kann dazu beitragen, die Komplexität der Integration zu minimieren. Durch die Vorab-Konfiguration von Cilium NetworkPolicies und Prometheus ServiceMonitors wird sichergestellt, dass diese Komponenten von Anfang an korrekt miteinander kommunizieren.\u003c/p\u003e\n\u003cp\u003eDiese strukturierte Herangehensweise ermöglicht es Teams, sich auf die Entwicklung und den Betrieb der Anwendungen zu konzentrieren, anstatt zeitaufwändige Integrationsprobleme zu beheben. Die Automatisierung von Day-2-Operationen, wie das Cordon und Draining von Knoten oder das Wiederherstellen von Backups, wird ebenfalls erleichtert.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Herausforderungen bei der Integration von CNCF-Projekten sind signifikant, können jedoch durch strategische Ansätze wie GitOps und die Verwendung von CAPI effektiv adressiert werden. Zukünftige Entwicklungen in der \u003ca href=\"/kubernetes/\"\u003eKubernetes-\u003c/a\u003e und CNCF-Landschaft werden weiterhin darauf abzielen, die Integration und Interoperabilität zu verbessern, um die Effizienz in Produktionsumgebungen zu steigern.\u003c/p\u003e\n", "summary": "TL;DR Die Integration mehrerer CNCF-Projekte in Produktionsumgebungen kann erhebliche versteckte Kosten verursachen, die als \u0026ldquo;Integration Tax\u0026rdquo; bezeichnet werden. Diese Kosten entstehen nicht nur durch die Installation und Anpassung der Tools, sondern vor allem durch die notwendige Verbindung und Interaktion der verschiedenen Komponenten. Eine nachhaltige Lösung zur Reduzierung dieser Kosten ist die Implementierung eines GitOps-Ansatzes mit einer klaren Trennung der Repositories.\nHauptinhalt Die Herausforderungen bei der Integration von CNCF-Projekten in Kubernetes-Umgebungen sind vielfältig und oft unerwartet. Ein Beispiel ist die Interaktion zwischen Prometheus und Cilium, bei der Monitoring-Daten aufgrund fehlender ServiceMonitors in Prometheus nicht angezeigt werden. Solche Probleme verdeutlichen die \u0026ldquo;Integration Tax\u0026rdquo;, die den Großteil der Zeit der Plattformteams in Anspruch nimmt. Statt sich auf die individuellen Projekte zu konzentrieren, müssen Teams oft viel Zeit damit verbringen, sicherzustellen, dass die verschiedenen Komponenten miteinander kommunizieren.\n", "image": "https://ayedo.de/the-kubernetes-integration-tax-prometheus-cilium-and-production-reality.png", "date_published": "2026-05-28T11:00:00Z", "date_modified": "2026-05-28T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","software-delivery","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/mitigating-cve-2026-31431-copy-fail-in-docker-engine/", "url": "https://ayedo.de/news/mitigating-cve-2026-31431-copy-fail-in-docker-engine/", "title": "Minderung von CVE-2026-31431 (“Copy Fail”) in Docker Engine", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eCVE-2026-31431, auch bekannt als \u0026ldquo;Copy Fail\u0026rdquo;, ist eine kürzlich entdeckte Privilegieneskalationsanfälligkeit im Linux-Kernel, die \u003ca href=\"https://www.docker.com/\"\u003eDocker\u003c/a\u003e -Umgebungen betrifft. Docker Engine-Versionen vor v29.4.3 sind potenziell anfällig, wenn sie auf ungeschützten Hosts betrieben werden. Eine Kernel-Aktualisierung ist die empfohlene Lösung, während Docker Maßnahmen ergriffen hat, um die Auswirkungen für betroffene \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e zu minimieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eCVE-2026-31431 ist eine Sicherheitsanfälligkeit im AF_ALG-Kryptosubsystem des Linux-Kernels, die es unprivilegierten Benutzern ermöglicht, kontrollierte Schreibvorgänge im Page-Cache durchzuführen. Dies kann dazu führen, dass Angreifer die Inhalte lesbarer Dateien temporär verändern, was besonders gefährlich ist, wenn setuid-Binärdateien betroffen sind. Die Schwachstelle betrifft alle ungeschützten Linux-Kernel-Versionen seit 2017 und wurde öffentlich bekannt, bevor viele Linux-Distributionen entsprechende Kernel-Patches bereitstellen konnten.\u003c/p\u003e\n\u003cp\u003eDie \u003ca href=\"https://www.docker.com/\"\u003eDocker\u003c/a\u003e -Engine war betroffen, weil ihre Standard-Profile vor Version v29.4.3 das Erstellen von AF_ALG-Sockets erlaubten. Nutzer, die Docker Engine v29.4.3 oder höher verwenden oder deren Host-Kernel gepatcht ist, sind nicht gefährdet. Für Benutzer, deren Distributionen noch keine Kernel-Updates bereitgestellt haben, ist die Aktualisierung der Docker Engine die derzeitige Lösung.\u003c/p\u003e\n\u003cp\u003eDie erste Maßnahme zur Minderung der Anfälligkeit bestand darin, das Standard-secomp-Profil von Docker Engine zu aktualisieren, um AF_ALG-Sockets zu blockieren. Dies stellte sich jedoch als problematisch heraus, da ältere 32-Bit-Binärdateien auf die socketcall-Schnittstelle zurückgreifen, die mehrere Socket-Operationen über einen einzigen Systemaufruf bündelt. Das Blockieren von socketcall führte dazu, dass viele ältere Anwendungen und Spiele nicht mehr funktionsfähig waren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Sicherheitsanfälligkeit ermöglicht es Angreifern, durch das Ausnutzen des Copy Fail-Exploits, der in \u003ca href=\"/kubernetes/\"\u003eContainern\u003c/a\u003e mit Standard-Sicherheitsprofilen läuft, auf den Page-Cache zuzugreifen und möglicherweise Root-Rechte zu erlangen. Da der Page-Cache zwischen Containern und dem Host geteilt wird, können die Auswirkungen nicht auf den angreifenden Container beschränkt werden. Dies bedeutet, dass andere Container und Anwendungen auf demselben Host ebenfalls betroffen sein können.\u003c/p\u003e\n\u003cp\u003eDie korrekte Lösung für die Schwachstelle ist ein Kernel-Update. Während Docker Maßnahmen zur Minderung der Anfälligkeit implementiert hat, bleibt die zugrunde liegende Schwachstelle bestehen, solange der Kernel nicht aktualisiert wird. Es ist wichtig, dass Administratoren sicherstellen, dass sie die aktuellsten Patches anwenden, um ihre Systeme zu schützen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entdeckung von CVE-2026-31431 unterstreicht die Notwendigkeit, Sicherheitsupdates zeitnah anzuwenden und die Konfigurationen von Container-Umgebungen regelmäßig zu überprüfen. Die kontinuierliche Zusammenarbeit zwischen Kernel-Entwicklern und \u003ca href=\"/kubernetes/\"\u003eContainer-Plattformanbietern\u003c/a\u003e ist entscheidend, um Sicherheitsanfälligkeiten effektiv zu adressieren und die Integrität der Systeme zu gewährleisten.\u003c/p\u003e\n", "summary": "TL;DR CVE-2026-31431, auch bekannt als \u0026ldquo;Copy Fail\u0026rdquo;, ist eine kürzlich entdeckte Privilegieneskalationsanfälligkeit im Linux-Kernel, die Docker -Umgebungen betrifft. Docker Engine-Versionen vor v29.4.3 sind potenziell anfällig, wenn sie auf ungeschützten Hosts betrieben werden. Eine Kernel-Aktualisierung ist die empfohlene Lösung, während Docker Maßnahmen ergriffen hat, um die Auswirkungen für betroffene Container zu minimieren.\nHauptinhalt CVE-2026-31431 ist eine Sicherheitsanfälligkeit im AF_ALG-Kryptosubsystem des Linux-Kernels, die es unprivilegierten Benutzern ermöglicht, kontrollierte Schreibvorgänge im Page-Cache durchzuführen. Dies kann dazu führen, dass Angreifer die Inhalte lesbarer Dateien temporär verändern, was besonders gefährlich ist, wenn setuid-Binärdateien betroffen sind. Die Schwachstelle betrifft alle ungeschützten Linux-Kernel-Versionen seit 2017 und wurde öffentlich bekannt, bevor viele Linux-Distributionen entsprechende Kernel-Patches bereitstellen konnten.\n", "image": "https://ayedo.de/mitigating-cve-2026-31431-copy-fail-in-docker-engine.png", "date_published": "2026-05-27T13:00:00Z", "date_modified": "2026-05-27T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/gpu-autoscaling-on-kubernetes-with-keda-building-an-external-scaler/", "url": "https://ayedo.de/news/gpu-autoscaling-on-kubernetes-with-keda-building-an-external-scaler/", "title": "GPU-Autoskalierung auf Kubernetes mit KEDA: Einen externen Scaler erstellen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Implementierung eines GPU-Autoscalers für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e mithilfe von KEDA ermöglicht es, GPU-Arbeitslasten effizient zu skalieren, indem relevante Metriken wie Auslastung, Speicher und Energieverbrauch berücksichtigt werden. Ein benutzerdefinierter DaemonSet sammelt GPU-Daten und stellt diese über ein Netzwerkprotokoll zur Verfügung, um die Skalierung von Anwendungen zu optimieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Nutzung von GPU-Workloads auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e kann herausfordernd sein, insbesondere wenn die Standard-Autoskalierungsmechanismen sich nur auf CPU und Arbeitsspeicher konzentrieren. Diese Diskrepanz führt häufig zu ineffizientem Einsatz von GPU-Ressourcen, was sowohl die Kosten erhöht als auch den Energieverbrauch steigert. Um diesen Herausforderungen zu begegnen, wurde ein Ansatz zur Entwicklung eines externen Scalers für KEDA (Kubernetes Event-driven Autoscaling) vorgestellt, der spezifisch auf GPU-Metriken fokussiert ist.\u003c/p\u003e\n\u003cp\u003eEin zentrales Problem bei der Integration von GPU-Metriken in KEDA ist die Notwendigkeit, die NVIDIA Management Library (NVML) zu verwenden, die nicht direkt mit KEDA kompatibel ist, da KEDA mit CGO_ENABLED=0 kompiliert wird. Zudem erfolgt die Kommunikation mit NVML lokal, was bedeutet, dass Metriken nur von der GPU auf dem gleichen Knoten abgerufen werden können. Um diese Einschränkungen zu überwinden, wurde ein benutzerdefinierter DaemonSet entwickelt, der auf jedem GPU-Knoten läuft und die erforderlichen Metriken über gRPC bereitstellt.\u003c/p\u003e\n\u003cp\u003eIn dieser Architektur ruft jeder Pod die NVML auf, um lokale GPU-Metriken zu erfassen und diese über die KEDA ExternalScaler-Schnittstelle verfügbar zu machen. Der KEDA-Operator kann dann auf diese Metriken zugreifen, um Entscheidungen zur Horizontal Pod Autoscaling (HPA) zu treffen. Die gesammelten Metriken umfassen unter anderem die GPU-Auslastung, den Speicherverbrauch, die Temperatur und den aktuellen Energieverbrauch.\u003c/p\u003e\n\u003cp\u003eFür Multi-GPU-Knoten können verschiedene Aggregationsmethoden wie Maximum, Minimum, Durchschnitt oder Summe gewählt werden. Um den Einstieg zu erleichtern, wurden vordefinierte Profile für gängige GPU-Arbeitslasten erstellt, die Standardwerte für die Skalierung festlegen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Architektur des GPU-Autoscalers ermöglicht eine detaillierte Überwachung und Anpassung der Ressourcennutzung in Echtzeit. Die Verwendung von gRPC für die Kommunikation zwischen den DaemonSets und dem KEDA-Operator stellt sicher, dass die Skalierung effizient und skalierbar ist. Entwickler und IT-Entscheider können die vordefinierten Profile anpassen oder eigene Metriken und Schwellenwerte definieren, um spezifische Anforderungen ihrer Anwendungen zu erfüllen. Darüber hinaus bietet der Mock-Collector-Modus die Möglichkeit, die Funktionalität des Scalers ohne physische GPU-Hardware zu testen, was die Integration und Validierung im Entwicklungsprozess erleichtert.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung eines GPU-Autoscalers für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e mit KEDA stellt einen bedeutenden Schritt in Richtung effizienter Ressourcennutzung in \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Umgebungen dar. Die Möglichkeit, GPU-spezifische Metriken zu integrieren, wird Unternehmen helfen, ihre KI- und ML-Anwendungen effektiver zu skalieren und gleichzeitig Kosten und Umweltbelastungen zu reduzieren. Die offene Architektur ermöglicht es, weitere Anpassungen vorzunehmen und neue Technologien in bestehende Systeme zu integrieren.\u003c/p\u003e\n", "summary": "TL;DR Die Implementierung eines GPU-Autoscalers für Kubernetes mithilfe von KEDA ermöglicht es, GPU-Arbeitslasten effizient zu skalieren, indem relevante Metriken wie Auslastung, Speicher und Energieverbrauch berücksichtigt werden. Ein benutzerdefinierter DaemonSet sammelt GPU-Daten und stellt diese über ein Netzwerkprotokoll zur Verfügung, um die Skalierung von Anwendungen zu optimieren.\nHauptinhalt Die Nutzung von GPU-Workloads auf Kubernetes kann herausfordernd sein, insbesondere wenn die Standard-Autoskalierungsmechanismen sich nur auf CPU und Arbeitsspeicher konzentrieren. Diese Diskrepanz führt häufig zu ineffizientem Einsatz von GPU-Ressourcen, was sowohl die Kosten erhöht als auch den Energieverbrauch steigert. Um diesen Herausforderungen zu begegnen, wurde ein Ansatz zur Entwicklung eines externen Scalers für KEDA (Kubernetes Event-driven Autoscaling) vorgestellt, der spezifisch auf GPU-Metriken fokussiert ist.\n", "image": "https://ayedo.de/gpu-autoscaling-on-kubernetes-with-keda-building-an-external-scaler.png", "date_published": "2026-05-27T11:00:00Z", "date_modified": "2026-05-27T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/reconciling-the-past-correcting-records-for-unfixed-kubernetes-cves/", "url": "https://ayedo.de/news/reconciling-the-past-correcting-records-for-unfixed-kubernetes-cves/", "title": "Die Vergangenheit in Einklang bringen: Korrektur von Aufzeichnungen für unbehandelte Kubernetes CVEs", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Kubernetes-Community wird am 1. Juni 2026 die CVE-Datenbank aktualisieren, um mehrere unbehandelte Sicherheitsanfälligkeiten korrekt zu kennzeichnen. Diese Änderungen betreffen insbesondere die CVEs CVE-2020-8561, CVE-2020-8562 und CVE-2021-25740, die aufgrund architektonischer Einschränkungen nicht behoben werden können. Administratoren sollten sich auf mögliche Änderungen in den Ergebnissen von Schwachstellenscannern vorbereiten.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eKubernetes-Plattform\u003c/a\u003e hat sich der Transparenz verpflichtet, um Cluster-Administratoren und Sicherheitsforschern zu helfen, potenzielle Sicherheitsrisiken zu identifizieren. Im Rahmen einer umfassenden Überprüfung der CVE-Datenbank wurden Diskrepanzen bei älteren, unbehandelten Sicherheitsanfälligkeiten festgestellt. Einige CVE-Einträge wiesen fälschlicherweise auf ein fixes Versionsfeld hin, was zu Missverständnissen führen kann. Die Korrektur dieser Einträge ist für die Sicherheit der Kubernetes-Umgebung von entscheidender Bedeutung.\u003c/p\u003e\n\u003cp\u003eDie drei betroffenen CVEs sind CVE-2020-8561, CVE-2020-8562 und CVE-2021-25740. Diese Sicherheitsanfälligkeiten wurden in den letzten Jahren veröffentlicht, jedoch wurde festgestellt, dass ihre CVE-Einträge nicht den tatsächlichen Status widerspiegeln. Insbesondere gab es falsche Angaben zu fixierten Versionen, obwohl diese Schwachstellen architektonische Designentscheidungen betreffen, die nicht einfach durch Codeänderungen behoben werden können.\u003c/p\u003e\n\u003cp\u003eDie aktualisierten CVE-Einträge sollen dazu beitragen, die Genauigkeit moderner Schwachstellenscanner zu verbessern. Falsche Angaben zu fixierten Versionen können zu falschen Sicherheitsbewertungen führen und das Risiko erhöhen, dass Administratoren sich in falscher Sicherheit wiegen. Die formale Kennzeichnung als unbehandelt wird auch sicherstellen, dass Plattformanbieter und Administratoren die Notwendigkeit administrativer Maßnahmen erkennen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie spezifischen Sicherheitsanfälligkeiten sind wie folgt:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eCVE-2020-8561: Webhook-Redirect im kube-apiserver\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSchweregrad:\u003c/strong\u003e Mittel (4.1)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProblem:\u003c/strong\u003e Der kube-apiserver folgt HTTP-Umleitungen, was es einem Angreifer ermöglicht, API-Anfragen auf interne Netzwerke umzuleiten.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWarum unbehandelt:\u003c/strong\u003e Eine Einschränkung dieser Funktion würde das Standardverhalten des HTTP-Clients brechen, was legitime Integrationen beeinträchtigen könnte.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMinderung:\u003c/strong\u003e Log-Level des API-Servers auf weniger als 10 setzen und dynamisches Profiling deaktivieren.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eCVE-2020-8562: Proxy-Bypass über DNS TOCTOU\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSchweregrad:\u003c/strong\u003e Niedrig (3.1)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProblem:\u003c/strong\u003e Eine Race-Condition im API-Server-Proxy erlaubt es Benutzern, IP-Beschränkungen zu umgehen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWarum unbehandelt:\u003c/strong\u003e Eine Lösung würde komplexe DNS-Umgebungen stören.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMinderung:\u003c/strong\u003e Verwendung eines lokalen DNS-Caching-Servers wie dnsmasq.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eCVE-2021-25740: Cross-Namespace-Weiterleitung über Endpunkte\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSchweregrad:\u003c/strong\u003e Niedrig (3.1)\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eProblem:\u003c/strong\u003e Eine Designschwäche erlaubt es Benutzern, IP-Adressen zu spezifizieren, die auf Backends in anderen Namespaces verweisen können.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWarum unbehandelt:\u003c/strong\u003e Dies ist eine grundlegende Funktion des Endpoints-APIs.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMinderung:\u003c/strong\u003e Schreibzugriff auf Endpunkte einschränken.\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eDie CVE-Einträge werden am 1. Juni 2026 aktualisiert, um korrekt zu reflektieren, dass alle Versionen betroffen sind. Administratoren sollten sich auf mögliche Änderungen in den Ergebnissen von Schwachstellenscannern vorbereiten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Korrektur der CVE-Datenbank ist ein wichtiger Schritt zur Verbesserung der Sicherheit in \u003ca href=\"/kubernetes/\"\u003eKubernetes-Umgebungen\u003c/a\u003e. Administratoren sollten die empfohlenen Maßnahmen zur Risikominderung umsetzen, um die Auswirkungen dieser unbehandelten Sicherheitsanfälligkeiten zu minimieren.\u003c/p\u003e\n", "summary": "TL;DR Die Kubernetes-Community wird am 1. Juni 2026 die CVE-Datenbank aktualisieren, um mehrere unbehandelte Sicherheitsanfälligkeiten korrekt zu kennzeichnen. Diese Änderungen betreffen insbesondere die CVEs CVE-2020-8561, CVE-2020-8562 und CVE-2021-25740, die aufgrund architektonischer Einschränkungen nicht behoben werden können. Administratoren sollten sich auf mögliche Änderungen in den Ergebnissen von Schwachstellenscannern vorbereiten.\nHauptinhalt Die Kubernetes-Plattform hat sich der Transparenz verpflichtet, um Cluster-Administratoren und Sicherheitsforschern zu helfen, potenzielle Sicherheitsrisiken zu identifizieren. Im Rahmen einer umfassenden Überprüfung der CVE-Datenbank wurden Diskrepanzen bei älteren, unbehandelten Sicherheitsanfälligkeiten festgestellt. Einige CVE-Einträge wiesen fälschlicherweise auf ein fixes Versionsfeld hin, was zu Missverständnissen führen kann. Die Korrektur dieser Einträge ist für die Sicherheit der Kubernetes-Umgebung von entscheidender Bedeutung.\n", "image": "https://ayedo.de/reconciling-the-past-correcting-records-for-unfixed-kubernetes-cves.png", "date_published": "2026-05-26T17:30:00Z", "date_modified": "2026-05-26T17:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","compliance","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/three-tag-leads-walk-into-the-toc/", "url": "https://ayedo.de/news/three-tag-leads-walk-into-the-toc/", "title": "Drei TAG-Leiter betreten das TOC", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDrei neue Mitglieder des Technical Oversight Committee (TOC) der Cloud Native Computing Foundation (CNCF) stammen aus den Technical Advisory Groups (TAGs). Diese Gruppen spielen eine entscheidende Rolle in der Entwicklung von Best Practices und Richtlinien, die den gesamten \u003ca href=\"https://www.example.com/cloud-native/\"\u003eCloud-Native-Ökosystem\u003c/a\u003e beeinflussen. Die Trennung zwischen TAG- und TOC-Rollen soll Interessenkonflikte vermeiden und die Unabhängigkeit der Arbeit der TAGs gewährleisten.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie CNCF hat kürzlich drei neue Mitglieder im TOC bekannt gegeben, die alle zuvor führende Positionen in verschiedenen TAGs innehatten. Brandt, Mario und Mauricio bringen umfangreiche Erfahrungen aus den Bereichen Sicherheit, operationale Resilienz und Entwicklererfahrung mit. Diese Entwicklung unterstreicht die enge Verbindung zwischen den TAGs und dem TOC, da die Arbeit der TAGs die Grundlage für strategische Entscheidungen auf der Ebene des TOC bildet.\u003c/p\u003e\n\u003cp\u003eTAGs sind spezialisierte Gruppen, die sich auf bestimmte Themen konzentrieren und als beratende Instanzen fungieren. Sie organisieren die von der TOC zugewiesenen Arbeiten und stellen sicher, dass diese mit der erforderlichen Expertise und Sorgfalt durchgeführt werden. Ihre Arbeit umfasst die Erstellung von Best Practices und Betriebshinweisen, die weit über die CNCF hinaus Einfluss nehmen. Diese Initiativen sind entscheidend für die Weiterentwicklung von Sicherheitsstandards, Governance-Richtlinien und operationaler Resilienz in der \u003ca href=\"https://www.example.com/cloud-native/\"\u003eCloud-Native-Welt\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eEin zentrales Thema, das die TAGs behandelt, ist die Sicherheit. Die Sicherheitsanforderungen für Projekte haben sich weiterentwickelt, und es ist unerlässlich, dass diese regelmäßig überprüft werden. Die TAG Security hat beispielsweise Leitfäden und \u003ca href=\"https://www.example.com/compliance/\"\u003eCompliance-Dokumente\u003c/a\u003e erstellt, die weltweit anerkannt sind und die Diskussion über Sicherheitspraktiken vorantreiben. Die kontinuierliche Anpassung an neue Bedrohungen ist für die Projekte von entscheidender Bedeutung, um Schwachstellen zu identifizieren und zu beheben.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Thema ist die operationale Resilienz. Diese umfasst nicht nur die Aufrechterhaltung des Betriebs, sondern auch die Fähigkeit, nach der Bereitstellung eines Projekts effektiv zu reagieren. Die TAG Operational Resilience arbeitet an verschiedenen Initiativen, darunter Projektfreigabeverfahren und Automatisierung von Service-Level-Zusagen. Diese Initiativen sollen sicherstellen, dass Unternehmen nicht nur auf Zwischenfälle reagieren, sondern proaktive Strategien entwickeln, um die Zuverlässigkeit und Effizienz ihrer Systeme zu verbessern.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Arbeit der TAGs hat direkte Auswirkungen auf die gesamte Cloud-Native-Community. Durch die Entwicklung von Best Practices und Richtlinien tragen sie dazu bei, dass Unternehmen ihre \u003ca href=\"https://www.example.com/cloud-native/\"\u003eCloud-Strategien\u003c/a\u003e effektiver umsetzen können. Die Initiativen zur Verbesserung der Sicherheit und Resilienz sind besonders relevant, da sie Unternehmen helfen, sich an die sich ständig ändernden Anforderungen und Bedrohungen anzupassen. Darüber hinaus fördert die Trennung der Rollen zwischen TAGs und TOC eine objektive Entscheidungsfindung, die auf den Bedürfnissen der Community basiert.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von TAG-Leitern in das TOC stärkt die Verbindung zwischen den verschiedenen Ebenen der CNCF und fördert eine kohärente Strategie für die Weiterentwicklung des Cloud-Native-Ökosystems. Die kontinuierliche Arbeit an Sicherheits- und Resilienzfragen wird entscheidend sein, um den Anforderungen der modernen IT-Landschaft gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Drei neue Mitglieder des Technical Oversight Committee (TOC) der Cloud Native Computing Foundation (CNCF) stammen aus den Technical Advisory Groups (TAGs). Diese Gruppen spielen eine entscheidende Rolle in der Entwicklung von Best Practices und Richtlinien, die den gesamten Cloud-Native-Ökosystem beeinflussen. Die Trennung zwischen TAG- und TOC-Rollen soll Interessenkonflikte vermeiden und die Unabhängigkeit der Arbeit der TAGs gewährleisten.\nHauptinhalt Die CNCF hat kürzlich drei neue Mitglieder im TOC bekannt gegeben, die alle zuvor führende Positionen in verschiedenen TAGs innehatten. Brandt, Mario und Mauricio bringen umfangreiche Erfahrungen aus den Bereichen Sicherheit, operationale Resilienz und Entwicklererfahrung mit. Diese Entwicklung unterstreicht die enge Verbindung zwischen den TAGs und dem TOC, da die Arbeit der TAGs die Grundlage für strategische Entscheidungen auf der Ebene des TOC bildet.\n", "image": "https://ayedo.de/three-tag-leads-walk-into-the-toc.png", "date_published": "2026-05-26T15:38:18Z", "date_modified": "2026-05-26T15:38:18Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","security","compliance","development","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/the-untrusted-autonomous-workload-how-ai-coding-agents-reshape-what-isolation-has-to-do/", "url": "https://ayedo.de/news/the-untrusted-autonomous-workload-how-ai-coding-agents-reshape-what-isolation-has-to-do/", "title": "Die untrusted autonome Workload: Wie AI Coding Agents die Isolation neu definieren", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Integration von KI-Coding-Agenten in Softwareentwicklungsprozesse verändert die Anforderungen an die Code-Isolation und Sicherheitsarchitekturen. Traditionelle \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e -Modelle bieten nicht die notwendige Sicherheit, um mit den neuen Bedrohungen umzugehen, die durch autonome Agenten entstehen. \u003ca href=\"/kubernetes/\"\u003eDocker\u003c/a\u003e hat daher neue Ansätze entwickelt, um diese Herausforderungen zu adressieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Verwendung von KI-Coding-Agenten in der Softwareentwicklung hat die Art und Weise, wie Entwickler mit ihrem Code interagieren, grundlegend verändert. Diese Agenten können autonom Änderungen vornehmen, Fehler beheben und sogar die Codebasis neu strukturieren, ohne dass der Entwickler die genauen Details dieser Änderungen kennt. Dies führt zu einem Zustand, in dem Entwickler möglicherweise das Vertrauen in die Integrität ihrer eigenen Codebasis verlieren. Die Gefahr besteht darin, dass diese Agenten unkontrolliert Änderungen vornehmen, die potenziell Sicherheitslücken oder andere Probleme verursachen können.\u003c/p\u003e\n\u003cp\u003eEin Beispiel für diese Problematik ist der Vorfall mit dem Trivy-Tool, einem Sicherheits-Scanner, der kompromittiert wurde. Während eines kurzen Zeitraums wurde ein schadhafter Code in die CI-Pipeline eingeführt, der sensible Informationen auslas. Dies verdeutlicht, dass nicht nur der Code selbst, sondern auch die Werkzeuge, die zur Überprüfung und Absicherung des Codes eingesetzt werden, zu einem Sicherheitsrisiko werden können, wenn sie nicht ausreichend isoliert sind.\u003c/p\u003e\n\u003cp\u003eTraditionelle \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e -Modelle waren auf die Annahme ausgelegt, dass der Entwickler die Kontrolle über den Code hat, den er ausführt. Diese Annahme ist jedoch nicht mehr gültig, wenn autonome Agenten im Spiel sind. Sie können Pakete installieren und Befehle ausführen, die der Entwickler nicht vorhergesehen hat, was zu einer erhöhten Angriffsfläche führt. Die Container-Technologie, die ursprünglich entwickelt wurde, um eine saubere Ausführungsumgebung zu bieten, reicht nicht mehr aus, um mit der Unsicherheit umzugehen, die durch diese neuen Agenten entsteht.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eUm die Sicherheitslücke zu schließen, die durch die Verwendung von KI-Coding-Agenten entsteht, hat \u003ca href=\"/kubernetes/\"\u003eDocker\u003c/a\u003e neue Lösungen entwickelt, die über das traditionelle Container-Modell hinausgehen. Eine der vorgeschlagenen Lösungen sind microVMs, die eine verbesserte Isolation bieten und es ermöglichen, dass autonome Agenten in einer kontrollierten Umgebung arbeiten. Diese microVMs bieten eine eigene Docker-Daemon-Instanz, die den Agenten von der Hauptumgebung des Entwicklers trennt. Dies verhindert, dass potenziell schädliche Änderungen unbemerkt bleiben und ermöglicht eine bessere Kontrolle über die Ausführung von Code.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus wird empfohlen, dass Entwickler sich nicht nur auf die vertrauten Container-Modelle verlassen, sondern auch neue Sicherheitsstrategien und -praktiken in ihre Arbeitsabläufe integrieren. Dazu gehört das Überprüfen von Änderungen, die von KI-Agenten vorgenommen werden, sowie das Implementieren von strengen Berechtigungen und Zugriffskontrollen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Herausforderung, die durch die Verwendung von KI-Coding-Agenten entsteht, erfordert ein Umdenken in Bezug auf Code-Isolation und Sicherheitsstrategien. Die Entwicklung neuer Technologien, wie microVMs, könnte entscheidend sein, um den Sicherheitsanforderungen in einer zunehmend automatisierten Entwicklungsumgebung gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Die Integration von KI-Coding-Agenten in Softwareentwicklungsprozesse verändert die Anforderungen an die Code-Isolation und Sicherheitsarchitekturen. Traditionelle Container -Modelle bieten nicht die notwendige Sicherheit, um mit den neuen Bedrohungen umzugehen, die durch autonome Agenten entstehen. Docker hat daher neue Ansätze entwickelt, um diese Herausforderungen zu adressieren.\nHauptinhalt Die Verwendung von KI-Coding-Agenten in der Softwareentwicklung hat die Art und Weise, wie Entwickler mit ihrem Code interagieren, grundlegend verändert. Diese Agenten können autonom Änderungen vornehmen, Fehler beheben und sogar die Codebasis neu strukturieren, ohne dass der Entwickler die genauen Details dieser Änderungen kennt. Dies führt zu einem Zustand, in dem Entwickler möglicherweise das Vertrauen in die Integrität ihrer eigenen Codebasis verlieren. Die Gefahr besteht darin, dass diese Agenten unkontrolliert Änderungen vornehmen, die potenziell Sicherheitslücken oder andere Probleme verursachen können.\n", "image": "https://ayedo.de/the-untrusted-autonomous-workload-how-ai-coding-agents-reshape-what-isolation-has-to-do.png", "date_published": "2026-05-26T13:00:00Z", "date_modified": "2026-05-26T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","kubernetes","security","software-delivery","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/news/announcing-etcd-3-7-0-beta-0/", "url": "https://ayedo.de/news/announcing-etcd-3-7-0-beta-0/", "title": "Ankündigung von etcd 3.7.0-beta.0", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie erste Beta-Version von etcd 3.7.0 ist verfügbar und bietet die neue Funktion RangeStream, die die Handhabung großer Ergebnislisten verbessert. Darüber hinaus wurden alle Komponenten von v2store entfernt, was die Version vollständig auf v3store umstellt. Die Unterstützung für die Version 3.4 endet, und Nutzer sollten ihre Cluster auf eine neuere Version aktualisieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Beta-Version 3.7.0 von etcd, einer verteilten Datenbank und einem wichtigen Bestandteil von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e, bringt mehrere bedeutende Verbesserungen mit sich. Eine der herausragendsten Neuerungen ist die Einführung von RangeStream, die es Anwendungen ermöglicht, große Ergebnislisten in kleineren, handhabbaren Chunks zu empfangen. Dies reduziert die Latenzzeiten und optimiert den Speicherverbrauch, was besonders in produktiven Umgebungen von Vorteil ist.\u003c/p\u003e\n\u003cp\u003eDie Implementierung von RangeStream wurde von einem neuen Mitwirkenden, einem Software-Ingenieur von Google, vorangetrieben. Diese Funktion löst ein bekanntes Problem in früheren Versionen, wo Anwendungen gezwungen waren, auf vollständige Ergebnislisten zu warten, was zu unvorhersehbaren Latenzen führte. Die Dokumentation von etcd enthält Anleitungen zur Nutzung von RangeStream in gRPC-Aufrufen sowie in etcdctl.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Schritt in der Entwicklung von etcd 3.7.0 ist die vollständige Entfernung des v2store. Diese Version ist die erste, die vollständig auf v3store basiert, was die Entdeckung, den Bootstrap-Prozess und die Verarbeitung von v2-Anfragen betrifft. Die Beseitigung veralteter experimenteller Flags könnte jedoch zu Komplikationen für Nutzer führen, die noch nicht auf die Version 3.6.11 aktualisiert haben. Nutzer werden aufgefordert, Feedback zu eventuellen Problemen zu geben, um die Upgrade-Dokumentation zu verbessern.\u003c/p\u003e\n\u003cp\u003eZusätzlich enthält die Beta-Version die Bibliotheken bbolt v1.5.0 und raft v3.7.0, die zur Stabilität und Leistung der Datenbank beitragen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung von RangeStream könnte signifikante Auswirkungen auf die Performance von Anwendungen haben, die große Datenmengen verarbeiten. Durch die Möglichkeit, Daten in Chunks zu empfangen, könnte die Reaktionszeit von Anwendungen verbessert und der Ressourcenverbrauch optimiert werden. Die vollständige Entfernung des v2store beseitigt potenzielle Sicherheitsrisiken und vereinfacht die Wartung, könnte jedoch bestehende Implementierungen beeinflussen, die noch auf v2 basieren. Nutzer sollten daher sorgfältig planen und testen, bevor sie auf die neue Version migrieren.\u003c/p\u003e\n\u003cp\u003eDie EOL (End of Life) der Version 3.4, die am 15. Mai 2026 in Kraft trat, bedeutet, dass Nutzer, die noch auf dieser Version arbeiten, dringend auf eine neuere Version umsteigen sollten, um Sicherheitsupdates und Support zu erhalten. Es wird erwartet, dass die Version 3.5 für ein weiteres Jahr nach der endgültigen Veröffentlichung von 3.7.0 unterstützt wird.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Beta-Version von etcd 3.7.0 stellt einen bedeutenden Fortschritt für die Plattform dar und bietet zahlreiche Verbesserungen, die die Benutzererfahrung und die Effizienz erhöhen. Nutzer sollten die neue Version testen und auf Feedback-Mechanismen zurückgreifen, um zur weiteren Entwicklung beizutragen. Die endgültige Version wird voraussichtlich im Laufe des Juni oder Anfang Juli veröffentlicht.\u003c/p\u003e\n", "summary": "TL;DR Die erste Beta-Version von etcd 3.7.0 ist verfügbar und bietet die neue Funktion RangeStream, die die Handhabung großer Ergebnislisten verbessert. Darüber hinaus wurden alle Komponenten von v2store entfernt, was die Version vollständig auf v3store umstellt. Die Unterstützung für die Version 3.4 endet, und Nutzer sollten ihre Cluster auf eine neuere Version aktualisieren.\nHauptinhalt Die Beta-Version 3.7.0 von etcd, einer verteilten Datenbank und einem wichtigen Bestandteil von Kubernetes, bringt mehrere bedeutende Verbesserungen mit sich. Eine der herausragendsten Neuerungen ist die Einführung von RangeStream, die es Anwendungen ermöglicht, große Ergebnislisten in kleineren, handhabbaren Chunks zu empfangen. Dies reduziert die Latenzzeiten und optimiert den Speicherverbrauch, was besonders in produktiven Umgebungen von Vorteil ist.\n", "image": "https://ayedo.de/announcing-etcd-3-7-0-beta-0.png", "date_published": "2026-05-20T00:00:00Z", "date_modified": "2026-05-20T00:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/news/meet-gordon-dockers-ai-agent-for-your-entire-container-workflow/", "url": "https://ayedo.de/news/meet-gordon-dockers-ai-agent-for-your-entire-container-workflow/", "title": "Lerne Gordon kennen: Dockers KI-Agent für deinen gesamten Container-Workflow", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eGordon ist ein KI-Agent von Docker, der den gesamten \u003ca href=\"/kubernetes/\"\u003eContainer-Workflow\u003c/a\u003e optimiert. Er analysiert Umgebungen, schlägt Lösungen vor und führt diese mit Genehmigung des Nutzers aus, wodurch die Problemlösung erheblich beschleunigt wird. Die Integration in Docker Desktop und CLI ermöglicht eine nahtlose Nutzung ohne zusätzliche Lernkurve.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eGordon wurde entwickelt, um die Herausforderungen moderner Softwareentwicklung zu bewältigen, insbesondere im Bereich der \u003ca href=\"/kubernetes/\"\u003eContainerisierung\u003c/a\u003e. In einer Zeit, in der Entwickler zunehmend auf KI-gestützte Tools zurückgreifen, um Code zu schreiben und Merge-Anfragen zu bearbeiten, bleibt die Fehlersuche in Containern oft eine Herausforderung. Typische Probleme wie ungültige Build-Caches oder unerwartete Fehler in CI-Umgebungen können die Produktivität erheblich beeinträchtigen. Gordon adressiert diese Probleme, indem er direkt auf die spezifische Container-Umgebung des Nutzers zugreift.\u003c/p\u003e\n\u003cp\u003eGordon ist in Docker Desktop Version 4.74+ und der CLI integriert. Er analysiert Protokolle, Images und Compose-Dateien, um den Kontext der Fehler zu verstehen. Anstatt den Nutzer an die Dokumentation zu verweisen, identifiziert er die Ursache eines Problems und schlägt eine Lösung vor, die der Nutzer dann genehmigen kann. Dies reduziert die Zeit, die für die Fehlersuche benötigt wird, von häufig über zwanzig Minuten auf nur zwei Minuten.\u003c/p\u003e\n\u003cp\u003eEin weiterer Vorteil von Gordon ist seine Fähigkeit, neue Umgebungen schnell aufzusetzen. Wenn ein Entwickler ein neues Projekt erhält, kann er Gordon einfach anweisen, die Anwendung zu containerisieren und eine Entwicklungsumgebung zu erstellen. Gordon liest den Code, erstellt die erforderlichen Dockerfiles und setzt die Umgebung auf, sodass der Entwickler sofort mit der Arbeit beginnen kann.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus bietet Gordon Unterstützung bei alltäglichen Aufgaben wie der Bereinigung nicht mehr benötigter Images oder der Optimierung von Dockerfiles. Er schlägt Verbesserungen vor, wie z.B. die Implementierung von Multi-Stage-Bauten oder die Verwendung schlankerer Basis-Images. Diese Funktionen tragen dazu bei, die Effizienz und die Ressourcennutzung zu maximieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eGordon nutzt eine umfassende Wissensdatenbank über Docker-Dokumentationen und Best Practices sowie Shell-Zugriff und Dateisystemoperationen. Die Architektur von Gordon erlaubt es, flexibel auf neue Anforderungen zu reagieren und verschiedene Funktionen zu kombinieren, um spezifische Probleme zu lösen. Da Gordon im gewohnten Docker-Umfeld arbeitet, entfällt die Notwendigkeit, neue Tools zu erlernen oder den Kontext bei Aufgabenwechseln neu aufzubauen.\u003c/p\u003e\n\u003cp\u003eDie Verwendung von Gordon kann den gesamten Entwicklungsprozess erheblich beschleunigen und die Effizienz der Entwickler steigern, da Routineaufgaben automatisiert und komplexe Probleme schnell gelöst werden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eGordon stellt einen bedeutenden Fortschritt in der Unterstützung von Entwicklern dar, indem er die Lücke zwischen Codierung und Deployment schließt. Mit seiner Einführung wird erwartet, dass die Produktivität in der \u003ca href=\"/kubernetes/\"\u003eContainerentwicklung\u003c/a\u003e weiter steigt und die Herausforderungen bei der Fehlersuche signifikant reduziert werden.\u003c/p\u003e\n", "summary": "TL;DR Gordon ist ein KI-Agent von Docker, der den gesamten Container-Workflow optimiert. Er analysiert Umgebungen, schlägt Lösungen vor und führt diese mit Genehmigung des Nutzers aus, wodurch die Problemlösung erheblich beschleunigt wird. Die Integration in Docker Desktop und CLI ermöglicht eine nahtlose Nutzung ohne zusätzliche Lernkurve.\nHauptinhalt Gordon wurde entwickelt, um die Herausforderungen moderner Softwareentwicklung zu bewältigen, insbesondere im Bereich der Containerisierung. In einer Zeit, in der Entwickler zunehmend auf KI-gestützte Tools zurückgreifen, um Code zu schreiben und Merge-Anfragen zu bearbeiten, bleibt die Fehlersuche in Containern oft eine Herausforderung. Typische Probleme wie ungültige Build-Caches oder unerwartete Fehler in CI-Umgebungen können die Produktivität erheblich beeinträchtigen. Gordon adressiert diese Probleme, indem er direkt auf die spezifische Container-Umgebung des Nutzers zugreift.\n", "image": "https://ayedo.de/meet-gordon-dockers-ai-agent-for-your-entire-container-workflow.png", "date_published": "2026-05-19T19:08:04Z", "date_modified": "2026-05-19T19:08:04Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","kubernetes","cloud-native","automation","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/coding-agent-horror-stories-the-security-crisis-threatening-developer-infrastructure/", "url": "https://ayedo.de/news/coding-agent-horror-stories-the-security-crisis-threatening-developer-infrastructure/", "title": "Coding-Agent-Horrorgeschichten: Die Sicherheitskrise, die die Entwicklerinfrastruktur bedroht", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAI-Coding-Agenten sind zunehmend in der Softwareentwicklung integriert, was sowohl Produktivitätsgewinne als auch erhebliche Sicherheitsrisiken mit sich bringt. Diese Agenten agieren mit weitreichenden Berechtigungen und können unvorhersehbare, potenziell schädliche Entscheidungen treffen, was Unternehmen vor neue Herausforderungen stellt. \u003ca href=\"/kubernetes/\"\u003eDocker-Sandboxes\u003c/a\u003e bieten eine Möglichkeit, diese Risiken zu minimieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIn den letzten Jahren haben AI-Coding-Agenten erheblich an Bedeutung gewonnen und sind mittlerweile in etwa 60 % der Entwicklungsprozesse integriert. Diese Agenten, wie Claude Code, GitHub Copilot und andere, können Aufgaben autonom erledigen, die früher Stunden oder Tage in Anspruch nahmen. Sie lesen Dateien, führen Shell-Befehle aus, schreiben und implementieren Code und treffen Entscheidungen, ohne dass eine explizite Genehmigung des Entwicklers erforderlich ist. Dies hat zu einem signifikanten Produktivitätsanstieg geführt, birgt jedoch auch erhebliche Risiken.\u003c/p\u003e\n\u003cp\u003eDie Funktionsweise dieser Agenten basiert auf einem einfachen Loop: beobachten, planen, handeln und wiederholen. Bei der Ausführung eines Auftrags zieht der Agent alle verfügbaren Informationen heran, einschließlich Umgebungsvariablen und Zugriff auf Datenbanken. Dies führt dazu, dass der Agent die gleichen Berechtigungen hat wie der Benutzer, der ihn gestartet hat. Wenn der Benutzer beispielsweise mit Administratorrechten eingeloggt ist, hat der Agent ebenfalls diese umfassenden Berechtigungen.\u003c/p\u003e\n\u003cp\u003eEin zentrales Problem besteht darin, dass AI-Coding-Agenten nicht deterministisch arbeiten. Während traditionelle Software genau das tut, was im Quellcode festgelegt ist, trifft ein AI-Agent Entscheidungen in Echtzeit, die für den Benutzer unerwartet sein können. Diese Entscheidungen können katastrophale Folgen haben, wie das versehentliche Löschen von Produktionsdaten oder das unkontrollierte Überschreiben von Dateien. Berichte über derartige Vorfälle sind in den letzten 16 Monaten dokumentiert worden, was die Notwendigkeit unterstreicht, Sicherheitsvorkehrungen zu treffen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Tatsache, dass AI-Coding-Agenten als der Benutzer agieren, stellt ein erhebliches Sicherheitsrisiko dar. Unternehmen müssen sicherstellen, dass ihre Entwicklungsumgebungen ausreichend geschützt sind, um unbefugten Zugriff und unbeabsichtigte Änderungen zu verhindern. \u003ca href=\"/kubernetes/\"\u003eDocker-Sandboxes\u003c/a\u003e bieten eine potenzielle Lösung, indem sie eine isolierte Umgebung schaffen, in der Agenten arbeiten können, ohne direkten Zugriff auf kritische Systeme oder Datenbanken zu haben. Dies könnte dazu beitragen, die Auswirkungen von Fehlentscheidungen zu minimieren und die Sicherheit der Entwicklerinfrastruktur zu erhöhen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von AI-Coding-Agenten in den Entwicklungsprozess bietet sowohl Chancen als auch Herausforderungen. Unternehmen sind gefordert, geeignete Sicherheitsmaßnahmen zu implementieren, um die Risiken zu managen, die mit der Nutzung dieser leistungsfähigen, aber potenziell gefährlichen Tools verbunden sind. Die Entwicklung sicherer Arbeitsumgebungen wird entscheidend sein, um die Vorteile von AI-Agenten zu nutzen, ohne die Integrität der Systeme zu gefährden.\u003c/p\u003e\n", "summary": "TL;DR AI-Coding-Agenten sind zunehmend in der Softwareentwicklung integriert, was sowohl Produktivitätsgewinne als auch erhebliche Sicherheitsrisiken mit sich bringt. Diese Agenten agieren mit weitreichenden Berechtigungen und können unvorhersehbare, potenziell schädliche Entscheidungen treffen, was Unternehmen vor neue Herausforderungen stellt. Docker-Sandboxes bieten eine Möglichkeit, diese Risiken zu minimieren.\nHauptinhalt In den letzten Jahren haben AI-Coding-Agenten erheblich an Bedeutung gewonnen und sind mittlerweile in etwa 60 % der Entwicklungsprozesse integriert. Diese Agenten, wie Claude Code, GitHub Copilot und andere, können Aufgaben autonom erledigen, die früher Stunden oder Tage in Anspruch nahmen. Sie lesen Dateien, führen Shell-Befehle aus, schreiben und implementieren Code und treffen Entscheidungen, ohne dass eine explizite Genehmigung des Entwicklers erforderlich ist. Dies hat zu einem signifikanten Produktivitätsanstieg geführt, birgt jedoch auch erhebliche Risiken.\n", "image": "https://ayedo.de/coding-agent-horror-stories-the-security-crisis-threatening-developer-infrastructure.png", "date_published": "2026-05-18T13:00:00Z", "date_modified": "2026-05-18T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","operations","cloud-native","development"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-new-metric-for-route-sync-in-the-cloud-controller-manager/", "url": "https://ayedo.de/news/kubernetes-v1-36-new-metric-for-route-sync-in-the-cloud-controller-manager/", "title": "Kubernetes v1.36: Neue Metrik für Route Sync im Cloud Controller Manager", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt eine neue Alpha-Metrik namens \u003ccode\u003eroute_controller_route_sync_total\u003c/code\u003e im Cloud Controller Manager ein, die die Anzahl der Synchronisierungen von Routen mit dem Cloud-Anbieter zählt. Diese Metrik unterstützt die Validierung des watch-basierten Routenabgleichs, der in Kubernetes v1.35 eingeführt wurde und die Effizienz der API-Nutzung verbessert.\u003c/p\u003e\n\u003cp\u003eKubernetes v1.36 bringt eine bedeutende Neuerung für den Cloud Controller Manager (CCM) mit sich: die Einführung der Metrik \u003ccode\u003eroute_controller_route_sync_total\u003c/code\u003e. Diese Alpha-Metrik zählt, wie oft Routen mit dem Cloud-Anbieter synchronisiert werden. Ihr Hauptziel ist es, Betreibern zu helfen, die neue Funktion des watch-basierten Routenabgleichs zu validieren, die in der vorherigen Version, Kubernetes v1.35, eingeführt wurde.\u003c/p\u003e\n\u003cp\u003eDer watch-basierte Routenabgleich verändert den bisherigen festen Intervallansatz, bei dem Routen in regelmäßigen Abständen synchronisiert wurden. Stattdessen wird nun nur synchronisiert, wenn sich tatsächlich Änderungen an den Knoten ergeben. Dies führt zu einer signifikanten Reduzierung der API-Aufrufe an den Infrastruktur-Anbieter, was insbesondere in Umgebungen mit begrenzten API-Raten von Vorteil ist. Die Metrik \u003ccode\u003eroute_controller_route_sync_total\u003c/code\u003e bietet eine Möglichkeit, den Unterschied in der Effizienz zwischen dem alten und dem neuen Ansatz zu messen.\u003c/p\u003e\n\u003cp\u003eUm den Einfluss des watch-basierten Routenabgleichs zu testen, können Betreiber die Metrik in einem A/B-Test verwenden. Dabei wird die Metrik mit deaktiviertem Feature Gate (Standardverhalten) mit der Metrik bei aktiviertem Feature Gate verglichen. In Clustern, in denen sich die Knoten selten ändern, sollte bei aktivem Feature Gate ein deutlicher Rückgang der Synchronisierungsrate zu beobachten sein.\u003c/p\u003e\n\u003cp\u003eEin Beispiel verdeutlicht das erwartete Verhalten: Bei deaktiviertem Feature Gate (fester Intervall) erhöht sich der Zähler kontinuierlich, unabhängig von Änderungen an den Knoten. Im Gegensatz dazu bleibt der Zähler bei aktiviertem Feature Gate unverändert, solange keine Knoten hinzugefügt, entfernt oder aktualisiert werden. Diese Unterschiede sind besonders in stabilen Clustern sichtbar, in denen sich die Knoten selten ändern.\u003c/p\u003e\n\u003cp\u003eDie Einführung dieser Metrik und die Anpassung des Routenabgleichs bieten Betreibern die Möglichkeit, ihre Ressourcen effizienter zu verwalten und die Belastung der API zu verringern. Dies könnte insbesondere für Unternehmen von Bedeutung sein, die in Umgebungen mit strengen API-Raten arbeiten.\u003c/p\u003e\n\u003cp\u003eInsgesamt stellt die neue Metrik in Kubernetes v1.36 eine wertvolle Ergänzung dar, die es Betreibern ermöglicht, die Effizienz ihrer \u003ca href=\"/cloud-native/\"\u003eCloud-Integration\u003c/a\u003e zu verbessern und gleichzeitig die Belastung der Infrastruktur zu reduzieren. Die Möglichkeit, Feedback über verschiedene Kanäle zu geben, zeigt, dass die Kubernetes-Community aktiv an der Verbesserung und Weiterentwicklung der \u003ca href=\"/platform/\"\u003ePlattform\u003c/a\u003e arbeitet.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt eine neue Alpha-Metrik namens route_controller_route_sync_total im Cloud Controller Manager ein, die die Anzahl der Synchronisierungen von Routen mit dem Cloud-Anbieter zählt. Diese Metrik unterstützt die Validierung des watch-basierten Routenabgleichs, der in Kubernetes v1.35 eingeführt wurde und die Effizienz der API-Nutzung verbessert.\nKubernetes v1.36 bringt eine bedeutende Neuerung für den Cloud Controller Manager (CCM) mit sich: die Einführung der Metrik route_controller_route_sync_total. Diese Alpha-Metrik zählt, wie oft Routen mit dem Cloud-Anbieter synchronisiert werden. Ihr Hauptziel ist es, Betreibern zu helfen, die neue Funktion des watch-basierten Routenabgleichs zu validieren, die in der vorherigen Version, Kubernetes v1.35, eingeführt wurde.\n", "image": "https://ayedo.de/kubernetes-v1-36-new-metric-for-route-sync-in-the-cloud-controller-manager.png", "date_published": "2026-05-15T18:35:00Z", "date_modified": "2026-05-15T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","cloud","operations"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-mixed-version-proxy-graduates-to-beta/", "url": "https://ayedo.de/news/kubernetes-v1-36-mixed-version-proxy-graduates-to-beta/", "title": "Kubernetes v1.36: Mixed Version Proxy erreicht Beta-Status", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt den Mixed Version Proxy (MVP) in den Beta-Status ein, um die Sicherheit bei Cluster-Upgrades zu erhöhen. Diese Funktion ermöglicht es API-Servern unterschiedlicher Versionen, Anfragen an die jeweils geeigneten Server weiterzuleiten, wodurch Fehler wie 404 Not Found vermieden werden.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Einführung des Mixed Version Proxy (MVP) in Kubernetes v1.36 markiert einen bedeutenden Fortschritt in der Handhabung von API-Anfragen während Cluster-Upgrades. Ursprünglich in Kubernetes v1.28 als Alpha-Funktion vorgestellt, zielt MVP darauf ab, die Verfügbarkeit und Stabilität des Control Plane zu verbessern, indem es sicherstellt, dass Anfragen, die von älteren API-Servern empfangen werden, an die entsprechenden, neueren API-Server weitergeleitet werden. Dies verhindert, dass Anfragen, die auf nicht unterstützte Ressourcen abzielen, fälschlicherweise mit einem 404-Fehler beantwortet werden.\u003c/p\u003e\n\u003cp\u003eEin häufiges Problem in hochverfügbaren Umgebungen ist, dass während eines Upgrades API-Server unterschiedlicher Versionen gleichzeitig betrieben werden. Diese Server können unterschiedliche API-Gruppen oder -Versionen bedienen. Ohne MVP würde ein API-Server, der eine Anfrage für eine neue API-Version erhält, die nicht lokal verfügbar ist, einen 404-Fehler zurückgeben. Dies kann zu schwerwiegenden Problemen führen, wie etwa fehlerhafter Garbage Collection oder blockierten Namespace-Löschungen.\u003c/p\u003e\n\u003cp\u003eDer MVP leitet die Anfrage stattdessen an einen peer API-Server weiter, der die angeforderte Ressource bereitstellen kann. Dieser Prozess verbessert die Nutzererfahrung und die Gesamtstabilität des Clusters erheblich.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Beta-Version des MVP bringt mehrere technische Verbesserungen mit sich. Eine der wesentlichen Änderungen ist der Übergang von der Abhängigkeit von der StorageVersion API hin zur Aggregated Discovery. Während die Alpha-Version auf der StorageVersion API basierte, die nicht für Custom Resource Definitions (CRDs) und aggregierte APIs unterstützt wurde, nutzt die Beta-Version nun die aggregierten Entdeckungsdaten. Dies ermöglicht eine dynamische Erkennung der Fähigkeiten der peer API-Server.\u003c/p\u003e\n\u003cp\u003eEin weiterer bedeutender Fortschritt ist die Einführung der Peer-Aggregated Discovery. Diese Funktion erlaubt es den API-Servern, die lokale Sicht auf die verfügbaren APIs mit den Entdeckungsdaten aller aktiven peer Server zu kombinieren. Dadurch erhalten Clients eine vollständige Übersicht über alle APIs im Cluster, unabhängig davon, mit welchem API-Server sie verbunden sind. Dies stellt sicher, dass alle verfügbaren Ressourcen sichtbar sind und verbessert die Effizienz bei der Nutzung der API.\u003c/p\u003e\n\u003cp\u003eFür die Aktivierung des MVP in Kubernetes v1.36 müssen bestimmte Konfigurationsparameter gesetzt werden. Während die Funktion standardmäßig aktiviert ist, ist es entscheidend, den Parameter \u003ccode\u003e--peer-ca-file=\u0026lt;path-to-ca\u0026gt;\u003c/code\u003e zu konfigurieren, um eine sichere Kommunikation zwischen den peer API-Servern zu gewährleisten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung des Mixed Version Proxy in den Beta-Status stellt einen wichtigen Schritt in der Weiterentwicklung von Kubernetes dar und verbessert die Handhabung von API-Anfragen während Cluster-Upgrades erheblich. Die neuen Funktionen ermöglichen eine nahtlose Interoperabilität zwischen unterschiedlichen API-Server-Versionen und tragen zur Stabilität und Verfügbarkeit von Kubernetes-Clustern bei.\u003c/p\u003e\n\u003cp\u003eDie Verwendung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und die Implementierung von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e Technologien sind entscheidend für die Optimierung von Cloud-native Anwendungen.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt den Mixed Version Proxy (MVP) in den Beta-Status ein, um die Sicherheit bei Cluster-Upgrades zu erhöhen. Diese Funktion ermöglicht es API-Servern unterschiedlicher Versionen, Anfragen an die jeweils geeigneten Server weiterzuleiten, wodurch Fehler wie 404 Not Found vermieden werden.\nHauptinhalt Die Einführung des Mixed Version Proxy (MVP) in Kubernetes v1.36 markiert einen bedeutenden Fortschritt in der Handhabung von API-Anfragen während Cluster-Upgrades. Ursprünglich in Kubernetes v1.28 als Alpha-Funktion vorgestellt, zielt MVP darauf ab, die Verfügbarkeit und Stabilität des Control Plane zu verbessern, indem es sicherstellt, dass Anfragen, die von älteren API-Servern empfangen werden, an die entsprechenden, neueren API-Server weitergeleitet werden. Dies verhindert, dass Anfragen, die auf nicht unterstützte Ressourcen abzielen, fälschlicherweise mit einem 404-Fehler beantwortet werden.\n", "image": "https://ayedo.de/kubernetes-v1-36-mixed-version-proxy-graduates-to-beta.png", "date_published": "2026-05-15T18:00:00Z", "date_modified": "2026-05-15T18:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/", "url": "https://ayedo.de/news/kubernetes-v1-36-deprecation-and-removal-of-service-externalips/", "title": "Kubernetes v1.36: Abkündigung und Entfernung von Service ExternalIPs", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eIn Kubernetes v1.36 wird das .spec.externalIPs-Feld für Services offiziell als veraltet markiert und soll in zukünftigen Versionen entfernt werden. Dies geschieht aufgrund von Sicherheitsbedenken, da die Funktionalität potenzielle Angriffsvektoren birgt. Alternativen wie manuell verwaltete LoadBalancer-Services oder der Einsatz von Drittanbieter-Load-Balancer-Controllern wie \u003ca href=\"/kubernetes/\"\u003eMetalLB\u003c/a\u003e werden empfohlen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eKubernetes hat das .spec.externalIPs-Feld für Services, das ursprünglich dazu gedacht war, cloud-ähnliche Load-Balancer-Funktionalitäten in nicht-cloudbasierten Clustern bereitzustellen, in der Version 1.36 als veraltet erklärt. Die Entscheidung wurde getroffen, nachdem festgestellt wurde, dass die API davon ausgeht, dass alle Benutzer im Cluster vollständig vertrauenswürdig sind. In Szenarien, in denen dies nicht zutrifft, könnten Sicherheitsanfälligkeiten, wie sie in CVE-2020-8554 beschrieben sind, ausgenutzt werden. Um die Nutzung des .spec.externalIPs-Feldes zu reduzieren, wurde bereits in Kubernetes 1.21 empfohlen, dieses Feld zu deaktivieren, und ein Admission Controller namens DenyServiceExternalIPs wurde eingeführt.\u003c/p\u003e\n\u003cp\u003eDie Sicherheitsprobleme, die mit der Nutzung von .spec.externalIPs verbunden sind, bleiben weiterhin bestehen. Daher wird erwartet, dass in einer zukünftigen Version von Kubernetes die Implementierung dieser Funktionalität aus kube-proxy entfernt wird. Zudem werden die Kriterien für die \u003ca href=\"/compliance/\"\u003eKubernetes-Konformität\u003c/a\u003e aktualisiert, um sicherzustellen, dass konforme Implementierungen die Unterstützung für .spec.externalIPs nicht bieten.\u003c/p\u003e\n\u003cp\u003eEs ist wichtig zu beachten, dass der Begriff \u0026ldquo;externe IP\u0026rdquo; in Kubernetes mehrere Bedeutungen hat. Die Abkündigung bezieht sich spezifisch auf das .spec.externalIPs-Feld. Wenn dieses Feld nicht in den Services verwendet wird, ist die Abkündigung nicht relevant. Dennoch wird empfohlen, den DenyServiceExternalIPs Admission Controller zu aktivieren, um eine zukünftige Nutzung des .spec.externalIPs-Feldes zu verhindern.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eFür Benutzer, die das .spec.externalIPs-Feld derzeit verwenden, stehen mehrere Alternativen zur Verfügung. Eine Möglichkeit besteht darin, von .spec.externalIPs auf einen LoadBalancer-Service zu wechseln, wobei die Load-Balancer-IP manuell zugewiesen wird. Dies hat jedoch ähnliche Sicherheitsimplikationen, da die IP-Adresse in der .status des Services gespeichert wird und nur von Benutzern mit entsprechenden Berechtigungen bearbeitet werden kann.\u003c/p\u003e\n\u003cp\u003eEine bessere Alternative ist die Verwendung eines nicht-cloudbasierten Load-Balancer-Controllers, wie \u003ca href=\"/kubernetes/\"\u003eMetalLB\u003c/a\u003e. Dieser ermöglicht es Administratoren, IP-Adressbereiche zu konfigurieren, die den Services zugewiesen werden können, und stellt sicher, dass keine zwei Services dieselbe IP-Adresse verwenden. Dies löst die Sicherheitsprobleme, die mit der Nutzung von .spec.externalIPs verbunden sind.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Abkündigung des .spec.externalIPs-Feldes in Kubernetes v1.36 stellt einen wichtigen Schritt in Richtung einer sichereren Cluster-Architektur dar. Die Nutzung von Alternativen wie \u003ca href=\"/kubernetes/\"\u003eMetalLB\u003c/a\u003e wird empfohlen, um die Funktionalität eines Load-Balancers sicher und effizient bereitzustellen.\u003c/p\u003e\n", "summary": "TL;DR In Kubernetes v1.36 wird das .spec.externalIPs-Feld für Services offiziell als veraltet markiert und soll in zukünftigen Versionen entfernt werden. Dies geschieht aufgrund von Sicherheitsbedenken, da die Funktionalität potenzielle Angriffsvektoren birgt. Alternativen wie manuell verwaltete LoadBalancer-Services oder der Einsatz von Drittanbieter-Load-Balancer-Controllern wie MetalLB werden empfohlen.\nHauptinhalt Kubernetes hat das .spec.externalIPs-Feld für Services, das ursprünglich dazu gedacht war, cloud-ähnliche Load-Balancer-Funktionalitäten in nicht-cloudbasierten Clustern bereitzustellen, in der Version 1.36 als veraltet erklärt. Die Entscheidung wurde getroffen, nachdem festgestellt wurde, dass die API davon ausgeht, dass alle Benutzer im Cluster vollständig vertrauenswürdig sind. In Szenarien, in denen dies nicht zutrifft, könnten Sicherheitsanfälligkeiten, wie sie in CVE-2020-8554 beschrieben sind, ausgenutzt werden. Um die Nutzung des .spec.externalIPs-Feldes zu reduzieren, wurde bereits in Kubernetes 1.21 empfohlen, dieses Feld zu deaktivieren, und ein Admission Controller namens DenyServiceExternalIPs wurde eingeführt.\n", "image": "https://ayedo.de/kubernetes-v1-36-deprecation-and-removal-of-service-externalips.png", "date_published": "2026-05-14T18:35:00Z", "date_modified": "2026-05-14T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","security","cloud-native","cloud","development"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-advancing-workload-aware-scheduling/", "url": "https://ayedo.de/news/kubernetes-v1-36-advancing-workload-aware-scheduling/", "title": "Kubernetes v1.36: Fortschritt beim workload-bewussten Scheduling", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 bringt bedeutende Fortschritte im Bereich des workload-bewussten Schedulings, einschließlich der Einführung der Workload- und PodGroup-APIs. Diese Trennung ermöglicht eine effizientere Verwaltung von Batch- und AI/ML-Workloads, verbessert die Skalierbarkeit und Leistung und bietet neue Funktionen wie Topologie- und vorab bewusste Preemption.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Version v1.36 von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e stellt eine entscheidende Weiterentwicklung im Scheduling-Management dar, insbesondere für komplexe Workloads wie AI/ML und Batch-Prozesse. Die Einführung der Workload API und der PodGroup API ist dabei zentral. Während die Workload API als statisches Template fungiert, verwaltet die PodGroup API den Runtime-Zustand der Pods. Diese Trennung verbessert die Effizienz des kube-schedulers, da er nun direkt auf die Informationen der PodGroup zugreifen kann, ohne die Workload-Objekte analysieren zu müssen.\u003c/p\u003e\n\u003cp\u003eIn v1.36 wurde die API-Gruppe scheduling.k8s.io/v1alpha2 eingeführt, die die vorherige v1alpha1-Version vollständig ersetzt. Die PodGroup API ermöglicht es, den Status von Pods effizient zu verwalten und Aktualisierungen pro Replica zu sharden. Dies führt zu einer höheren Skalierbarkeit und Performance, da der Scheduler nun die Pods als Teil einer Gruppe und nicht einzeln betrachtet.\u003c/p\u003e\n\u003cp\u003eZusätzlich zur Verbesserung der API-Struktur bietet die neue Version auch Funktionen wie Topologie-bewusstes Scheduling und workload-bewusste Preemption. Diese Features helfen dabei, Ressourcen gezielter zuzuweisen und die Effizienz der Ausführung zu steigern. Die Unterstützung von ResourceClaims für Workloads ermöglicht zudem eine dynamische Ressourcenallokation für PodGroups.\u003c/p\u003e\n\u003cp\u003eDie Integration zwischen dem Job-Controller und der neuen API wird ebenfalls in dieser Version demonstriert, was die praktische Anwendbarkeit der neuen Funktionen unterstreicht.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Trennung von Workload und PodGroup in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 hat mehrere technische Implikationen. Die Workload API fungiert als statisches Template, während die PodGroup API den dynamischen Zustand der Pods verwaltet. Dies reduziert die Komplexität im Scheduler und ermöglicht eine atomare Verarbeitung von Workloads. Der neue PodGroup Scheduling Cycle behandelt Pod-Gruppen als Einheit, was das Risiko von Deadlocks verringert und die Effizienz des Ressourcenmanagements erhöht.\u003c/p\u003e\n\u003cp\u003eDie neuen Topologie- und workload-bewussten Preemption-Funktionen erweitern die Möglichkeiten des Schedulings erheblich und ermöglichen eine verbesserte Planung basierend auf den tatsächlichen Anforderungen der Workloads.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklungen in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 setzen einen wichtigen Schritt in Richtung eines effizienteren und leistungsfähigeren Schedulings. Die Trennung von Workload- und PodGroup-APIs schafft eine solide Grundlage für zukünftige Verbesserungen im Bereich des workload-bewussten Schedulings. Die Integration neuer Features wird voraussichtlich die Handhabung komplexer Workloads weiter optimieren.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 bringt bedeutende Fortschritte im Bereich des workload-bewussten Schedulings, einschließlich der Einführung der Workload- und PodGroup-APIs. Diese Trennung ermöglicht eine effizientere Verwaltung von Batch- und AI/ML-Workloads, verbessert die Skalierbarkeit und Leistung und bietet neue Funktionen wie Topologie- und vorab bewusste Preemption.\nHauptinhalt Die Version v1.36 von Kubernetes stellt eine entscheidende Weiterentwicklung im Scheduling-Management dar, insbesondere für komplexe Workloads wie AI/ML und Batch-Prozesse. Die Einführung der Workload API und der PodGroup API ist dabei zentral. Während die Workload API als statisches Template fungiert, verwaltet die PodGroup API den Runtime-Zustand der Pods. Diese Trennung verbessert die Effizienz des kube-schedulers, da er nun direkt auf die Informationen der PodGroup zugreifen kann, ohne die Workload-Objekte analysieren zu müssen.\n", "image": "https://ayedo.de/kubernetes-v1-36-advancing-workload-aware-scheduling.png", "date_published": "2026-05-13T18:35:00Z", "date_modified": "2026-05-13T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-psi-metrics-for-kubernetes-graduates-to-ga/", "url": "https://ayedo.de/news/kubernetes-v1-36-psi-metrics-for-kubernetes-graduates-to-ga/", "title": "Kubernetes v1.36: PSI-Metriken für Kubernetes-Absolventen in GA", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt die Pressure Stall Information (PSI) Metriken in den stabilen Status ein, um eine präzisere Überwachung der Ressourcenbelastung zu ermöglichen. Diese Metriken bieten Einblicke in die tatsächliche Auslastung von CPU, Speicher und I/O, indem sie die Zeit erfassen, in der Aufgaben aufgrund von Ressourcensättigung blockiert sind.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit der Einführung von Kubernetes v1.36 wird die Pressure Stall Information (PSI) als stabiler Bestandteil des Systems bereitgestellt. PSI, ursprünglich im Linux-Kernel 2018 implementiert, hilft dabei, Ressourcenengpässe zu erkennen, bevor sie zu Ausfällen führen. Im Gegensatz zu herkömmlichen Auslastungsmetriken, die lediglich die Nutzung anzeigen, bietet PSI eine detaillierte Analyse der Zeit, in der Aufgaben aufgrund von Ressourcenengpässen gestoppt werden.\u003c/p\u003e\n\u003cp\u003eDie neuen PSI-Metriken ermöglichen es Nutzern, die Ressourcenkontention auf verschiedenen Ebenen – Node, Pod und \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e – zu überwachen. Die Metriken umfassen kumulierte Zeitwerte und gleitende Durchschnitte über Zeitfenster von 10, 60 und 300 Sekunden, um zwischen temporären Spitzen und anhaltenden Belastungen zu unterscheiden.\u003c/p\u003e\n\u003cp\u003eUm die Stabilität und Leistungsfähigkeit der PSI-Implementierung zu gewährleisten, wurden umfassende Leistungstests durchgeführt. Diese Tests umfassten hochdichte Workloads mit mehr als 80 Pods auf verschiedenen Maschinentypen. Die Tests isolierten die Auswirkungen der Kubelet- und Kernel-Sammlung, um den Ressourcenaufwand der neuen Metriken zu bewerten.\u003c/p\u003e\n\u003cp\u003eIm ersten Testszenario wurde der Ressourcenverbrauch des Kubelets auf Maschinen mit vier Kernen untersucht. Dabei zeigte sich, dass die Kubelet-Abfrage der PSI-Metriken keinen signifikanten Einfluss auf die Ressourcennutzung hatte. Der Ressourcenverbrauch blieb im normalen Rahmen und bestätigte, dass die Kubelet-Logik effizient und unauffällig in die regulären Betriebszyklen integriert ist.\u003c/p\u003e\n\u003cp\u003eIm zweiten Testszenario wurde die Effizienz der PSI-Überwachung auf Kernel-Ebene bewertet. Selbst unter hoher Last blieb der CPU-Verbrauch zwischen aktivierter und deaktivierter PSI-Funktion minimal, was die Effizienz des internen Kernel-Trackings unter Beweis stellte. Diese Ergebnisse zeigen, dass die PSI-Integration in Kubernetes sowohl in Bezug auf Performance als auch auf Ressourcenverbrauch für Produktionsumgebungen geeignet ist.\u003c/p\u003e\n\u003cp\u003eEine weitere Verbesserung in v1.36 ist die intelligentere Handhabung der Metrikausgabe durch das Kubelet. Zuvor konnten falsche Nullwerte ausgegeben werden, wenn die zugrunde liegende Linux-Kernel-Version PSI nicht unterstützte. In der neuen Version erkennt das Kubelet nun die Unterstützung von PSI durch die cgroup-Konfigurationen, was zu präziseren und verlässlicheren Metriken führt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung von PSI in Kubernetes v1.36 hat weitreichende technische Implikationen für \u003ca href=\"/kubernetes/\"\u003eDevOps\u003c/a\u003e Teams und Cloud-Architekten. Die Möglichkeit, Ressourcenengpässe präziser zu überwachen, ermöglicht eine proaktive Verwaltung von Anwendungen und Infrastruktur. Die geringen zusätzlichen Ressourcenanforderungen für das Kubelet und die Kernel-Integration bedeuten, dass Unternehmen PSI ohne signifikante Leistungseinbußen implementieren können. Dies verbessert nicht nur die Fehlervorhersage, sondern optimiert auch die Ressourcennutzung in Kubernetes-Clustern.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Stabilisierung der PSI-Metriken in Kubernetes v1.36 bietet eine wertvolle Erweiterung für die Überwachung und Verwaltung von Ressourcen in \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Umgebungen. Mit diesen neuen Metriken sind Unternehmen besser gerüstet, um die Performance ihrer Anwendungen zu optimieren und potenzielle Engpässe frühzeitig zu identifizieren.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt die Pressure Stall Information (PSI) Metriken in den stabilen Status ein, um eine präzisere Überwachung der Ressourcenbelastung zu ermöglichen. Diese Metriken bieten Einblicke in die tatsächliche Auslastung von CPU, Speicher und I/O, indem sie die Zeit erfassen, in der Aufgaben aufgrund von Ressourcensättigung blockiert sind.\nHauptinhalt Mit der Einführung von Kubernetes v1.36 wird die Pressure Stall Information (PSI) als stabiler Bestandteil des Systems bereitgestellt. PSI, ursprünglich im Linux-Kernel 2018 implementiert, hilft dabei, Ressourcenengpässe zu erkennen, bevor sie zu Ausfällen führen. Im Gegensatz zu herkömmlichen Auslastungsmetriken, die lediglich die Nutzung anzeigen, bietet PSI eine detaillierte Analyse der Zeit, in der Aufgaben aufgrund von Ressourcenengpässen gestoppt werden.\n", "image": "https://ayedo.de/kubernetes-v1-36-psi-metrics-for-kubernetes-graduates-to-ga.png", "date_published": "2026-05-12T18:35:00Z", "date_modified": "2026-05-12T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","digital-sovereignty","software-delivery","platform"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-moving-volume-group-snapshots-to-ga/", "url": "https://ayedo.de/news/kubernetes-v1-36-moving-volume-group-snapshots-to-ga/", "title": "Kubernetes v1.36: Volume Group Snapshots in GA verschieben", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMit der Veröffentlichung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 wurde die Unterstützung für Volume Group Snapshots in den Status \u0026ldquo;Allgemeine Verfügbarkeit\u0026rdquo; (GA) überführt. Diese Funktion ermöglicht es, konsistente Snapshots mehrerer Volumes gleichzeitig zu erstellen, was insbesondere für Anwendungen mit mehreren Volumes von Vorteil ist.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 hat die Unterstützung für Volume Group Snapshots, die zuvor in den Alpha- und Beta-Phasen getestet wurden, nun offiziell freigegeben. Diese Funktion basiert auf einer Reihe von Erweiterungs-APIs, die es Nutzern ermöglichen, konsistente Snapshots für eine Gruppe von Volumes zu erstellen. Durch die Verwendung eines Label-Selectors können mehrere PersistentVolumeClaim-Objekte für das Snapshotting gruppiert werden. Ziel ist es, diese Snapshots auf neue Volumes wiederherzustellen und die Arbeitslast basierend auf einem konsistenten Wiederherstellungspunkt zurückzusetzen.\u003c/p\u003e\n\u003cp\u003eVolume Group Snapshots sind besonders nützlich, wenn Anwendungen Daten über mehrere Volumes hinweg speichern. Beispielsweise könnte eine Anwendung ihre Daten in einem Volume und Protokolle in einem anderen Volume ablegen. Wenn Snapshots dieser Volumes zu unterschiedlichen Zeitpunkten erstellt werden, kann dies zu Inkonsistenzen führen, die die Funktionsfähigkeit der Anwendung beeinträchtigen. Mit der neuen Funktion können Snapshots für alle Volumes in der Gruppe gleichzeitig erstellt werden, ohne dass die Anwendung in einen konsistenten Zustand versetzt werden muss.\u003c/p\u003e\n\u003cp\u003eDie Unterstützung für Volume Group Snapshots erfolgt über drei API-Arten: VolumeGroupSnapshot, VolumeGroupSnapshotContent und VolumeGroupSnapshotClass. Diese API-Objekte sind als CustomResourceDefinitions (CRDs) definiert und ermöglichen die Verwaltung von Snapshots. Die API-Version wurde auf v1 angehoben, was eine verbesserte Stabilität und Fehlerbehebungen auf Basis von Rückmeldungen aus den Beta-Versionen mit sich bringt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung von Volume Group Snapshots in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e erfordert die Verwendung von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e Storage Interface (CSI)-Volume-Treibern. Bei der Erstellung eines neuen Gruppen-Snapshots muss ein VolumeGroupSnapshotClass-Objekt definiert werden. Die PersistentVolumeClaims (PVCs), die zusammen gesnapshottet werden sollen, müssen mit einem gemeinsamen Label versehen werden, damit der Snapshot-Controller diese finden kann.\u003c/p\u003e\n\u003cp\u003eEin Beispiel für die Erstellung eines neuen VolumeGroupSnapshot könnte wie folgt aussehen: Zunächst werden die PVCs mit Labels versehen, um sie zu gruppieren. Anschließend wird ein VolumeGroupSnapshot-Objekt erstellt, das auf die definierten PVCs verweist. Bei der Wiederherstellung kann ein neuer PersistentVolumeClaim angefordert werden, um die Daten aus dem Snapshot zu rehydrieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung von Volume Group Snapshots in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 stellt einen bedeutenden Fortschritt für die Datenverwaltung in Cloud-nativen Anwendungen dar. Diese Funktion verbessert die Konsistenz und Verfügbarkeit von Daten und erleichtert die Wiederherstellung von Arbeitslasten in komplexen Anwendungsarchitekturen.\u003c/p\u003e\n", "summary": "TL;DR Mit der Veröffentlichung von Kubernetes v1.36 wurde die Unterstützung für Volume Group Snapshots in den Status \u0026ldquo;Allgemeine Verfügbarkeit\u0026rdquo; (GA) überführt. Diese Funktion ermöglicht es, konsistente Snapshots mehrerer Volumes gleichzeitig zu erstellen, was insbesondere für Anwendungen mit mehreren Volumes von Vorteil ist.\nHauptinhalt Kubernetes v1.36 hat die Unterstützung für Volume Group Snapshots, die zuvor in den Alpha- und Beta-Phasen getestet wurden, nun offiziell freigegeben. Diese Funktion basiert auf einer Reihe von Erweiterungs-APIs, die es Nutzern ermöglichen, konsistente Snapshots für eine Gruppe von Volumes zu erstellen. Durch die Verwendung eines Label-Selectors können mehrere PersistentVolumeClaim-Objekte für das Snapshotting gruppiert werden. Ziel ist es, diese Snapshots auf neue Volumes wiederherzustellen und die Arbeitslast basierend auf einem konsistenten Wiederherstellungspunkt zurückzusetzen.\n", "image": "https://ayedo.de/kubernetes-v1-36-moving-volume-group-snapshots-to-ga.png", "date_published": "2026-05-08T18:35:00Z", "date_modified": "2026-05-08T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-more-drivers-new-features-and-the-next-era-of-dra/", "url": "https://ayedo.de/news/kubernetes-v1-36-more-drivers-new-features-and-the-next-era-of-dra/", "title": "Kubernetes v1.36: Mehr Treiber, neue Funktionen und die nächste Ära von DRA", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 bringt bedeutende Fortschritte in der dynamischen Ressourcenallokation (DRA) mit neuen Funktionen und Verbesserungen, die die Flexibilität bei der Verwaltung von Hardwarebeschleunigern und spezialisierten Ressourcen erweitern. Zu den wichtigsten Neuerungen gehören die Unterstützung von Prioritäten bei der Geräteanfrage, erweiterte Ressourcenunterstützung, partitionierbare Geräte und verbesserte Gerätebindung.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Version 1.36 von Kubernetes markiert einen wichtigen Schritt in der Weiterentwicklung der dynamischen Ressourcenallokation (DRA). Diese Funktion hat die Art und Weise revolutioniert, wie Plattformadministratoren Hardwarebeschleuniger und spezialisierte Ressourcen verwalten. Die Verbesserungen in dieser Version umfassen eine Vielzahl von neuen Funktionen, die die Benutzerfreundlichkeit erhöhen und die Integration in bestehende Systeme erleichtern.\u003c/p\u003e\n\u003cp\u003eEin zentrales Merkmal ist die Einführung der Priorisierten Liste, die es ermöglicht, eine Reihenfolge von Präferenzen für die Anforderung von Geräten zu definieren. Anstatt eine spezifische Gerätemodellnummer festzulegen, können Administratoren eine Liste von bevorzugten Modellen angeben, was die Flexibilität bei der Planung und Nutzung des Clusters erheblich verbessert. Diese Funktion hat den Vorteil, dass sie die Cluster-Auslastung optimiert, indem sie sicherstellt, dass verfügbare Ressourcen effizient genutzt werden.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus wird die Unterstützung für erweiterte Ressourcen nun in der Beta-Phase angeboten. Dies ermöglicht eine schrittweise Migration zu DRA, da Clusterbetreiber weiterhin traditionelle erweiterte Ressourcen auf Pods anfordern können, während Entwickler die neue ResourceClaim-API nach Bedarf implementieren.\u003c/p\u003e\n\u003cp\u003eEin weiteres bedeutendes Feature sind die partitionierbaren Geräte, die es ermöglichen, physische Hardware in kleinere logische Instanzen zu unterteilen. Dies ist besonders nützlich für Multi-Instance-GPUs, die es Administratoren erlauben, teure Beschleuniger effizient über mehrere Pods hinweg zu teilen. Die Einführung von Geräte-Taints bietet eine verbesserte Möglichkeit, die Zuweisung von Hardware zu steuern, indem fehlerhafte Geräte markiert oder spezielle Hardware für bestimmte Teams reserviert werden kann.\u003c/p\u003e\n\u003cp\u003eDie Funktion zur Gerätebindung verbessert die Zuverlässigkeit der Planung, indem sie sicherstellt, dass Pods erst dann einem Node zugewiesen werden, wenn alle erforderlichen externen Ressourcen bereitstehen. Dies reduziert das Risiko von Pod-Fehlern durch vorzeitige Zuweisungen und sorgt für einen robusteren Bereitstellungsprozess.\u003c/p\u003e\n\u003cp\u003eEin zusätzliches Feature ist der Status der Ressourcen-Gesundheit, der es ermöglicht, den Gesundheitszustand von Geräten direkt im Pod-Status anzuzeigen. Dies verbessert die Sichtbarkeit und erleichtert die schnelle Identifizierung von Hardwarefehlern.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie neuen Funktionen in Kubernetes v1.36, insbesondere die Unterstützung für ResourceClaims in PodGroups, bieten erhebliche Vorteile für große skalierbare AI/ML-Arbeitslasten. Diese Funktion beseitigt frühere Engpässe, die mit der Anzahl der Pods verbunden waren, die eine Ressourcennutzung teilen konnten, und reduziert den Verwaltungsaufwand für spezialisierte Orchestratoren. Zudem wird die Verwaltung von node-allocatable Ressourcen wie CPU und Speicher unter die DRA-APIs integriert, was eine einheitliche Handhabung aller Ressourcen innerhalb des Clusters ermöglicht.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 stellt einen bedeutenden Fortschritt in der dynamischen Ressourcenallokation dar und bietet eine Vielzahl neuer Funktionen, die die Effizienz und Flexibilität bei der Verwaltung von Ressourcen erhöhen. Die kontinuierliche Entwicklung von DRA wird voraussichtlich weitere Verbesserungen und Möglichkeiten für \u003ca href=\"/kubernetes/\"\u003eCloud-native\u003c/a\u003e Architekturen und \u003ca href=\"/kubernetes/\"\u003eDevOps\u003c/a\u003e Praktiken mit sich bringen.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 bringt bedeutende Fortschritte in der dynamischen Ressourcenallokation (DRA) mit neuen Funktionen und Verbesserungen, die die Flexibilität bei der Verwaltung von Hardwarebeschleunigern und spezialisierten Ressourcen erweitern. Zu den wichtigsten Neuerungen gehören die Unterstützung von Prioritäten bei der Geräteanfrage, erweiterte Ressourcenunterstützung, partitionierbare Geräte und verbesserte Gerätebindung.\nHauptinhalt Die Version 1.36 von Kubernetes markiert einen wichtigen Schritt in der Weiterentwicklung der dynamischen Ressourcenallokation (DRA). Diese Funktion hat die Art und Weise revolutioniert, wie Plattformadministratoren Hardwarebeschleuniger und spezialisierte Ressourcen verwalten. Die Verbesserungen in dieser Version umfassen eine Vielzahl von neuen Funktionen, die die Benutzerfreundlichkeit erhöhen und die Integration in bestehende Systeme erleichtern.\n", "image": "https://ayedo.de/kubernetes-v1-36-more-drivers-new-features-and-the-next-era-of-dra.png", "date_published": "2026-05-07T18:35:00Z", "date_modified": "2026-05-07T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-server-side-sharded-list-and-watch/", "url": "https://ayedo.de/news/kubernetes-v1-36-server-side-sharded-list-and-watch/", "title": "Kubernetes v1.36: Server-seitige Sharded Liste und Watch", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt die Funktion \u0026ldquo;Server-seitige Sharded Liste und Watch\u0026rdquo; als Alpha-Feature ein, um die Effizienz von Controllern in großen Clustern zu verbessern. Diese Funktion ermöglicht es dem API-Server, Ereignisse bereits an der Quelle zu filtern, sodass jede Controller-Instanz nur die relevanten Ressourcen empfängt, was die CPU- und Netzwerkbelastung erheblich reduziert.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit dem Wachstum von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Clustern auf Zehntausende von Knoten stehen Controller, die hochgradige Ressourcen wie Pods überwachen, vor erheblichen Skalierungsproblemen. Bisher empfing jede Instanz eines horizontal skalierten Controllers den vollständigen Ereignisstrom vom API-Server, was zu unnötigen CPU-, Speicher- und Netzwerkressourcen führte, da viele der empfangenen Objekte nicht relevant waren. Die Einführung der serverseitigen Sharded Liste und Watch in Kubernetes v1.36 zielt darauf ab, dieses Problem zu lösen, indem das Filtern von Ereignissen auf den API-Server verlagert wird.\u003c/p\u003e\n\u003cp\u003eDie neue Funktion ermöglicht es jedem Controller, dem API-Server mitzuteilen, welchen Hash-Bereich er überwachen möchte. Der API-Server sendet dann nur die Ereignisse, die in diesen Bereich fallen. Dies reduziert die Datenmenge, die über das Netzwerk fließt, und minimiert die CPU-Auslastung für die Deserialisierung unnötiger Daten. Die Implementierung erfolgt durch die Hinzufügung eines \u003ccode\u003eshardSelector\u003c/code\u003e-Feldes zu den \u003ccode\u003eListOptions\u003c/code\u003e, wobei Clients den Hash-Bereich über die Funktion \u003ccode\u003eshardRange()\u003c/code\u003e angeben.\u003c/p\u003e\n\u003ch3 id=\"funktionsweise\"\u003eFunktionsweise\u003c/h3\u003e\n\u003cp\u003eDer API-Server berechnet einen deterministischen 64-Bit-FNV-1a-Hash des angegebenen Feldes und gibt nur Objekte zurück, deren Hash innerhalb des definierten Bereichs liegt. Derzeit werden die Felder \u003ccode\u003eobject.metadata.uid\u003c/code\u003e und \u003ccode\u003eobject.metadata.namespace\u003c/code\u003e unterstützt. Controller, die typischerweise Informer verwenden, um Ressourcen zu listen und zu überwachen, können den \u003ccode\u003eshardSelector\u003c/code\u003e in ihre Anfragen integrieren. Dies geschieht über die Methode \u003ccode\u003eWithTweakListOptions\u003c/code\u003e, die es ermöglicht, den \u003ccode\u003eshardSelector\u003c/code\u003e in die \u003ccode\u003eListOptions\u003c/code\u003e einzufügen.\u003c/p\u003e\n\u003cp\u003eFür eine Implementierung mit zwei Replikaten wird der Hash-Bereich in zwei Hälften aufgeteilt. Jede Replikat-Instanz erhält somit nur einen Teil des Gesamtbereichs, was die Effizienz weiter steigert. Auch nicht zusammenhängende Bereiche können abgedeckt werden, indem mehrere \u003ccode\u003eshardRange()\u003c/code\u003e-Aufrufe kombiniert werden.\u003c/p\u003e\n\u003ch3 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h3\u003e\n\u003cp\u003eDie Einführung dieser Funktion hat signifikante technische Implikationen für die Skalierbarkeit von Kubernetes-Clustern. Durch die Reduzierung der Datenmenge, die jede Controller-Instanz verarbeiten muss, wird nicht nur die Effizienz erhöht, sondern auch die Reaktionszeit der Controller verbessert. Da die Hash-Funktion über alle API-Server-Instanzen hinweg konsistent ist, kann die Funktion sicher in Umgebungen mit mehreren API-Servern eingesetzt werden. Die Unterstützung des \u003ccode\u003eshardSelector\u003c/code\u003e wird in den Antwortmetadaten durch ein \u003ccode\u003eshardInfo\u003c/code\u003e-Feld angezeigt, das den verwendeten Selektor zurückgibt. Fehlt dieses Feld, bedeutet dies, dass der Server den Selektor nicht anerkannt hat, und der Client muss in der Lage sein, die vollständige Ergebnismenge zu verarbeiten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie serverseitige Sharded Liste und Watch-Funktion in Kubernetes v1.36 bietet eine vielversprechende Lösung für die Herausforderungen der Skalierung in großen Clustern. Die Funktion befindet sich derzeit im Alpha-Stadium und erfordert das Aktivieren des \u003ccode\u003eShardedListAndWatch\u003c/code\u003e-Feature-Gates auf dem API-Server. Feedback von Entwicklern und Betreibern großer Cluster wird aktiv gesucht, um die Funktion weiter zu verbessern.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt die Funktion \u0026ldquo;Server-seitige Sharded Liste und Watch\u0026rdquo; als Alpha-Feature ein, um die Effizienz von Controllern in großen Clustern zu verbessern. Diese Funktion ermöglicht es dem API-Server, Ereignisse bereits an der Quelle zu filtern, sodass jede Controller-Instanz nur die relevanten Ressourcen empfängt, was die CPU- und Netzwerkbelastung erheblich reduziert.\nHauptinhalt Mit dem Wachstum von Kubernetes-Clustern auf Zehntausende von Knoten stehen Controller, die hochgradige Ressourcen wie Pods überwachen, vor erheblichen Skalierungsproblemen. Bisher empfing jede Instanz eines horizontal skalierten Controllers den vollständigen Ereignisstrom vom API-Server, was zu unnötigen CPU-, Speicher- und Netzwerkressourcen führte, da viele der empfangenen Objekte nicht relevant waren. Die Einführung der serverseitigen Sharded Liste und Watch in Kubernetes v1.36 zielt darauf ab, dieses Problem zu lösen, indem das Filtern von Ereignissen auf den API-Server verlagert wird.\n", "image": "https://ayedo.de/kubernetes-v1-36-server-side-sharded-list-and-watch.png", "date_published": "2026-05-06T18:35:00Z", "date_modified": "2026-05-06T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-declarative-validation-graduates-to-ga/", "url": "https://ayedo.de/news/kubernetes-v1-36-declarative-validation-graduates-to-ga/", "title": "Kubernetes v1.36: Deklarative Validierung erreicht GA", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eMit Kubernetes v1.36 hat die deklarative Validierung für \u003ca href=\"https://kubernetes/\"\u003eKubernetes\u003c/a\u003e native Typen den Status \u0026ldquo;General Availability\u0026rdquo; (GA) erreicht. Diese neue Funktion verbessert die API-Dokumentation und -Zuverlässigkeit, reduziert technischen Schulden und ermöglicht eine einfachere Integration mit Tools wie Kubebuilder.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 markiert einen bedeutenden Fortschritt in der Entwicklung des Kubernetes-Ökosystems durch die Einführung der deklarativen Validierung. Diese Funktion ermöglicht es Entwicklern, Validierungsregeln direkt in den Typdefinitionen mittels spezieller Marker-Tags zu definieren. Dies ersetzt die vorherige Praxis, die stark auf handgeschriebenem Go-Code basierte und zu einer Vielzahl von Problemen führte, darunter technische Schulden, Inkonsistenzen und schwer nachvollziehbare APIs.\u003c/p\u003e\n\u003cp\u003eVor der Einführung der deklarativen Validierung umfasste der handgeschriebene Validierungscode etwa 18.000 Zeilen, was die Wartung erschwerte und die Wahrscheinlichkeit von Fehlern erhöhte. Zudem waren die Validierungsregeln oft inkonsistent angewendet, was zu Verwirrung bei Entwicklern und Tools führte. Die neue deklarative Validierung nutzt Interface Definition Language (IDL) Tags, die direkt in den \u003ccode\u003etypes.go\u003c/code\u003e-Dateien platziert werden. Dies ermöglicht eine klare und konsistente Definition von Validierungsregeln.\u003c/p\u003e\n\u003cp\u003eEin zentrales Element der deklarativen Validierung ist der Code-Generator \u003ccode\u003evalidation-gen\u003c/code\u003e, der die Marker-Tags analysiert und automatisch die entsprechenden Go-Validierungsfunktionen generiert. Diese Funktionen werden nahtlos im API-Schema registriert und bieten eine erweiterbare Plattform, auf der Entwickler neue Validatoren hinzufügen können.\u003c/p\u003e\n\u003cp\u003eDie deklarative Validierung führt eine umfassende Sammlung von Marker-Tags ein, die reichhaltige Validierungsfähigkeiten für Go-Typen bieten. Zu den häufigsten Tags gehören unter anderem \u003ccode\u003e+k8s:optional\u003c/code\u003e, \u003ccode\u003e+k8s:required\u003c/code\u003e, \u003ccode\u003e+k8s:minimum\u003c/code\u003e, und \u003ccode\u003e+k8s:immutable\u003c/code\u003e. Diese Tags machen die Validierungsregeln selbsterklärend und sofort sichtbar für Entwickler, was die Lesbarkeit und Wartbarkeit verbessert.\u003c/p\u003e\n\u003cp\u003eEin weiterer bedeutender Fortschritt ist das Konzept des \u0026ldquo;Ambient Ratcheting\u0026rdquo;. Dieses ermöglicht es, Validierungsregeln bei Updates von bestehenden Objekten dynamisch anzupassen, ohne dass bestehende Objekte beeinträchtigt werden. Wenn ein Benutzer ein Objekt aktualisiert, vergleicht das Validierungsframework das neue Objekt mit dem alten. Wenn der Wert eines bestimmten Feldes unverändert bleibt, wird die neue Validierungsregel umgangen. Dies ermöglicht eine sofortige Anpassung der Validierungsregeln, ohne die Stabilität bestehender Objekte zu gefährden.\u003c/p\u003e\n\u003cp\u003eZusätzlich wird die API-Überprüfung durch Tools wie \u003ccode\u003ekube-api-linter\u003c/code\u003e verbessert, die nun in der Lage sind, API-Typen statisch zu analysieren und API-Konventionen automatisch durchzusetzen. Dies reduziert den manuellen Aufwand für die Überprüfung und bietet Entwicklern sofortiges Feedback.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung der deklarativen Validierung hat weitreichende technische Implikationen. Durch die Reduzierung von handgeschriebenem Code wird die Wartbarkeit des Codes erhöht und die Wahrscheinlichkeit von Fehlern verringert. Die Möglichkeit, Validierungsregeln in einer strukturierten Weise zu definieren, verbessert die Konsistenz und Nachvollziehbarkeit der APIs. Darüber hinaus erleichtert die Integration mit Tools wie \u003ccode\u003ekube-api-linter\u003c/code\u003e die Einhaltung von Best Practices und Standards innerhalb des \u003ca href=\"https://kubernetes/\"\u003eKubernetes\u003c/a\u003e Ökosystems.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Umstellung auf deklarative Validierung in Kubernetes v1.36 stellt einen bedeutenden Fortschritt in der API-Entwicklung dar und bietet sowohl Entwicklern als auch Nutzern verbesserte Werkzeuge zur Erstellung und Wartung von \u003ca href=\"https://kubernetes/\"\u003eKubernetes\u003c/a\u003e Anwendungen. Zukünftige Entwicklungen könnten weitere Optimierungen und erweiterte Funktionalitäten in diesem Bereich ermöglichen.\u003c/p\u003e\n", "summary": "TL;DR Mit Kubernetes v1.36 hat die deklarative Validierung für Kubernetes native Typen den Status \u0026ldquo;General Availability\u0026rdquo; (GA) erreicht. Diese neue Funktion verbessert die API-Dokumentation und -Zuverlässigkeit, reduziert technischen Schulden und ermöglicht eine einfachere Integration mit Tools wie Kubebuilder.\nHauptinhalt Kubernetes v1.36 markiert einen bedeutenden Fortschritt in der Entwicklung des Kubernetes-Ökosystems durch die Einführung der deklarativen Validierung. Diese Funktion ermöglicht es Entwicklern, Validierungsregeln direkt in den Typdefinitionen mittels spezieller Marker-Tags zu definieren. Dies ersetzt die vorherige Praxis, die stark auf handgeschriebenem Go-Code basierte und zu einer Vielzahl von Problemen führte, darunter technische Schulden, Inkonsistenzen und schwer nachvollziehbare APIs.\n", "image": "https://ayedo.de/kubernetes-v1-36-declarative-validation-graduates-to-ga.png", "date_published": "2026-05-05T18:35:00Z", "date_modified": "2026-05-05T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","operations","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-admission-policies-that-can-t-be-deleted/", "url": "https://ayedo.de/news/kubernetes-v1-36-admission-policies-that-can-t-be-deleted/", "title": "Kubernetes v1.36: Nicht löschbare Admission Policies", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt ein neues Alpha-Feature namens manifest-basiertes Admission Control ein, das die Verwaltung von Admission Policies verbessert, indem es diese als Dateien auf dem Dateisystem speichert. Dadurch werden Sicherheitsrichtlinien vor dem Start des API-Servers geladen, was eine durchgehende Durchsetzung von Richtlinien ermöglicht und das Risiko von Löschungen durch privilegierte Benutzer minimiert.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit der Einführung von Kubernetes v1.36 wird das Problem der Sicherheitsrichtlinien, die während der Cluster-Bootstrap-Phase nicht aktiv sind, angegangen. Bisher konnten Admission Policies, die als API-Objekte erstellt wurden, von Benutzern mit den entsprechenden Berechtigungen gelöscht werden, was zu einer Sicherheitslücke führte. Die neue Funktion ermöglicht es, Admission Webhooks und CEL-basierte Richtlinien als Dateien auf dem Dateisystem zu definieren, die der API-Server beim Start lädt, bevor er Anfragen bearbeitet.\u003c/p\u003e\n\u003cp\u003eDas bestehende System zur Durchsetzung von Richtlinien in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e funktioniert über API-Objekte wie ValidatingAdmissionPolicy und Webhook-Konfigurationen. Während der Cluster-Bootstrap-Phase gibt es jedoch eine kritische Zeitspanne, in der der API-Server bereits Anfragen bearbeitet, die Richtlinien jedoch noch nicht aktiv sind. Dies kann zu Problemen führen, insbesondere bei der Wiederherstellung von Backups oder nach einem Ausfall von etcd. Zudem können privilegierte Benutzer kritische Admission Policies löschen, da die Webhooks nicht auf ihre eigenen Konfigurationsressourcen zugreifen können.\u003c/p\u003e\n\u003cp\u003eUm diese Probleme zu lösen, wurde ein neues Feld namens \u003ccode\u003estaticManifestsDir\u003c/code\u003e in die AdmissionConfiguration eingeführt. Dieses Feld verweist auf ein Verzeichnis, in dem die YAML-Dateien der Richtlinien abgelegt werden. Der API-Server lädt diese Dateien beim Start, was sicherstellt, dass die Richtlinien immer aktiv sind. Die Manifestdateien müssen den Namenssuffix \u003ccode\u003e.static.k8s.io\u003c/code\u003e tragen, um Kollisionen mit API-basierten Konfigurationen zu vermeiden und die Herkunft der Admission-Entscheidungen in Metriken oder Audit-Logs klar zu kennzeichnen.\u003c/p\u003e\n\u003cp\u003eEin Beispiel für eine solche Richtlinie könnte das Verbot von privilegierten \u003ca href=\"/kubernetes/\"\u003eContainern\u003c/a\u003e außerhalb des \u003ccode\u003ekube-system\u003c/code\u003e-Namespaces sein. Diese Richtlinie wird in der YAML-Datei definiert und kann einfach geändert werden, indem die Datei auf dem Dateisystem aktualisiert wird, ohne dass es zu zirkulären Abhängigkeiten kommt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie manifest-basierten Admission Policies bieten eine robuste Methode zur Durchsetzung von Sicherheitsrichtlinien in Kubernetes-Umgebungen. Durch die Möglichkeit, Richtlinien direkt im Dateisystem zu speichern und sie beim Start des API-Servers zu laden, wird die Sicherheit erhöht. Administrators können nun sicherstellen, dass kritische Richtlinien nicht versehentlich gelöscht werden können, da die API nicht auf ihre eigenen Konfigurationen zugreift. Dies reduziert das Risiko von Sicherheitsvorfällen erheblich und vereinfacht die Verwaltung von Admission Policies in großen Kubernetes-Cluster-Umgebungen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung von manifest-basierten Admission Policies in Kubernetes v1.36 stellt einen bedeutenden Fortschritt in der Sicherheitsarchitektur des Systems dar. Diese Funktion wird es ermöglichen, Richtlinien durchgehend und zuverlässig durchzusetzen, was insbesondere für Unternehmen von Bedeutung ist, die auf eine starke Sicherheitsstrategie angewiesen sind.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt ein neues Alpha-Feature namens manifest-basiertes Admission Control ein, das die Verwaltung von Admission Policies verbessert, indem es diese als Dateien auf dem Dateisystem speichert. Dadurch werden Sicherheitsrichtlinien vor dem Start des API-Servers geladen, was eine durchgehende Durchsetzung von Richtlinien ermöglicht und das Risiko von Löschungen durch privilegierte Benutzer minimiert.\nHauptinhalt Mit der Einführung von Kubernetes v1.36 wird das Problem der Sicherheitsrichtlinien, die während der Cluster-Bootstrap-Phase nicht aktiv sind, angegangen. Bisher konnten Admission Policies, die als API-Objekte erstellt wurden, von Benutzern mit den entsprechenden Berechtigungen gelöscht werden, was zu einer Sicherheitslücke führte. Die neue Funktion ermöglicht es, Admission Webhooks und CEL-basierte Richtlinien als Dateien auf dem Dateisystem zu definieren, die der API-Server beim Start lädt, bevor er Anfragen bearbeitet.\n", "image": "https://ayedo.de/kubernetes-v1-36-admission-policies-that-can-t-be-deleted.png", "date_published": "2026-05-04T18:35:00Z", "date_modified": "2026-05-04T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","development","digital-sovereignty"], "language": "de" }, ] }