{ "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/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" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-pod-level-resource-managers-alpha/", "url": "https://ayedo.de/news/kubernetes-v1-36-pod-level-resource-managers-alpha/", "title": "Kubernetes v1.36: Pod-Level Ressourcenmanager (Alpha)", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt die Pod-Level Resource Managers als Alpha-Feature ein, um eine flexiblere und leistungsfähigere Ressourcenverwaltung für leistungsintensive Workloads zu ermöglichen. Diese Funktion erweitert die bestehenden Ressourcenmanager und erlaubt eine pod-zentrierte Zuweisung von Ressourcen, wodurch NUMA-Ausrichtung und Effizienz kombiniert werden.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie neue Funktion der Pod-Level Resource Managers in Kubernetes v1.36 bietet eine verbesserte Möglichkeit zur Ressourcenverwaltung, insbesondere für Anwendungen, die hohe Leistung und geringe Latenz erfordern, wie maschinelles Lernen, hochfrequentes Trading oder latenzempfindliche Datenbanken. In der Vergangenheit mussten bei der Zuweisung von Ressourcen für \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e innerhalb eines Pods oft Kompromisse eingegangen werden, um NUMA-aligned Ressourcen zu erhalten. Dies führte häufig dazu, dass alle Container im Pod exklusive und integerbasierte CPU-Ressourcen benötigten, was ineffizient sein konnte, insbesondere für leichte Sidecar-Container.\u003c/p\u003e\n\u003cp\u003eMit der Einführung der Pod-Level Resource Managers wird es möglich, hybride Ressourcenzuweisungsmodelle zu erstellen. Diese Modelle ermöglichen es, die Ressourcen für den Hauptanwendungscontainer exklusiv zuzuweisen, während die Sidecar-Container in einem gemeinsamen Pool innerhalb des Pods laufen. Dies verbessert die Ressourcennutzung und ermöglicht eine bessere Isolation der kritischen Anwendungen von den Hilfsanwendungen.\u003c/p\u003e\n\u003cp\u003ePraktische Anwendungsfälle für diese Funktion umfassen beispielsweise einen eng gekoppelten Datenbank-Pod, bei dem die Hauptdatenbank-Container exklusive CPU- und Speicherkapazitäten erhalten, während die Sidecar-Container wie Metrik-Exporter und Backup-Agent in einem gemeinsamen Pool arbeiten. Ein weiteres Beispiel ist ein ML-Workload, bei dem ein GPU-beschleunigter Trainingscontainer NUMA-aligned Ressourcen erhält, während ein Service-Mesh-Sidecar im allgemeinen Knotenpool betrieben wird.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Aktivierung der Pod-Level Resource Managers erfolgt über die Feature Gates PodLevelResourceManagers und PodLevelResources. Diese ermöglichen es dem Kubelet, die Ressourcenverteilung auf Pod-Ebene zu steuern, was eine präzisere Kontrolle über die Ressourcennutzung bietet. Bei der Verwendung dieser Funktion wird die Zuweisung von CPU-Ressourcen für \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e, die exklusive Zuweisungen benötigen, optimiert, indem die CFS-Quota (Completely Fair Scheduler) auf Container mit exklusiven CPU-Slices deaktiviert wird. Dies erlaubt diesen Containern, ohne Quotenbeschränkungen zu laufen und somit maximale Leistung zu erzielen.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus können Administratoren die Topologie-Manager-Einstellungen anpassen, um die Ressourcenzuweisung je nach Anwendungsfall zu optimieren. Dies ist besonders vorteilhaft für Umgebungen, in denen verschiedene Workloads mit unterschiedlichen Leistungsanforderungen koexistieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung der Pod-Level Resource Managers in Kubernetes v1.36 stellt einen bedeutenden Fortschritt in der Ressourcenverwaltung dar und ermöglicht eine effizientere Nutzung von Ressourcen für leistungsintensive Anwendungen. Diese Funktion wird voraussichtlich in zukünftigen Versionen weiter verfeinert und ausgebaut, wodurch Kubernetes seine Position als führende Plattform für \u003ca href=\"/kubernetes/\"\u003eCloud-native\u003c/a\u003e Anwendungen stärkt.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt die Pod-Level Resource Managers als Alpha-Feature ein, um eine flexiblere und leistungsfähigere Ressourcenverwaltung für leistungsintensive Workloads zu ermöglichen. Diese Funktion erweitert die bestehenden Ressourcenmanager und erlaubt eine pod-zentrierte Zuweisung von Ressourcen, wodurch NUMA-Ausrichtung und Effizienz kombiniert werden.\nHauptinhalt Die neue Funktion der Pod-Level Resource Managers in Kubernetes v1.36 bietet eine verbesserte Möglichkeit zur Ressourcenverwaltung, insbesondere für Anwendungen, die hohe Leistung und geringe Latenz erfordern, wie maschinelles Lernen, hochfrequentes Trading oder latenzempfindliche Datenbanken. In der Vergangenheit mussten bei der Zuweisung von Ressourcen für Container innerhalb eines Pods oft Kompromisse eingegangen werden, um NUMA-aligned Ressourcen zu erhalten. Dies führte häufig dazu, dass alle Container im Pod exklusive und integerbasierte CPU-Ressourcen benötigten, was ineffizient sein konnte, insbesondere für leichte Sidecar-Container.\n", "image": "https://ayedo.de/kubernetes-v1-36-pod-level-resource-managers-alpha.png", "date_published": "2026-05-01T18:35:00Z", "date_modified": "2026-05-01T18: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-in-place-vertical-scaling-for-pod-level-resources-graduates-to-beta/", "url": "https://ayedo.de/news/kubernetes-v1-36-in-place-vertical-scaling-for-pod-level-resources-graduates-to-beta/", "title": "Kubernetes v1.36: In-Place Vertikales Skalieren für Pod-Level Ressourcen erreicht Beta", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 hat das In-Place Vertikale Skalieren von Pod-Level Ressourcen auf Beta-Status angehoben. Diese Funktion erlaubt es, Ressourcenbudget eines laufenden Pods dynamisch zu aktualisieren, oft ohne einen Neustart der \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e. Dies vereinfacht das Management von komplexen Pods und verbessert die Ressourcennutzung während hoher Last.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIn der neuesten Version von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e, v1.36, wurde das In-Place Vertikale Skalieren von Pod-Level Ressourcen auf den Beta-Status angehoben. Diese Funktion ist standardmäßig über das Feature Gate \u003ccode\u003eInPlacePodLevelResourcesVerticalScaling\u003c/code\u003e aktiviert und ermöglicht es Nutzern, das aggregierte Ressourcenbudget eines laufenden Pods zu ändern. Ein wesentlicher Vorteil dieser Funktion ist, dass sie oft ohne einen Neustart der Container durchgeführt werden kann.\u003c/p\u003e\n\u003cp\u003eDas Pod-Level Ressourcenmodell vereinfacht die Verwaltung komplexer Pods, insbesondere solcher mit Sidecars, indem es den Containern erlaubt, einen gemeinsamen Pool von Ressourcen zu nutzen. In v1.36 können Administratoren die Grenzen dieses gemeinsamen Pools in Echtzeit anpassen, was besonders nützlich ist, wenn für die Container keine individuellen Limits definiert sind. Bei einer Anpassung der Pod-Level Dimensionen passen sich die Container automatisch an die neuen Grenzen an, was eine flexible Skalierung während Spitzenlasten ermöglicht.\u003c/p\u003e\n\u003cp\u003eEin zentrales Element dieser Funktion ist die \u003ccode\u003eresizePolicy\u003c/code\u003e, die bestimmt, ob ein Neustart der Container erforderlich ist, um die neuen Ressourcenlimits anzuwenden. Der Kubelet überprüft diese Policy für jeden Container, der seine Limits vom Pod-Level Budget erbt. Ist die \u003ccode\u003erestartPolicy\u003c/code\u003e eines Containers auf \u003ccode\u003eNotRequired\u003c/code\u003e gesetzt, versucht der Kubelet, die cgroup-Limits dynamisch über die \u003ca href=\"/kubernetes/\"\u003eContainer Runtime Interface (CRI)\u003c/a\u003e zu aktualisieren. Bei der Einstellung \u003ccode\u003eRestartContainer\u003c/code\u003e wird der Container neu gestartet, um die neuen Grenzen sicher anzuwenden.\u003c/p\u003e\n\u003cp\u003eEin Beispiel verdeutlicht die Funktionsweise: Ein Pod wird mit einem CPU-Limit von 2 CPUs definiert. Da die einzelnen Container keine eigenen Limits haben, teilen sie sich diesen Pool. Um die CPU-Kapazität auf 4 CPUs zu verdoppeln, kann ein Patch angewendet werden, der die Spezifikation des Pods aktualisiert.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eBei der Anwendung eines Resize-Patches führt der Kubelet mehrere Prüfungen durch, um die Stabilität des Nodes sicherzustellen. Zunächst erfolgt eine Machbarkeitsprüfung, die sicherstellt, dass die neuen aggregierten Anforderungen innerhalb der verfügbaren Kapazität des Nodes liegen. Sollte der Node überlastet sein, wird der Status \u003ccode\u003ePodResizePending\u003c/code\u003e angezeigt, um sofortiges Feedback zu geben.\u003c/p\u003e\n\u003cp\u003eDie Aktualisierung der cgroups erfolgt in einer bestimmten Reihenfolge, um ein Übermaß an Ressourcen zu vermeiden. Bei einer Erhöhung wird zuerst die Pod-Level cgroup erweitert, bevor die cgroups der einzelnen Container vergrößert werden. Bei einer Verringerung werden die cgroups der Container zuerst gedrosselt, bevor die aggregierte Pod-Level cgroup verkleinert wird.\u003c/p\u003e\n\u003cp\u003eDie Überwachbarkeit des Resize-Status erfolgt durch die Verwendung von Pod-Bedingungen, die den Lebenszyklus eines Resizes verfolgen. Diese Bedingungen geben Auskunft darüber, ob die Spezifikation aktualisiert wurde, ob der Node die Änderung angenommen hat und ob die Änderungen vollständig auf die cgroups angewendet wurden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung des In-Place Vertikalen Skalierens in Kubernetes v1.36 stellt einen bedeutenden Fortschritt in der Ressourcennutzung dar und wird voraussichtlich in künftigen Versionen weiter verbessert, insbesondere durch die Integration des Vertical Pod Autoscalers (VPA), der Empfehlungen für Pod-Level Ressourcen abgeben und automatische Anpassungen auslösen kann.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 hat das In-Place Vertikale Skalieren von Pod-Level Ressourcen auf Beta-Status angehoben. Diese Funktion erlaubt es, Ressourcenbudget eines laufenden Pods dynamisch zu aktualisieren, oft ohne einen Neustart der Container. Dies vereinfacht das Management von komplexen Pods und verbessert die Ressourcennutzung während hoher Last.\nHauptinhalt In der neuesten Version von Kubernetes, v1.36, wurde das In-Place Vertikale Skalieren von Pod-Level Ressourcen auf den Beta-Status angehoben. Diese Funktion ist standardmäßig über das Feature Gate InPlacePodLevelResourcesVerticalScaling aktiviert und ermöglicht es Nutzern, das aggregierte Ressourcenbudget eines laufenden Pods zu ändern. Ein wesentlicher Vorteil dieser Funktion ist, dass sie oft ohne einen Neustart der Container durchgeführt werden kann.\n", "image": "https://ayedo.de/kubernetes-v1-36-in-place-vertical-scaling-for-pod-level-resources-graduates-to-beta.png", "date_published": "2026-04-30T18:35:00Z", "date_modified": "2026-04-30T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","finops","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-tiered-memory-protection-with-memory-qos/", "url": "https://ayedo.de/news/kubernetes-v1-36-tiered-memory-protection-with-memory-qos/", "title": "Kubernetes v1.36: Gestaffelter Speicherschutz mit Memory QoS", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Kubernetes-Version 1.36 führt signifikante Updates für die Memory QoS-Funktion ein, darunter gestaffelte Speicherschutzmechanismen, die eine differenzierte Behandlung von \u003ca href=\"https://kubernetes/\"\u003eContainer-Speicher\u003c/a\u003e basierend auf QoS-Klassen ermöglichen. Neu sind auch Observabilitätsmetriken und Warnungen für ältere Kernel-Versionen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eKubernetes 1.36 bringt Verbesserungen für die Memory Quality of Service (QoS) ein, die ursprünglich in Version 1.22 eingeführt wurden. Die neuen Funktionen zielen darauf ab, die Kontrolle über den Speicherverbrauch von Containern zu optimieren und die Effizienz der Ressourcennutzung zu steigern. Besonders hervorzuheben ist die Trennung von Throttling und Reservierung, was eine flexiblere Handhabung der Speicherressourcen ermöglicht.\u003c/p\u003e\n\u003cp\u003eDie neue \u003ccode\u003ememoryReservationPolicy\u003c/code\u003e-Option erlaubt es, die Speichernutzung gezielt zu steuern. Bei der Einstellung „TieredReservation“ wird der Speicher basierend auf der QoS-Klasse des Pods reserviert. So erhalten „Guaranteed“-Pods eine harte Schutzgarantie durch \u003ccode\u003ememory.min\u003c/code\u003e, während „Burstable“-Pods eine weiche Schutzgarantie über \u003ccode\u003ememory.low\u003c/code\u003e erhalten. „BestEffort“-Pods hingegen haben keinen Schutz und deren Speicher ist vollständig reclaimable.\u003c/p\u003e\n\u003cp\u003eEin Beispiel verdeutlicht diese Änderungen: Ein „Guaranteed“-Pod, der 512 MiB Speicher anfordert, erhält eine Garantie, dass dieser Speicher nicht zurückgefordert wird. Im Gegensatz dazu kann der Speicher eines „Burstable“-Pods unter extremen Druckbedingungen zurückgefordert werden, was in früheren Versionen nicht möglich war, da dort \u003ccode\u003ememory.min\u003c/code\u003e für alle Container mit einer Speicherauslastung gesetzt wurde.\u003c/p\u003e\n\u003cp\u003eZusätzlich wurden Observabilitätsmetriken in die kubelet-API integriert. Diese Metriken ermöglichen eine bessere Kapazitätsplanung, indem sie die Gesamtmenge des reservierten Speichers für „Guaranteed“- und „Burstable“-Pods bereitstellen. Diese Informationen sind entscheidend für die Überwachung und Optimierung der Ressourcennutzung.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Aspekt dieser Version ist die Überprüfung der Kernel-Version. Bei Verwendung von \u003ccode\u003ememory.high\u003c/code\u003e-Throttling auf älteren Kernels (vor Version 5.9) kann es zu Problemen kommen. Kubernetes 1.36 führt eine Warnung ein, wenn der Kernel älter ist, um Administratoren auf potenzielle Probleme hinzuweisen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung der Memory QoS in Kubernetes 1.36 nutzt vier Hauptschnittstellen des cgroup v2-Speichercontrollers: \u003ccode\u003ememory.max\u003c/code\u003e, \u003ccode\u003ememory.min\u003c/code\u003e, \u003ccode\u003ememory.low\u003c/code\u003e und \u003ccode\u003ememory.high\u003c/code\u003e. Diese Schnittstellen ermöglichen eine präzise Steuerung der Speichernutzung auf Basis der QoS-Klassen. Die Änderungen an der Speicherkonfiguration, insbesondere die Einführung der gestaffelten Reservierung, verbessern die Ressourcennutzung und verringern das Risiko von Out-of-Memory (OOM)-Situationen, was für viele Produktionsumgebungen von großer Bedeutung ist.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eKubernetes 1.36 stellt einen bedeutenden Schritt in der Entwicklung der Memory QoS dar und bietet neue Möglichkeiten zur Optimierung der Speichernutzung. Die neuen Funktionen werden es \u003ca href=\"https://kubernetes/\"\u003eDevOps-Teams\u003c/a\u003e ermöglichen, ihre Anwendungen effizienter zu betreiben und die Zuverlässigkeit der Systeme zu erhöhen. Die kontinuierliche Verbesserung der Speicherverwaltung wird entscheidend für die Skalierbarkeit und Stabilität von \u003ca href=\"https://kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Anwendungen sein.\u003c/p\u003e\n", "summary": "TL;DR Die Kubernetes-Version 1.36 führt signifikante Updates für die Memory QoS-Funktion ein, darunter gestaffelte Speicherschutzmechanismen, die eine differenzierte Behandlung von Container-Speicher basierend auf QoS-Klassen ermöglichen. Neu sind auch Observabilitätsmetriken und Warnungen für ältere Kernel-Versionen.\nHauptinhalt Kubernetes 1.36 bringt Verbesserungen für die Memory Quality of Service (QoS) ein, die ursprünglich in Version 1.22 eingeführt wurden. Die neuen Funktionen zielen darauf ab, die Kontrolle über den Speicherverbrauch von Containern zu optimieren und die Effizienz der Ressourcennutzung zu steigern. Besonders hervorzuheben ist die Trennung von Throttling und Reservierung, was eine flexiblere Handhabung der Speicherressourcen ermöglicht.\n", "image": "https://ayedo.de/kubernetes-v1-36-tiered-memory-protection-with-memory-qos.png", "date_published": "2026-04-29T18:35:00Z", "date_modified": "2026-04-29T18: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-staleness-mitigation-and-observability-for-controllers/", "url": "https://ayedo.de/news/kubernetes-v1-36-staleness-mitigation-and-observability-for-controllers/", "title": "Kubernetes v1.36: Staleness-Minderung und Beobachtbarkeit für Controller", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt Verbesserungen zur Minderung von Staleness in \u003ca href=\"/kubernetes/\"\u003eControllern\u003c/a\u003e ein, um die Zuverlässigkeit und Reaktionsfähigkeit zu erhöhen. Diese Version umfasst neue Funktionen in client-go und kube-controller-manager, die eine konsistente Verarbeitung von Ereignissen gewährleisten und die Beobachtbarkeit der Controller-Operationen verbessern.\u003c/p\u003e\n\u003cp\u003eKubernetes v1.36 bringt bedeutende Fortschritte in der Handhabung von Staleness, einem Problem, das viele Controller betrifft und zu inkorrektem Verhalten führen kann. Staleness tritt auf, wenn der lokale Cache eines Controllers veraltete Informationen enthält, was dazu führt, dass der Controller falsche oder verspätete Aktionen ausführt. Um dieses Problem zu adressieren, wurden in der neuen Version sowohl client-go als auch der kube-controller-manager aktualisiert.\u003c/p\u003e\n\u003cp\u003eStaleness entsteht, wenn der Controller, der die aktuelle Cluster-Statusinformation in einem Cache speichert, veraltete Daten verwendet. Dies kann passieren, wenn der Controller neu gestartet wird oder wenn der API-Server nicht verfügbar ist. In diesen Fällen kann der Controller nicht die neuesten Informationen abrufen, was zu inkorrektem Handeln führt. Die neue Version von Kubernetes zielt darauf ab, diese Probleme zu minimieren und die Reaktionsfähigkeit der Controller zu verbessern.\u003c/p\u003e\n\u003ch3 id=\"verbesserungen-in-kubernetes-v136\"\u003eVerbesserungen in Kubernetes v1.36\u003c/h3\u003e\n\u003cp\u003eDie Verbesserungen in Kubernetes v1.36 beinhalten wesentliche Änderungen in client-go, insbesondere die Einführung von atomarer FIFO-Verarbeitung. Diese Funktion ermöglicht es der Warteschlange, Operationen, die in Batches empfangen werden, atomar zu verarbeiten. Dadurch wird sichergestellt, dass die Warteschlange stets in einem konsistenten Zustand bleibt, auch wenn Ereignisse nicht in der Reihenfolge eintreffen, in der sie empfangen wurden. Zuvor konnte die Verarbeitung in der Reihenfolge des Eintreffens zu Inkonsistenzen im Cache führen.\u003c/p\u003e\n\u003cp\u003eZusätzlich erhalten Anwender von client-go die Möglichkeit, den neuesten Ressourcenstatus des Caches zu überprüfen. Dies wird durch die neue Funktion \u003ccode\u003eLastStoreSyncResourceVersion()\u003c/code\u003e ermöglicht, die es den Controllern erlaubt, vor der Durchführung von Aktionen den aktuellen Stand des Caches zu validieren.\u003c/p\u003e\n\u003cp\u003eIm kube-controller-manager können vier verschiedene Controller – DaemonSet, StatefulSet, ReplicaSet und Job Controller – von diesen Verbesserungen profitieren. Diese Controller, die oft mit \u003ca href=\"/kubernetes/\"\u003ePods\u003c/a\u003e arbeiten, sind in der Regel am stärksten umkämpft. Die neuen Funktionen sind standardmäßig aktiviert und können bei Bedarf deaktiviert werden.\u003c/p\u003e\n\u003cp\u003eWenn der relevante Feature-Gate aktiviert ist, überprüft der Controller vor der Ausführung einer Aktion die neueste Ressourcenversion des Caches. Ist diese niedriger als die Version, die der Controller im API-Server geschrieben hat, wird keine Aktion durchgeführt, da der Cache veraltet ist. Dies stellt sicher, dass der Controller nur auf aktuelle Informationen reagiert.\u003c/p\u003e\n\u003ch3 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h3\u003e\n\u003cp\u003eDie Implementierung dieser neuen Funktionen erfordert eine Anpassung von Informer-Autoren, die client-go verwenden. Diese können die neuen Features sofort nutzen, um sicherzustellen, dass ihre Caches nicht veraltet sind, bevor sie Aktionen ausführen. Die Bereitstellung einer \u003ccode\u003eConsistencyStore\u003c/code\u003e-Datenstruktur ermöglicht eine einfache Abfrage des Caches und den Vergleich der neuesten Ressourcenversion, was die Gesamtzuverlässigkeit der Controller-Operationen erhöht.\u003c/p\u003e\n\u003ch3 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h3\u003e\n\u003cp\u003eDie Verbesserungen in Kubernetes v1.36 zur Minderung von Staleness und zur Erhöhung der Beobachtbarkeit bieten eine solide Grundlage für die Entwicklung robusterer und reaktionsfähiger Controller. Diese Entwicklungen werden voraussichtlich die Effizienz und Stabilität von Kubernetes-Umgebungen weiter steigern.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt Verbesserungen zur Minderung von Staleness in Controllern ein, um die Zuverlässigkeit und Reaktionsfähigkeit zu erhöhen. Diese Version umfasst neue Funktionen in client-go und kube-controller-manager, die eine konsistente Verarbeitung von Ereignissen gewährleisten und die Beobachtbarkeit der Controller-Operationen verbessern.\nKubernetes v1.36 bringt bedeutende Fortschritte in der Handhabung von Staleness, einem Problem, das viele Controller betrifft und zu inkorrektem Verhalten führen kann. Staleness tritt auf, wenn der lokale Cache eines Controllers veraltete Informationen enthält, was dazu führt, dass der Controller falsche oder verspätete Aktionen ausführt. Um dieses Problem zu adressieren, wurden in der neuen Version sowohl client-go als auch der kube-controller-manager aktualisiert.\n", "image": "https://ayedo.de/kubernetes-v1-36-staleness-mitigation-and-observability-for-controllers.png", "date_published": "2026-04-28T18:35:00Z", "date_modified": "2026-04-28T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","operations","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-mutable-pod-resources-for-suspended-jobs-beta/", "url": "https://ayedo.de/news/kubernetes-v1-36-mutable-pod-resources-for-suspended-jobs-beta/", "title": "Kubernetes v1.36: Änderbare Pod-Ressourcen für angehaltene Jobs (Beta)", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 führt die Möglichkeit ein, Ressourcenanforderungen und -limits von Pods in angehaltenen Jobs anzupassen, was zuvor nur in der Alpha-Phase verfügbar war. Diese Funktion ermöglicht es Cluster-Administratoren, Ressourcen dynamisch zu aktualisieren, um besser auf die aktuelle Cluster-Kapazität und -Prioritäten reagieren zu können.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit der Einführung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 wurde die Funktion zur Änderung von Pod-Ressourcen für angehaltene Jobs in den Beta-Status überführt. Diese Funktion, die bereits in v1.35 als Alpha verfügbar war, erlaubt es, die Anforderungen an CPU, Arbeitsspeicher, GPU und erweiterte Ressourcen eines Jobs anzupassen, während dieser sich im angehaltenen Zustand befindet. Dies ist besonders vorteilhaft für Batch- und Machine-Learning-Workloads, deren Ressourcenbedarf oft nicht genau zum Zeitpunkt der Job-Erstellung bekannt ist.\u003c/p\u003e\n\u003cp\u003eVor der Einführung dieser Funktion waren die Ressourcenanforderungen eines Jobs unveränderlich, sobald sie festgelegt wurden. Wenn ein Queue-Controller, wie Kueue, feststellte, dass ein angehaltener Job mit anderen Ressourcen ausgeführt werden sollte, blieb nur die Möglichkeit, den Job zu löschen und neu zu erstellen, was zu einem Verlust aller zugehörigen Metadaten, Statusinformationen und Historie führte. Die neue Funktion ermöglicht es zudem, dass ein spezifischer Job-Instanz für einen CronJob mit reduzierten Ressourcen langsam voranschreiten kann, anstatt bei hoher Clusterlast vollständig zu scheitern.\u003c/p\u003e\n\u003cp\u003eBeispielsweise könnte ein Machine-Learning-Training-Job, der ursprünglich 4 GPUs anforderte, von einem Queue-Controller angepasst werden, der feststellt, dass nur 2 GPUs verfügbar sind. Der Controller kann die Ressourcenanforderungen vor der Wiederaufnahme des Jobs aktualisieren, sodass der Job mit den neuen Spezifikationen fortgesetzt werden kann.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-API-Server haben die Unveränderlichkeit von Pod-Template-Ressourcenfeldern speziell für angehaltene Jobs gelockert. Dabei wurden keine neuen API-Typen eingeführt; die bestehenden Strukturen für Jobs und Pod-Templates wurden durch gelockerte Validierungen angepasst. Die mutierbaren Felder umfassen die Ressourcenanforderungen und -limits für \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e und Init-Container.\u003c/p\u003e\n\u003cp\u003eRessourcenaktualisierungen sind nur unter bestimmten Bedingungen zulässig: Der Job muss auf \u0026ldquo;suspend: true\u0026rdquo; gesetzt sein, und für einen zuvor laufenden Job müssen alle aktiven Pods terminiert sein, bevor Änderungen an den Ressourcen akzeptiert werden. Standardvalidierungen für Ressourcen bleiben bestehen, beispielsweise müssen die Limits größer oder gleich den Anforderungen sein.\u003c/p\u003e\n\u003cp\u003eMit der Promotion in den Beta-Status in Kubernetes v1.36 ist das Feature \u0026ldquo;MutablePodResourcesForSuspendedJobs\u0026rdquo; standardmäßig aktiviert. Dies bedeutet, dass Cluster, die v1.36 oder höher verwenden, diese Funktion ohne zusätzliche Konfiguration nutzen können.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Möglichkeit, Ressourcen für angehaltene Jobs in Kubernetes dynamisch anzupassen, stellt einen bedeutenden Fortschritt dar, der die Flexibilität und Effizienz von Workloads in Cloud-Umgebungen verbessert. Die Funktion wird erwartet, dass sie die Handhabung von Ressourcen in hochdynamischen Umgebungen weiter optimiert.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 führt die Möglichkeit ein, Ressourcenanforderungen und -limits von Pods in angehaltenen Jobs anzupassen, was zuvor nur in der Alpha-Phase verfügbar war. Diese Funktion ermöglicht es Cluster-Administratoren, Ressourcen dynamisch zu aktualisieren, um besser auf die aktuelle Cluster-Kapazität und -Prioritäten reagieren zu können.\nHauptinhalt Mit der Einführung von Kubernetes v1.36 wurde die Funktion zur Änderung von Pod-Ressourcen für angehaltene Jobs in den Beta-Status überführt. Diese Funktion, die bereits in v1.35 als Alpha verfügbar war, erlaubt es, die Anforderungen an CPU, Arbeitsspeicher, GPU und erweiterte Ressourcen eines Jobs anzupassen, während dieser sich im angehaltenen Zustand befindet. Dies ist besonders vorteilhaft für Batch- und Machine-Learning-Workloads, deren Ressourcenbedarf oft nicht genau zum Zeitpunkt der Job-Erstellung bekannt ist.\n", "image": "https://ayedo.de/kubernetes-v1-36-mutable-pod-resources-for-suspended-jobs-beta.png", "date_published": "2026-04-27T18:35:00Z", "date_modified": "2026-04-27T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","ai","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-fine-grained-kubelet-api-authorization-graduates-to-ga/", "url": "https://ayedo.de/news/kubernetes-v1-36-fine-grained-kubelet-api-authorization-graduates-to-ga/", "title": "Kubernetes v1.36: Detaillierte Kubelet API-Autorisierung erreicht GA", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Kubernetes-Version 1.36 führt die feingranulare Kubelet API-Autorisierung als allgemein verfügbare Funktion ein. Diese Neuerung ermöglicht präzise Zugriffskontrollen auf die Kubelet-API und ersetzt die zuvor erforderliche, breite Berechtigung \u0026ldquo;nodes/proxy\u0026rdquo;, die Sicherheitsrisiken mit sich brachte.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie feingranulare Kubelet API-Autorisierung ist eine bedeutende Verbesserung in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36, die es ermöglicht, den Zugriff auf die Kubelet-API präziser zu steuern. Diese Funktion wurde ursprünglich in Kubernetes v1.32 als Alpha-Feature eingeführt, in v1.33 in den Beta-Status überführt und hat nun den Status „Allgemeine Verfügbarkeit“ (GA) erreicht. Der Feature-Gate ist nun standardmäßig aktiviert und kann nicht mehr deaktiviert werden.\u003c/p\u003e\n\u003cp\u003eDie Kubelet-API bietet mehrere Endpunkte, die auf sensible Daten zugreifen, darunter Pod-Listen, Node-Metriken und \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e-Logs. Vor der Einführung der feingranularen Autorisierung war der Zugriff auf diese APIs durch ein grobgranulares Berechtigungsmodell geregelt, das häufig die Erlaubnis „nodes/proxy“ erforderte. Diese Berechtigung war jedoch problematisch, da sie nicht nur den Zugriff auf Metriken, sondern auch die Möglichkeit bot, beliebige Befehle in Containern auszuführen. Dies widerspricht dem Prinzip der minimalen Berechtigung, da eine Kompromittierung eines Monitoring-Tools potenziell zu einem umfassenden Sicherheitsvorfall führen könnte.\u003c/p\u003e\n\u003cp\u003eZusätzlich wurde festgestellt, dass die „nodes/proxy GET“-Berechtigung, die oft Monitoring-Tools zugewiesen wird, ausgenutzt werden kann, um Befehle in Pods auszuführen. Dies liegt an einem Missverhältnis zwischen der Funktionsweise von WebSocket-Verbindungen und der Zuordnung von HTTP-Methoden zu RBAC-Verben. Angreifer können über WebSocket-Clients wie „websocat“ direkt auf die Kubelet-API zugreifen und gefährliche Befehle ausführen.\u003c/p\u003e\n\u003cp\u003eMit der Einführung der feingranularen Kubelet-Autorisierung wird nun ein zusätzlicher, spezifischer Autorisierungscheck durchgeführt, bevor auf die grobgranulare Berechtigung zurückgegriffen wird. Bestimmte, häufig genutzte Kubelet-API-Pfade sind jetzt eigenen Subressourcen zugeordnet, was eine differenzierte Zugriffskontrolle ermöglicht. Beispielsweise werden Endpunkte wie „/metrics“ und „/pods“ nun über spezifische Subressourcen angesprochen, wodurch die Notwendigkeit einer breiten Berechtigung entfällt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie neue Implementierung der feingranularen Autorisierung sorgt dafür, dass der Kubelet bei Anfragen zunächst eine spezifische Berechtigungsprüfung für die jeweilige Subressource durchführt. Falls diese Prüfung erfolgreich ist, wird der Zugriff gewährt. Andernfalls wird ein Fallback auf die grobgranulare Berechtigung „nodes/proxy“ vorgenommen, um die Abwärtskompatibilität zu gewährleisten. Dies ermöglicht eine schrittweise Migration für bestehende Workloads, während neue Deployments von Anfang an auf minimalen Zugriff setzen können.\u003c/p\u003e\n\u003cp\u003eEin Beispiel für diese neue Berechtigungsstruktur ist die Verwendung eines RBAC-ClusterRoles für Monitoring-Agenten. Anstatt eine breite Berechtigung wie „nodes/proxy“ zu gewähren, können Administratoren nun spezifische Berechtigungen für den Zugriff auf „/metrics“ oder andere relevante Endpunkte definieren. Dies reduziert das Risiko von Sicherheitsvorfällen erheblich und verbessert die gesamte Sicherheit der \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e-Umgebung.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie feingranulare Kubelet API-Autorisierung stellt einen wichtigen Schritt in Richtung einer sichereren Kubernetes-Architektur dar. Die Implementierung präziserer Zugriffskontrollen reduziert das Risiko von Sicherheitsvorfällen und stärkt das Vertrauen in die Plattform. Die kontinuierliche Verbesserung der Sicherheitsfeatures wird entscheidend sein, um den wachsenden Anforderungen an \u003ca href=\"/kubernetes/\"\u003eCloud-native\u003c/a\u003e Umgebungen gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Die Kubernetes-Version 1.36 führt die feingranulare Kubelet API-Autorisierung als allgemein verfügbare Funktion ein. Diese Neuerung ermöglicht präzise Zugriffskontrollen auf die Kubelet-API und ersetzt die zuvor erforderliche, breite Berechtigung \u0026ldquo;nodes/proxy\u0026rdquo;, die Sicherheitsrisiken mit sich brachte.\nHauptinhalt Die feingranulare Kubelet API-Autorisierung ist eine bedeutende Verbesserung in Kubernetes v1.36, die es ermöglicht, den Zugriff auf die Kubelet-API präziser zu steuern. Diese Funktion wurde ursprünglich in Kubernetes v1.32 als Alpha-Feature eingeführt, in v1.33 in den Beta-Status überführt und hat nun den Status „Allgemeine Verfügbarkeit“ (GA) erreicht. Der Feature-Gate ist nun standardmäßig aktiviert und kann nicht mehr deaktiviert werden.\n", "image": "https://ayedo.de/kubernetes-v1-36-fine-grained-kubelet-api-authorization-graduates-to-ga.png", "date_published": "2026-04-24T18:35:00Z", "date_modified": "2026-04-24T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","operations","development"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-user-namespaces-in-kubernetes-are-finally-ga/", "url": "https://ayedo.de/news/kubernetes-v1-36-user-namespaces-in-kubernetes-are-finally-ga/", "title": "Kubernetes v1.36: User Namespaces in Kubernetes sind endlich GA", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 hat die Unterstützung für User Namespaces in den Status \u0026ldquo;General Availability\u0026rdquo; (GA) überführt. Diese Funktion ermöglicht eine bessere Sicherheitsisolierung für \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e, indem sie rootlose Arbeitslasten in Benutzer-Namensräumen ermöglicht, was neue Anwendungsfälle ohne die Notwendigkeit von vollständig privilegierten Containern eröffnet.\u003c/p\u003e\n\u003cp\u003eKubernetes v1.36 bringt eine bedeutende Neuerung mit der Einführung von User Namespaces, die nun als stabil und für den produktiven Einsatz geeignet gelten. Diese Funktion ist ausschließlich für Linux-Betriebssysteme verfügbar und stellt einen wichtigen Fortschritt in der Sicherheitsarchitektur von Kubernetes dar. User Namespaces ermöglichen es, Container mit administrativen Rechten auszuführen, während sie gleichzeitig in einem isolierten Benutzer-Namensraum verbleiben. Dies bedeutet, dass bestimmte Privilegien, wie etwa CAP_NET_ADMIN, nur innerhalb des Containers gelten, ohne Auswirkungen auf den Host.\u003c/p\u003e\n\u003cp\u003eEin zentrales Sicherheitsproblem bei Containern war bisher, dass Prozesse, die als root innerhalb eines Containers ausgeführt werden, auch auf dem Host als root betrachtet werden. Dies birgt das Risiko, dass ein Angreifer, der eine Schwachstelle im Kernel oder eine falsch konfigurierte Mount-Option ausnutzt, vollständigen Zugriff auf den Host erlangen kann. Die Einführung von User Namespaces zielt darauf ab, dieses Risiko zu minimieren, indem die Identität des Prozesses innerhalb des Containers isoliert wird.\u003c/p\u003e\n\u003cp\u003eEin wesentlicher technologischer Fortschritt, der zur Stabilität dieser Funktion beigetragen hat, sind ID-mapped mounts, die in Linux 5.12 eingeführt wurden. Diese Technik ermöglicht es, die Dateibesitzrechte nicht auf der Festplatte zu ändern, sondern sie zur Zeit des Mountens transparent umzuwandeln. Dadurch wird die Notwendigkeit des rekursiven Änderns der Dateibesitzrechte vermieden, was insbesondere bei großen Volumes die Startleistung erheblich verbessert.\u003c/p\u003e\n\u003cp\u003eDie Implementierung von User Namespaces in Kubernetes v1.36 ist unkompliziert. Um diese Funktion zu nutzen, muss in der Pod-Spezifikation lediglich der Parameter hostUsers: false gesetzt werden. Dies erfordert keine Änderungen an den \u003ca href=\"/kubernetes/\"\u003eContainer-Images\u003c/a\u003e oder komplexe Konfigurationen. Die Benutzeroberfläche bleibt dabei unverändert zu der, die bereits in der Alpha-Phase eingeführt wurde.\u003c/p\u003e\n\u003cp\u003eZusammenfassend bietet Kubernetes v1.36 mit der Einführung von User Namespaces eine verbesserte Sicherheitsarchitektur, die es ermöglicht, Container mit administrativen Rechten zu betreiben, ohne die Sicherheit des Hosts zu gefährden. Die Funktion ist das Ergebnis jahrelanger Entwicklungsarbeit und stellt einen bedeutenden Schritt in der Weiterentwicklung von Kubernetes dar.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 hat die Unterstützung für User Namespaces in den Status \u0026ldquo;General Availability\u0026rdquo; (GA) überführt. Diese Funktion ermöglicht eine bessere Sicherheitsisolierung für Container, indem sie rootlose Arbeitslasten in Benutzer-Namensräumen ermöglicht, was neue Anwendungsfälle ohne die Notwendigkeit von vollständig privilegierten Containern eröffnet.\nKubernetes v1.36 bringt eine bedeutende Neuerung mit der Einführung von User Namespaces, die nun als stabil und für den produktiven Einsatz geeignet gelten. Diese Funktion ist ausschließlich für Linux-Betriebssysteme verfügbar und stellt einen wichtigen Fortschritt in der Sicherheitsarchitektur von Kubernetes dar. User Namespaces ermöglichen es, Container mit administrativen Rechten auszuführen, während sie gleichzeitig in einem isolierten Benutzer-Namensraum verbleiben. Dies bedeutet, dass bestimmte Privilegien, wie etwa CAP_NET_ADMIN, nur innerhalb des Containers gelten, ohne Auswirkungen auf den Host.\n", "image": "https://ayedo.de/kubernetes-v1-36-user-namespaces-in-kubernetes-are-finally-ga.png", "date_published": "2026-04-23T18:35:00Z", "date_modified": "2026-04-23T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/selinux-volume-label-changes-goes-ga-and-likely-implications-in-v1-37/", "url": "https://ayedo.de/news/selinux-volume-label-changes-goes-ga-and-likely-implications-in-v1-37/", "title": "SELinux Volume Label Änderungen werden GA (und mögliche Auswirkungen in v1.37)", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie kommende \u003ca href=\"https://kubernetes.io/\"\u003eKubernetes-Version\u003c/a\u003e v1.37 wird voraussichtlich die SELinuxMount-Feature-Gate standardmäßig aktivieren, was die Einrichtung von \u003ca href=\"/kubernetes/\"\u003eVolumes\u003c/a\u003e beschleunigt. Diese Änderung könnte jedoch bestehende Anwendungen stören, die auf das alte rekursive Relabeling-Modell angewiesen sind, insbesondere bei der gemeinsamen Nutzung von Volumes zwischen privilegierten und unprivilegierten Pods.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e plant, in der Version v1.37 die SELinuxMount-Feature-Gate standardmäßig zu aktivieren. Dies wird die Performance bei der Einrichtung von Volumes für die meisten Workloads verbessern, kann jedoch zu Komplikationen führen, wenn Anwendungen weiterhin auf das frühere Modell des rekursiven Relabelings angewiesen sind. Insbesondere kann es Probleme geben, wenn ein Volume zwischen privilegierten und unprivilegierten Pods auf demselben Knoten geteilt wird.\u003c/p\u003e\n\u003cp\u003eFür Cluster, die SELinux nicht verwenden, bleibt alles unverändert, da der kubelet die SELinux-Logik überspringt, wenn SELinux im Linux-Kernel deaktiviert oder nicht verfügbar ist. Die aktuelle Version v1.36 von Kubernetes bietet eine Gelegenheit zur Überprüfung und gegebenenfalls Anpassung der Cluster-Konfiguration, um sich auf die bevorstehenden Änderungen vorzubereiten.\u003c/p\u003e\n\u003cp\u003eHistorisch gesehen wendet der \u003ca href=\"/kubernetes/\"\u003eContainer-Runtime\u003c/a\u003e SELinux-Labels auf Pods und deren Volumes an, indem er die Labels von den securityContext-Feldern des Pods an den Container-Runtime übergibt. Dieser Prozess kann zeitaufwendig sein, insbesondere bei großen Volumes oder bei Volumes, die sich auf einem Remote-Dateisystem befinden.\u003c/p\u003e\n\u003cp\u003eEine wichtige Verbesserung besteht darin, dass der kubelet, wo immer möglich, das Volume mit der Option \u003ccode\u003e-o context=\u0026lt;label\u0026gt;\u003c/code\u003e mounten kann. Dadurch wird das korrekte Label für alle Inodes auf diesem Mount ohne rekursive Traversierung angewendet. Diese Funktionalität ist an bestimmte Bedingungen geknüpft, darunter die Unterstützung von SELinux durch das Betriebssystem und die Aktivierung der Feature-Gates.\u003c/p\u003e\n\u003cp\u003eDie Einführung dieser Änderungen erfolgt schrittweise. Zunächst wurden ReadWriteOncePod-Volumes unter dem SELinuxMountReadWriteOncePod-Feature-Gate behandelt, das seit v1.28 standardmäßig aktiviert ist und in v1.36 die allgemeine Verfügbarkeit erreicht hat. Die breitere Unterstützung erfolgt unter dem SELinuxMount-Flag, gekoppelt mit dem Feld spec.securityContext.seLinuxChangePolicy in Pods.\u003c/p\u003e\n\u003cp\u003eUm die Vorteile der neuen Mount-Methode zu nutzen, müssen mehrere Bedingungen erfüllt sein: Das Betriebssystem muss SELinux unterstützen, die Feature-Gates müssen aktiviert sein, und der Pod muss über eine gültige PersistentVolumeClaim mit den entsprechenden Zugriffsmodi verfügen. Andernfalls wird der Container-Runtime weiterhin rekursiv die SELinux-Labels auf die Volumes anwenden.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Aktivierung des SELinuxMount-Feature-Gates könnte signifikante Auswirkungen auf die Performance und Sicherheit von Kubernetes-Clustern haben. Insbesondere die Möglichkeit, Volumes ohne rekursive Relabeling-Prozesse zu mounten, kann die Geschwindigkeit von Deployments und die Reaktionsfähigkeit von Anwendungen erheblich verbessern. Gleichzeitig müssen Entwickler und Administratoren sicherstellen, dass ihre Anwendungen und Sicherheitskonfigurationen mit den neuen Anforderungen kompatibel sind, um potenzielle Störungen zu vermeiden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie bevorstehenden Änderungen in Kubernetes v1.37 bieten sowohl Chancen zur Performance-Optimierung als auch Herausforderungen in Bezug auf die Kompatibilität bestehender Anwendungen. Eine sorgfältige Planung und Überprüfung der Cluster-Konfiguration wird empfohlen, um einen reibungslosen Übergang zu gewährleisten.\u003c/p\u003e\n", "summary": "TL;DR Die kommende Kubernetes-Version v1.37 wird voraussichtlich die SELinuxMount-Feature-Gate standardmäßig aktivieren, was die Einrichtung von Volumes beschleunigt. Diese Änderung könnte jedoch bestehende Anwendungen stören, die auf das alte rekursive Relabeling-Modell angewiesen sind, insbesondere bei der gemeinsamen Nutzung von Volumes zwischen privilegierten und unprivilegierten Pods.\nHauptinhalt Kubernetes plant, in der Version v1.37 die SELinuxMount-Feature-Gate standardmäßig zu aktivieren. Dies wird die Performance bei der Einrichtung von Volumes für die meisten Workloads verbessern, kann jedoch zu Komplikationen führen, wenn Anwendungen weiterhin auf das frühere Modell des rekursiven Relabelings angewiesen sind. Insbesondere kann es Probleme geben, wenn ein Volume zwischen privilegierten und unprivilegierten Pods auf demselben Knoten geteilt wird.\n", "image": "https://ayedo.de/selinux-volume-label-changes-goes-ga-and-likely-implications-in-v1-37.png", "date_published": "2026-04-22T18:35:00Z", "date_modified": "2026-04-22T18:35:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","operations","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-haru-haru/", "url": "https://ayedo.de/news/kubernetes-v1-36-haru-haru/", "title": "Kubernetes v1.36: ハル (Haru)", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 bringt 70 neue Verbesserungen, darunter 18 stabile, 25 Beta- und 25 Alpha-Funktionen. Zu den Schlüsselfunktionen gehören die allgemeine Verfügbarkeit der feingranularen API-Autorisierung für den Kubelet sowie die Beta-Einführung des Ressourcen-Gesundheitsstatus, der eine vereinheitlichte Gesundheitsberichterstattung für spezialisierte Hardware ermöglicht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Veröffentlichung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36 markiert den Beginn des Jahres 2026 mit einer Vielzahl neuer Funktionen und Verbesserungen. Insgesamt wurden 70 Änderungen implementiert, wobei 18 Funktionen den Status \u0026ldquo;Stabil\u0026rdquo; erreicht haben, 25 in die Beta-Phase übergegangen sind und weitere 25 sich im Alpha-Stadium befinden. Diese kontinuierliche Weiterentwicklung zeigt die Stärke des Kubernetes-Entwicklungszyklus und die engagierte Unterstützung durch die Community.\u003c/p\u003e\n\u003cp\u003eEin herausragendes Merkmal dieser Version ist die feingranulare API-Autorisierung für den Kubelet, die nun allgemein verfügbar ist. Diese Funktion ermöglicht eine präzisere Steuerung des Zugriffs auf die HTTPS-API des Kubelet und ersetzt die zuvor erforderlichen, weitreichenden Berechtigungen für Monitoring- und Observability-Anwendungen. Dies verbessert die Sicherheitslage erheblich, da Administratoren nun den Zugriff auf das Kubelet besser steuern können.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Update ist die Einführung des Ressourcen-Gesundheitsstatus, der in die Beta-Phase übergegangen ist. Diese Funktion bietet eine native Möglichkeit zur Berichterstattung über den Gesundheitszustand zugewiesener Geräte, was die Diagnose von Pod-Abstürzen aufgrund von Hardwarefehlern erleichtert. Administratoren können jetzt mit dem Befehl \u003ccode\u003ekubectl describe pod\u003c/code\u003e feststellen, ob ein \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003eabsturz auf einen ungesunden oder unbekannten Gerätestatus zurückzuführen ist. Diese verbesserte Sichtbarkeit ermöglicht es, fehlerhafte Hardware schnell zu identifizieren und die Wiederherstellung von hochperformanten Workloads zu optimieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie feingranulare API-Autorisierung ist ein entscheidender Schritt in Richtung einer sichereren Kubernetes-Umgebung. Durch die Möglichkeit, Berechtigungen spezifisch zuzuweisen, wird die Angriffsfläche verringert, was insbesondere in produktiven Umgebungen von großer Bedeutung ist. Die Einführung des Ressourcen-Gesundheitsstatus verbessert die Fehlerdiagnose erheblich und ermöglicht es \u003ca href=\"/kubernetes/\"\u003eDevOps\u003c/a\u003e-Teams, proaktiver auf Hardwareprobleme zu reagieren. Dies könnte zu einer erhöhten Stabilität und Verfügbarkeit von Anwendungen führen, die auf Kubernetes basieren.\u003c/p\u003e\n\u003cp\u003eZusätzlich zu diesen Hauptfunktionen enthält v1.36 auch verschiedene Deprecations und Entfernungen, die für Benutzer von Bedeutung sind, um ihre Kubernetes-Implementierungen aktuell zu halten und potenzielle Probleme zu vermeiden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 stellt einen bedeutenden Fortschritt in der Weiterentwicklung der Plattform dar, indem es sowohl Sicherheits- als auch Diagnosefunktionen verbessert. Die kontinuierliche Entwicklung und die Einführung neuer Funktionen zeigen, dass Kubernetes auf dem richtigen Weg ist, um den Anforderungen moderner Cloud-Native-Anwendungen gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 bringt 70 neue Verbesserungen, darunter 18 stabile, 25 Beta- und 25 Alpha-Funktionen. Zu den Schlüsselfunktionen gehören die allgemeine Verfügbarkeit der feingranularen API-Autorisierung für den Kubelet sowie die Beta-Einführung des Ressourcen-Gesundheitsstatus, der eine vereinheitlichte Gesundheitsberichterstattung für spezialisierte Hardware ermöglicht.\nHauptinhalt Die Veröffentlichung von Kubernetes v1.36 markiert den Beginn des Jahres 2026 mit einer Vielzahl neuer Funktionen und Verbesserungen. Insgesamt wurden 70 Änderungen implementiert, wobei 18 Funktionen den Status \u0026ldquo;Stabil\u0026rdquo; erreicht haben, 25 in die Beta-Phase übergegangen sind und weitere 25 sich im Alpha-Stadium befinden. Diese kontinuierliche Weiterentwicklung zeigt die Stärke des Kubernetes-Entwicklungszyklus und die engagierte Unterstützung durch die Community.\n", "image": "https://ayedo.de/kubernetes-v1-36-haru-haru.png", "date_published": "2026-04-22T00:00:00Z", "date_modified": "2026-04-22T00:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","operations","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/gateway-api-v1-5-moving-features-to-stable/", "url": "https://ayedo.de/news/gateway-api-v1-5-moving-features-to-stable/", "title": "Gateway API v1.5: Funktionen in Stabil übertragen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Gateway API v1.5 hat am 27. Februar 2026 bedeutende Funktionen von experimentell auf stabil übertragen. Zu den neuen stabilen Features gehören ListenerSet, TLSRoute, HTTPRoute CORS Filter, Client Certificate Validation, Certificate Selection für Gateway TLS Origination und ReferenceGrant. Diese Version führt zudem einen neuen Release-Prozess ein, der eine zuverlässigere Veröffentlichung ermöglicht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Gateway API v1.5 stellt die größte Veröffentlichung des Projekts dar und konzentriert sich auf die Stabilisierung von Funktionen, die von der Community stark nachgefragt wurden. Die sechs neuen stabilen Features sind darauf ausgelegt, die Flexibilität und Skalierbarkeit der API zu verbessern und den Umgang mit komplexen Multi-Tenant-Umgebungen zu erleichtern.\u003c/p\u003e\n\u003cp\u003eEin zentrales neues Feature ist das ListenerSet, das es ermöglicht, mehrere Listener unabhängig zu definieren und diese dann mit einem Gateway zu kombinieren. Dies adressiert Herausforderungen, die bei der Koordination von Änderungen an einem Gateway zwischen Plattform- und Anwendungsteams auftreten können. ListenerSets ermöglichen es, mehr als 64 Listener an einem einzigen Gateway anzuhängen, was insbesondere für große Deployments und Szenarien mit mehreren Hostnamen pro Listener von Bedeutung ist. Trotz dieser Erweiterung bleibt das listener-Feld im Gateway eine Pflichtangabe, und jedes Gateway muss mindestens einen gültigen Listener aufweisen.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Feature ist das TLSRoute, das es ermöglicht, Anfragen basierend auf der Server Name Indication (SNI) während des TLS-Handshakes an die entsprechenden \u003ca href=\"/kubernetes/\"\u003eKubernetes-Backends\u003c/a\u003e weiterzuleiten. Die TLS-Listener eines Gateways können dabei in zwei Modi konfiguriert werden: Passthrough oder Terminate. Bei der Verwendung von Gateway API v1.5 Standard über v1.4 oder früheren experimentellen Versionen sind bestehende TLSRoutes nicht nutzbar, da sie in einer nicht unterstützten Version gespeichert sind.\u003c/p\u003e\n\u003cp\u003eZusätzlich wurden der HTTPRoute CORS Filter, die Client Certificate Validation und die Certificate Selection für Gateway TLS Origination in den stabilen Status überführt. Diese Features erweitern die Möglichkeiten zur Handhabung von HTTP-Anfragen und zur Sicherstellung von Sicherheitsanforderungen in \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Anwendungen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDer neue Release-Prozess der Gateway API v1.5 basiert auf einem Release-Train-Modell. Dies bedeutet, dass alle bereitgestellten Features zu einem festgelegten Stichtag veröffentlicht werden, was sowohl experimentelle als auch standardisierte Features betrifft. Die Einführung der Rollen des Release Managers und Release Shadows soll die Koordination und Qualität der Veröffentlichungen verbessern. Diese Änderungen zielen darauf ab, eine konsistente und zuverlässige Veröffentlichung zu gewährleisten, die auf den bewährten Verfahren des \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e SIG Release aufbaut.\u003c/p\u003e\n\u003cp\u003eDie Implementierung des ListenerSet-Features könnte für Unternehmen, die auf Multi-Tenant-Architekturen setzen, von erheblichem Vorteil sein, da es die Verwaltung von Gateways vereinfacht und die Zusammenarbeit zwischen verschiedenen Teams fördert.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Gateway API v1.5 bietet eine Vielzahl von stabilen Funktionen, die die Effizienz und Flexibilität der API verbessern. Die neuen Features und der optimierte Release-Prozess könnten die Akzeptanz und Nutzung der Gateway API in Cloud-nativen Umgebungen weiter steigern.\u003c/p\u003e\n", "summary": "TL;DR Die Gateway API v1.5 hat am 27. Februar 2026 bedeutende Funktionen von experimentell auf stabil übertragen. Zu den neuen stabilen Features gehören ListenerSet, TLSRoute, HTTPRoute CORS Filter, Client Certificate Validation, Certificate Selection für Gateway TLS Origination und ReferenceGrant. Diese Version führt zudem einen neuen Release-Prozess ein, der eine zuverlässigere Veröffentlichung ermöglicht.\nHauptinhalt Die Gateway API v1.5 stellt die größte Veröffentlichung des Projekts dar und konzentriert sich auf die Stabilisierung von Funktionen, die von der Community stark nachgefragt wurden. Die sechs neuen stabilen Features sind darauf ausgelegt, die Flexibilität und Skalierbarkeit der API zu verbessern und den Umgang mit komplexen Multi-Tenant-Umgebungen zu erleichtern.\n", "image": "https://ayedo.de/gateway-api-v1-5-moving-features-to-stable.png", "date_published": "2026-04-21T16:30:00Z", "date_modified": "2026-04-21T16:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","software-delivery","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/kubernetes-v1-36-sneak-peek/", "url": "https://ayedo.de/news/kubernetes-v1-36-sneak-peek/", "title": "Kubernetes v1.36 Vorschau", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 wird Ende April 2026 veröffentlicht und bringt sowohl wichtige Verbesserungen als auch die Abschaffung bestimmter Funktionen mit sich. Zu den bemerkenswerten Änderungen zählen die Abschaffung des \u003ccode\u003eexternalIPs\u003c/code\u003e-Feldes in Services und die endgültige Entfernung des \u003ccode\u003egitRepo\u003c/code\u003e-Volume-Treibers. Zudem wird eine schnellere SELinux-Beschriftung für Volumes allgemein verfügbar gemacht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie bevorstehende Version \u003ca href=\"https://kubernetes/\"\u003eKubernetes\u003c/a\u003e v1.36, die für Ende April 2026 geplant ist, beinhaltet eine Reihe von bedeutenden Änderungen und Verbesserungen. Ein zentrales Element der Entwicklung ist die konsequente Umsetzung der Deprecation-Politik, die sicherstellt, dass stabile APIs nur dann abgeschafft werden, wenn eine neuere, stabile Version verfügbar ist. Deprecated APIs werden weiterhin funktionieren, jedoch mit Warnhinweisen, bis sie in einer zukünftigen Version entfernt werden.\u003c/p\u003e\n\u003cp\u003eEin wichtiges Beispiel für diese Politik ist die Einstellung des \u003ccode\u003eingress-nginx\u003c/code\u003e-Projekts, das am 24. März 2026 angekündigt wurde. Die Community wird ermutigt, alternative Ingress-Controller zu evaluieren, die den aktuellen Sicherheits- und Wartungsstandards entsprechen. Diese Maßnahme unterstreicht den Ansatz von Kubernetes, eine kontinuierliche Evolution zu gewährleisten, ohne abrupten Änderungen.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Punkt in der v1.36 ist die Deprecation des \u003ccode\u003eexternalIPs\u003c/code\u003e-Feldes in der Service-Spezifikation. Dieses Feld hat sich als Sicherheitsrisiko erwiesen, da es Angriffe auf den Clusterverkehr ermöglichen kann. Ab v1.36 werden Warnungen angezeigt, wenn \u003ccode\u003eexternalIPs\u003c/code\u003e verwendet wird, und die vollständige Entfernung ist für v1.43 geplant. Nutzer, die auf \u003ccode\u003eexternalIPs\u003c/code\u003e angewiesen sind, sollten alternative Lösungen wie LoadBalancer-Services oder den \u003ca href=\"https://kubernetes/\"\u003eGateway API\u003c/a\u003e in Betracht ziehen.\u003c/p\u003e\n\u003cp\u003eZusätzlich wird der \u003ccode\u003egitRepo\u003c/code\u003e-Volume-Treiber, der seit v1.11 als deprecated gilt, in v1.36 endgültig entfernt. Dies geschieht, um Sicherheitsrisiken zu minimieren, da die Nutzung von \u003ccode\u003egitRepo\u003c/code\u003e potenziell Angreifern ermöglichen könnte, Code mit Root-Rechten auf dem Knoten auszuführen. Bestehende Workloads, die auf \u003ccode\u003egitRepo\u003c/code\u003e angewiesen sind, müssen auf unterstützte Methoden wie Init-Container oder externe git-sync-Tools umsteigen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie neuen Features und Änderungen in Kubernetes v1.36 haben weitreichende technische Implikationen. Die Abschaffung des \u003ccode\u003eexternalIPs\u003c/code\u003e-Feldes zwingt Administratoren dazu, ihre Architekturen zu überdenken und sicherere Methoden zur Handhabung externen Verkehrs zu implementieren. Die endgültige Entfernung des \u003ccode\u003egitRepo\u003c/code\u003e-Volume-Treibers stellt sicher, dass Sicherheitslücken, die durch diese Methode entstanden sind, nicht mehr ausgenutzt werden können.\u003c/p\u003e\n\u003cp\u003eDie allgemeine Verfügbarkeit der schnelleren SELinux-Beschriftung für Volumes wird die Leistung von Pods, die SELinux verwenden, verbessern und die Startzeiten verkürzen. Diese Verbesserung könnte insbesondere für Unternehmen von Bedeutung sein, die auf Sicherheit und Effizienz angewiesen sind.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eKubernetes v1.36 bringt bedeutende Änderungen mit sich, die sowohl die Sicherheit als auch die Leistung der Plattform verbessern sollen. Die Community wird aufgefordert, sich auf die bevorstehenden Änderungen vorzubereiten und geeignete Migrationen und Anpassungen vorzunehmen, um die neuen Standards zu erfüllen.\u003c/p\u003e\n", "summary": "TL;DR Kubernetes v1.36 wird Ende April 2026 veröffentlicht und bringt sowohl wichtige Verbesserungen als auch die Abschaffung bestimmter Funktionen mit sich. Zu den bemerkenswerten Änderungen zählen die Abschaffung des externalIPs-Feldes in Services und die endgültige Entfernung des gitRepo-Volume-Treibers. Zudem wird eine schnellere SELinux-Beschriftung für Volumes allgemein verfügbar gemacht.\nHauptinhalt Die bevorstehende Version Kubernetes v1.36, die für Ende April 2026 geplant ist, beinhaltet eine Reihe von bedeutenden Änderungen und Verbesserungen. Ein zentrales Element der Entwicklung ist die konsequente Umsetzung der Deprecation-Politik, die sicherstellt, dass stabile APIs nur dann abgeschafft werden, wenn eine neuere, stabile Version verfügbar ist. Deprecated APIs werden weiterhin funktionieren, jedoch mit Warnhinweisen, bis sie in einer zukünftigen Version entfernt werden.\n", "image": "https://ayedo.de/kubernetes-v1-36-sneak-peek.png", "date_published": "2026-03-30T00:00:00Z", "date_modified": "2026-03-30T00:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","operations","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/the-platform-under-the-model-how-cloud-native-powers-ai-engineering-in-production/", "url": "https://ayedo.de/news/the-platform-under-the-model-how-cloud-native-powers-ai-engineering-in-production/", "title": "Die Plattform im Modell: Wie Cloud Native KI-Engineering in der Produktion unterstützt", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAI-Workloads finden zunehmend Anwendung in Produktionsumgebungen auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e, jedoch stehen viele Teams vor Herausforderungen beim Übergang von Modellen zu zuverlässigen Systemen. Die \u003ca href=\"/kubernetes/\"\u003eCloud-Native-Ökosystem\u003c/a\u003e bietet eine Vielzahl von Tools und Standards, um diesen Übergang zu erleichtern, einschließlich dynamischer Ressourcenallokation, Inferenz-Routing und Observabilität.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Disziplin des AI-Engineerings konzentriert sich auf den Aufbau zuverlässiger, produktionsgerechter Systeme, die AI-Modelle als Komponenten nutzen. Dies geht über das Training von Modellen und das Design von Prompts hinaus und umfasst die operativen Herausforderungen, die Teams bei der Durchführung von Inferenz in großem Maßstab begegnen. Wichtige Aspekte sind die Bereitstellung von Modellen mit niedriger Latenz und hoher Verfügbarkeit, effizientes Scheduling von GPU- und Beschleuniger-Ressourcen, sowie das Management von Modellversionen und Rollouts in mehrmandantenfähigen Umgebungen.\u003c/p\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eCloud-Native-Umgebung\u003c/a\u003e hat sich über die Jahre hinweg entwickelt und bietet viele Lösungen für diese Infrastrukturprobleme. Kubernetes hat sich als die zentrale Orchestrierungsschicht für AI-Inferenz und -Training etabliert. Eine aktuelle Umfrage zeigt, dass 82 % der Container-Nutzer Kubernetes in der Produktion einsetzen. Eine bedeutende Neuerung ist die dynamische Ressourcenallokation (DRA), die in Kubernetes 1.34 in den allgemeinen verfügbaren Status übergegangen ist. DRA ermöglicht eine präzisere und topology-bewusste GPU-Zuteilung.\u003c/p\u003e\n\u003cp\u003eFür das Routing von Inferenzanfragen steht die Inference Gateway API zur Verfügung, die Kubernetes-native APIs bereitstellt, um Anfragen basierend auf Modellnamen und Endpunktgesundheit zu steuern. Dies ermöglicht es Plattformteams, mehrere GenAI-Workloads auf gemeinsamen Modellserver-Pools zu betreiben, was die Ressourcennutzung optimiert.\u003c/p\u003e\n\u003cp\u003eIm Bereich der Observabilität sind OpenTelemetry und Prometheus nach wie vor entscheidend. AI-Workloads bringen neue Metriken mit sich, die neben den traditionellen Infrastrukturmetriken erfasst werden müssen. Tools wie der inference-perf-Benchmark helfen, Leistungsmetriken von großen Sprachmodellen zu standardisieren und in Prometheus zu integrieren.\u003c/p\u003e\n\u003cp\u003eKubeflow hat sich als wichtiges Projekt etabliert, das Pipeline-Orchestrierung, Experimentverfolgung und Modellbereitstellung bietet. Kueue unterstützt die Job-Queue und faire Planung für Batch- und Trainings-Workloads. Für Governance und Sicherheit sorgen Open Policy Agent (OPA) sowie SPIFFE/SPIRE, die die notwendigen Governance-Primitives für den produktiven Einsatz von AI bereitstellen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Herausforderungen, die sich aus der Integration von AI in \u003ca href=\"/kubernetes/\"\u003eCloud-Native-Umgebungen\u003c/a\u003e ergeben, erfordern ein tiefes Verständnis der neuen Arbeitslastmuster. AI-Entwickler müssen sich mit Kubernetes vertraut machen, insbesondere mit der Inferenz-Serving-Architektur. Die Verwendung von DRA zur Verwaltung von GPU-Ressourcen und die Instrumentierung mit OpenTelemetry sind von entscheidender Bedeutung, um die Effizienz zu maximieren. Plattformingenieure müssen die Anforderungen an die Autoskalierung basierend auf Token-Durchsatz verstehen, um eine optimale Leistung sicherzustellen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Kluft zwischen AI-Praktikern und Cloud-Native-Praktikern muss geschlossen werden, um die Effizienz und Zuverlässigkeit der AI-Workloads in Produktionsumgebungen zu steigern. Die Integration bewährter Cloud-Native-Praktiken in AI-Projekte wird entscheidend sein, um die Herausforderungen der Zukunft zu meistern.\u003c/p\u003e\n", "summary": "TL;DR AI-Workloads finden zunehmend Anwendung in Produktionsumgebungen auf Kubernetes, jedoch stehen viele Teams vor Herausforderungen beim Übergang von Modellen zu zuverlässigen Systemen. Die Cloud-Native-Ökosystem bietet eine Vielzahl von Tools und Standards, um diesen Übergang zu erleichtern, einschließlich dynamischer Ressourcenallokation, Inferenz-Routing und Observabilität.\nHauptinhalt Die Disziplin des AI-Engineerings konzentriert sich auf den Aufbau zuverlässiger, produktionsgerechter Systeme, die AI-Modelle als Komponenten nutzen. Dies geht über das Training von Modellen und das Design von Prompts hinaus und umfasst die operativen Herausforderungen, die Teams bei der Durchführung von Inferenz in großem Maßstab begegnen. Wichtige Aspekte sind die Bereitstellung von Modellen mit niedriger Latenz und hoher Verfügbarkeit, effizientes Scheduling von GPU- und Beschleuniger-Ressourcen, sowie das Management von Modellversionen und Rollouts in mehrmandantenfähigen Umgebungen.\n", "image": "https://ayedo.de/the-platform-under-the-model-how-cloud-native-powers-ai-engineering-in-production.png", "date_published": "2026-03-26T09:07:14Z", "date_modified": "2026-03-26T09:07:14Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cncf","cloud-native","open-source","ai-engineering","kubernetes","inferenz-routing","ressourcenallokation"], "language": "de" },{ "id": "https://ayedo.de/news/announcing-kubescape-4-0-enterprise-stability-meets-the-ai-era/", "url": "https://ayedo.de/news/announcing-kubescape-4-0-enterprise-stability-meets-the-ai-era/", "title": "Ankündigung von Kubescape 4.0: Unternehmensstabilität trifft auf die KI-Ära", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Veröffentlichung von Kubescape 4.0 bringt bedeutende Verbesserungen in der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Sicherheit\u003c/a\u003e, insbesondere durch die allgemeine Verfügbarkeit der Runtime Threat Detection und des Kubescape Storage. Die neue Version ermöglicht eine proaktive Sicherheitsüberwachung und bietet spezielle Funktionen für KI-Agenten, um sowohl ihre Sicherheitslage als auch die von Kubernetes-Clustern zu analysieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eKubescape 4.0 stellt einen wichtigen Fortschritt in der Open-Source-\u003ca href=\"/kubernetes/\"\u003eKubernetes-Sicherheit\u003c/a\u003e dar, indem es unternehmensgerechte Stabilität und fortschrittliche Bedrohungserkennung bietet. Ein zentrales Merkmal dieser Version ist die allgemeine Verfügbarkeit der Runtime Threat Detection, die auf CEL-basierten Erkennungsregeln basiert. Diese Regeln sind effizient und ermöglichen den direkten Zugriff auf Kubescape-Anwendungsprofile, die als Sicherheitsgrundlage für die Workloads dienen.\u003c/p\u003e\n\u003cp\u003eDie Runtime Threat Detection überwacht eine Vielzahl von Ereignissen, darunter Systeminteraktionen wie Prozesse und Systemaufrufe, Netzwerkanfragen sowie Aktivitäten im Dateisystem. Um die Benutzerfreundlichkeit zu erhöhen, werden Regeln und Regelbindungen jetzt als \u003ca href=\"/kubernetes/\"\u003eKubernetes Custom Resource Definitions (CRDs)\u003c/a\u003e verwaltet. Alerts können an bestehende Systeme wie AlertManager, SIEM, Syslog und HTTP-Webhooks exportiert werden.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Feature ist das Kubescape Storage, das nun ebenfalls die allgemeine Verfügbarkeit erreicht hat. Dieses Modul nutzt die Kubernetes Aggregated API, um als zentrales Repository für alle sicherheitsrelevanten Metadaten zu fungieren. Durch die Auslagerung von benutzerdefinierten Objekten wie Anwendungsprofilen und Schwachstellenmanifeste in diesen dedizierten Speicherbereich wird sichergestellt, dass sicherheitsrelevante Daten die Standard-ETCD-Instanz nicht überlasten. Diese Architektur ist für große, hochdichte Cluster optimiert und bietet die erforderliche Leistung für moderne Unternehmensumgebungen.\u003c/p\u003e\n\u003cp\u003eAuf Basis des Feedbacks der Community wurde der Host-Sensor in Kubescape 4.0 entfernt, da er als komplex und schwer zu überwachen galt. Die Funktionen des Host-Agenten wurden direkt in den Node-Agenten integriert, wodurch die Notwendigkeit für temporäre, hochprivilegierte Pods entfällt. Diese Änderung trägt zu einer saubereren Clusterumgebung bei und erleichtert die Überprüfung der Sicherheitslage.\u003c/p\u003e\n\u003cp\u003eEin bedeutendes Merkmal von Kubescape 4.0 ist die Integration von Funktionen für KI-Agenten. Diese neue KAgent-native Plug-in ermöglicht es KI-Assistenten, die Sicherheitslage von Kubernetes-Clustern direkt zu analysieren. Dazu gehören Sicherheitsüberprüfungen auf Schwachstellen, detaillierte Handlungsempfehlungen zur Behebung von Sicherheitsproblemen sowie eine Runtime-Observabilität, die es KI-Agenten ermöglicht, das Verhalten von \u003ca href=\"/kubernetes/\"\u003eContainern\u003c/a\u003e in Echtzeit zu überwachen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung der Runtime Threat Detection und des Kubescape Storage stellt einen bedeutenden Fortschritt in der Sicherheitsarchitektur dar. Durch den Einsatz von CEL-basierten Regeln wird die Effizienz der Bedrohungserkennung erhöht, während die Aggregated API eine verbesserte Handhabung von Sicherheitsmetadaten ermöglicht. Die Vereinfachung der Agentenarchitektur sorgt für eine stabilere und auditierbare Sicherheitslage, die insbesondere für große Unternehmen von Bedeutung ist.\u003c/p\u003e\n\u003cp\u003eDie neuen Funktionen für KI-Agenten sind besonders relevant angesichts der zunehmenden Autonomie dieser Systeme. Die Implementierung robuster Sicherheitsrichtlinien ist entscheidend, um potenzielle Risiken zu minimieren und die Integrität der Infrastruktur zu gewährleisten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eMit Kubescape 4.0 wird ein wichtiger Schritt in der Weiterentwicklung der Kubernetes-Sicherheit vollzogen, insbesondere im Hinblick auf die Integration von KI-Technologien. Die neuen Funktionen bieten sowohl Sicherheitsverantwortlichen als auch Entwicklern wertvolle Werkzeuge, um die Herausforderungen der modernen \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e Landschaft zu bewältigen.\u003c/p\u003e\n", "summary": "TL;DR Die Veröffentlichung von Kubescape 4.0 bringt bedeutende Verbesserungen in der Kubernetes-Sicherheit, insbesondere durch die allgemeine Verfügbarkeit der Runtime Threat Detection und des Kubescape Storage. Die neue Version ermöglicht eine proaktive Sicherheitsüberwachung und bietet spezielle Funktionen für KI-Agenten, um sowohl ihre Sicherheitslage als auch die von Kubernetes-Clustern zu analysieren.\nHauptinhalt Kubescape 4.0 stellt einen wichtigen Fortschritt in der Open-Source-Kubernetes-Sicherheit dar, indem es unternehmensgerechte Stabilität und fortschrittliche Bedrohungserkennung bietet. Ein zentrales Merkmal dieser Version ist die allgemeine Verfügbarkeit der Runtime Threat Detection, die auf CEL-basierten Erkennungsregeln basiert. Diese Regeln sind effizient und ermöglichen den direkten Zugriff auf Kubescape-Anwendungsprofile, die als Sicherheitsgrundlage für die Workloads dienen.\n", "image": "https://ayedo.de/announcing-kubescape-4-0-enterprise-stability-meets-the-ai-era.png", "date_published": "2026-03-26T08:00:00Z", "date_modified": "2026-03-26T08:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cncf","cloud-native","open-source","kubescape","kubernetes-sicherheit","runtime-threat-detection","open-source-sicherheit"], "language": "de" },{ "id": "https://ayedo.de/news/f5-elevates-to-gold-membership-in-the-cloud-native-computing-foundation/", "url": "https://ayedo.de/news/f5-elevates-to-gold-membership-in-the-cloud-native-computing-foundation/", "title": "F5 Erhält Goldmitgliedschaft in der Cloud Native Computing Foundation", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eF5 hat seine Mitgliedschaft in der \u003ca href=\"https://cncf.io/\"\u003eCloud Native Computing Foundation\u003c/a\u003e (CNCF) auf Gold erhöht, um die Entwicklung von Open-Source-Technologien im Bereich \u003ca href=\"/cloud-native/\"\u003eCloud Native\u003c/a\u003e zu fördern. Diese Partnerschaft fokussiert sich auf Schlüsselprojekte wie OpenTelemetry, \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Ingress und Gateway API, um sichere Netzwerkinfrastrukturen und AI-gesteuerte Observabilität zu verbessern.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eF5, ein Anbieter für hybride Multicloud-Anwendungsbereitstellung und Sicherheit, hat seine Mitgliedschaft in der CNCF auf Gold erhöht. Diese Entscheidung unterstreicht F5s Engagement für die Förderung von Innovationen im Bereich Cloud Native. Als Unternehmenssponsor von NGINX und aktiver Mitwirkender an verschiedenen CNCF-Projekten, zielt F5 darauf ab, die Sicherheit und Skalierbarkeit von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und Multicloud-Infrastrukturen zu verbessern.\u003c/p\u003e\n\u003cp\u003eDie Goldmitgliedschaft ermöglicht F5 eine intensivere Zusammenarbeit mit der CNCF-Community, um die Entwicklung und Integration von Technologien voranzutreiben, die für moderne Anwendungen und AI-Workloads entscheidend sind. F5 bringt umfassende Expertise in den Bereichen Netzwerklösungen, Sicherheit und AI-gesteuerte Observabilität ein. Zu den wesentlichen Beiträgen zählen die Weiterentwicklung von Standards für Kubernetes Ingress und Gateway API sowie die Verbesserung von Service-Mesh-Funktionen durch Tools wie Istio.\u003c/p\u003e\n\u003cp\u003eDie CNCF hat die Bedeutung von F5s Engagement für die Entwicklung sicherer und skalierbarer Infrastrukturen hervorgehoben. Insbesondere die Unterstützung bei der Bereitstellung von AI-Inferenz-Workloads wird als entscheidend für die Produktion angesehen, da diese Workloads auf skalierbare Infrastrukturen angewiesen sind.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Teilnahme an der CNCF als Goldmitglied ermöglicht F5, engere Beziehungen zu anderen führenden Unternehmen in der \u003ca href=\"/cloud-native/\"\u003eCloud-Native\u003c/a\u003e Community zu pflegen. Dies fördert nicht nur die Zusammenarbeit an bestehenden Projekten, sondern auch die Entwicklung neuer Technologien, die auf die Herausforderungen der modernen Anwendungsbereitstellung und AI-Inferenz abzielen. Die verbesserten Standards für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Ingress und Gateway API tragen dazu bei, die Integration und den Betrieb von Anwendungen in multicloud Umgebungen zu optimieren.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus unterstützt F5 die Entwicklung von Tools, die es Organisationen ermöglichen, nicht nur aktuelle Workloads zu verwalten, sondern auch innovative Lösungen für zukünftige Herausforderungen zu schaffen. Die Fokussierung auf AI-gesteuerte Observabilität und die Integration von Echtzeit-Telemetrie in Anwendungen ist ein weiterer Schritt in Richtung einer robusteren und sichereren Cloud-Native-Infrastruktur.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eF5s Erhöhung zur Goldmitgliedschaft in der CNCF ist ein bedeutender Schritt zur Stärkung der Cloud-Native-Innovation. Diese Initiative wird die Entwicklung sicherer, skalierbarer Lösungen vorantreiben und die Zusammenarbeit innerhalb der Branche fördern, was letztlich zu einer verbesserten Anwendungsbereitstellung in komplexen Umgebungen führen wird.\u003c/p\u003e\n", "summary": "TL;DR F5 hat seine Mitgliedschaft in der Cloud Native Computing Foundation (CNCF) auf Gold erhöht, um die Entwicklung von Open-Source-Technologien im Bereich Cloud Native zu fördern. Diese Partnerschaft fokussiert sich auf Schlüsselprojekte wie OpenTelemetry, Kubernetes Ingress und Gateway API, um sichere Netzwerkinfrastrukturen und AI-gesteuerte Observabilität zu verbessern.\nHauptinhalt F5, ein Anbieter für hybride Multicloud-Anwendungsbereitstellung und Sicherheit, hat seine Mitgliedschaft in der CNCF auf Gold erhöht. Diese Entscheidung unterstreicht F5s Engagement für die Förderung von Innovationen im Bereich Cloud Native. Als Unternehmenssponsor von NGINX und aktiver Mitwirkender an verschiedenen CNCF-Projekten, zielt F5 darauf ab, die Sicherheit und Skalierbarkeit von Kubernetes und Multicloud-Infrastrukturen zu verbessern.\n", "image": "https://ayedo.de/f5-elevates-to-gold-membership-in-the-cloud-native-computing-foundation.png", "date_published": "2026-03-26T08:00:00Z", "date_modified": "2026-03-26T08:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cncf","cloud-native","open-source","f5","kubernetes","ai-observability","multicloud"], "language": "de" },{ "id": "https://ayedo.de/news/cncf-backstage-documentary-highlights-project-evolution-from-development-to-global-open-source-standard-for-platform-engineering/", "url": "https://ayedo.de/news/cncf-backstage-documentary-highlights-project-evolution-from-development-to-global-open-source-standard-for-platform-engineering/", "title": "CNCF Backstage-Dokumentation hebt die Projektentwicklung zum globalen Open-Source-Standard für Platform Engineering hervor", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Cloud Native Computing Foundation (CNCF) hat eine Dokumentation über das Backstage-Projekt veröffentlicht, das sich von einem internen Tool bei Spotify zu einem globalen Open-Source-Standard für \u003ca href=\"/platform/\"\u003ePlatform Engineering\u003c/a\u003e entwickelt hat. Backstage verbessert die Entwicklererfahrung, indem es komplexe Infrastrukturen vereinfacht und die Einarbeitungszeit für Entwickler reduziert.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Dokumentation mit dem Titel „Backstage: From Spreadsheet to Standard“ beleuchtet die Entwicklung des Backstage-Projekts, das ursprünglich als internes Entwicklerportal bei Spotify eingeführt wurde. Ziel war es, die Fragmentierung zu reduzieren, die Effizienz zu steigern und die Entwicklererfahrung zu verbessern. Innerhalb von nur fünf Jahren hat sich Backstage zu einem führenden Open-Source-Framework für den Aufbau interner Entwicklerportale (IDPs) entwickelt und wird mittlerweile als globaler Standard im Bereich \u003ca href=\"/platform/\"\u003ePlatform Engineering\u003c/a\u003e anerkannt.\u003c/p\u003e\n\u003cp\u003eBackstage ermöglicht eine einheitliche Entwicklererfahrung, die es Teams erlaubt, komplexe Infrastrukturprojekte effizient zu verwalten. Durch die Reduzierung der Einarbeitungszeit für Entwickler wird die Skalierung von Organisationen sicherer und effizienter. Die Dokumentation würdigt die Arbeit von [Platform Engineering]-Teams, cloud-nativen Praktikern und Entwicklern, die zur Entwicklung und Verbreitung von Backstage beigetragen haben.\u003c/p\u003e\n\u003cp\u003eDie Popularität und das Wachstum von Backstage sind auch in den jährlichen Projektgeschwindigkeitsberichten der CNCF dokumentiert. Im Jahr 2020, als Backstage zur CNCF beitrug, belegte das Projekt den achten Platz unter über 100 Projekten. Bis 2025 verbesserte sich diese Platzierung auf den sechsten Platz unter mehr als 230 Projekten, was die starke Projektgesundheit und das Momentum innerhalb des \u003ca href=\"/kubernetes/\"\u003ecloud-nativen\u003c/a\u003e Ökosystems widerspiegelt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eBackstage bietet eine Plattform, die es Unternehmen ermöglicht, interne Entwicklungsprozesse zu standardisieren und zu optimieren. Durch die Implementierung von Backstage können Organisationen die Zusammenarbeit zwischen verschiedenen Teams fördern und die Effizienz ihrer Entwicklungszyklen steigern. Die Verwendung von Backstage als Teil der Entwicklerinfrastruktur kann dazu beitragen, die Qualität der Softwareprodukte zu verbessern und die Time-to-Market für neue Funktionen zu verkürzen.\u003c/p\u003e\n\u003cp\u003eDie Entwicklung von Backstage als Open-Source-Projekt zeigt zudem, wie wichtig die Community-Zusammenarbeit in der Softwareentwicklung ist. Die Beteiligung einer Vielzahl von Entwicklern und Unternehmen trägt zur kontinuierlichen Verbesserung und Anpassung des Projekts an die Bedürfnisse der Nutzer bei.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Veröffentlichung der Dokumentation über Backstage verdeutlicht die Bedeutung von Open-Source-Lösungen im Bereich \u003ca href=\"/platform/\"\u003ePlatform Engineering\u003c/a\u003e. Die Weiterentwicklung von Backstage wird voraussichtlich weiterhin eine zentrale Rolle in der Optimierung von Entwicklungsprozessen und der Verbesserung der Entwicklererfahrung spielen.\u003c/p\u003e\n", "summary": "TL;DR Die Cloud Native Computing Foundation (CNCF) hat eine Dokumentation über das Backstage-Projekt veröffentlicht, das sich von einem internen Tool bei Spotify zu einem globalen Open-Source-Standard für Platform Engineering entwickelt hat. Backstage verbessert die Entwicklererfahrung, indem es komplexe Infrastrukturen vereinfacht und die Einarbeitungszeit für Entwickler reduziert.\nHauptinhalt Die Dokumentation mit dem Titel „Backstage: From Spreadsheet to Standard“ beleuchtet die Entwicklung des Backstage-Projekts, das ursprünglich als internes Entwicklerportal bei Spotify eingeführt wurde. Ziel war es, die Fragmentierung zu reduzieren, die Effizienz zu steigern und die Entwicklererfahrung zu verbessern. Innerhalb von nur fünf Jahren hat sich Backstage zu einem führenden Open-Source-Framework für den Aufbau interner Entwicklerportale (IDPs) entwickelt und wird mittlerweile als globaler Standard im Bereich Platform Engineering anerkannt.\n", "image": "https://ayedo.de/cncf-backstage-documentary-highlights-project-evolution-from-development-to-global-open-source-standard-for-platform-engineering.png", "date_published": "2026-03-25T17:15:00Z", "date_modified": "2026-03-25T17:15:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cncf","cloud-native","open-source","backstage","platform-engineering","developer-experience","internal-developer-portals"], "language": "de" },{ "id": "https://ayedo.de/news/higress-joins-cncf-delivering-an-enterprise-grade-ai-gateway-and-a-seamless-path-from-nginx-ingress/", "url": "https://ayedo.de/news/higress-joins-cncf-delivering-an-enterprise-grade-ai-gateway-and-a-seamless-path-from-nginx-ingress/", "title": "Higress tritt der CNCF bei: Bereitstellung eines Enterprise-Grade AI Gateways und nahtloser Übergang von Nginx Ingress", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eHigress ist ein neues, leistungsstarkes API-Gateway, das der Cloud Native Computing Foundation (CNCF) als Sandbox-Projekt beigetreten ist. Es vereint Ingress- und AI-Gateway-Funktionen und bietet eine sichere, skalierbare Lösung zur Verwaltung von \u003ca href=\"/kubernetes/\"\u003eCloud-nativen\u003c/a\u003e und KI-Workloads.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eHigress hat die Abstimmung des Technischen Aufsichtsausschusses (TOC) der CNCF bestanden und ist nun Teil des CNCF-Ökosystems. Das API-Gateway wurde auf Basis von Envoy und Istio entwickelt und zielt darauf ab, die Komplexität des Betriebs von Cloud-nativen und KI-Anwendungen zu reduzieren. Es integriert die Funktionen eines Traffic Gateways, Microservices Gateways und AI Gateways in einer einzigen Kontrollinstanz.\u003c/p\u003e\n\u003cp\u003eDie Kernkompetenzen von Higress beruhen auf zwei Hauptsäulen: den Ingress-Controller- und Gateway-Funktionen sowie den AI-nativen Gateway-Funktionen. Als ausgereifter \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e Ingress Controller unterstützt Higress vollständig die Gateway-API und deren Inference Extension. Mit der geplanten Ablösung von Nginx Ingress im Jahr 2026 stellt Higress eine sichere, sofort einsatzbereite Alternative dar. Es bietet volle Kompatibilität mit gängigen Nginx Ingress-Anmerkungen und ersetzt das anfällige Konfigurationsinjektionsmodell durch ein robustes xDS-Kontrollsystem und eine Wasm-Sandbox, was die Sicherheitsrisiken veralteter Architekturen eliminiert.\u003c/p\u003e\n\u003cp\u003eIm Bereich der AI-nativen Gateway-Funktionen behandelt Higress KI-Verkehr als gleichwertig. Es bietet native Unterstützung für die Invocation von Large Language Models (LLM), das Model Context Protocol (MCP) und vielfältige KI-Inferenzszenarien. Zu den Funktionen gehören tokenbasierte Ratenbegrenzung, Multi-Model-Fallback, Integration von Retrieval-Augmented Generation (RAG), modellbewusste Routenführung und intelligentes Lastenbalancing. Diese Ansätze standardisieren, wie cloud-native Anwendungen LLMs konsumieren, und positionieren Higress als zentrale Anlaufstelle für KI-Agenten und LLM-Verkehr.\u003c/p\u003e\n\u003cp\u003eHigress hat sich bereits in verschiedenen anspruchsvollen Produktionsumgebungen bewährt, mit Adoptern aus verschiedenen Branchen, darunter Internetdienste, Finanzen, Reisen, Hardware und Unterhaltung. Zu den aktuellen Nutzern zählen Unternehmen wie Alibaba Group, Ant Group und DJI, die Higress nicht nur für robustes Cloud-natives Traffic-Routing, sondern auch für die Bereitstellung von AI-Gateway-Funktionen in ihren Anwendungen nutzen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Entscheidung, der CNCF beizutreten, ist strategisch und zielt darauf ab, die Zusammenarbeit mit anderen führenden Projekten wie \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e und Envoy zu intensivieren. Dies wird Higress ermöglichen, technische Standards zu co-kreieren und seine Rolle in modernen cloud-nativen Architekturen zu festigen. Die neutrale Governance der CNCF fördert eine aktive, vielfältige Entwickler- und Benutzerbasis, die für die langfristige Vitalität des Projekts entscheidend ist. Zudem wird die Notwendigkeit einer Infrastruktur für KI-Anwendungen, die speziell für solche Workloads optimiert ist, immer dringlicher. Higress ist gut positioniert, um universelle Standards für AI-Gateways innerhalb der CNCF zu etablieren.\u003c/p\u003e\n\u003cp\u003eDie zukünftige Entwicklung von Higress wird sich auf zwei Hauptbereiche konzentrieren: die langfristige Kompatibilität mit Ingress-Standards und die kontinuierliche Erweiterung der AI-Fähigkeiten. Dies umfasst die Unterstützung der Gateway-API und die Bereitstellung umfassender Migrationslösungen für Nginx Ingress-Nutzer.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eHigress stellt einen bedeutenden Fortschritt in der Bereitstellung von API-Gateway-Lösungen dar und wird voraussichtlich eine Schlüsselrolle in der Evolution der Cloud-nativen und KI-Infrastruktur übernehmen. Die Integration in die CNCF bietet eine Plattform für weiteres Wachstum und Innovation.\u003c/p\u003e\n", "summary": "TL;DR Higress ist ein neues, leistungsstarkes API-Gateway, das der Cloud Native Computing Foundation (CNCF) als Sandbox-Projekt beigetreten ist. Es vereint Ingress- und AI-Gateway-Funktionen und bietet eine sichere, skalierbare Lösung zur Verwaltung von Cloud-nativen und KI-Workloads.\nHauptinhalt Higress hat die Abstimmung des Technischen Aufsichtsausschusses (TOC) der CNCF bestanden und ist nun Teil des CNCF-Ökosystems. Das API-Gateway wurde auf Basis von Envoy und Istio entwickelt und zielt darauf ab, die Komplexität des Betriebs von Cloud-nativen und KI-Anwendungen zu reduzieren. Es integriert die Funktionen eines Traffic Gateways, Microservices Gateways und AI Gateways in einer einzigen Kontrollinstanz.\n", "image": "https://ayedo.de/higress-joins-cncf-delivering-an-enterprise-grade-ai-gateway-and-a-seamless-path-from-nginx-ingress.png", "date_published": "2026-03-25T13:22:03Z", "date_modified": "2026-03-25T13:22:03Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cncf","cloud-native","open-source","higress","api-gateway","kubernetes","ai-gateway"], "language": "de" },{ "id": "https://ayedo.de/news/cncf-celebrates-innovators-advancing-cloud-native-at-kubecon-cloudnativecon-europe/", "url": "https://ayedo.de/news/cncf-celebrates-innovators-advancing-cloud-native-at-kubecon-cloudnativecon-europe/", "title": "CNCF feiert Innovatoren, die Cloud Native auf der KubeCon + CloudNativeCon Europa vorantreiben", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Cloud Native Computing Foundation (CNCF) hat auf der KubeCon + CloudNativeCon Europe 2026 die Gewinner der CNCF Community Awards bekannt gegeben. Die Auszeichnungen würdigen herausragende Beiträge zur \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Community\u003c/a\u003e, darunter innovative Ansätze zur Skalierung von KI-Infrastrukturen und erfolgreiche Cloud-Migrationen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie CNCF hat im Rahmen der KubeCon + CloudNativeCon Europe 2026 in Amsterdam die CNCF Community Awards verliehen. Diese Auszeichnungen ehren Schlüsselpersonen, die durch ihre Beiträge zu CNCF-Projekten und Technischen Beratungsgremien (TAGs) maßgeblich zur Weiterentwicklung des \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Ökosystems\u003c/a\u003e beigetragen haben. Die Preisverleihung fand während einer speziellen Zeremonie statt, bei der die Gewinner für ihre Verdienste gewürdigt wurden.\u003c/p\u003e\n\u003cp\u003eDie Outstanding Mentor Award wurde an Hung-Ying (Hydai) Tai verliehen, der als R\u0026amp;D-Manager bei Second State tätig ist. Tai hat sich durch seine Mentoring-Tätigkeiten im LFX Mentorship-Programm hervorgetan und zahlreiche Mentees bei der Umsetzung wichtiger Cloud-Native-Projekte unterstützt, darunter WASI-NN-Implementierungen und Optimierungen für große Sprachmodelle (LLMs).\u003c/p\u003e\n\u003cp\u003eEin weiterer bedeutender Preis ist der TAGGIE Award, der an Personen vergeben wird, die sich besonders für die Entwicklung der CNCF TAGs engagieren. Die diesjährigen Gewinner sind Yoshiyuki Tabata, Brandt Keller, Josh Gavant, Carol Valencia und Dylan Page. Diese Auszeichnung würdigt ihre Beiträge zur Skalierung der technischen und benutzergemeinschaftlichen Mitwirkung und zur Sicherstellung der Qualität und Integrität innerhalb des Cloud-Native-Ökosystems.\u003c/p\u003e\n\u003cp\u003eDer Top End User Award 2026 ging an die SNCF für ihre umfassende \u003ca href=\"/cloud-native/\"\u003eCloud-Migration\u003c/a\u003e und innovative private Cloud-Strategie. Die SNCF hat 70 % ihrer 2.000 Anwendungen in die Cloud migriert und nutzt \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e als einheitliche Abstraktionsschicht über öffentliche und private Umgebungen hinweg. Um die Datenhoheit für lokale Workloads zu gewährleisten, wurde eine private Cloud auf Basis von OpenStack aufgebaut, die öffentliche Cloud-Äquivalenz, vollständige Automatisierung und operationale Kontrolle auf einer leistungsstarken, offenen Plattform bietet.\u003c/p\u003e\n\u003cp\u003eDie Auszeichnung für den End User Case Study Contest erhielt Saxo Bank, die GitOps und deklarative Automatisierung über containerisierte Workloads hinaus erweitert hat. Saxo Bank entwickelte das Saxo Service Blueprint, um Herausforderungen bei der Integration von Kubernetes mit externen Unternehmenssystemen zu bewältigen. Durch den Einsatz von Kubernetes-Operatoren und GitOps ermöglicht die Bank eine automatisierte Bereitstellung, die manuelle Schritte eliminiert und über 1.800 automatisierte Operationen pro Pull-Request ausführt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Auszeichnungen verdeutlichen die zunehmende Bedeutung von Mentorship und Community-Engagement in der Cloud-Native-Welt. Die Erfolge von SNCF und Saxo Bank zeigen, wie Unternehmen durch strategische Cloud-Migrationen und innovative Anwendungsarchitekturen Wettbewerbsvorteile erzielen können. Die Verwendung von Kubernetes als einheitliche Abstraktionsschicht und die Implementierung von GitOps sind entscheidende Trends, die die Effizienz und Agilität in der Softwareentwicklung fördern.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie CNCF Community Awards unterstreichen die Dynamik und Innovationskraft der Cloud-Native-Community. Die kontinuierliche Zusammenarbeit und der Wissensaustausch innerhalb dieser Gemeinschaft sind entscheidend für die Bewältigung zukünftiger Herausforderungen in der Cloud-Technologie.\u003c/p\u003e\n", "summary": "TL;DR Die Cloud Native Computing Foundation (CNCF) hat auf der KubeCon + CloudNativeCon Europe 2026 die Gewinner der CNCF Community Awards bekannt gegeben. Die Auszeichnungen würdigen herausragende Beiträge zur Cloud-Native-Community, darunter innovative Ansätze zur Skalierung von KI-Infrastrukturen und erfolgreiche Cloud-Migrationen.\nHauptinhalt Die CNCF hat im Rahmen der KubeCon + CloudNativeCon Europe 2026 in Amsterdam die CNCF Community Awards verliehen. Diese Auszeichnungen ehren Schlüsselpersonen, die durch ihre Beiträge zu CNCF-Projekten und Technischen Beratungsgremien (TAGs) maßgeblich zur Weiterentwicklung des Cloud-Native-Ökosystems beigetragen haben. Die Preisverleihung fand während einer speziellen Zeremonie statt, bei der die Gewinner für ihre Verdienste gewürdigt wurden.\n", "image": "https://ayedo.de/cncf-celebrates-innovators-advancing-cloud-native-at-kubecon-cloudnativecon-europe.png", "date_published": "2026-03-25T09:30:00Z", "date_modified": "2026-03-25T09:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cncf","cloud-native","open-source","kubecon","cloud-migration","kubernetes","ai-infrastructure"], "language": "de" }, ] }