{ "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/how-the-controller-runtime-cache-actually-works-and-why-your-controller-does-not-crash-the-api-server/", "url": "https://ayedo.de/news/how-the-controller-runtime-cache-actually-works-and-why-your-controller-does-not-crash-the-api-server/", "title": "How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server", "content_html": "\u003ch1 id=\"how-the-controller-runtime-cache-actually-works-and-why-your-controller-does-not-crash-the-api-server\"\u003eHow the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://kubernetes.io/blog/2026/07/29/controller-runtime-cache-explained/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "How the controller-runtime Cache Actually Works, and Why Your Controller Does Not Crash the API Server Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/how-the-controller-runtime-cache-actually-works-and-why-your-controller-does-not-crash-the-api-server.png", "date_published": "2026-07-29T18:00:00Z", "date_modified": "2026-07-29T18: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/your-kubernetes-health-checks-are-accidentally-waking-your-services-heres-the-fix/", "url": "https://ayedo.de/news/your-kubernetes-health-checks-are-accidentally-waking-your-services-heres-the-fix/", "title": "Your Kubernetes health checks are accidentally waking your services. Here’s the fix.", "content_html": "\u003ch1 id=\"your-kubernetes-health-checks-are-accidentally-waking-your-services-heres-the-fix\"\u003eYour Kubernetes health checks are accidentally waking your services. Here’s the fix.\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/29/your-kubernetes-health-checks-are-accidentally-waking-your-services-heres-the-fix/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Your Kubernetes health checks are accidentally waking your services. Here’s the fix. Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/your-kubernetes-health-checks-are-accidentally-waking-your-services-heres-the-fix.png", "date_published": "2026-07-29T11:00:00Z", "date_modified": "2026-07-29T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/cncf-and-slashdata-report-finds-japans-cloud-native-community-reaches-nearly-1-million-developers/", "url": "https://ayedo.de/news/cncf-and-slashdata-report-finds-japans-cloud-native-community-reaches-nearly-1-million-developers/", "title": "CNCF and SlashData Report Finds Japan’s Cloud Native Community Reaches Nearly 1 Million Developers", "content_html": "\u003ch1 id=\"cncf-and-slashdata-report-finds-japans-cloud-native-community-reaches-nearly-1-million-developers\"\u003eCNCF and SlashData Report Finds Japan’s Cloud Native Community Reaches Nearly 1 Million Developers\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/announcements/2026/07/28/cncf-and-slashdata-report-finds-japans-cloud-native-community-reaches-nearly-1-million-developers/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "CNCF and SlashData Report Finds Japan’s Cloud Native Community Reaches Nearly 1 Million Developers Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/cncf-and-slashdata-report-finds-japans-cloud-native-community-reaches-nearly-1-million-developers.png", "date_published": "2026-07-29T00:30:00Z", "date_modified": "2026-07-29T00:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","development","cloud","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/subaru-wins-cncf-end-user-case-study-contest-for-accelerating-ai-development-with-cloud-native-infrastructure/", "url": "https://ayedo.de/news/subaru-wins-cncf-end-user-case-study-contest-for-accelerating-ai-development-with-cloud-native-infrastructure/", "title": "Subaru Wins CNCF End User Case Study Contest for Accelerating AI Development with Cloud Native Infrastructure", "content_html": "\u003ch1 id=\"subaru-wins-cncf-end-user-case-study-contest-for-accelerating-ai-development-with-cloud-native-infrastructure\"\u003eSubaru Wins CNCF End User Case Study Contest for Accelerating AI Development with Cloud Native Infrastructure\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/announcements/2026/07/28/subaru-wins-cncf-end-user-case-study-contest-for-accelerating-ai-development-with-cloud-native-infrastructure/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Subaru Wins CNCF End User Case Study Contest for Accelerating AI Development with Cloud Native Infrastructure Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/subaru-wins-cncf-end-user-case-study-contest-for-accelerating-ai-development-with-cloud-native-infrastructure.png", "date_published": "2026-07-29T00:30:00Z", "date_modified": "2026-07-29T00:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","development","cloud","operations","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/lima-v2-2-windows-guests-and-tpm-2-0-emulation/", "url": "https://ayedo.de/news/lima-v2-2-windows-guests-and-tpm-2-0-emulation/", "title": "Lima v2.2: Windows guests and TPM 2.0 emulation", "content_html": "\u003ch1 id=\"lima-v22-windows-guests-and-tpm-20-emulation\"\u003eLima v2.2: Windows guests and TPM 2.0 emulation\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/28/lima-v2-2-windows-guests-and-tpm-2-0-emulation/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Lima v2.2: Windows guests and TPM 2.0 emulation Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/lima-v2-2-windows-guests-and-tpm-2-0-emulation.png", "date_published": "2026-07-29T00:00:00Z", "date_modified": "2026-07-29T00:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","automation","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/welcome-cohdi-to-the-cncf-evolving-kubernetes-into-composable-disaggregated-infrastructures/", "url": "https://ayedo.de/news/welcome-cohdi-to-the-cncf-evolving-kubernetes-into-composable-disaggregated-infrastructures/", "title": "Welcome CoHDI to the CNCF: Evolving Kubernetes into composable disaggregated infrastructures", "content_html": "\u003ch1 id=\"welcome-cohdi-to-the-cncf-evolving-kubernetes-into-composable-disaggregated-infrastructures\"\u003eWelcome CoHDI to the CNCF: Evolving Kubernetes into composable disaggregated infrastructures\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/28/welcome-cohdi-to-the-cncf-evolving-kubernetes-into-composable-disaggregated-infrastructures/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Welcome CoHDI to the CNCF: Evolving Kubernetes into composable disaggregated infrastructures Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/welcome-cohdi-to-the-cncf-evolving-kubernetes-into-composable-disaggregated-infrastructures.png", "date_published": "2026-07-29T00:00:00Z", "date_modified": "2026-07-29T00:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","operations","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/how-japans-250-training-surge-is-shaping-global-ai-talent/", "url": "https://ayedo.de/news/how-japans-250-training-surge-is-shaping-global-ai-talent/", "title": "How Japan’s 250% Training Surge is Shaping Global AI Talent", "content_html": "\u003ch1 id=\"how-japans-250-training-surge-is-shaping-global-ai-talent\"\u003eHow Japan’s 250% Training Surge is Shaping Global AI Talent\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/28/how-japans-250-training-surge-is-shaping-global-ai-talent/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "How Japan’s 250% Training Surge is Shaping Global AI Talent Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/how-japans-250-training-surge-is-shaping-global-ai-talent.png", "date_published": "2026-07-28T23:28:55Z", "date_modified": "2026-07-28T23:28:55Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","development","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/kubeflow-unveils-new-cloud-native-innovations-to-supercharge-ai/", "url": "https://ayedo.de/news/kubeflow-unveils-new-cloud-native-innovations-to-supercharge-ai/", "title": "Kubeflow unveils new cloud native innovations to supercharge AI", "content_html": "\u003ch1 id=\"kubeflow-unveils-new-cloud-native-innovations-to-supercharge-ai\"\u003eKubeflow unveils new cloud native innovations to supercharge AI\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/28/kubeflow-unveils-new-cloud-native-innovations-to-supercharge-ai/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Kubeflow unveils new cloud native innovations to supercharge AI Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/kubeflow-unveils-new-cloud-native-innovations-to-supercharge-ai.png", "date_published": "2026-07-28T23:00:00Z", "date_modified": "2026-07-28T23:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","cloud","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/cncf-announces-schedule-for-debut-observability-summit-europe/", "url": "https://ayedo.de/news/cncf-announces-schedule-for-debut-observability-summit-europe/", "title": "CNCF Announces Schedule for Debut Observability Summit Europe", "content_html": "\u003ch1 id=\"cncf-announces-schedule-for-debut-observability-summit-europe\"\u003eCNCF Announces Schedule for Debut Observability Summit Europe\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/announcements/2026/07/28/cncf-announces-schedule-for-debut-observability-summit-europe/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "CNCF Announces Schedule for Debut Observability Summit Europe Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/cncf-announces-schedule-for-debut-observability-summit-europe.png", "date_published": "2026-07-28T16:00:00Z", "date_modified": "2026-07-28T16:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","operations","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/coding-agent-horror-stories-the-29-million-secret-problem/", "url": "https://ayedo.de/news/coding-agent-horror-stories-the-29-million-secret-problem/", "title": "Coding Agent Horror Stories: The 29 Million Secret Problem", "content_html": "\u003ch1 id=\"coding-agent-horror-stories-the-29-million-secret-problem\"\u003eCoding Agent Horror Stories: The 29 Million Secret Problem\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/coding-agent-horror-stories-the-29-million-secret-problem/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Coding Agent Horror Stories: The 29 Million Secret Problem Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/coding-agent-horror-stories-the-29-million-secret-problem.png", "date_published": "2026-07-28T13:00:00Z", "date_modified": "2026-07-28T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/federating-clusters-for-zero-downtime-kubernetes/", "url": "https://ayedo.de/news/federating-clusters-for-zero-downtime-kubernetes/", "title": "Federating clusters for zero-downtime Kubernetes", "content_html": "\u003ch1 id=\"federating-clusters-for-zero-downtime-kubernetes\"\u003eFederating clusters for zero-downtime Kubernetes\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/27/federating-clusters-for-zero-downtime-kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Federating clusters for zero-downtime Kubernetes Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/federating-clusters-for-zero-downtime-kubernetes.png", "date_published": "2026-07-27T11:00:00Z", "date_modified": "2026-07-27T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","software-delivery","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/agentic-ai-needs-guardrails-not-guesswork/", "url": "https://ayedo.de/news/agentic-ai-needs-guardrails-not-guesswork/", "title": "Agentic AI Needs Guardrails, Not Guesswork", "content_html": "\u003ch1 id=\"agentic-ai-needs-guardrails-not-guesswork\"\u003eAgentic AI Needs Guardrails, Not Guesswork\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/agentic-ai-needs-guardrails-not-guesswork/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Agentic AI Needs Guardrails, Not Guesswork Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/agentic-ai-needs-guardrails-not-guesswork.png", "date_published": "2026-07-24T17:19:36Z", "date_modified": "2026-07-24T17:19:36Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","ai","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/opentelemetry-has-graduated-now-what/", "url": "https://ayedo.de/news/opentelemetry-has-graduated-now-what/", "title": "OpenTelemetry has graduated… Now what?", "content_html": "\u003ch1 id=\"opentelemetry-has-graduated-now-what\"\u003eOpenTelemetry has graduated… Now what?\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.cncf.io/blog/2026/07/24/opentelemetry-has-graduated-now-what/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "OpenTelemetry has graduated… Now what? Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/opentelemetry-has-graduated-now-what.png", "date_published": "2026-07-24T11:00:00Z", "date_modified": "2026-07-24T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","development","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/runtime-enforcement-not-runtime-advice/", "url": "https://ayedo.de/news/runtime-enforcement-not-runtime-advice/", "title": "Runtime Enforcement, Not Runtime Advice", "content_html": "\u003ch1 id=\"runtime-enforcement-not-runtime-advice\"\u003eRuntime Enforcement, Not Runtime Advice\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/runtime-enforcement-not-runtime-advice/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Runtime Enforcement, Not Runtime Advice Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/runtime-enforcement-not-runtime-advice.png", "date_published": "2026-07-22T13:00:00Z", "date_modified": "2026-07-22T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/coding-agent-horror-stories-the-agent-that-deleted-production/", "url": "https://ayedo.de/news/coding-agent-horror-stories-the-agent-that-deleted-production/", "title": "Coding Agent Horror Stories: The Agent That Deleted Production", "content_html": "\u003ch1 id=\"coding-agent-horror-stories-the-agent-that-deleted-production\"\u003eCoding Agent Horror Stories: The Agent That Deleted Production\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/coding-agent-horror-stories-the-agent-that-deleted-production/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Coding Agent Horror Stories: The Agent That Deleted Production Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/coding-agent-horror-stories-the-agent-that-deleted-production.png", "date_published": "2026-07-20T13:00:00Z", "date_modified": "2026-07-20T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/from-the-captains-chair-mohammad-ali-arabi/", "url": "https://ayedo.de/news/from-the-captains-chair-mohammad-ali-arabi/", "title": "From the Captain’s Chair: Mohammad-Ali A’râbi", "content_html": "\u003ch1 id=\"from-the-captains-chair-mohammad-ali-arâbi\"\u003eFrom the Captain’s Chair: Mohammad-Ali A’râbi\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/from-the-captains-chair-mohammad-ali-arabi/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "From the Captain’s Chair: Mohammad-Ali A’râbi Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/from-the-captains-chair-mohammad-ali-arabi.png", "date_published": "2026-07-16T17:15:44Z", "date_modified": "2026-07-16T17:15:44Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/ai-agents-explained-how-to-build-with-them-safely/", "url": "https://ayedo.de/news/ai-agents-explained-how-to-build-with-them-safely/", "title": "AI Agents Explained: How to Build with Them Safely", "content_html": "\u003ch1 id=\"ai-agents-explained-how-to-build-with-them-safely\"\u003eAI Agents Explained: How to Build with Them Safely\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/what-are-ai-agents/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "AI Agents Explained: How to Build with Them Safely Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/ai-agents-explained-how-to-build-with-them-safely.png", "date_published": "2026-07-16T13:00:00Z", "date_modified": "2026-07-16T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/the-developer-has-changed-so-should-developer-conferences/", "url": "https://ayedo.de/news/the-developer-has-changed-so-should-developer-conferences/", "title": "The Developer Has Changed. So Should Developer Conferences", "content_html": "\u003ch1 id=\"the-developer-has-changed-so-should-developer-conferences\"\u003eThe Developer Has Changed. So Should Developer Conferences\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/docker-wearedevelopers-world-congress-north-america-2026/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "The Developer Has Changed. So Should Developer Conferences Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/the-developer-has-changed-so-should-developer-conferences.png", "date_published": "2026-07-16T13:00:00Z", "date_modified": "2026-07-16T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/building-a-custom-metrics-exporter-for-kubernetes/", "url": "https://ayedo.de/news/building-a-custom-metrics-exporter-for-kubernetes/", "title": "Building a Custom Metrics Exporter for Kubernetes", "content_html": "\u003ch1 id=\"building-a-custom-metrics-exporter-for-kubernetes\"\u003eBuilding a Custom Metrics Exporter for Kubernetes\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://kubernetes.io/blog/2026/07/14/custom-metrics-exporter-kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Building a Custom Metrics Exporter for Kubernetes Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/building-a-custom-metrics-exporter-for-kubernetes.png", "date_published": "2026-07-14T18:00:00Z", "date_modified": "2026-07-14T18: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/ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won/", "url": "https://ayedo.de/news/ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won/", "title": "AI Engineer World’s Fair 2026: The Runtime Is Where Agent Trust Is Won", "content_html": "\u003ch1 id=\"ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won\"\u003eAI Engineer World’s Fair 2026: The Runtime Is Where Agent Trust Is Won\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://www.docker.com/blog/ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "AI Engineer World’s Fair 2026: The Runtime Is Where Agent Trust Is Won Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/ai-engineer-worlds-fair-2026-the-runtime-is-where-agent-trust-is-won.png", "date_published": "2026-07-14T13:00:00Z", "date_modified": "2026-07-14T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","cloud-native","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/operating-ai-ml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow/", "url": "https://ayedo.de/news/operating-ai-ml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow/", "title": "Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow", "content_html": "\u003ch1 id=\"operating-aiml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow\"\u003eOperating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://kubernetes.io/blog/2026/07/13/introducing-headlamp-plugin-for-kubeflow/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Operating AI/ML Workloads on Kubernetes: A Headlamp Plugin for Kubeflow Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/operating-ai-ml-workloads-on-kubernetes-a-headlamp-plugin-for-kubeflow.png", "date_published": "2026-07-13T20:00:00Z", "date_modified": "2026-07-13T20: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/kubernetes-dashboard-to-headlamp-a-step-by-step-guide/", "url": "https://ayedo.de/news/kubernetes-dashboard-to-headlamp-a-step-by-step-guide/", "title": "Kubernetes Dashboard to Headlamp: A Step-by-Step Guide", "content_html": "\u003ch1 id=\"kubernetes-dashboard-to-headlamp-a-step-by-step-guide\"\u003eKubernetes Dashboard to Headlamp: A Step-by-Step Guide\u003c/h1\u003e\n\u003cp\u003eMehr Informationen im \u003ca href=\"https://kubernetes.io/blog/2026/07/13/kubernetes-dashboard-to-headlamp/\" target=\"_blank\" rel=\"noopener\"\u003eOriginalartikel\u003c/a\u003e\n.\u003c/p\u003e\n", "summary": "Kubernetes Dashboard to Headlamp: A Step-by-Step Guide Mehr Informationen im Originalartikel .\n", "image": "https://ayedo.de/kubernetes-dashboard-to-headlamp-a-step-by-step-guide.png", "date_published": "2026-07-13T18:00:00Z", "date_modified": "2026-07-13T18: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/operating-opentelemetry-at-scale-with-opamp/", "url": "https://ayedo.de/news/operating-opentelemetry-at-scale-with-opamp/", "title": "OpenTelemetry im großen Maßstab mit OpAMP betreiben", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eOpenTelemetry gewinnt in der Praxis zunehmend an Bedeutung, was zu Herausforderungen bei der Verwaltung und Konfiguration von Agenten führt. Der Open Agent Management Protocol (OpAMP) bietet eine standardisierte Lösung, um diese Agenten zentral zu verwalten, Aktualisierungen durchzuführen und deren Gesundheitszustand zu überwachen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eMit dem wachsenden Einsatz von \u003ca href=\"/kubernetes/\"\u003eOpenTelemetry\u003c/a\u003e\n in Produktionsumgebungen stehen Organisationen vor der Herausforderung, eine Vielzahl von Collectors in heterogenen Umgebungen zu verwalten. Der Open Agent Management Protocol (OpAMP) adressiert diese Herausforderung, indem er eine einheitliche Schnittstelle bereitstellt, die es ermöglicht, Agenten zentral zu konfigurieren, Updates zu pushen und ihre Gesundheit zu überwachen.\u003c/p\u003e\n\u003cp\u003eDie Komplexität der OpenTelemetry-Implementierungen hat zugenommen, da Organisationen Collectors in verschiedenen Umgebungen einsetzen, von großen Gateways bis hin zu eingebetteten Geräten. Diese Vielfalt führt zu einem fragmentierten Managementansatz, der die Effizienz der Observability-Strategien beeinträchtigen kann. Vor der Einführung von OpAMP mussten Unternehmen oft mehrere in-house entwickelte Managementprotokolle nutzen, was zu operationalem Friktionen führte.\u003c/p\u003e\n\u003cp\u003eEin zentrales Merkmal von OpAMP ist die Echtzeitfähigkeit. Es ermöglicht den zentralen Backends, Agenten über WebSocket- oder HTTP-Verbindungen zu konfigurieren und deren Statusinformationen in Echtzeit zu sammeln. Dies ist besonders wichtig, da die Betriebsfähigkeit der Observability-Infrastruktur kritisch für den Erfolg der gesamten IT-Strategie ist. OpAMP hat sich über die einfache Konfigurationsverwaltung hinaus entwickelt und bietet nun auch Funktionen zur Überwachung der Agentengesundheit und zur Erkennung von Konfigurationsabweichungen.\u003c/p\u003e\n\u003cp\u003eDie Architektur von OpAMP umfasst mehrere Schlüsselkomponenten: Die OpAMP-Erweiterung fungiert als read-only Komponente, die aktuelle Konfigurationen und Gesundheitsstatus meldet. Der OpAMP-Supervisor arbeitet als separater Prozess neben dem Collector und implementiert sowohl Lese- als auch Schreibfunktionen. Diese Struktur ermöglicht eine effiziente Verwaltung großer Datenagentenflotten.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eOpAMP ist als Netzwerkprotokollspezifikation konzipiert, die sich auf die Fernverwaltung von Datenagenten konzentriert. Die Kommunikation erfolgt über zwei Nachrichtenarten: server-to-agent und agent-to-server, die mithilfe von Protocol Buffers definiert sind. Dies sorgt für eine einfache und effiziente Implementierung. Die Spezifikation befindet sich im opamp-spec-Repository unter \u003ca href=\"/kubernetes/\"\u003eOpenTelemetry\u003c/a\u003e\n, während opamp-go die Referenzimplementierung in Go bereitstellt.\u003c/p\u003e\n\u003cp\u003eEin weiteres bemerkenswertes Merkmal von OpAMP ist die Möglichkeit, eine \u0026ldquo;Observability für Ihre Observability\u0026rdquo; zu gewährleisten. Dies bedeutet, dass Organisationen in der Lage sind, den Zustand ihrer Observability-Infrastruktur zu überwachen und sicherzustellen, dass diese ordnungsgemäß funktioniert. Die Integration von OpAMP in bestehende Systeme kann die Effizienz und Zuverlässigkeit von Observability-Lösungen erheblich steigern.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eOpAMP stellt eine entscheidende Entwicklung für die Verwaltung von OpenTelemetry-Implementierungen dar, insbesondere in großen und komplexen Umgebungen. Die Standardisierung und Echtzeitüberwachung bieten Organisationen die Möglichkeit, ihre Observability-Strategien zu optimieren und die Effizienz ihrer IT-Betriebe zu steigern.\u003c/p\u003e\n", "summary": "TL;DR OpenTelemetry gewinnt in der Praxis zunehmend an Bedeutung, was zu Herausforderungen bei der Verwaltung und Konfiguration von Agenten führt. Der Open Agent Management Protocol (OpAMP) bietet eine standardisierte Lösung, um diese Agenten zentral zu verwalten, Aktualisierungen durchzuführen und deren Gesundheitszustand zu überwachen.\nHauptinhalt Mit dem wachsenden Einsatz von OpenTelemetry in Produktionsumgebungen stehen Organisationen vor der Herausforderung, eine Vielzahl von Collectors in heterogenen Umgebungen zu verwalten. Der Open Agent Management Protocol (OpAMP) adressiert diese Herausforderung, indem er eine einheitliche Schnittstelle bereitstellt, die es ermöglicht, Agenten zentral zu konfigurieren, Updates zu pushen und ihre Gesundheit zu überwachen.\n", "image": "https://ayedo.de/operating-opentelemetry-at-scale-with-opamp.png", "date_published": "2026-07-13T11:30:00Z", "date_modified": "2026-07-13T11:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","operations","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/where-should-ai-workloads-run-a-sovereign-and-sensible-approach/", "url": "https://ayedo.de/news/where-should-ai-workloads-run-a-sovereign-and-sensible-approach/", "title": "Wo sollten KI-Workloads ausgeführt werden? Ein souveräner und sinnvoller Ansatz", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAI wird zunehmend ein zentraler Bestandteil von Unternehmensstrategien, und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n hat sich als bevorzugte Plattform für die Ausführung von KI-Workloads etabliert. Die Wahl des Hosting-Standorts für KI-Modelle ist entscheidend und sollte unter Berücksichtigung von Kosten, Datenhoheit und regulatorischen Anforderungen getroffen werden.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Integration von Künstlicher Intelligenz (KI) in Unternehmensstrategien nimmt zu, wobei die Diskussion über die besten Plattformen zur Ausführung von KI-Workloads an Bedeutung gewinnt. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n hat sich als eine weit verbreitete Grundlage für die KI-Infrastruktur etabliert, da es eine effiziente Ressourcenverwaltung, Automatisierung, Portabilität und betriebliche Konsistenz bietet. Dennoch bleibt die Frage, wo genau die KI-Modelle ausgeführt werden sollten. Unternehmen stehen vor der Entscheidung, ob sie KI als externen Dienst konsumieren, Rohkapazitäten mieten oder die Workloads in private Clouds oder lokale Rechenzentren verlagern.\u003c/p\u003e\n\u003cp\u003eViele proprietäre KI-Modelle übertreffen nach wie vor Open-Source-Alternativen in Bereichen wie Schlussfolgerungen und allgemeiner Anwendbarkeit. Allerdings erfordern nicht alle KI-Workloads die neuesten, leistungsstärksten Modelle. Routinemäßige, wiederkehrende Aufgaben können oft mit älteren Modellen oder sogar mit Consumer-Hardware bewältigt werden. Wenn diese Aufgaben sensible Daten oder stark regulierte Prozesse betreffen, sind On-Premises- oder Private-Cloud-Umgebungen möglicherweise die sinnvollere Wahl. Die Kontrolle über Daten, \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n und langfristige Planbarkeit sind wesentliche Argumente für die Eigenverantwortung in der Infrastruktur.\u003c/p\u003e\n\u003cp\u003eDie Kostenfrage ist ebenfalls entscheidend. Die hohen Investitionen in die Infrastruktur für KI-Workloads sind nicht nachhaltig, wenn die Einnahmen nicht signifikant steigen. Dies wird voraussichtlich zu höheren Preisen für Verbraucher und Unternehmen führen, was das Geschäftsmodell von KI-Services beeinflussen könnte. Die Vorstellung, dass man einfach ein Abonnement erwerben kann, könnte sich als nicht tragfähig erweisen.\u003c/p\u003e\n\u003cp\u003eIm Hinblick auf die digitale Souveränität ist \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n ein zentraler Aspekt. Es gibt keine einheitliche Definition, jedoch wird sie als ein fortlaufender Prozess betrachtet, der fünf Elemente umfasst: operative Autonomie, Compliance, Auditierbarkeit, Portabilität und Resilienz. Diese Elemente sind entscheidend, um sicherzustellen, dass Systeme rechtlich und technisch nachhaltig funktionieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eBevor Unternehmen ernsthafte KI-Workloads auf eine Plattform migrieren, sollte eine umfassende Analyse der AI-Bereitschaft durchgeführt werden. Wichtige Faktoren sind unter anderem die Kapazität der Beschleuniger, die Leistung des Speichers, die Datenlokalität, die Netzisolierung, die Integration von Identitätsmanagement, Monitoring, Backup, Wiederherstellung, Softwareversorgung, Schwachstellenmanagement und Richtliniendurchsetzung. Ohne diese grundlegenden Überprüfungen könnte die Plattform zwar als souverän gelten, jedoch in der Praxis fragil sein.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entscheidung, wo und wie KI-Workloads ausgeführt werden, erfordert eine sorgfältige Abwägung von Kosten, \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n und technischer Infrastruktur. Unternehmen sollten proaktive Schritte unternehmen, um sicherzustellen, dass ihre Systeme sowohl leistungsfähig als auch konform sind, während sie sich auf die Integration von KI-Technologien vorbereiten.\u003c/p\u003e\n", "summary": "TL;DR AI wird zunehmend ein zentraler Bestandteil von Unternehmensstrategien, und Kubernetes hat sich als bevorzugte Plattform für die Ausführung von KI-Workloads etabliert. Die Wahl des Hosting-Standorts für KI-Modelle ist entscheidend und sollte unter Berücksichtigung von Kosten, Datenhoheit und regulatorischen Anforderungen getroffen werden.\nHauptinhalt Die Integration von Künstlicher Intelligenz (KI) in Unternehmensstrategien nimmt zu, wobei die Diskussion über die besten Plattformen zur Ausführung von KI-Workloads an Bedeutung gewinnt. Kubernetes hat sich als eine weit verbreitete Grundlage für die KI-Infrastruktur etabliert, da es eine effiziente Ressourcenverwaltung, Automatisierung, Portabilität und betriebliche Konsistenz bietet. Dennoch bleibt die Frage, wo genau die KI-Modelle ausgeführt werden sollten. Unternehmen stehen vor der Entscheidung, ob sie KI als externen Dienst konsumieren, Rohkapazitäten mieten oder die Workloads in private Clouds oder lokale Rechenzentren verlagern.\n", "image": "https://ayedo.de/where-should-ai-workloads-run-a-sovereign-and-sensible-approach.png", "date_published": "2026-07-10T23:00:00Z", "date_modified": "2026-07-10T23:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","compliance","hosting","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/navigating-the-ingress-nginx-retirement/", "url": "https://ayedo.de/news/navigating-the-ingress-nginx-retirement/", "title": "Navigieren durch die Ingress-NGINX-Rente", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer ingress-nginx-Controller für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n wird im März 2026 eingestellt, was erhebliche Risiken für die Betriebsführung mit sich bringt. Organisationen stehen vor der Wahl, entweder zu einem anderen Ingress-Controller wie Contour zu migrieren oder die \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n zu implementieren, die eine moderne und zukunftssichere Lösung bietet.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Ankündigung über die Einstellung des ingress-nginx-Controllers hat weitreichende Folgen für Infrastrukturteams. Während die Ingress API weiterhin unterstützt wird, bedeutet das Ende des community-gepflegten Controllers, dass Organisationen aktiv werden müssen, um ihre Netzwerkarchitektur zu modernisieren und Sicherheitsrisiken zu vermeiden. Die Entscheidung zwischen zwei Hauptmigrationen ist entscheidend: eine \u0026ldquo;Lift-and-Shift\u0026rdquo;-Migration zu einem anderen Ingress-Controller oder der Wechsel zur \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch3 id=\"path-a-die-lift-and-shift-migration\"\u003ePath A: Die \u0026ldquo;Lift-and-Shift\u0026rdquo;-Migration\u003c/h3\u003e\n\u003cp\u003eDiese Option ermöglicht es Betreibern, ihre bestehenden Ingress YAML-Ressourcen beizubehalten und lediglich die zugrunde liegende Ingress-Klasse auf einen Envoy-basierten Controller wie Contour umzuschalten. Dies minimiert sofortige Störungen in den Routing-Definitionen. Allerdings müssen alle spezifischen nginx.ingress.kubernetes.io/*-Annotationen manuell in die entsprechenden Annotationen von Contour übersetzt werden, was zusätzlichen Aufwand bedeutet.\u003c/p\u003e\n\u003ch3 id=\"path-b-die-architektonische-evolution\"\u003ePath B: Die architektonische Evolution\u003c/h3\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n stellt den Nachfolger der Ingress API dar und bietet ein rollenorientiertes Design, das Infrastrukturfragen von der Anwendungsrouting-Logik trennt. Diese API adressiert strukturelle Einschränkungen der bisherigen Ingress-NGINX-Implementierung und standardisiert Funktionen wie Traffic-Splitting und sicheres Routing über Namespaces hinweg. Der Wechsel zur \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n erfordert jedoch einen höheren Migrationsaufwand, da Routing-Manifestdateien vollständig neu geschrieben werden müssen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Wahl zwischen diesen beiden Pfaden sollte auf einer neutralen Analyse der Vor- und Nachteile basieren. Bei einer Migration zu Contour (Path A) ist der Aufwand gering bis mittel, da bestehende Annotationen übersetzt werden müssen. In Bezug auf die Betriebsführung bleibt der Ansatz monolithisch und wird von den Betriebsmitarbeitern verwaltet. Im Gegensatz dazu bietet die \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n (Path B) eine zukunftssichere Lösung mit aktiver Weiterentwicklung, die auf eine rollenbasierte Verwaltung setzt. Dies ermöglicht es Entwicklern, HTTP-Routen zu verwalten, während das Betriebsteam die Gateway-Ressourcen überwacht.\u003c/p\u003e\n\u003cp\u003eDie Migration sollte strategisch angegangen werden. Eine gründliche Bestandsaufnahme der aktuellen technischen Schulden ist notwendig, gefolgt von der Nutzung von Tools wie ingress2gateway zur Automatisierung der Übersetzung. Ein inkrementeller Rollout, bei dem zunächst nicht-kritische Workloads migriert werden, kann helfen, Risiken zu minimieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entscheidung zwischen Contour und der \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n hängt von den spezifischen betrieblichen Einschränkungen, den Zeitrahmen für die Migration und den langfristigen architektonischen Zielen der Organisation ab. Während eine kurzfristige Migration zu Contour eine praktische Lösung darstellen kann, bietet die \u003ca href=\"/kubernetes/\"\u003eGateway API\u003c/a\u003e\n eine zukunftssichere und flexible Alternative für Unternehmen, die bereit sind, ihre Plattform zu modernisieren.\u003c/p\u003e\n", "summary": "TL;DR Der ingress-nginx-Controller für Kubernetes wird im März 2026 eingestellt, was erhebliche Risiken für die Betriebsführung mit sich bringt. Organisationen stehen vor der Wahl, entweder zu einem anderen Ingress-Controller wie Contour zu migrieren oder die Gateway API zu implementieren, die eine moderne und zukunftssichere Lösung bietet.\nHauptinhalt Die Ankündigung über die Einstellung des ingress-nginx-Controllers hat weitreichende Folgen für Infrastrukturteams. Während die Ingress API weiterhin unterstützt wird, bedeutet das Ende des community-gepflegten Controllers, dass Organisationen aktiv werden müssen, um ihre Netzwerkarchitektur zu modernisieren und Sicherheitsrisiken zu vermeiden. Die Entscheidung zwischen zwei Hauptmigrationen ist entscheidend: eine \u0026ldquo;Lift-and-Shift\u0026rdquo;-Migration zu einem anderen Ingress-Controller oder der Wechsel zur Gateway API .\n", "image": "https://ayedo.de/navigating-the-ingress-nginx-retirement.png", "date_published": "2026-07-09T20:45:02Z", "date_modified": "2026-07-09T20:45:02Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","security","development","operations"], "language": "de" },{ "id": "https://ayedo.de/news/the-cncf-data-storage-in-cloud-native-ai-white-paper/", "url": "https://ayedo.de/news/the-cncf-data-storage-in-cloud-native-ai-white-paper/", "title": "Das CNCF White Paper zu Datenspeicherung in Cloud Native AI", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDas CNCF-White Paper zu Datenspeicherung in \u003ca href=\"https://cloud-native/\" target=\"_blank\" rel=\"noopener\"\u003eCloud Native\u003c/a\u003e\n AI behandelt die Herausforderungen und Lösungen für die Speicherung von Daten in KI- und ML-Workloads. Es identifiziert kritische Engpässe in traditionellen Speicherarchitekturen und bietet strukturierte Ansätze zur Optimierung der Datenverarbeitung in cloud-nativen Umgebungen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Implementierung von KI- und ML-Workloads in modernen Unternehmen hat sich als zentrales Ziel etabliert. Dabei stehen Organisationen vor der Herausforderung, große Datenmengen effizient in cloud-nativen Infrastrukturen zu verarbeiten. Das CNCF Technical Advisory Group for Infrastructure (TAG Infrastructure) hat ein umfassendes White Paper veröffentlicht, das sich mit der Datenverarbeitung in diesem Kontext befasst.\u003c/p\u003e\n\u003cp\u003eEin zentrales Problem ist die Speicherung von Daten in der Geschwindigkeit, die für KI-Anwendungen erforderlich ist. Traditionelle Speicherarchitekturen, die für Standard-Microservices optimiert sind, stoßen an ihre Grenzen, wenn es darum geht, massive Datensätze an hochleistungsfähige Hardware wie GPUs zu liefern. Infrastrukturteams sehen sich dabei mit verschiedenen Herausforderungen konfrontiert, darunter das \u0026ldquo;Small-File Trap\u0026rdquo;, bei dem Millionen kleiner Dateien die Metadaten-Server stark belasten.\u003c/p\u003e\n\u003cp\u003eDas White Paper unterteilt das cloud-native AI-Datenökosystem in wesentliche Strukturebenen. Dazu gehören hybride Data Lake Houses, die zentrale Systeme zusammenführen und offene Formate wie Apache Parquet und Iceberg verwenden. Zudem wird die Rolle von Vektor-Datenbanken wie Milvus hervorgehoben, die für Ähnlichkeitssuchen und Retrieval-Augmented Generation (RAG) ausgelegt sind.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Aspekt ist die Optimierung der Datenlokalität. Um Verzögerungen durch Datenübertragungen zu minimieren, werden Strategien zur Datenlokalität vorgestellt, wobei das CNCF-Projekt Fluid zur Orchestrierung von verteiltem Caching innerhalb von \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n hervorgehoben wird. Die Standardisierung von Schnittstellen durch die \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eContainer Storage Interface\u003c/a\u003e\n (CSI) und die Container Object Storage Interface (COSI) wird ebenfalls behandelt, um die Integration von Speicherlösungen zu erleichtern.\u003c/p\u003e\n\u003cp\u003eDas White Paper beschreibt auch moderne Datenpipelines, die den Übergang von traditionellen Batch-Prozessen zu Echtzeit-Streaming unter Verwendung von Change Data Capture (CDC) und Event-Streaming-Plattformen wie Apache Kafka skizzieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eEine detaillierte Analyse der Speicheranforderungen über den gesamten Lebenszyklus von KI-Workloads wird im White Paper vorgenommen. Diese umfasst drei Phasen:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eModelltraining\u003c/strong\u003e: Diese Phase erfordert eine hohe Durchsatzrate und muss nicht-sequenziellen Zugriff tolerieren, um massive, synchronisierte Schreibvorgänge während des Checkpointings zu bewältigen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eModell-Inferenz\u003c/strong\u003e: Hier steht die Latenz im Vordergrund. Produktionssysteme nutzen fortschrittliche Speicherarchitekturen wie KV-Caching und Prefix-Caching, um redundante Berechnungen zu vermeiden.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAgentic AI\u003c/strong\u003e: In dieser aufkommenden Phase ist ein komplexes, iteratives Denkmodell erforderlich, das sowohl kurzfristige als auch langfristige Speicherlösungen benötigt, um vergangene Sitzungen zu konsolidieren.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDas White Paper bietet wertvolle Einblicke und strukturierte Ansätze zur Bewältigung der Herausforderungen bei der Speicherung von Daten in cloud-nativen KI-Anwendungen. Die Community wird ermutigt, sich aktiv an der Entwicklung nachhaltiger Architekturmodelle zu beteiligen, um die Effizienz und Leistung in diesem schnelllebigen Bereich zu steigern.\u003c/p\u003e\n", "summary": "TL;DR Das CNCF-White Paper zu Datenspeicherung in Cloud Native AI behandelt die Herausforderungen und Lösungen für die Speicherung von Daten in KI- und ML-Workloads. Es identifiziert kritische Engpässe in traditionellen Speicherarchitekturen und bietet strukturierte Ansätze zur Optimierung der Datenverarbeitung in cloud-nativen Umgebungen.\nHauptinhalt Die Implementierung von KI- und ML-Workloads in modernen Unternehmen hat sich als zentrales Ziel etabliert. Dabei stehen Organisationen vor der Herausforderung, große Datenmengen effizient in cloud-nativen Infrastrukturen zu verarbeiten. Das CNCF Technical Advisory Group for Infrastructure (TAG Infrastructure) hat ein umfassendes White Paper veröffentlicht, das sich mit der Datenverarbeitung in diesem Kontext befasst.\n", "image": "https://ayedo.de/the-cncf-data-storage-in-cloud-native-ai-white-paper.png", "date_published": "2026-07-08T17:35:54Z", "date_modified": "2026-07-08T17:35:54Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","ai","development","cloud"], "language": "de" },{ "id": "https://ayedo.de/news/your-laptop-is-the-new-production-environment/", "url": "https://ayedo.de/news/your-laptop-is-the-new-production-environment/", "title": "Ihr Laptop ist die neue Produktionsumgebung", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Rolle des Laptops in der Softwareentwicklung verändert sich, da KI-gestützte Agenten zunehmend fähig sind, eigenständig Aufgaben zu übernehmen, anstatt nur Empfehlungen zu geben. Dies bringt neue Herausforderungen in Bezug auf Vertrauen und Governance mit sich, da Entwickler sicherstellen müssen, dass diese Agenten innerhalb definierter Grenzen agieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIn den letzten Jahren hat sich die Technologie für Entwickler erheblich weiterentwickelt. Zunächst unterstützten KI-Tools die Entwickler, indem sie Code-Schnipsel generierten und Fragen beantworteten. Mit dem Aufkommen von Co-Piloten konnten größere Aufgaben innerhalb bestehender Workflows erledigt werden. Aktuell befinden wir uns jedoch in einer neuen Ära, in der KI-Agenten nicht nur Empfehlungen abgeben, sondern auch eigenständig Aktionen ausführen. Dies stellt einen grundlegenden Wandel in der Softwareentwicklung dar, da die Verantwortung für Entscheidungen zunehmend von Menschen auf Software-Agenten übertragen wird.\u003c/p\u003e\n\u003cp\u003eEin bemerkenswerter Aspekt dieser Entwicklung ist die Verschiebung der Vertrauensgrenzen. Früher wurden KI-Tools hauptsächlich als Hilfsmittel genutzt, um Informationen zu überprüfen oder kleine Codeabschnitte zu generieren. Mit der zunehmenden Fähigkeit von Agenten, komplexe Aufgaben zu erledigen, wächst das Vertrauen in deren Einsatz. Agenten können jetzt nicht nur Code modifizieren und Tests durchführen, sondern auch direkt mit externen Systemen interagieren. Dies führt zu einer signifikanten Produktivitätssteigerung, aber auch zu neuen Herausforderungen hinsichtlich der Sicherheit und Governance.\u003c/p\u003e\n\u003cp\u003eDie Aussage, dass der Laptop zur neuen Produktionsumgebung geworden ist, verdeutlicht, dass Entwickler nun Entscheidungen direkt auf ihren Geräten treffen. Dies hat weitreichende Implikationen für die Art und Weise, wie Software entwickelt und verwaltet wird. Die Interaktion von Agenten mit realen Systemen erfordert ein Umdenken in Bezug auf Sicherheitsprotokolle und Governance-Modelle, die traditionell auf menschlichen Akteuren basierten.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Integration von KI-Agenten in den Entwicklungsprozess bringt neue Sicherheitsherausforderungen mit sich. Während herkömmliche Sicherheitskontrollen auf der Annahme beruhen, dass Menschen Aktionen durchführen und Systeme diese kontrollieren, operieren Agenten innerhalb einer anderen Struktur. Sie können auf Repositories zugreifen, Befehle ausführen und mit externen Tools interagieren, oft mit den gleichen Berechtigungen wie der Entwickler selbst. Dies verschiebt einen Großteil der Arbeit außerhalb der ursprünglich dafür vorgesehenen Governance-Systeme und erfordert ein neues Verständnis von Sicherheitsrichtlinien und Überwachung.\u003c/p\u003e\n\u003cp\u003eEntwickler stehen vor der Herausforderung, sicherzustellen, dass Agenten innerhalb der festgelegten Grenzen agieren. Das Vertrauen in diese Technologien ist entscheidend, um die Akzeptanz zu fördern und sicherzustellen, dass die Automatisierung nicht zu Sicherheitsrisiken führt. Governance wird somit nicht nur wichtig, um Systeme zu schützen, sondern auch, um das Vertrauen der Entwickler in die eingesetzten Systeme zu stärken.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Rolle des Laptops als Produktionsumgebung wird durch die Fähigkeiten von KI-Agenten neu definiert. Um die Vorteile dieser Technologien zu nutzen, müssen Organisationen jedoch neue Governance-Modelle entwickeln, die das Vertrauen in automatisierte Prozesse stärken und gleichzeitig Sicherheitsrisiken minimieren.\u003c/p\u003e\n\u003cp\u003eZusätzlich sollten Entwickler die Möglichkeiten von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n in Betracht ziehen, um Container-Management und Orchestrierung zu optimieren, während sie gleichzeitig die \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n im Auge behalten, um Sicherheitsstandards einzuhalten.\u003c/p\u003e\n", "summary": "TL;DR Die Rolle des Laptops in der Softwareentwicklung verändert sich, da KI-gestützte Agenten zunehmend fähig sind, eigenständig Aufgaben zu übernehmen, anstatt nur Empfehlungen zu geben. Dies bringt neue Herausforderungen in Bezug auf Vertrauen und Governance mit sich, da Entwickler sicherstellen müssen, dass diese Agenten innerhalb definierter Grenzen agieren.\nHauptinhalt In den letzten Jahren hat sich die Technologie für Entwickler erheblich weiterentwickelt. Zunächst unterstützten KI-Tools die Entwickler, indem sie Code-Schnipsel generierten und Fragen beantworteten. Mit dem Aufkommen von Co-Piloten konnten größere Aufgaben innerhalb bestehender Workflows erledigt werden. Aktuell befinden wir uns jedoch in einer neuen Ära, in der KI-Agenten nicht nur Empfehlungen abgeben, sondern auch eigenständig Aktionen ausführen. Dies stellt einen grundlegenden Wandel in der Softwareentwicklung dar, da die Verantwortung für Entscheidungen zunehmend von Menschen auf Software-Agenten übertragen wird.\n", "image": "https://ayedo.de/your-laptop-is-the-new-production-environment.png", "date_published": "2026-07-08T13:00:00Z", "date_modified": "2026-07-08T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/announcing-etcd-v3-7-0/", "url": "https://ayedo.de/news/announcing-etcd-v3-7-0/", "title": "Ankündigung von etcd v3.7.0", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Veröffentlichung von etcd v3.7.0 bringt bedeutende Verbesserungen, darunter die neue RangeStream-Funktion, die Verarbeitung großer Ergebnissets optimiert. Zudem wurden die letzten Reste des veralteten v2-Stores entfernt, und eine umfassende Überarbeitung der Protobuf-Bibliotheken durchgeführt. Diese Version verspricht eine verbesserte Leistung und Effizienz für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Nutzer und andere Anwendungen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie neueste Version von etcd, v3.7.0, stellt einen bedeutenden Fortschritt für diesen verteilten Schlüssel-Wert-Speicher dar, der eine zentrale Rolle in der \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Architektur spielt. Die Einführung der RangeStream-Funktion ermöglicht es Anwendungen, große Ergebnissets in kleineren, handhabbaren Chunks zu verarbeiten, was die Latenzzeiten verringert und den Speicherverbrauch auf Server- und Client-Seite optimiert. Dies ist besonders vorteilhaft für Nutzer, die mit umfangreichen Datensätzen arbeiten.\u003c/p\u003e\n\u003cp\u003eZusätzlich zur RangeStream-Funktion bietet v3.7.0 mehrere Leistungsverbesserungen, darunter eine Optimierung für Schlüssel-only Range-Anfragen. Diese Änderungen reduzieren die Notwendigkeit, alle serialisierten Werte aus dem Backend zu laden, was die Effizienz bei Anfragen verbessert, die nur die Schlüssel benötigen. Die neue Version sorgt auch für eine signifikante Reduzierung der CPU-Nutzung bei etcd-Mitgliedern im Vergleich zur vorherigen Version v3.6.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Aspekt dieser Version ist die vollständige Migration von veralteten Protobuf-Bibliotheken zu vollständig unterstützten Alternativen. Diese Überarbeitung verbessert nicht nur die Sicherheit und Wartbarkeit, sondern führt auch zu einer Reduzierung der CPU-Nutzung durch etcd-Komponenten.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie RangeStream-Funktion stellt einen Paradigmenwechsel für den Umgang mit großen Datenmengen dar. Vor dieser Änderung mussten vollständige Ergebnissets im Speicher gehalten werden, was zu unerwarteten Latenzen führte. Mit der neuen Funktion können Entwickler nun gezielt mit Chunks arbeiten, was die Effizienz erheblich steigert.\u003c/p\u003e\n\u003cp\u003eDie Optimierung der Schlüssel-only Range-Anfragen bedeutet, dass bei spezifischen Anfragen nur die notwendigen Daten aus dem Speicher gelesen werden, was die Backend-Lesevorgänge minimiert. Dies ist besonders relevant für Anwendungen, die nur an den Schlüsseln interessiert sind und keine zusätzlichen Daten benötigen.\u003c/p\u003e\n\u003cp\u003eDie Überarbeitung der Protobuf-Bibliotheken könnte für Entwickler, die auf etcd-Go-Module angewiesen sind, von Belang sein. Diese Nutzer müssen möglicherweise ihre Abhängigkeiten aktualisieren, um mit den Änderungen in der API und den Protobuf-Bibliotheken kompatibel zu bleiben.\u003c/p\u003e\n\u003cp\u003eDie Unterstützung von Unix-Socket-Endpunkten in etcd v3.7.0 ermöglicht eine lokale Kommunikation ohne TCP-Port, was vor allem für Entwicklungs- und Testumgebungen sowie Edge-Device-Anwendungen von Vorteil ist.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Veröffentlichung von etcd v3.7.0 stellt einen bedeutenden Schritt in der Weiterentwicklung des Schlüssel-Wert-Speichers dar, mit einem klaren Fokus auf Leistung und Effizienz. Die neuen Funktionen und Optimierungen bieten Entwicklern und IT-Entscheidern wertvolle Werkzeuge, um ihre Anwendungen effektiver zu gestalten.\u003c/p\u003e\n", "summary": "TL;DR Die Veröffentlichung von etcd v3.7.0 bringt bedeutende Verbesserungen, darunter die neue RangeStream-Funktion, die Verarbeitung großer Ergebnissets optimiert. Zudem wurden die letzten Reste des veralteten v2-Stores entfernt, und eine umfassende Überarbeitung der Protobuf-Bibliotheken durchgeführt. Diese Version verspricht eine verbesserte Leistung und Effizienz für Kubernetes -Nutzer und andere Anwendungen.\nHauptinhalt Die neueste Version von etcd, v3.7.0, stellt einen bedeutenden Fortschritt für diesen verteilten Schlüssel-Wert-Speicher dar, der eine zentrale Rolle in der Kubernetes -Architektur spielt. Die Einführung der RangeStream-Funktion ermöglicht es Anwendungen, große Ergebnissets in kleineren, handhabbaren Chunks zu verarbeiten, was die Latenzzeiten verringert und den Speicherverbrauch auf Server- und Client-Seite optimiert. Dies ist besonders vorteilhaft für Nutzer, die mit umfangreichen Datensätzen arbeiten.\n", "image": "https://ayedo.de/announcing-etcd-v3-7-0.png", "date_published": "2026-07-08T12:00:00Z", "date_modified": "2026-07-08T12: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/network-boundary-for-ai-agents-using-nginx-and-opentelemetry/", "url": "https://ayedo.de/news/network-boundary-for-ai-agents-using-nginx-and-opentelemetry/", "title": "Netzwerkgrenze für KI-Agenten mit NGINX und OpenTelemetry", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Implementierung einer Netzwerkgrenze für KI-Agenten mithilfe von \u003ca href=\"https://www.nginx.com/\" target=\"_blank\" rel=\"noopener\"\u003eNGINX\u003c/a\u003e\n und \u003ca href=\"https://opentelemetry.io/\" target=\"_blank\" rel=\"noopener\"\u003eOpenTelemetry\u003c/a\u003e\n ermöglicht eine kontrollierte und beobachtbare Umgebung für autonome Systeme. Diese Architektur nutzt bestehende Open-Source-Technologien, um den Netzwerkverkehr zu steuern und gleichzeitig Einblicke in die Aktivitäten der Agenten zu gewinnen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie zunehmende Autonomie von KI-Agenten bietet das Potenzial zur Automatisierung von Aufgaben, die zuvor menschliches Eingreifen erforderten. Diese Entwicklungen bringen jedoch neue operationale und sicherheitstechnische Herausforderungen mit sich. Eine innovative Lösung besteht darin, eine Netzwerkgrenze zu schaffen, die sowohl durchsetzbar als auch beobachtbar ist, ohne dass neue Infrastrukturen erforderlich sind. Dies wird durch die Kombination von \u003ca href=\"https://www.nginx.com/\" target=\"_blank\" rel=\"noopener\"\u003eNGINX\u003c/a\u003e\n als Verkehrssteuerung und \u003ca href=\"https://opentelemetry.io/\" target=\"_blank\" rel=\"noopener\"\u003eOpenTelemetry\u003c/a\u003e\n für die Überwachung erreicht.\u003c/p\u003e\n\u003cp\u003eNGINX fungiert als Reverse-Proxy für eingehenden Datenverkehr und als Forward-Proxy für ausgehenden Datenverkehr. Durch die Implementierung von iptables-Regeln kann der gesamte ausgehende Datenverkehr auf die Agenten-Anfragen beschränkt werden, wodurch die Netzwerkgrenze Teil der Architektur wird. Dies sorgt für eine robuste Kontrolle über den Datenfluss, die nicht nur von der Anwendung selbst abhängt.\u003c/p\u003e\n\u003cp\u003eDie native \u003ca href=\"https://opentelemetry.io/\" target=\"_blank\" rel=\"noopener\"\u003eOpenTelemetry\u003c/a\u003e\n -Integration in NGINX ermöglicht es, für jede Anfrage einen OTEL-Span zu generieren. Dadurch wird eine umfassende Sichtbarkeit des Datenverkehrs erreicht, die es ermöglicht, Benutzerinteraktionen mit den externen Aufrufen der Agenten zu korrelieren. Die gesammelten OTEL-Spans können in ein Audit-Log gespeichert oder in gängige Observability- und Sicherheitstools wie Jaeger oder Grafana integriert werden.\u003c/p\u003e\n\u003cp\u003eZur Validierung dieser Architektur wurde ein einzelner \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes\u003c/a\u003e\n -Cluster mit vier Workloads bereitgestellt: NGINX, Ollama, OpenClaw und ein OpenTelemetry Collector. Diese Konfiguration kann auf verschiedenen Plattformen, von Edge-Geräten bis hin zu Unternehmensinfrastrukturen, implementiert werden.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Nutzung von NGINX und OpenTelemetry zur Schaffung einer Netzwerkgrenze für KI-Agenten bietet mehrere technische Vorteile. Erstens ermöglicht die Verwendung von Open-Source-Komponenten eine kosteneffiziente Implementierung, die auf bestehenden \u003ca href=\"https://kubernetes.io/\" target=\"_blank\" rel=\"noopener\"\u003eCloud-nativen\u003c/a\u003e\n Technologien basiert. Zweitens wird durch die Kombination von Verkehrssteuerung und Überwachung eine granularere Kontrolle über den Datenverkehr erreicht, wodurch Sicherheitsrisiken minimiert werden können.\u003c/p\u003e\n\u003cp\u003eEs ist wichtig zu beachten, dass dieser Ansatz sich auf die Kontrolle und Beobachtung des Netzwerkverhaltens konzentriert, jedoch nicht die Absicht oder die Entscheidungsfindung der Agenten selbst bewertet. Die Implementierung von Proxy-basierten Kontrollen erfordert zusätzliche Sicherheits- und Überwachungsmaßnahmen, die in eine umfassendere Verteidigungsstrategie integriert werden müssen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Kombination von NGINX und OpenTelemetry zur Schaffung einer Netzwerkgrenze für KI-Agenten stellt einen vielversprechenden Ansatz dar, um die Sicherheit und Kontrolle in der zunehmend autonomen Welt der KI zu verbessern. Zukünftige Entwicklungen werden sich darauf konzentrieren, wie Netzwerksteuerungen in höhere Governance-Mechanismen für autonome Systeme integriert werden können.\u003c/p\u003e\n", "summary": "TL;DR Die Implementierung einer Netzwerkgrenze für KI-Agenten mithilfe von NGINX und OpenTelemetry ermöglicht eine kontrollierte und beobachtbare Umgebung für autonome Systeme. Diese Architektur nutzt bestehende Open-Source-Technologien, um den Netzwerkverkehr zu steuern und gleichzeitig Einblicke in die Aktivitäten der Agenten zu gewinnen.\nHauptinhalt Die zunehmende Autonomie von KI-Agenten bietet das Potenzial zur Automatisierung von Aufgaben, die zuvor menschliches Eingreifen erforderten. Diese Entwicklungen bringen jedoch neue operationale und sicherheitstechnische Herausforderungen mit sich. Eine innovative Lösung besteht darin, eine Netzwerkgrenze zu schaffen, die sowohl durchsetzbar als auch beobachtbar ist, ohne dass neue Infrastrukturen erforderlich sind. Dies wird durch die Kombination von NGINX als Verkehrssteuerung und OpenTelemetry für die Überwachung erreicht.\n", "image": "https://ayedo.de/network-boundary-for-ai-agents-using-nginx-and-opentelemetry.png", "date_published": "2026-07-08T11:00:00Z", "date_modified": "2026-07-08T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","operations","security","development","compliance"], "language": "de" },{ "id": "https://ayedo.de/news/two-months-of-open-community-groups/", "url": "https://ayedo.de/news/two-months-of-open-community-groups/", "title": "Zwei Monate der Open Community Groups", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Cloud Native Computing Foundation (CNCF) hat vor zwei Monaten die Open Community Groups (OCG) als offene, quelloffene Plattform für Online-Meetups gestartet. Diese Plattform entstand aus dem Bedarf, eine maßgeschneiderte Lösung für die Community zu schaffen, und hat bereits eine Vielzahl von Gruppen und Veranstaltungen angezogen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Open Community Groups (OCG) wurden als Antwort auf den Bedarf an einer flexiblen und anpassbaren Plattform für Community-Interaktionen innerhalb des Open-Source-Ökosystems entwickelt. Die CNCF hat fast zwei Jahre in die Entwicklung dieser Plattform investiert, um eine Lösung zu bieten, die besser auf die spezifischen Anforderungen der Community abgestimmt ist, anstatt bestehende, aber unzureichende Open-Source-Optionen zu nutzen.\u003c/p\u003e\n\u003cp\u003eDie Migration der bestehenden Community-Plattform zu OCG fand am Wochenende des 2. Mai statt. Dabei wurde ein Redirect-Service eingerichtet, um den Datenverkehr zu steuern, je nachdem, ob es sich um eine Cloud Native Community Group (CNCG), einen \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eKubernetes Community Day\u003c/a\u003e\n (KCD) oder eine virtuelle Veranstaltung handelte. Die ersten Tage nach der Migration waren mit einigen Herausforderungen verbunden, jedoch konnten diese schnell behoben werden.\u003c/p\u003e\n\u003cp\u003eAktuell umfasst die Plattform 289 Gruppen mit insgesamt 89.202 Mitgliedern. Bislang wurden 6.024 Veranstaltungen organisiert, an denen 146.182 Teilnehmer teilnahmen. Diese Zahlen verdeutlichen das Wachstum und das Engagement innerhalb der Community.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie OCG-Plattform zielt darauf ab, die Interaktion zwischen den Mitgliedern zu fördern und die Integration in das CNCF-Ökosystem zu verbessern. Zukünftige Entwicklungen beinhalten die Implementierung einer Zahlungsfunktion für Veranstaltungen wie KCDs sowie eine engere Anbindung an andere Tools wie Slack und Mailinglisten. Diese Funktionen sind darauf ausgelegt, die Benutzererfahrung zu optimieren und die Plattform nahtlos in bestehende Arbeitsabläufe zu integrieren.\u003c/p\u003e\n\u003cp\u003eDie offene Natur der Plattform ermöglicht es der Community, aktiv an der Weiterentwicklung mitzuwirken. Bislang wurden über 68 Issues geschlossen und 408 Pull Requests (PRs) zusammengeführt, was die aktive Beteiligung und das Engagement der Community unterstreicht.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung der Open Community Groups stellt einen bedeutenden Schritt zur Stärkung der Open-Source-Community dar. Mit der kontinuierlichen Verbesserung und den geplanten Erweiterungen wird die Plattform voraussichtlich eine zentrale Rolle in der \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eCloud-Native-\u003c/a\u003e\n und \u003ca href=\"https://kubernetes/\" target=\"_blank\" rel=\"noopener\"\u003eDevOps-Landschaft\u003c/a\u003e\n einnehmen.\u003c/p\u003e\n", "summary": "TL;DR Die Cloud Native Computing Foundation (CNCF) hat vor zwei Monaten die Open Community Groups (OCG) als offene, quelloffene Plattform für Online-Meetups gestartet. Diese Plattform entstand aus dem Bedarf, eine maßgeschneiderte Lösung für die Community zu schaffen, und hat bereits eine Vielzahl von Gruppen und Veranstaltungen angezogen.\nHauptinhalt Die Open Community Groups (OCG) wurden als Antwort auf den Bedarf an einer flexiblen und anpassbaren Plattform für Community-Interaktionen innerhalb des Open-Source-Ökosystems entwickelt. Die CNCF hat fast zwei Jahre in die Entwicklung dieser Plattform investiert, um eine Lösung zu bieten, die besser auf die spezifischen Anforderungen der Community abgestimmt ist, anstatt bestehende, aber unzureichende Open-Source-Optionen zu nutzen.\n", "image": "https://ayedo.de/two-months-of-open-community-groups.png", "date_published": "2026-07-07T15:44:58Z", "date_modified": "2026-07-07T15:44:58Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","platform","development","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/why-sandboxing-your-agent-is-not-enough/", "url": "https://ayedo.de/news/why-sandboxing-your-agent-is-not-enough/", "title": "Warum das Sandboxing Ihres Agents nicht ausreicht", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Projekte agent-sandbox und agent-substrate bieten unterschiedliche Ansätze zur sicheren Ausführung von KI-Agenten in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen. Während agent-sandbox auf Sicherheit und Isolation fokussiert ist, zielt agent-substrate auf Effizienz und Skalierbarkeit ab, indem es die Ausführung von Agenten dynamisch verwaltet.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung im Bereich der KI-Agenten schreitet rasant voran, was die Notwendigkeit einer sicheren und isolierten Umgebung für deren Ausführung unterstreicht. Das Projekt agent-sandbox nutzt die bereits in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n entwickelten Bausteine, um eine Sandbox für KI-Agenten zu schaffen. Es bietet eine Sandbox Custom Resource Definition (CRD) und einen Controller, der starke Identitäten für Agenten, persistente Speicherung, Lebenszyklusmanagement und Sicherheitsmechanismen bereitstellt.\u003c/p\u003e\n\u003cp\u003eIm Gegensatz dazu ist agent-substrate ein eigenständiges Projekt, das auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n aufbaut, jedoch nicht Teil einer Kubernetes-SIG oder eines anderen Cloud-Native-Projekts ist. Agent-substrate zielt darauf ab, die Möglichkeiten der Agentenausführung über die reine Sandbox-Funktionalität hinaus zu erweitern. Es bietet höhere Skalierbarkeit, bessere Ressourcennutzung, niedrigere Latenzzeiten und ein dynamisches Lebenszyklusmanagement für Agenten. Agenten werden in sicheren Arbeits-Pods für kurze Zeiträume ausgeführt und können bei Inaktivität pausiert und später auf einem verfügbaren Worker fortgesetzt werden.\u003c/p\u003e\n\u003cp\u003eDer Ansatz von agent-substrate ermöglicht es, Agenten ähnlich wie serverlose Workloads zu verwalten. Dies bedeutet, dass sie bei Bedarf geplant, pausiert und mit minimalem Overhead wieder aufgenommen werden können, während sie weiterhin von der Sandbox-Isolation profitieren. Diese Flexibilität ist besonders wichtig in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen, in denen Ressourcen oft begrenzt sind.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Unterschiede zwischen agent-sandbox und agent-substrate sind signifikant. Agent-sandbox konzentriert sich auf Sicherheit und Verwaltung, während agent-substrate die Effizienz und operationalen Skalierbarkeit in den Vordergrund rückt. Die Kombination beider Ansätze könnte eine optimale Lösung für die Verwaltung großer Agentenflotten bieten. Mit agent-substrate können Agenten dynamisch aufgerufen werden, was die Notwendigkeit verringert, Ressourcen für ständig laufende Agenten zu binden. Dies führt zu einer signifikanten Reduzierung des Ressourcenverbrauchs und einer besseren Auslastung der vorhandenen Infrastruktur.\u003c/p\u003e\n\u003cp\u003eDie Integration von agent-substrate mit kagent ermöglicht eine vereinfachte und deklarative Verwaltung der Agenten. Anstatt jedem Agenten einen eigenen Pod zuzuweisen, können Ressourcen in gemeinsamen Arbeits-Pools effizienter genutzt werden. Dies verbessert nicht nur die Ressourcennutzung, sondern reduziert auch die Komplexität bei der Verwaltung der Agenten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Kombination von agent-sandbox und agent-substrate bietet eine vielversprechende Perspektive für die sichere und effiziente Ausführung von KI-Agenten in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Die Entwicklung in diesem Bereich wird weiterhin entscheidend sein, um den steigenden Anforderungen an Skalierbarkeit und Sicherheit gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Die Projekte agent-sandbox und agent-substrate bieten unterschiedliche Ansätze zur sicheren Ausführung von KI-Agenten in Kubernetes -Umgebungen. Während agent-sandbox auf Sicherheit und Isolation fokussiert ist, zielt agent-substrate auf Effizienz und Skalierbarkeit ab, indem es die Ausführung von Agenten dynamisch verwaltet.\nHauptinhalt Die Entwicklung im Bereich der KI-Agenten schreitet rasant voran, was die Notwendigkeit einer sicheren und isolierten Umgebung für deren Ausführung unterstreicht. Das Projekt agent-sandbox nutzt die bereits in Kubernetes entwickelten Bausteine, um eine Sandbox für KI-Agenten zu schaffen. Es bietet eine Sandbox Custom Resource Definition (CRD) und einen Controller, der starke Identitäten für Agenten, persistente Speicherung, Lebenszyklusmanagement und Sicherheitsmechanismen bereitstellt.\n", "image": "https://ayedo.de/why-sandboxing-your-agent-is-not-enough.png", "date_published": "2026-07-07T11:30:00Z", "date_modified": "2026-07-07T11:30:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","security","operations","development"], "language": "de" },{ "id": "https://ayedo.de/news/the-4-body-problem-of-sre-why-autonomous-operations-depend-on-context/", "url": "https://ayedo.de/news/the-4-body-problem-of-sre-why-autonomous-operations-depend-on-context/", "title": "Das 4-Körper-Problem der SRE: Warum autonome Operationen vom Kontext abhängen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAutonome Operationen im Site Reliability Engineering (SRE) stehen vor Herausforderungen, die nicht nur technischer Natur sind. Der entscheidende Faktor ist der Kontext, in dem Entscheidungen getroffen werden müssen. Ein neues Konzept, das als \u0026ldquo;4-Körper-Problem\u0026rdquo; bezeichnet wird, beschreibt die Notwendigkeit, vier miteinander verbundene Informationsquellen zu berücksichtigen, um effektive Entscheidungen zu treffen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Diskussionen unter erfahrenen SREs und Plattformingenieuren haben gezeigt, dass der Einsatz von Künstlicher Intelligenz (KI) in Operations nicht nur von der Leistungsfähigkeit der Modelle abhängt, sondern vor allem von der Qualität des Kontextes, in dem diese Modelle arbeiten. Das sogenannte \u0026ldquo;4-Körper-Problem\u0026rdquo; beschreibt die Komplexität, die entsteht, wenn mehrere Informationsquellen in Entscheidungsprozesse integriert werden müssen.\u003c/p\u003e\n\u003cp\u003eIn einem typischen Szenario müssen SREs Entscheidungen auf der Grundlage von vier zentralen Informationsquellen treffen:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eCode\u003c/strong\u003e: Alle Änderungen im Code, einschließlich Commits, Pull Requests, Versionen und Konfigurationen, müssen berücksichtigt werden. Es ist entscheidend zu wissen, was wann bereitgestellt wurde und welche Unterschiede zu vorherigen Versionen bestehen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eInfrastrukturzustand\u003c/strong\u003e: Der aktuelle Zustand der Cloud-Umgebungen, Netzwerke, \u003ca href=\"/kubernetes/\"\u003eKubernetes-Cluster\u003c/a\u003e\n und IAM-Richtlinien ist grundlegend. Hierbei ist es wichtig, die Diskrepanz zwischen dem, was in Terraform definiert ist, und dem tatsächlichen Zustand zu erkennen.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eLaufzeitsignale\u003c/strong\u003e: Metriken, Logs und Alarme sind entscheidend, um den aktuellen Zustand des Systems zu verstehen und Veränderungen im Verhalten zu identifizieren.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eBetriebswissen\u003c/strong\u003e: Das gesammelte Wissen der Ingenieure, einschließlich Post-Mortems, Entscheidungsdokumentationen und On-Call-Playbooks, spielt eine wichtige Rolle. Oft sind diese Informationen nur in den Köpfen weniger erfahrener Mitarbeiter vorhanden, was zu einem Wissensengpass führen kann.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eDie Herausforderung besteht darin, dass Entscheidungen häufig an den Schnittstellen dieser vier Bereiche getroffen werden müssen. Historisch gesehen gab es keine Systeme, die diese Schnittstellen effektiv verwalten konnten, was zu einem Vertrauensdefizit zwischen den verschiedenen Informationsquellen führt.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Diskussionen haben auch die Problematik von Agenten hervorgehoben, die in der Lage sein sollten, automatisierte Ursachenanalysen (RCA) durchzuführen. Die Qualität der Daten, über die diese Agenten verfügen, ist entscheidend für den Erfolg ihrer Entscheidungen. Wenn der Kontext fragmentiert ist, können Agenten nicht nur scheitern, sondern auch plausibel falsche Entscheidungen treffen, die nicht sofort erkennbar sind. Dies kann zu ernsthaften Problemen führen, insbesondere in kritischen Produktionsumgebungen.\u003c/p\u003e\n\u003cp\u003eEin zentrales Anliegen ist, dass Agenten nicht nur schneller alarmieren sollten, sondern auch in der Lage sein müssen, fundierte Hypothesen für Ursachenanalysen bereitzustellen, bevor menschliche Ingenieure eingreifen. Dies erfordert eine umfassende Integration der verschiedenen Informationsquellen, um die Effizienz und Zuverlässigkeit autonomer Systeme zu verbessern.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Herausforderungen im SRE-Bereich verdeutlichen die Notwendigkeit, den Kontext in Entscheidungsprozesse zu integrieren, um die Vorteile autonomer Operationen voll auszuschöpfen. Zukünftige Entwicklungen sollten sich darauf konzentrieren, Systeme zu schaffen, die diese vier Informationsquellen effektiv miteinander verknüpfen, um die Betriebseffizienz zu steigern und Vertrauenslücken zu schließen.\u003c/p\u003e\n", "summary": "TL;DR Autonome Operationen im Site Reliability Engineering (SRE) stehen vor Herausforderungen, die nicht nur technischer Natur sind. Der entscheidende Faktor ist der Kontext, in dem Entscheidungen getroffen werden müssen. Ein neues Konzept, das als \u0026ldquo;4-Körper-Problem\u0026rdquo; bezeichnet wird, beschreibt die Notwendigkeit, vier miteinander verbundene Informationsquellen zu berücksichtigen, um effektive Entscheidungen zu treffen.\nHauptinhalt Die Diskussionen unter erfahrenen SREs und Plattformingenieuren haben gezeigt, dass der Einsatz von Künstlicher Intelligenz (KI) in Operations nicht nur von der Leistungsfähigkeit der Modelle abhängt, sondern vor allem von der Qualität des Kontextes, in dem diese Modelle arbeiten. Das sogenannte \u0026ldquo;4-Körper-Problem\u0026rdquo; beschreibt die Komplexität, die entsteht, wenn mehrere Informationsquellen in Entscheidungsprozesse integriert werden müssen.\n", "image": "https://ayedo.de/the-4-body-problem-of-sre-why-autonomous-operations-depend-on-context.png", "date_published": "2026-07-06T11:00:00Z", "date_modified": "2026-07-06T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","operations","automation","development"], "language": "de" },{ "id": "https://ayedo.de/news/evolving-platform-engineering-for-ai-native-workloads/", "url": "https://ayedo.de/news/evolving-platform-engineering-for-ai-native-workloads/", "title": "Evolving Plattformengineering für KI-native Workloads", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie rasante Entwicklung von KI-Technologien erfordert eine Evolution der Plattformen im Bereich Platform Engineering, um den neuen Anforderungen an KI-native Workloads gerecht zu werden. Platform Engineering 2.0 erweitert die bestehenden Grundlagen um neue Funktionen, die eine breitere Nutzerbasis und spezifische Sicherheits- und \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n Anforderungen berücksichtigen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Einführung von Platform Engineering 1.0 hat signifikante Vorteile für die Softwareentwicklung gebracht, darunter beschleunigte Bereitstellungen durch Golden Paths und die Reduzierung der kognitiven Belastung für Entwickler durch interne Entwicklerplattformen (IDPs). Diese Plattformen haben es Entwicklern ermöglicht, Zeit zu sparen, die zuvor für Ticket-Erstellungen aufgewendet wurde. Dennoch erfordert die zunehmende Nutzung von KI-Technologien eine Anpassung dieser Plattformen, um den sich verändernden Arbeitslasten und Betriebsmodellen gerecht zu werden.\u003c/p\u003e\n\u003cp\u003eDie aktuellen Herausforderungen für Plattformteams sind vielfältig. Zunächst wird die Notwendigkeit für schnellere Codegenerierung und höhere Durchsatzraten durch den Einsatz von KI-Coding-Assistenten deutlich. Dies kann Software-Lieferpipelines unter Druck setzen. Zudem integrieren Anwendungen zunehmend autonome KI-Agenten, was bedeutet, dass Plattformen auch Anforderungen wie GPU-Bereitstellung, Modelllebenszyklusmanagement und Governance für KI-gesteuerte Systeme berücksichtigen müssen.\u003c/p\u003e\n\u003cp\u003eRegulatorische Anforderungen an Datensouveränität und kontinuierliche \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n dürfen nicht als nachträgliche Ergänzungen betrachtet werden. Sicherheitsaspekte müssen von Anfang an in den Entwicklungsprozess integriert werden, da KI-Modelle neue Sicherheitsrisiken mit sich bringen. Darüber hinaus benötigen verschiedene Rollen innerhalb eines Unternehmens, wie ML-Ingenieure, Datenwissenschaftler und FinOps-Praktiker, Zugang zur Plattform, was über die traditionelle Entwicklerzentrierung hinausgeht.\u003c/p\u003e\n\u003cp\u003eDie Evolution hin zu Platform Engineering 2.0 bietet einen Rahmen zur Diskussion über die erweiterten Plattformfähigkeiten, die für die Anforderungen der KI-Ära erforderlich sind. Die Kernprinzipien wie „Platform as Product“, Entwicklerproduktivität und Shift-Left-Security bleiben relevant, jedoch verändert sich die Zielgruppe der Plattform, ihre Funktionen und der Aufbau.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Evolution zu Platform Engineering 2.0 wird durch fünf Säulen strukturiert:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eAI-Native Platform\u003c/strong\u003e: Die Plattform unterstützt KI-Workloads von Grund auf und bietet umfassende Unterstützung für GPU/TPU-Zuweisung, Modellbereitstellung und Governance.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eMulti-Persona Experience\u003c/strong\u003e: Die Plattform bedient nicht nur Entwickler, sondern auch Datenwissenschaftler, ML-Ingenieure und Führungskräfte, indem sie ihnen spezifische Tools wie GPU-Bereitstellung und Echtzeit-FinOps-Dashboards bereitstellt.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eEmbedded FinOps\u003c/strong\u003e: Finanzielle Verantwortlichkeit wird in die Plattform integriert, sodass jede Entscheidung kostenbewusst getroffen wird.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eSecurity Shifts Down\u003c/strong\u003e: Sicherheitsmaßnahmen werden in die Plattform- und Laufzeitschichten integriert, um spezifische Bedrohungen im Zusammenhang mit KI zu adressieren.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eComposable by Design\u003c/strong\u003e: Die Plattform wird modular und API-first gestaltet, was einen schnellen Austausch von Komponenten ermöglicht, ohne dass umfangreiche Anpassungen erforderlich sind.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eDie Infrastruktur bleibt das wesentliche Kernstück jeder Plattformstrategie, da sie die erforderlichen Ressourcen für Berechnung, Speicherung und spezialisierte GPU-Ressourcen bereitstellt.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Anpassung von Plattformen an die Anforderungen der KI-Ära ist entscheidend für die Effizienz und Sicherheit in der Softwareentwicklung. Platform Engineering 2.0 stellt sicher, dass Unternehmen die notwendigen Werkzeuge und Governance-Strukturen haben, um den Herausforderungen der Zukunft zu begegnen.\u003c/p\u003e\n", "summary": "TL;DR Die rasante Entwicklung von KI-Technologien erfordert eine Evolution der Plattformen im Bereich Platform Engineering, um den neuen Anforderungen an KI-native Workloads gerecht zu werden. Platform Engineering 2.0 erweitert die bestehenden Grundlagen um neue Funktionen, die eine breitere Nutzerbasis und spezifische Sicherheits- und Compliance Anforderungen berücksichtigen.\nHauptinhalt Die Einführung von Platform Engineering 1.0 hat signifikante Vorteile für die Softwareentwicklung gebracht, darunter beschleunigte Bereitstellungen durch Golden Paths und die Reduzierung der kognitiven Belastung für Entwickler durch interne Entwicklerplattformen (IDPs). Diese Plattformen haben es Entwicklern ermöglicht, Zeit zu sparen, die zuvor für Ticket-Erstellungen aufgewendet wurde. Dennoch erfordert die zunehmende Nutzung von KI-Technologien eine Anpassung dieser Plattformen, um den sich verändernden Arbeitslasten und Betriebsmodellen gerecht zu werden.\n", "image": "https://ayedo.de/evolving-platform-engineering-for-ai-native-workloads.png", "date_published": "2026-07-06T11:00:00Z", "date_modified": "2026-07-06T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","compliance","platform","digital-sovereignty","development"], "language": "de" },{ "id": "https://ayedo.de/news/how-data-sovereignty-is-changing-cloud-native-infrastructure-design/", "url": "https://ayedo.de/news/how-data-sovereignty-is-changing-cloud-native-infrastructure-design/", "title": "Wie Datensouveränität das Design cloud-nativer Infrastruktur verändert", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDatensouveränität verändert die Gestaltung cloud-nativer Infrastrukturen, indem sie den Fokus von geografischen Standorten auf rechtliche Rahmenbedingungen verlagert. Regulierungen wie der EU Cloud and AI Development Act und der US CLOUD Act fordern Unternehmen auf, ihre Infrastruktur so zu gestalten, dass sie den Anforderungen an Datenhoheit und Betriebskontrolle gerecht werden.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Diskussion um Datensouveränität hat sich in den letzten Jahren erheblich gewandelt. Anstatt lediglich den Standort von Servern zu betrachten, wird zunehmend berücksichtigt, welche rechtlichen Rahmenbedingungen für die Daten gelten. Der US CLOUD Act hat verdeutlicht, dass der Zugang zu Daten nicht nur von ihrem physischen Standort, sondern vor allem von der Kontrolle des Unternehmens abhängt, das die Infrastruktur betreibt. Dies führt dazu, dass die Auswahl eines geografischen Standorts für die Datenhaltung nicht mehr ausreicht, um die rechtlichen Anforderungen an die Datensouveränität zu erfüllen.\u003c/p\u003e\n\u003cp\u003eDer im Juni 2026 vorgeschlagene EU Cloud and AI Development Act (CADA) bringt ein vierstufiges Souveränitätsmodell für die Beschaffung von Cloud-Diensten im öffentlichen Sektor mit sich. Auch in Kanada wird die Datenresidenz und die juristische Kontrolle von Cloud-Anbietern bewertet. Immer mehr Länder führen Anforderungen an die Datenlokalisierung und Souveränität ein, wobei sich die regulatorischen Rahmenbedingungen über die Datenresidenz hinaus erstrecken und Aspekte wie operationale Kontrolle, Transparenz in der Lieferkette, Portabilität und Resilienz betreffen.\u003c/p\u003e\n\u003cp\u003eDer EU-Datenakt fördert die Interoperabilität und senkt die Hürden für den Anbieterwechsel, während der AI Act Anforderungen an Nachverfolgbarkeit, Governance und Verantwortlichkeit für KI-Systeme einführt. Die NIS2- und DORA-Richtlinien legen einen stärkeren Fokus auf Abhängigkeiten in der Lieferkette, operationale Resilienz und Konzentrationsrisiken. Diese Entwicklungen zeigen, dass die Kontrolle über die Infrastruktur zunehmend nicht nur eine technische Entscheidung, sondern auch eine regulatorische Erwartung ist.\u003c/p\u003e\n\u003cp\u003eFür Plattformingenieure stellt sich die Herausforderung, die Anforderungen an die Souveränität zu erfüllen, ohne die Automatisierung, Portabilität und operationale Effizienz zu opfern, die die Cloud-Infrastruktur ursprünglich attraktiv gemacht haben.\u003c/p\u003e\n\u003cp\u003eImmer mehr regulierte Unternehmen in Europa setzen auf die Zusammenstellung souveräner Plattformen aus Open-Source-Komponenten, anstatt Souveränität als kostenpflichtige Zusatzleistung von Hyperscalern zu erwerben. \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n wird als Orchestrierungs- und Richtlinienebene genutzt, während GitOps für operative Konsistenz über verschiedene Jurisdiktionen sorgt. OpenStack bildet die zugrunde liegende Infrastruktur. Diese Kombination ermöglicht es Organisationen, Anforderungen an die Souveränität durch Architektur statt durch Verträge durchzusetzen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDer Einsatz von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n als Kontrollplattform für Souveränität bietet zahlreiche Vorteile. Admission Controllers können die Platzierung von Workloads vor deren Planung durchsetzen. Node Affinity-Regeln garantieren, dass Workloads nur auf genehmigter Infrastruktur innerhalb der richtigen Jurisdiktion landen. Namespace-Isolierung schafft klare Grenzen zwischen Mandanten, Umgebungen oder Regionen. Policy Engines bewerten jede API-Anfrage hinsichtlich der Souveränitätsanforderungen und lehnen nicht konforme Ressourcen ab, bevor sie in die Produktion gelangen.\u003c/p\u003e\n\u003cp\u003eDas Konzept \u0026ldquo;Policy as Code\u0026rdquo; ermöglicht eine kontinuierliche Durchsetzung von Souveränitätsrichtlinien. Diese Richtlinien werden in Git verwaltet, peer-reviewed und automatisch während des Bereitstellungsprozesses durchgesetzt. Tools wie OPA/Gatekeeper und Kyverno erlauben es Organisationen, juristische Anforderungen direkt in den Cluster zu kodieren, was die Nachverfolgbarkeit und Auditierbarkeit jeder Policy-Änderung gewährleistet.\u003c/p\u003e\n\u003cp\u003eEs ist jedoch zu beachten, dass \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n auf einer darunterliegenden Infrastruktur angewiesen ist. Compute, Netzwerk, Speicher und Identität müssen aus einer Quelle stammen, die innerhalb der eigenen Jurisdiktion betrieben wird, um die durch Kubernetes gewährten Garantien aufrechtzuerhalten.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung hin zu souveränen Infrastrukturen wird die Art und Weise, wie Unternehmen ihre Cloud-Ressourcen verwalten, nachhaltig beeinflussen. In der Zukunft wird die Einhaltung von Souveränitätsanforderungen eine zentrale Rolle in der Architektur cloud-nativer Lösungen spielen.\u003c/p\u003e\n", "summary": "TL;DR Datensouveränität verändert die Gestaltung cloud-nativer Infrastrukturen, indem sie den Fokus von geografischen Standorten auf rechtliche Rahmenbedingungen verlagert. Regulierungen wie der EU Cloud and AI Development Act und der US CLOUD Act fordern Unternehmen auf, ihre Infrastruktur so zu gestalten, dass sie den Anforderungen an Datenhoheit und Betriebskontrolle gerecht werden.\nHauptinhalt Die Diskussion um Datensouveränität hat sich in den letzten Jahren erheblich gewandelt. Anstatt lediglich den Standort von Servern zu betrachten, wird zunehmend berücksichtigt, welche rechtlichen Rahmenbedingungen für die Daten gelten. Der US CLOUD Act hat verdeutlicht, dass der Zugang zu Daten nicht nur von ihrem physischen Standort, sondern vor allem von der Kontrolle des Unternehmens abhängt, das die Infrastruktur betreibt. Dies führt dazu, dass die Auswahl eines geografischen Standorts für die Datenhaltung nicht mehr ausreicht, um die rechtlichen Anforderungen an die Datensouveränität zu erfüllen.\n", "image": "https://ayedo.de/how-data-sovereignty-is-changing-cloud-native-infrastructure-design.png", "date_published": "2026-07-03T11:00:00Z", "date_modified": "2026-07-03T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","digital-sovereignty","development","compliance","operations"], "language": "de" },{ "id": "https://ayedo.de/news/why-ai-agents-need-isolation/", "url": "https://ayedo.de/news/why-ai-agents-need-isolation/", "title": "Warum AI-Agenten Isolation benötigen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAI-Coding-Agenten verändern die Softwareentwicklung, indem sie Aufgaben automatisieren und selbstständig Code ausführen. Um Sicherheitsrisiken zu minimieren, ist die Isolation von AI-Agenten entscheidend. \u003ca href=\"/kubernetes/\"\u003eDocker\u003c/a\u003e\n SBX bietet eine sichere Ausführungsumgebung durch microVMs und kontrollierten Zugriff auf Ressourcen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Integration von AI-Coding-Agenten in Entwicklungsworkflows ermöglicht es, Aufgaben wie das Schreiben von Code, das Installieren von Abhängigkeiten und das Debuggen von Repositories zu automatisieren. Diese Agenten können nicht nur Vorschläge machen, sondern auch aktiv Terminalbefehle ausführen und direkt mit Entwicklungsumgebungen interagieren. Diese Entwicklung birgt jedoch auch neue Sicherheitsrisiken, da AI-generierter Code potenziell gefährliche Aktionen ausführen kann, wie das Löschen wichtiger Dateien oder das Zugänglichmachen sensibler Daten.\u003c/p\u003e\n\u003cp\u003eDie Notwendigkeit einer kontrollierten Ausführungsumgebung wird durch die Tatsache verstärkt, dass AI-Agenten oft untrusted Code ausführen und mit externen Diensten interagieren. Um die Sicherheit zu gewährleisten, ist es wichtig, dass AI-generierte Aktionen nicht uneingeschränkten Zugriff auf das Host-System erhalten. Isolation schafft eine klare Trennung zwischen dem Host, dem AI-Agenten und den ausgeführten Codes, wodurch das Risiko von unbeabsichtigten Schäden und Datenlecks reduziert wird.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"/kubernetes/\"\u003eDocker\u003c/a\u003e\n SBX bietet einen innovativen Ansatz zur Isolation von AI-Agenten. Im Gegensatz zu herkömmlichen \u003ca href=\"/kubernetes/\"\u003eContainern\u003c/a\u003e\n, die den Host-Kernel teilen, verwendet Docker SBX microVMs, die eine stärkere Isolation bieten. Diese Technologie ermöglicht es, dass AI-Agenten in einer sicheren Umgebung operieren, ohne das Host-System direkt zu gefährden. Diese Isolation ist nicht nur eine Sicherheitsmaßnahme, sondern wird auch als verantwortungsbewusste Praxis in der AI-gestützten Entwicklung angesehen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDocker SBX legt besonderen Wert auf die sichere Ausführung von AI-Workflows. Die Plattform bietet sandboxed Umgebungen, kontrollierte Netzwerkanbindungen und eine verbesserte Handhabung von Anmeldeinformationen. Anmeldeinformationen verbleiben auf dem Host und werden über einen Proxy in die Sandbox geleitet, wodurch das Risiko einer direkten Exposition reduziert wird. Diese Maßnahmen sind besonders wichtig, da AI-Agenten zunehmend mit APIs, Cloud-Diensten und externen Tools interagieren.\u003c/p\u003e\n\u003cp\u003eEin häufiges Beispiel für die Notwendigkeit von Isolation ist die Ausführung gefährlicher Befehle wie \u003ccode\u003esudo rm -rf /*\u003c/code\u003e innerhalb einer Sandbox. Solche drastischen Beispiele verdeutlichen die Wichtigkeit, AI-generierte Befehle in Umgebungen auszuführen, die Fehler sicher eingrenzen können. Der Einsatz von microVMs anstelle von herkömmlichen Containern bietet zusätzliche Sicherheit, da sie eine isolierte Ausführungsumgebung schaffen, die für AI-Workflows optimiert ist.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Isolation von AI-Agenten ist ein kritischer Aspekt der modernen Softwareentwicklung, insbesondere in einem zunehmend automatisierten Umfeld. Docker SBX stellt eine Lösung bereit, die sowohl Sicherheit als auch Benutzerfreundlichkeit in der Entwicklung von AI-gestützten Anwendungen gewährleistet. Zukünftige Entwicklungen werden voraussichtlich weitere Fortschritte in der sicheren Integration von AI in Entwicklungsworkflows mit sich bringen.\u003c/p\u003e\n", "summary": "TL;DR AI-Coding-Agenten verändern die Softwareentwicklung, indem sie Aufgaben automatisieren und selbstständig Code ausführen. Um Sicherheitsrisiken zu minimieren, ist die Isolation von AI-Agenten entscheidend. Docker SBX bietet eine sichere Ausführungsumgebung durch microVMs und kontrollierten Zugriff auf Ressourcen.\nHauptinhalt Die Integration von AI-Coding-Agenten in Entwicklungsworkflows ermöglicht es, Aufgaben wie das Schreiben von Code, das Installieren von Abhängigkeiten und das Debuggen von Repositories zu automatisieren. Diese Agenten können nicht nur Vorschläge machen, sondern auch aktiv Terminalbefehle ausführen und direkt mit Entwicklungsumgebungen interagieren. Diese Entwicklung birgt jedoch auch neue Sicherheitsrisiken, da AI-generierter Code potenziell gefährliche Aktionen ausführen kann, wie das Löschen wichtiger Dateien oder das Zugänglichmachen sensibler Daten.\n", "image": "https://ayedo.de/why-ai-agents-need-isolation.png", "date_published": "2026-07-01T13:00:00Z", "date_modified": "2026-07-01T13:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","automation","security","cloud-native","development"], "language": "de" },{ "id": "https://ayedo.de/news/what-does-eu-ai-act-compliance-require/", "url": "https://ayedo.de/news/what-does-eu-ai-act-compliance-require/", "title": "Was erfordert die Einhaltung des EU AI Act?", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer EU AI Act, der im August 2024 in Kraft trat, stellt umfassende \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n Anforderungen an Organisationen, die KI-Systeme auf dem EU-Markt bereitstellen. Die Regelungen basieren auf einem vierstufigen Risikomodell und beinhalten unter anderem Transparenzpflichten, Dokumentationsanforderungen und hohe Bußgelder bei Nichteinhaltung. Die Umsetzung erfolgt schrittweise bis 2027.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDer EU AI Act ist die erste umfassende Regulierung für Künstliche Intelligenz weltweit und richtet sich an alle Organisationen, die KI-Systeme in der EU bereitstellen oder deren Ergebnisse in der EU verwendet werden. Die Regelungen sind in Phasen bis 2027 umzusetzen, wobei bereits einige Anforderungen in Kraft sind. Der Act unterscheidet zwischen vier Risikokategorien, die bestimmen, welche regulatorischen Verpflichtungen für ein KI-System gelten.\u003c/p\u003e\n\u003cp\u003eDie erste Kategorie ist der Bereich des inakzeptablen Risikos, in dem bestimmte Praktiken wie manipulative Techniken, soziale Bewertungssysteme und die Nutzung von Gesichtserkennung ohne Einwilligung verboten sind. Diese Regelungen sind seit Februar 2025 in Kraft.\u003c/p\u003e\n\u003cp\u003eDie zweite Kategorie umfasst hochriskante Systeme, die strengen \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n Anforderungen unterliegen. Diese Systeme werden in zwei Gruppen unterteilt: Systeme, die als Sicherheitskomponente oder Produkt unter bestehende EU-Sicherheitsvorschriften fallen, und Systeme, die in sensiblen Bereichen wie Bildung, Strafverfolgung oder kritischer Infrastruktur eingesetzt werden. Für hochriskante Systeme sind umfassende Dokumentations-, Test- und Protokollierungspflichten erforderlich.\u003c/p\u003e\n\u003cp\u003eDie dritte Kategorie umfasst Systeme mit begrenztem Risiko, die sich auf Transparenz- und Offenlegungspflichten konzentrieren. Anbieter müssen sicherstellen, dass Nutzer erkennen, dass sie mit einem KI-System interagieren, und generierte Inhalte als solche kennzeichnen. Diese Anforderungen gelten beispielsweise für Chatbots und Deepfake-Technologien.\u003c/p\u003e\n\u003cp\u003eDie vierte Kategorie ist der Bereich des minimalen Risikos, in dem die meisten derzeit auf dem Markt befindlichen KI-Systeme, wie Spamfilter und Empfehlungsalgorithmen, fallen. Für diese Systeme gelten keine spezifischen regulatorischen Verpflichtungen, jedoch wird die Einhaltung freiwilliger Verhaltensrichtlinien empfohlen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einhaltung des EU AI Act erfordert von Unternehmen, dass sie ihre Entwicklungs- und Betriebsabläufe gründlich überprüfen. Insbesondere für hochriskante Systeme ist eine umfangreiche Dokumentation und Nachverfolgbarkeit der Daten und Entscheidungen unabdingbar. Die Verpflichtung zur Transparenz in der dritten Risikokategorie erfordert technische Implementierungen, die sicherstellen, dass Nutzer klar erkennen, wann sie mit KI interagieren. Bei Nichteinhaltung drohen erhebliche Strafen von bis zu 35 Millionen Euro oder 7 % des globalen Umsatzes, die von nationalen Behörden und dem EU AI Office durchgesetzt werden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung des EU AI Act stellt eine bedeutende Herausforderung und Chance für Unternehmen dar, die KI-Technologien entwickeln und einsetzen. Die schrittweise Umsetzung der Anforderungen bietet Zeit für Anpassungen, erfordert jedoch proaktive Maßnahmen zur Sicherstellung der \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n in allen Phasen des Lebenszyklus von KI-Systemen.\u003c/p\u003e\n", "summary": "TL;DR Der EU AI Act, der im August 2024 in Kraft trat, stellt umfassende Compliance Anforderungen an Organisationen, die KI-Systeme auf dem EU-Markt bereitstellen. Die Regelungen basieren auf einem vierstufigen Risikomodell und beinhalten unter anderem Transparenzpflichten, Dokumentationsanforderungen und hohe Bußgelder bei Nichteinhaltung. Die Umsetzung erfolgt schrittweise bis 2027.\nHauptinhalt Der EU AI Act ist die erste umfassende Regulierung für Künstliche Intelligenz weltweit und richtet sich an alle Organisationen, die KI-Systeme in der EU bereitstellen oder deren Ergebnisse in der EU verwendet werden. Die Regelungen sind in Phasen bis 2027 umzusetzen, wobei bereits einige Anforderungen in Kraft sind. Der Act unterscheidet zwischen vier Risikokategorien, die bestimmen, welche regulatorischen Verpflichtungen für ein KI-System gelten.\n", "image": "https://ayedo.de/what-does-eu-ai-act-compliance-require.png", "date_published": "2026-06-27T03:11:14Z", "date_modified": "2026-06-27T03:11:14Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["compliance","docker","security","politics","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/news/open-source-maintainership-in-the-age-of-ai/", "url": "https://ayedo.de/news/open-source-maintainership-in-the-age-of-ai/", "title": "Open-Source-Wartung im Zeitalter der KI", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eKubernetes-Community\u003c/a\u003e\n hat Richtlinien für den Einsatz von KI-unterstützter Softwareentwicklung entwickelt, um die Codequalität zu sichern und menschliche Verantwortung zu fördern. Diese Richtlinien verlangen Transparenz bei der Nutzung von KI-Tools und stellen sicher, dass menschliche Entwickler die Verantwortung für ihre Änderungen übernehmen.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eIm Zuge der zunehmenden Integration von Künstlicher Intelligenz (KI) in die Softwareentwicklung hat die \u003ca href=\"/kubernetes/\"\u003eKubernetes-Community\u003c/a\u003e\n Maßnahmen ergriffen, um die Qualität des Codes zu gewährleisten und die menschliche Aufsicht zu betonen. Die Einführung einer KI-Politik war ein zentraler Schritt, um klare Richtlinien für die Nutzung von KI-Tools zu schaffen. Diese Richtlinien sollen sicherstellen, dass Innovationen gefördert werden, während gleichzeitig die Verantwortlichkeit gewahrt bleibt.\u003c/p\u003e\n\u003cp\u003eEin wesentlicher Aspekt der neuen Politik ist die Transparenz. Entwickler sind verpflichtet, offenzulegen, wenn sie KI-Tools zur Unterstützung bei Pull-Requests (PRs) verwendet haben. Ein einfacher Hinweis im PR-Beschreibungstext genügt, um den Prüfern den Kontext zu verdeutlichen und eine angemessene Überprüfung zu ermöglichen.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus bleibt der menschliche Entwickler für alle Änderungen verantwortlich. Die Politik schließt die Nennung von KI als Mitautor in Commits aus und verbietet die Verwendung von Co-Signaturen oder Attributen, die die Arbeit einer KI zuschreiben. Dies soll sicherstellen, dass im Falle eines Problems immer ein Mensch vorhanden ist, der die Änderungen versteht und beheben kann.\u003c/p\u003e\n\u003cp\u003eEin weiteres wichtiges Element ist die Durchsetzung der Contributor License Agreements (CLA). Die Cloud Native Computing Foundation (CNCF) hat ein Tool zur Überprüfung dieser Vereinbarungen bereitgestellt, das sicherstellt, dass KI-Agenten nicht als Mitautoren aufgeführt werden können. Dies signalisiert den Prüfern, dass ein PR möglicherweise nicht bereit für die Zusammenführung ist.\u003c/p\u003e\n\u003cp\u003eDie Politik fordert auch, dass die Prüfer mit Menschen und nicht mit KI interagieren. Entwickler dürfen sich nicht auf KI verlassen, um auf Überprüfungsanmerkungen zu reagieren. Wenn ein Entwickler nicht in der Lage ist, Änderungen, die mit Hilfe von KI generiert wurden, persönlich zu erklären, wird der PR geschlossen. Diese Maßnahme fördert den Wissensaustausch und stellt sicher, dass die Entwickler das eingereichte Codeverständnis haben.\u003c/p\u003e\n\u003cp\u003eZusätzlich müssen die Entwickler KI-generierte Änderungen durch Code-Reviews, Tests und persönliches Verständnis verifizieren. Es reicht nicht aus, dass der Code funktioniert; die Entwickler müssen auch verstehen, warum er funktioniert und in der Lage sein, ihn zu warten. Diese Richtlinien spiegeln einen reifen Ansatz im Umgang mit KI wider: KI als Hilfsmittel zu nutzen, ohne menschliches Urteilsvermögen, Verständnis oder Verantwortung zu ersetzen.\u003c/p\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eKubernetes-Community\u003c/a\u003e\n hat auch begonnen, automatisierte KI-Review-Tools zu evaluieren. Es gibt zahlreiche Tools, die bei der Überprüfung von Code helfen, jedoch bringen KI-Pull-Request-Tools Herausforderungen in der Governance mit sich. Ein wichtiges Kriterium für die Einführung neuer KI-Tools ist die Bereitschaft der Maintainer, diese in den Kubernetes-SIG-Repositories zu testen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung von Tools wie GitHub Copilot und CodeRabbit hat gezeigt, dass KI-gestützte Überprüfungen eine wertvolle Unterstützung für Maintainer darstellen können. Diese Tools müssen jedoch so konfiguriert werden, dass sie den spezifischen Bedürfnissen der \u003ca href=\"/kubernetes/\"\u003eKubernetes-Community\u003c/a\u003e\n gerecht werden. Ein zentrales Ziel ist es, automatisierte Überprüfungstools zu entwickeln, die Maintainer nicht anfordern müssen, um eine breitere Akzeptanz in der Community zu erreichen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eKubernetes-Community\u003c/a\u003e\n hat mit der Entwicklung und Implementierung ihrer KI-Richtlinien einen proaktiven Ansatz zur Integration von KI in die Softwareentwicklung verfolgt. Zukünftige Schritte werden darauf abzielen, die Balance zwischen KI-Nutzung und menschlicher Verantwortung weiter zu optimieren.\u003c/p\u003e\n", "summary": "TL;DR Die Kubernetes-Community hat Richtlinien für den Einsatz von KI-unterstützter Softwareentwicklung entwickelt, um die Codequalität zu sichern und menschliche Verantwortung zu fördern. Diese Richtlinien verlangen Transparenz bei der Nutzung von KI-Tools und stellen sicher, dass menschliche Entwickler die Verantwortung für ihre Änderungen übernehmen.\nHauptinhalt Im Zuge der zunehmenden Integration von Künstlicher Intelligenz (KI) in die Softwareentwicklung hat die Kubernetes-Community Maßnahmen ergriffen, um die Qualität des Codes zu gewährleisten und die menschliche Aufsicht zu betonen. Die Einführung einer KI-Politik war ein zentraler Schritt, um klare Richtlinien für die Nutzung von KI-Tools zu schaffen. Diese Richtlinien sollen sicherstellen, dass Innovationen gefördert werden, während gleichzeitig die Verantwortlichkeit gewahrt bleibt.\n", "image": "https://ayedo.de/open-source-maintainership-in-the-age-of-ai.png", "date_published": "2026-06-26T18:00:00Z", "date_modified": "2026-06-26T18:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","compliance","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/introducing-the-cluster-api-plugin-for-headlamp/", "url": "https://ayedo.de/news/introducing-the-cluster-api-plugin-for-headlamp/", "title": "Einführung des Cluster API Plugins für Headlamp", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDas Cluster API Plugin für Headlamp ermöglicht eine visuelle und benutzerfreundliche Verwaltung von Cluster API-Ressourcen in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Es bietet umfassende Einblicke in den Status von Clustern, Maschinen und deren Beziehungen, was die Debugging- und Betriebsabläufe für Plattformteams erheblich vereinfacht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eHeadlamp ist ein Open-Source-Projekt, das als erweiterbare Benutzeroberfläche für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n dient. Es ermöglicht Nutzern, Cluster-Ressourcen direkt über ihren Browser zu erkunden, zu verwalten und zu debuggen. Mit der Einführung des Cluster API (CAPI) Plugins für Headlamp wird die Verwaltung von Cluster-Ressourcen erheblich vereinfacht. CAPI ist ein \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Unterprojekt, das deklarative APIs für das Lifecycle-Management von Clustern bereitstellt. Es ermöglicht Plattformteams, Kubernetes-Cluster effizient zu provisionieren, zu aktualisieren und zu verwalten.\u003c/p\u003e\n\u003cp\u003eDas Cluster API Plugin integriert sich nahtlos in Headlamp und bietet eine dedizierte Sektion für Cluster API. Es stellt eine visuelle Übersicht über die Kernressourcen von CAPI bereit, darunter Cluster, Maschinen und deren Status. Zu den Hauptfunktionen des Plugins gehören:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eClusterübersicht\u003c/strong\u003e: Nutzer können den Status von Clustern, einschließlich der Kontrollebenen und Arbeitslasten, in Echtzeit einsehen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMaschinenübersicht\u003c/strong\u003e: Detaillierte Informationen zu MachineDeployments, MachineSets, Maschinen und MachinePools werden angezeigt, einschließlich deren Status und Bedingungen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCluster API Dashboard\u003c/strong\u003e: Bietet eine zentrale Ansicht des Gesundheitsstatus der Cluster API-Ressourcen, aktiver Probleme und Informationen zu Anbietern.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eÜberwachung der Kontrollebenen\u003c/strong\u003e: Verfolgen von KubeadmControlPlane-Replikaten und deren Versionen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSkalierung über die Benutzeroberfläche\u003c/strong\u003e: Maschinen können direkt aus Headlamp skaliert werden, ohne dass Terminalbefehle erforderlich sind.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBesitzverhältnisse\u003c/strong\u003e: Die Beziehungen zwischen Clustern, Deployments und Maschinen werden klar dargestellt.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKubeadmConfig-Inspektion\u003c/strong\u003e: Bootstrap-Konfigurationen können in einem strukturierten Format angesehen werden, ohne dass rohes YAML erforderlich ist.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTopologie-Bewusstsein\u003c/strong\u003e: Automatische Erkennung und Kennzeichnung von ClusterClass-gemanagten Ressourcen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKartenansicht\u003c/strong\u003e: Visualisiert die Beziehungen zwischen Clustern, Kontrollebenen und Arbeitslasten.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDynamische API-Versionierung\u003c/strong\u003e: Unterstützung sowohl für v1beta1 als auch für v1beta2 Cluster API-Versionen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrometheus-Metriken\u003c/strong\u003e: Live-Metriken können direkt auf den Detailseiten der Cluster API-Ressourcen angezeigt werden.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung des Cluster API Plugins in Headlamp ermöglicht eine vereinfachte Verwaltung von Cluster-Ressourcen, die traditionell komplexe kubectl-Befehle und tiefgehendes Wissen über Besitzverhältnisse erforderte. Die visuelle Darstellung der Ressourcen und deren Status fördert eine schnellere Identifizierung von Problemen und ermöglicht eine effizientere Fehlerbehebung. Die Integration von Prometheus-Metriken innerhalb der Benutzeroberfläche bietet eine wertvolle Ergänzung zur Überwachung der Cluster-Leistung und -Gesundheit.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Einführung des Cluster API Plugins für Headlamp stellt einen bedeutenden Fortschritt in der Verwaltung von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Clustern dar. Es verbessert die Benutzererfahrung und die Effizienz für Plattformteams und erleichtert das Lifecycle-Management von Cloud-nativen Anwendungen. Zukünftige Entwicklungen könnten weitere Funktionen und Integrationen bieten, um die Verwaltung von Cloud-nativen Anwendungen weiter zu optimieren.\u003c/p\u003e\n", "summary": "TL;DR Das Cluster API Plugin für Headlamp ermöglicht eine visuelle und benutzerfreundliche Verwaltung von Cluster API-Ressourcen in Kubernetes . Es bietet umfassende Einblicke in den Status von Clustern, Maschinen und deren Beziehungen, was die Debugging- und Betriebsabläufe für Plattformteams erheblich vereinfacht.\nHauptinhalt Headlamp ist ein Open-Source-Projekt, das als erweiterbare Benutzeroberfläche für Kubernetes dient. Es ermöglicht Nutzern, Cluster-Ressourcen direkt über ihren Browser zu erkunden, zu verwalten und zu debuggen. Mit der Einführung des Cluster API (CAPI) Plugins für Headlamp wird die Verwaltung von Cluster-Ressourcen erheblich vereinfacht. CAPI ist ein Kubernetes -Unterprojekt, das deklarative APIs für das Lifecycle-Management von Clustern bereitstellt. Es ermöglicht Plattformteams, Kubernetes-Cluster effizient zu provisionieren, zu aktualisieren und zu verwalten.\n", "image": "https://ayedo.de/introducing-the-cluster-api-plugin-for-headlamp.png", "date_published": "2026-06-25T22:00:00Z", "date_modified": "2026-06-25T22:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","platform","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/how-to-generate-an-sbom-for-container-workflows/", "url": "https://ayedo.de/news/how-to-generate-an-sbom-for-container-workflows/", "title": "Wie man ein SBOM für Container-Workflows erstellt", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Erstellung eines Software Bill of Materials (SBOM) für \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n -Workflows ist entscheidend für die Sicherheit und \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n in Softwarelieferketten. Die Qualität eines SBOM hängt stark davon ab, ob es zur Build-Zeit oder nach dem Build generiert wird, wobei die Build-Zeit-Generierung eine umfassendere und genauere Dokumentation der Abhängigkeiten ermöglicht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Generierung von SBOMs stellt für viele Organisationen eine Herausforderung dar, da 86 % der Unternehmen Schwierigkeiten bei der Erstellung berichten. Ein wesentlicher Grund dafür ist die Vielzahl an Tools, die für unterschiedliche Artefakttypen verwendet werden, was zu inkonsistenten Ergebnissen führt. SBOMs sind jedoch für Sicherheits- und Compliance-Teams von großer Bedeutung, da sie eine zentrale Rolle bei der Reaktion auf Sicherheitsanfälligkeiten und der Erfüllung von Audit-Anforderungen spielen.\u003c/p\u003e\n\u003cp\u003eEin zentrales Element für die Qualität eines SBOM ist der Zeitpunkt der Generierung. Es gibt zwei Hauptansätze: die Generierung zur Build-Zeit und die nachträgliche Analyse. Die Generierung zur Build-Zeit integriert sich in das Build-System und hat Zugriff auf den vollständigen Abhängigkeitsbaum sowie die Metadaten des Paketmanagers. Dies ermöglicht eine präzise Erfassung aller Abhängigkeiten, einschließlich der transitive Abhängigkeiten, die von nachträglichen Scannern möglicherweise übersehen werden.\u003c/p\u003e\n\u003cp\u003eIm Gegensatz dazu arbeiten nachträgliche Scanning-Tools, indem sie das fertige Artefakt analysieren und dessen Inhalte rückentwickeln. Diese Methode kann jedoch oft nicht alle Abhängigkeiten erfassen, insbesondere bei statisch verlinkten Binärdateien oder während des Builds installierten OS-Paketen. Daher wird empfohlen, SBOMs während des Builds zu generieren, wenn der Zugriff auf das Build-System vorhanden ist. Für Drittanbieter-Images oder ältere Artefakte ohne Build-Integration ist das nachträgliche Scannen die geeignete Wahl.\u003c/p\u003e\n\u003cp\u003eDie Nützlichkeit eines SBOM hängt nicht nur von seiner Existenz ab, sondern auch von der Qualität der Informationen, die es enthält. Fünf Kriterien sind entscheidend für die Handlungsfähigkeit eines SBOMs: Vollständigkeit, Genauigkeit, Aktualität, Verifizierbarkeit und die Fähigkeit, die tatsächlichen installierten Versionen zu reflektieren. Ein vollständiges SBOM berücksichtigt alle Komponenten des Artefakts über alle Schichten und Pakettypen hinweg und erfasst sowohl OS-Pakete als auch Anwendungsabhängigkeiten.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Generierung eines qualitativ hochwertigen SBOM erfordert den Zugang zum gesamten Build-Kontext, einschließlich der Abhängigkeitsgraphen jeder Build-Phase. Bei der Verwendung von Multi-Stage-\u003ca href=\"/kubernetes/\"\u003eDocker\u003c/a\u003e\nfiles oder minimalen Basis-Images können erhebliche Lücken entstehen, wenn nachträgliche Scanner verwendet werden, da sie möglicherweise nicht alle Abhängigkeiten erkennen. Um dies zu vermeiden, sollten Organisationen sicherstellen, dass ihre Build-Systeme die Generierung von SBOMs unterstützen und diese als Teil des Build-Prozesses automatisiert werden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie korrekte Erstellung und Nutzung von SBOMs ist für die Sicherheit und Compliance in modernen Software-Lieferketten unerlässlich. Zukünftige Entwicklungen in der Automatisierung und Integration von SBOM-Generierung in Build-Prozesse könnten die Effizienz und Genauigkeit weiter verbessern.\u003c/p\u003e\n", "summary": "TL;DR Die Erstellung eines Software Bill of Materials (SBOM) für Container -Workflows ist entscheidend für die Sicherheit und Compliance in Softwarelieferketten. Die Qualität eines SBOM hängt stark davon ab, ob es zur Build-Zeit oder nach dem Build generiert wird, wobei die Build-Zeit-Generierung eine umfassendere und genauere Dokumentation der Abhängigkeiten ermöglicht.\nHauptinhalt Die Generierung von SBOMs stellt für viele Organisationen eine Herausforderung dar, da 86 % der Unternehmen Schwierigkeiten bei der Erstellung berichten. Ein wesentlicher Grund dafür ist die Vielzahl an Tools, die für unterschiedliche Artefakttypen verwendet werden, was zu inkonsistenten Ergebnissen führt. SBOMs sind jedoch für Sicherheits- und Compliance-Teams von großer Bedeutung, da sie eine zentrale Rolle bei der Reaktion auf Sicherheitsanfälligkeiten und der Erfüllung von Audit-Anforderungen spielen.\n", "image": "https://ayedo.de/how-to-generate-an-sbom-for-container-workflows.png", "date_published": "2026-06-25T20:44:07Z", "date_modified": "2026-06-25T20:44:07Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["compliance","docker","kubernetes","security","cloud-native"], "language": "de" },{ "id": "https://ayedo.de/news/inspect-volcano-workloads-faster-with-headlamp/", "url": "https://ayedo.de/news/inspect-volcano-workloads-faster-with-headlamp/", "title": "Überprüfen Sie Volcano-Workloads schneller mit Headlamp", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Integration des Volcano-Plugins in die Headlamp-Oberfläche ermöglicht eine schnellere und effizientere Überprüfung von Batch-Workloads in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Durch die zentrale Darstellung von Jobs, Queues und PodGroups wird die Verwaltung und Fehlersuche in komplexen Workloads erheblich vereinfacht.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eVolcano ist ein \u003ca href=\"/kubernetes/\"\u003eCloud-Native\u003c/a\u003e\n Batch-Scheduler für Kubernetes, der speziell für Hochleistungsrechnen, künstliche Intelligenz, maschinelles Lernen und andere Batch-Workloads entwickelt wurde. Im Gegensatz zu den ursprünglichen Kubernetes-Anwendungen, die auf langlaufende Dienste ausgelegt sind, behandelt Volcano dynamisch ankommende Jobs, die um begrenzte Ressourcen konkurrieren und möglicherweise mehrere Worker benötigen, um nützliche Arbeit zu leisten.\u003c/p\u003e\n\u003cp\u003eDas Volcano-Plugin für Headlamp bringt die Kernressourcen von Volcano in eine benutzerfreundliche Web-Oberfläche. Dies ermöglicht eine einfache Inspektion des Arbeitslaststatus, des Verhaltens von Warteschlangen und der Details zur Gang-Scheduling in einer einzigen Ansicht. Die zentrale Benutzeroberfläche erleichtert die Navigation zwischen verschiedenen Ressourcen, sodass Benutzer nicht mehr zwischen verschiedenen CLI-Tools wechseln müssen.\u003c/p\u003e\n\u003cp\u003eDie wichtigsten Ressourcen, die Volcano einführt, umfassen:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eJob\u003c/strong\u003e: Beschreibt eine Batch-Arbeitslast als eine Gruppe von Aufgaben und den zugehörigen Pods.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eQueue\u003c/strong\u003e: Teilt die Clusterkapazität zwischen Teams oder Workloads mithilfe von Quoten und Prioritäten.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePodGroup\u003c/strong\u003e: Verknüpft eine Gruppe von Pods, sodass der Scheduler sie als eine Einheit für das Gang-Scheduling behandelt.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDas Plugin bietet spezifische Ansichten für jede dieser Ressourcen unter einem eigenen Abschnitt in der Headlamp-Seitenleiste. In der Job-Ansicht können Benutzer schnell den Status der Arbeitslast, die Warteschlange, die Anzahl der laufenden Aufgaben und weitere relevante Informationen einsehen. Die Detailansicht ermöglicht es, tiefere Einblicke in den Status der Pods und die damit verbundenen Ressourcen zu erhalten.\u003c/p\u003e\n\u003cp\u003eDie Warteschlangenansicht bietet umfassende Informationen zur Ressourcenzuteilung und -einschränkung, was die Analyse von Ressourcenverteilungen über verschiedene Warteschlangen hinweg erleichtert. Die PodGroup-Ansicht hilft bei der Überwachung des Gang-Scheduling und zeigt den Fortschritt sowie die Mindestressourcenerfordernisse an.\u003c/p\u003e\n\u003cp\u003eZusätzlich gibt es eine Kartenansicht, die die Verbindungen zwischen Jobs, PodGroups, Queues und Pods visualisiert. Diese Ansicht ist besonders nützlich, wenn eine Arbeitslast aussteht oder nicht wie erwartet vorankommt, da sie einen schnellen Überblick über alle relevanten Ressourcen und deren Status bietet.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Integration des Volcano-Plugins in Headlamp ermöglicht eine nahtlose Verbindung zwischen verschiedenen Kubernetes-Ressourcen, was die Effizienz bei der Verwaltung von Batch-Workloads erhöht. Die Möglichkeit, direkt von der UI auf Job-Protokolle zuzugreifen und Lebenszyklusaktionen wie \u0026ldquo;Suspend\u0026rdquo; und \u0026ldquo;Resume\u0026rdquo; zu nutzen, reduziert die Komplexität und verbessert die Reaktionszeiten bei der Fehlersuche. Die visuelle Darstellung der Ressourcenbeziehungen hilft, Engpässe und Probleme schneller zu identifizieren.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Kombination von Volcano und Headlamp stellt eine signifikante Verbesserung für die Verwaltung von Batch-Workloads in Kubernetes dar. Diese Integration wird voraussichtlich die Effizienz in der Cloud-Native-Entwicklung weiter steigern und die Benutzerfreundlichkeit für \u003ca href=\"/kubernetes/\"\u003eDevOps\u003c/a\u003e\n Teams erhöhen.\u003c/p\u003e\n", "summary": "TL;DR Die Integration des Volcano-Plugins in die Headlamp-Oberfläche ermöglicht eine schnellere und effizientere Überprüfung von Batch-Workloads in Kubernetes . Durch die zentrale Darstellung von Jobs, Queues und PodGroups wird die Verwaltung und Fehlersuche in komplexen Workloads erheblich vereinfacht.\nHauptinhalt Volcano ist ein Cloud-Native Batch-Scheduler für Kubernetes, der speziell für Hochleistungsrechnen, künstliche Intelligenz, maschinelles Lernen und andere Batch-Workloads entwickelt wurde. Im Gegensatz zu den ursprünglichen Kubernetes-Anwendungen, die auf langlaufende Dienste ausgelegt sind, behandelt Volcano dynamisch ankommende Jobs, die um begrenzte Ressourcen konkurrieren und möglicherweise mehrere Worker benötigen, um nützliche Arbeit zu leisten.\n", "image": "https://ayedo.de/inspect-volcano-workloads-faster-with-headlamp.png", "date_published": "2026-06-25T20:00:00Z", "date_modified": "2026-06-25T20:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","operations","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/see-your-serverless-introducing-the-headlamp-plugin-for-knative/", "url": "https://ayedo.de/news/see-your-serverless-introducing-the-headlamp-plugin-for-knative/", "title": "Sieh dein Serverless: Einführung des Headlamp-Plugins für Knative", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDas Headlamp-Plugin für Knative ermöglicht eine umfassende Verwaltung und Überwachung von serverlosen Workloads in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n. Es integriert wichtige Funktionen wie KService-Management, Traffic-Splitting und Autoscaling-Konfiguration in einer benutzerfreundlichen Oberfläche, um den täglichen Betrieb zu erleichtern.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eHeadlamp ist ein Open-Source-Projekt, das als UI für \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n entwickelt wurde und es Nutzern ermöglicht, Cluster-Ressourcen zu erkunden, zu verwalten und zu debuggen. Knative hingegen bringt serverlose Workloads in Kubernetes und übernimmt Aufgaben wie Traffic-Routing, Autoscaling und Versionsverwaltung. Der Betrieb von Knative-Workloads kann jedoch komplex sein, da häufig zwischen verschiedenen Tools wie dem Kn CLI, kubectl und der Kubernetes UI gewechselt werden muss. Das neue Headlamp-Plugin für Knative zielt darauf ab, diese Lücke zu schließen, indem es eine zentrale Plattform bietet, um Workloads zu inspizieren, zu verstehen und zu verwalten.\u003c/p\u003e\n\u003cp\u003eDas Plugin ermöglicht eine Integration von Knative-Ressourcen in die Kartenansicht von Headlamp. Nutzer können die Beziehungen zwischen KServices, Revisions und DomainMappings in einer einzigen grafischen Darstellung sehen. KServices, als zentrale Ressource in Knative, verwalten den Lebenszyklus von Routen, Konfigurationen und Revisions. Das Plugin bietet eine detaillierte Ansicht der KServices und ermöglicht es, Traffic-Splits zu bearbeiten, Pods neu zu starten und Protokolle einzusehen. Wichtige Aktionen sind im Header sichtbar und abhängig von den aktuellen RBAC-Berechtigungen zugänglich.\u003c/p\u003e\n\u003cp\u003eEin weiteres zentrales Feature ist das Traffic-Splitting, das es ermöglicht, den Traffic über mehrere Revisions eines Dienstes zu verteilen. Dies ist besonders nützlich für Canary-Releases, schrittweise Rollouts und A/B-Tests. Das Plugin zeigt die Traffic-Zuweisung für jede Revision sowie deren Status und Konfiguration an. Änderungen an den Traffic-Prozentsätzen können direkt im Plugin vorgenommen werden, wobei eine Validierung sicherstellt, dass die Summe 100 % beträgt.\u003c/p\u003e\n\u003cp\u003eDas Plugin bietet außerdem Einblicke in die Autoscaling-Konfiguration. Knative unterstützt eine Vielzahl von Einstellungen, die in Kombination aus KService-spezifischen Anmerkungen und clusterweiten ConfigMaps abgeleitet werden. Das Plugin zeigt die effektiven Konfigurationen pro KService an, sodass Nutzer schnell erkennen können, ob eine Einstellung explizit konfiguriert oder auf die Cluster-Standardeinstellungen zurückfällt.\u003c/p\u003e\n\u003cp\u003eDie Integration mit Prometheus ermöglicht die Überwachung von Anforderungsraten, Latenz und Ressourcennutzung. Dies ist besonders hilfreich, um die Auswirkungen von Traffic-Splits in Echtzeit zu validieren. Zusätzlich bietet das Plugin Dashboard-Ansichten für andere CRDs wie Revisions, DomainMappings und eine Übersicht über das Networking auf Cluster-Ebene.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Installation des Knative-Plugins erfolgt über den Plugin-Katalog in Headlamp Desktop, nachdem Knative im Cluster installiert wurde. Die aktuelle Version des Plugins ist 0.3.0-beta. Nutzer sind eingeladen, Feedback zu geben und etwaige Probleme zu melden, um die Funktionalität weiter zu verbessern.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDas Headlamp-Plugin für Knative stellt eine bedeutende Erweiterung für die Verwaltung von serverlosen Workloads in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n dar und könnte den täglichen Betrieb für \u003ca href=\"/kubernetes/\"\u003eDevOps\u003c/a\u003e\n -Teams erheblich vereinfachen. Die kontinuierliche Weiterentwicklung und das Feedback von Nutzern werden entscheidend sein, um die Funktionalität weiter zu optimieren.\u003c/p\u003e\n", "summary": "TL;DR Das Headlamp-Plugin für Knative ermöglicht eine umfassende Verwaltung und Überwachung von serverlosen Workloads in Kubernetes . Es integriert wichtige Funktionen wie KService-Management, Traffic-Splitting und Autoscaling-Konfiguration in einer benutzerfreundlichen Oberfläche, um den täglichen Betrieb zu erleichtern.\nHauptinhalt Headlamp ist ein Open-Source-Projekt, das als UI für Kubernetes entwickelt wurde und es Nutzern ermöglicht, Cluster-Ressourcen zu erkunden, zu verwalten und zu debuggen. Knative hingegen bringt serverlose Workloads in Kubernetes und übernimmt Aufgaben wie Traffic-Routing, Autoscaling und Versionsverwaltung. Der Betrieb von Knative-Workloads kann jedoch komplex sein, da häufig zwischen verschiedenen Tools wie dem Kn CLI, kubectl und der Kubernetes UI gewechselt werden muss. Das neue Headlamp-Plugin für Knative zielt darauf ab, diese Lücke zu schließen, indem es eine zentrale Plattform bietet, um Workloads zu inspizieren, zu verstehen und zu verwalten.\n", "image": "https://ayedo.de/see-your-serverless-introducing-the-headlamp-plugin-for-knative.png", "date_published": "2026-06-25T18:00:00Z", "date_modified": "2026-06-25T18:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","software-delivery","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/eu-cyber-resilience-act-overview-requirements-and-timelines/", "url": "https://ayedo.de/news/eu-cyber-resilience-act-overview-requirements-and-timelines/", "title": "EU Cyber Resilience Act: Überblick, Anforderungen und Zeitrahmen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer EU Cyber Resilience Act (CRA) legt ab dem 11. Dezember 2027 verbindliche Sicherheitsstandards für Produkte mit digitalen Elementen fest, um die Cybersicherheit in der EU zu stärken. Ab dem 11. September 2026 müssen Hersteller aktive Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden melden. Die Regelung betrifft alle Hersteller und Anbieter von Software und Hardware, einschließlich \u003ca href=\"/kubernetes/\"\u003econtainerisierter Software\u003c/a\u003e\n.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDer EU Cyber Resilience Act (CRA) wurde am 10. Dezember 2024 eingeführt, um den wachsenden Bedrohungen durch Cyberangriffe zu begegnen und die grundlegenden Werte der EU zu schützen. Angesichts der steigenden Häufigkeit und Kosten von Cyberangriffen, die Produkte mit digitalen Elementen betreffen, stellt der CRA die erste umfassende Regelung zur Cybersicherheit für alle in Europa verkauften Hardware- und Softwareprodukte dar. Ein Bericht zeigt, dass 77 % der Unternehmen im vergangenen Jahr Vorfälle in der Lieferkette erlitten haben, was die Dringlichkeit dieser Regelung unterstreicht.\u003c/p\u003e\n\u003cp\u003eDie Vorschriften des CRA werden ab dem 11. Dezember 2027 vollständig wirksam, während die Verpflichtung zur Meldung von Schwachstellen bereits am 11. September 2026 in Kraft tritt. Für Entwickler und Anbieter von \u003ca href=\"/kubernetes/\"\u003econtainerisierter Software\u003c/a\u003e\n bedeutet dies, dass Praktiken wie die Erstellung von Software Bill of Materials (SBOM), die Offenlegung von Schwachstellen und die Härtung von Images von freiwilligen Best Practices zu rechtlichen Anforderungen werden.\u003c/p\u003e\n\u003cp\u003eDer CRA definiert Produkte mit digitalen Elementen als Software- oder Hardwareprodukte, einschließlich ihrer Fernverarbeitungslösungen und separat angebotener Komponenten. Diese weit gefasste Definition umfasst alles von IoT-Geräten bis hin zu Unternehmenssoftware-Plattformen und \u003ca href=\"/kubernetes/\"\u003eContainer-Images\u003c/a\u003e\n, die über Registries verteilt werden. Hersteller sind verpflichtet, Produkte sicher zu gestalten, Schwachstellen während des gesamten Produktlebenszyklus zu verwalten und Transparenz über die Softwarezusammensetzung zu bieten.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDer CRA stellt sicher, dass Hersteller vor der Markteinführung eines Produkts eine Bewertung durchführen, um die Einhaltung der Cybersicherheitsanforderungen zu garantieren. Nach dieser Bewertung können sie das CE-Zeichen anbringen und eine Konformitätserklärung beilegen. Nach der Markteinführung müssen Hersteller Schwachstellen im Produkt während seiner gesamten Lebensdauer verwalten und aktiv ausgenutzte Schwachstellen sowie schwerwiegende Vorfälle melden.\u003c/p\u003e\n\u003cp\u003eDie Regelung steht im Zusammenhang mit anderen EU-Vorgaben wie NIS2, die sich auf die Cybersicherheit wesentlicher und wichtiger Einrichtungen konzentriert. Während der CRA auf die Sicherheit von Produkten abzielt, regelt NIS2 die Sicherheit von Organisationen. Eine spezielle Prüfung wurde eingeführt, um zu bestimmen, wann Cloud-Komponenten unter den CRA fallen. Diese Prüfung umfasst die Bedingungen, ob die Verarbeitung remote erfolgt, ob das Produkt ohne diese Funktionalität seine Kernfunktion verlieren würde und ob der Hersteller für die Entwicklung oder Kontrolle dieser Komponente verantwortlich ist.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDer EU Cyber Resilience Act wird die Cybersicherheitslandschaft in Europa erheblich verändern und Hersteller sowie Anbieter vor neue Herausforderungen stellen. Unternehmen sollten sich frühzeitig auf die bevorstehenden Anforderungen vorbereiten, um die \u003ca href=\"/compliance/\"\u003eCompliance\u003c/a\u003e\n fristgerecht sicherzustellen.\u003c/p\u003e\n", "summary": "TL;DR Der EU Cyber Resilience Act (CRA) legt ab dem 11. Dezember 2027 verbindliche Sicherheitsstandards für Produkte mit digitalen Elementen fest, um die Cybersicherheit in der EU zu stärken. Ab dem 11. September 2026 müssen Hersteller aktive Schwachstellen und schwerwiegende Sicherheitsvorfälle innerhalb von 24 Stunden melden. Die Regelung betrifft alle Hersteller und Anbieter von Software und Hardware, einschließlich containerisierter Software .\nHauptinhalt Der EU Cyber Resilience Act (CRA) wurde am 10. Dezember 2024 eingeführt, um den wachsenden Bedrohungen durch Cyberangriffe zu begegnen und die grundlegenden Werte der EU zu schützen. Angesichts der steigenden Häufigkeit und Kosten von Cyberangriffen, die Produkte mit digitalen Elementen betreffen, stellt der CRA die erste umfassende Regelung zur Cybersicherheit für alle in Europa verkauften Hardware- und Softwareprodukte dar. Ein Bericht zeigt, dass 77 % der Unternehmen im vergangenen Jahr Vorfälle in der Lieferkette erlitten haben, was die Dringlichkeit dieser Regelung unterstreicht.\n", "image": "https://ayedo.de/eu-cyber-resilience-act-overview-requirements-and-timelines.png", "date_published": "2026-06-25T15:36:43Z", "date_modified": "2026-06-25T15:36:43Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","politics","cloud-native","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/building-a-cluster-aware-ai-agent-with-kubernetes-argo-cd-and-gitops/", "url": "https://ayedo.de/news/building-a-cluster-aware-ai-agent-with-kubernetes-argo-cd-and-gitops/", "title": "Erstellung eines clusterbewussten KI-Agenten mit Kubernetes, Argo CD und GitOps", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDer Artikel beschreibt die Implementierung eines clusterbewussten KI-Agenten innerhalb eines \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clusters\u003c/a\u003e\n, der ohne externe Cloud-Dienste betrieben wird. Der Agent verwendet lokale Daten und ein Large Language Model (LLM), um spezifische Diagnosen und Analysen durchzuführen, während die gesamte CI/CD-Pipeline durch GitHub Actions und \u003ca href=\"/kubernetes/\"\u003eArgo CD\u003c/a\u003e\n gesteuert wird.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung eines clusterbewussten KI-Agenten stellt einen innovativen Ansatz dar, um KI-Funktionalitäten direkt innerhalb eines \u003ca href=\"/kubernetes/\"\u003eKubernetes-Clusters\u003c/a\u003e\n zu implementieren. Im Gegensatz zu herkömmlichen „AI for Kubernetes“-Tools, die externe SaaS-Dienste nutzen, bleibt hier alle Daten im Cluster. Der Agent beobachtet den aktuellen Zustand des Clusters über die Kubernetes-API und nutzt ein lokales LLM, um fundierte Entscheidungen zu treffen.\u003c/p\u003e\n\u003cp\u003eDie Architektur des Systems besteht aus zwei Hauptkomponenten: einer CI/CD-Kette und der Kubernetes-Laufzeitumgebung. Auf der Laufzeitseite bedient ein Ollama-Pod ein lokal gehostetes Mistral 7B Modell, während ein FastAPI-Pod die HTTP-API des Agenten und die Benutzeroberfläche bereitstellt. Ein PersistentVolumeClaim speichert die Modellgewichte, um wiederholte Downloads zu vermeiden. Der Agent ist so konzipiert, dass er nur Leserechte auf Cluster-Ressourcen hat, was bedeutet, dass er keine Änderungen am Cluster vornehmen kann.\u003c/p\u003e\n\u003cp\u003eDie CI/CD-Pipeline wird durch Änderungen im Git-Repository ausgelöst, die GitHub Actions aktivieren, um ein Multi-Architektur-Image zu erstellen. Der \u003ca href=\"/kubernetes/\"\u003eArgo CD\u003c/a\u003e\n Image Updater überwacht Docker Hub auf neue Tags und aktualisiert die kustomization.yaml im Repository, was schließlich zu einer Aktualisierung des Clusters führt. Diese Entkopplung der Komponenten sorgt dafür, dass GitHub Actions und Argo CD unabhängig voneinander arbeiten können, während sie dennoch eine einheitliche Quelle der Wahrheit bewahren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung eines clusterbewussten KI-Agenten bietet mehrere Vorteile für Plattformingenieure. Die Möglichkeit, live Cluster-Daten zu lesen und zu analysieren, führt zu präziseren und umsetzbaren Diagnosen. Der Agent unterscheidet sich grundlegend von einem typischen LLM, das lediglich auf trainierten Daten basiert. Während ein LLM allgemeine Antworten liefern kann, bietet der Agent spezifische Informationen, die auf dem aktuellen Zustand des Clusters basieren.\u003c/p\u003e\n\u003cp\u003eDie Verwendung von GitOps für die Verwaltung von Prompts, Modellwahl und RBAC ermöglicht eine vollständige Nachvollziehbarkeit und Auditing der Agentenaktivitäten. Diese Transparenz kann die Sicherheits- und \u003ca href=\"/compliance/\"\u003eCompliance-Anforderungen\u003c/a\u003e\n in vielen Organisationen unterstützen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung eines clusterbewussten KI-Agenten innerhalb von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n zeigt das Potenzial für verbesserte Effizienz und Sicherheit bei der Nutzung von KI in Cloud-Umgebungen. Zukünftige Entwicklungen könnten die Integration weiterer KI-Funktionalitäten und eine Erweiterung des Modells zur Unterstützung komplexerer Anwendungsfälle umfassen.\u003c/p\u003e\n", "summary": "TL;DR Der Artikel beschreibt die Implementierung eines clusterbewussten KI-Agenten innerhalb eines Kubernetes-Clusters , der ohne externe Cloud-Dienste betrieben wird. Der Agent verwendet lokale Daten und ein Large Language Model (LLM), um spezifische Diagnosen und Analysen durchzuführen, während die gesamte CI/CD-Pipeline durch GitHub Actions und Argo CD gesteuert wird.\nHauptinhalt Die Entwicklung eines clusterbewussten KI-Agenten stellt einen innovativen Ansatz dar, um KI-Funktionalitäten direkt innerhalb eines Kubernetes-Clusters zu implementieren. Im Gegensatz zu herkömmlichen „AI for Kubernetes“-Tools, die externe SaaS-Dienste nutzen, bleibt hier alle Daten im Cluster. Der Agent beobachtet den aktuellen Zustand des Clusters über die Kubernetes-API und nutzt ein lokales LLM, um fundierte Entscheidungen zu treffen.\n", "image": "https://ayedo.de/building-a-cluster-aware-ai-agent-with-kubernetes-argo-cd-and-gitops.png", "date_published": "2026-06-25T11:25:00Z", "date_modified": "2026-06-25T11:25:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","software-delivery","development","docker"], "language": "de" },{ "id": "https://ayedo.de/news/spotlight-on-wg-device-management/", "url": "https://ayedo.de/news/spotlight-on-wg-device-management/", "title": "Im Fokus: WG Device Management", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie zunehmende Nutzung von KI, Edge- und Telekommunikationsanwendungen auf \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n erfordert eine verbesserte Hardwareverwaltung. Die Device Management Working Group hat das Dynamic Resource Allocation (DRA)-Projekt entwickelt, das nun in den allgemeinen verfügbaren Status übergegangen ist und eine strukturierte Herangehensweise an die Verwaltung spezialisierter Hardware bietet.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie Device Management Working Group wurde gegründet, um die Konfiguration, den Austausch und die Zuweisung von spezialisierten Hardwarekomponenten wie GPUs, TPUs und FPGAs in \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Umgebungen zu optimieren. Traditionell wurde die Hardwareverwaltung in Kubernetes über die Device Plugin API abgewickelt, die jedoch als unzureichend angesehen wird, da sie Geräte als undurchsichtige Ganzzahlen behandelt. Dies bedeutet, dass Nutzer lediglich angeben können, wie viele GPUs sie benötigen, ohne spezifische Anforderungen an die Hardware oder deren Verknüpfung zu formulieren.\u003c/p\u003e\n\u003cp\u003eDas DRA-Projekt hat sich als Antwort auf diese Herausforderungen entwickelt und bietet eine strukturierte Methode zur Verwaltung von Hardware-Ressourcen. Es gliedert den Prozess in vier Phasen: Modellierung, Anforderung, Planung und Aktivierung. In der Modellierungsphase verwenden Anbieter die ResourceSlice API, um die detaillierten Fähigkeiten und Kapazitäten ihrer Hardware zu kommunizieren. In der Anforderungsphase definieren Nutzer ihre spezifischen Hardwarebedürfnisse über die ResourceClaim API. Die Planungsphase ermöglicht es dem \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Scheduler, die Anforderungen der Workloads intelligent mit den verfügbaren Hardware-Ressourcen abzugleichen. Schließlich wird in der Aktivierungsphase der „Handshake“ durchgeführt, um das Gerät für die Nutzung durch das Pod vorzubereiten und zu sichern.\u003c/p\u003e\n\u003cp\u003eDie Co-Vorsitzenden der Working Group, Kevin Klues von NVIDIA, Patrick Ohly von Intel und John Belamaric von Google, haben gemeinsam an der Entwicklung von DRA gearbeitet. Sie betonen, dass die Notwendigkeit für diese Verbesserungen durch die Herausforderungen bei der Nutzung von externen Beschleunigern entstanden ist. Der Übergang von einer einfachen Integer-Darstellung zu einem strukturierten Modell ermöglicht eine präzisere und flexiblere Nutzung von Hardware-Ressourcen in Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Einführung von DRA könnte tiefgreifende Auswirkungen auf die Art und Weise haben, wie \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n-Cluster konfiguriert und verwaltet werden. Die Möglichkeit, spezialisierte Hardware granular zu beschreiben und zu verwalten, könnte die Effizienz und Leistung von Anwendungen, die auf diese Ressourcen angewiesen sind, erheblich steigern. Zudem könnte die verbesserte Planung und Zuweisung von Ressourcen die Komplexität verringern und die Autoskalierung von Anwendungen erleichtern.\u003c/p\u003e\n\u003cp\u003eEin weiterer wichtiger Aspekt ist die Interoperabilität der neuen APIs mit bestehenden Kubernetes-Architekturen. Die erfolgreiche Integration von DRA wird davon abhängen, wie gut die Community diese neuen Ansätze annimmt und implementiert.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Fortschritte im Bereich des Device Managements, insbesondere durch das DRA-Projekt, markieren einen wichtigen Schritt in der Evolution von \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n als Plattform für moderne, hardwareintensive Anwendungen. Die Entwicklungen in diesem Bereich werden weiterhin beobachtet, da sie potenziell die Effizienz und Flexibilität von Cloud-nativen Architekturen erheblich verbessern können.\u003c/p\u003e\n", "summary": "TL;DR Die zunehmende Nutzung von KI, Edge- und Telekommunikationsanwendungen auf Kubernetes erfordert eine verbesserte Hardwareverwaltung. Die Device Management Working Group hat das Dynamic Resource Allocation (DRA)-Projekt entwickelt, das nun in den allgemeinen verfügbaren Status übergegangen ist und eine strukturierte Herangehensweise an die Verwaltung spezialisierter Hardware bietet.\nHauptinhalt Die Device Management Working Group wurde gegründet, um die Konfiguration, den Austausch und die Zuweisung von spezialisierten Hardwarekomponenten wie GPUs, TPUs und FPGAs in Kubernetes -Umgebungen zu optimieren. Traditionell wurde die Hardwareverwaltung in Kubernetes über die Device Plugin API abgewickelt, die jedoch als unzureichend angesehen wird, da sie Geräte als undurchsichtige Ganzzahlen behandelt. Dies bedeutet, dass Nutzer lediglich angeben können, wie viele GPUs sie benötigen, ohne spezifische Anforderungen an die Hardware oder deren Verknüpfung zu formulieren.\n", "image": "https://ayedo.de/spotlight-on-wg-device-management.png", "date_published": "2026-06-24T18:00:00Z", "date_modified": "2026-06-24T18:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["kubernetes","cloud-native","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/from-awareness-to-engineered-accessibility-in-open-source/", "url": "https://ayedo.de/news/from-awareness-to-engineered-accessibility-in-open-source/", "title": "Von Bewusstsein zu geplanter Zugänglichkeit in Open Source", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Diskussion um Zugänglichkeit im Open-Source-Bereich hat sich weiterentwickelt, von individueller Anpassung hin zu einem systematischen Ansatz, der kognitive Barrieren im Design adressiert. Die Neurodiversity-Community hat sich darauf konzentriert, die Herausforderungen neurodivergenter Mitwirkender zu identifizieren und Lösungen zu entwickeln, die die Zusammenarbeit verbessern und die Inklusion fördern.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDas Open-Source-Ökosystem bietet die Möglichkeit, dass jeder jederzeit beitragen kann, doch in der Praxis stoßen viele auf unsichtbare Barrieren. Diese Barrieren entstehen durch Annahmen in der Dokumentation, Kommunikationsnormen und Governance-Strukturen, die nicht für alle Benutzergruppen geeignet sind. Die Neurodiversity-Community hat sich gebildet, um neurodivergente Mitwirkende und deren Verbündete zu unterstützen und auf die Herausforderungen aufmerksam zu machen, die diese Barrieren mit sich bringen.\u003c/p\u003e\n\u003cp\u003eIn den vergangenen Jahren hat sich die Diskussion um Zugänglichkeit in der \u003ca href=\"/cloud-native/\"\u003eCloud-Native-Community\u003c/a\u003e\n von einer individuellen Perspektive hin zu einem systematischen Ansatz gewandelt. Bei der KubeCon + CloudNativeCon North America 2025 in Atlanta wurden grundlegende Konzepte zur Neurodiversität in Engineering-Teams vorgestellt. Der Fokus lag darauf, wie kognitive Unterschiede wie ADHS, Autismus und Dyslexie in verteilten Engineering-Umgebungen sichtbar werden können. Es wurde betont, dass asynchrone Kommunikationsmuster, wie schriftliche Spezifikationen und strukturierte RFCs, als potenzielle Gleichmacher fungieren können, wenn klare Erwartungen an Reaktionszeiten und Tonfall definiert sind.\u003c/p\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon Europe 2026 in Amsterdam brachte eine weitere Vertiefung der Diskussion. Der Fokus lag hier auf dem Aufbau von Peer-Mentorship-Netzwerken, die erfahrene neurodivergente Maintainer mit neuen Mitwirkenden verbinden, um praktische Ansätze zur Bewältigung von Stress und zur Verbesserung der Zusammenarbeit zu teilen. Zudem wurden \u0026ldquo;Wie man mit mir arbeitet\u0026rdquo;-Leitfäden gefördert, um soziale Unsicherheiten in verteilten Teams zu reduzieren.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung von Zugänglichkeit im Open-Source-Bereich wird zunehmend als architektonische Verantwortung betrachtet, die von allen Beteiligten getragen werden muss. Die Implementierung von strukturierten Unterstützungsmechanismen und klaren Kommunikationsrichtlinien kann nicht nur die Inklusion fördern, sondern auch die Qualität und Effizienz von Projekten steigern. Indem die Community ein Umfeld schafft, das unterschiedliche kognitive Stile anerkennt und fördert, können innovative Problemlösungen und neue Perspektiven in den Entwicklungsprozess integriert werden. Die Nutzung von \u003ca href=\"/kubernetes/\"\u003eContainer\u003c/a\u003e\n und \u003ca href=\"/kubernetes/\"\u003eKubernetes\u003c/a\u003e\n kann dabei helfen, diese Ziele zu erreichen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Veränderungen in der Diskussion um Zugänglichkeit im Open-Source-Bereich zeigen, dass ein systematischer Ansatz notwendig ist, um kognitive Barrieren abzubauen. Die fortlaufende Entwicklung und Implementierung solcher Strategien wird entscheidend sein, um eine inklusivere und produktivere Community zu schaffen.\u003c/p\u003e\n", "summary": "TL;DR Die Diskussion um Zugänglichkeit im Open-Source-Bereich hat sich weiterentwickelt, von individueller Anpassung hin zu einem systematischen Ansatz, der kognitive Barrieren im Design adressiert. Die Neurodiversity-Community hat sich darauf konzentriert, die Herausforderungen neurodivergenter Mitwirkender zu identifizieren und Lösungen zu entwickeln, die die Zusammenarbeit verbessern und die Inklusion fördern.\nHauptinhalt Das Open-Source-Ökosystem bietet die Möglichkeit, dass jeder jederzeit beitragen kann, doch in der Praxis stoßen viele auf unsichtbare Barrieren. Diese Barrieren entstehen durch Annahmen in der Dokumentation, Kommunikationsnormen und Governance-Strukturen, die nicht für alle Benutzergruppen geeignet sind. Die Neurodiversity-Community hat sich gebildet, um neurodivergente Mitwirkende und deren Verbündete zu unterstützen und auf die Herausforderungen aufmerksam zu machen, die diese Barrieren mit sich bringen.\n", "image": "https://ayedo.de/from-awareness-to-engineered-accessibility-in-open-source.png", "date_published": "2026-06-24T11:32:00Z", "date_modified": "2026-06-24T11:32:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/what-is-an-sbom-and-why-cant-you-ship-without-one/", "url": "https://ayedo.de/news/what-is-an-sbom-and-why-cant-you-ship-without-one/", "title": "Was ist ein SBOM (und warum kannst du ohne keinen Release versenden)?", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eEin Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareartefakts und spielt eine entscheidende Rolle in der Sicherheit der Software-Lieferkette. Trotz der erkannten Vorteile in der Schwachstellenbewältigung haben viele Organisationen Schwierigkeiten bei der Erstellung von SBOMs. Regulierungen machen SBOMs zunehmend zu einer Voraussetzung für den Softwarevertrieb.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eEin SBOM ist eine strukturierte Auflistung aller Komponenten, Bibliotheken und Module, die in einem Softwareartefakt enthalten sind. Bei \u003ca href=\"/kubernetes/\"\u003econtainerisierten Anwendungen\u003c/a\u003e\n, wie beispielsweise einem auf Alpine Linux basierenden Containerbild, sind zahlreiche Systempakete und deren Abhängigkeiten beteiligt. Ein SBOM beantwortet die grundlegende Frage, welche Software tatsächlich in der Produktion läuft. Es erfasst die gesamte Abhängigkeitsstruktur und enthält wichtige Metadaten zu jeder Komponente, wie Version, Lizenz und Herkunft.\u003c/p\u003e\n\u003cp\u003eEin gut strukturiertes SBOM umfasst mehrere Kategorien von Metadaten für jede Komponente:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eKomponentenidentität\u003c/strong\u003e: Name, Version und Anbieter der Software (z.B. openssl 3.1.4, verwaltet vom OpenSSL-Projekt).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eLizenzierung\u003c/strong\u003e: Art der Lizenz, die die Weiterverbreitung und Nutzung regelt (z.B. MIT, Apache 2.0, GPL).\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAbhängigkeitsbeziehungen\u003c/strong\u003e: Wie Komponenten voneinander abhängen, einschließlich direkter und transformativer Abhängigkeiten.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eEindeutige Identifikatoren\u003c/strong\u003e: Paket-URLs oder SWID-Tags, die eine Kreuzreferenzierung mit Schwachdatenbanken ermöglichen.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrüfziffern und Hashes\u003c/strong\u003e: Kryptographische Hashes, die bestätigen, dass die Komponente nicht verändert wurde.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDie Daten werden unter Verwendung offener Standards, hauptsächlich SPDX oder CycloneDX, strukturiert, um maschinenlesbar und interoperabel zu sein.\u003c/p\u003e\n\u003cp\u003eSBOMs sind besonders wichtig für die Sicherheit der Software-Lieferkette. Bei der Offenlegung von Schwachstellen, wie der Log4Shell-Sicherheitsanfälligkeit, konnten Organisationen mit aktuellen SBOMs schnell identifizieren, welche Images betroffen waren. Ohne SBOMs mussten Teams oft manuell Abhängigkeiten verfolgen, was zeitaufwendig und fehleranfällig ist.\u003c/p\u003e\n\u003cp\u003eEin SBOM ermöglicht eine schnellere Reaktion auf Sicherheitsvorfälle. Bei der Entdeckung einer neuen CVE (Common Vulnerability and Exposure) kann sofort ermittelt werden, wo das Unternehmen exponiert ist. Dies geschieht durch den Abgleich des betroffenen Pakets und der Version mit der SBOM-Bibliothek, was die Reaktionszeit erheblich verkürzt. In Kombination mit kontinuierlichem Schwachstellenscanning wird dieser Prozess weiter automatisiert.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung von SBOMs wird durch neue regulatorische Vorgaben vorangetrieben. In den USA hat die Executive Order 14028 Anforderungen für SBOMs für Software, die an Bundesbehörden verkauft wird, festgelegt. Dies zeigt, dass SBOMs nicht nur eine bewährte Praxis, sondern zunehmend auch eine gesetzliche Anforderung werden. Organisationen, die SBOMs in ihrem Entwicklungs- und Bereitstellungsprozess integrieren, können nicht nur ihre Sicherheitslage verbessern, sondern auch \u003ca href=\"/compliance/\"\u003eCompliance-Anforderungen\u003c/a\u003e\n erfüllen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von SBOMs in den Softwareentwicklungsprozess ist entscheidend für die Sicherheit und Transparenz in der Software-Lieferkette. Angesichts der zunehmenden regulatorischen Anforderungen wird die Fähigkeit, SBOMs effektiv zu generieren und zu verwalten, für Unternehmen von zentraler Bedeutung sein.\u003c/p\u003e\n", "summary": "TL;DR Ein Software Bill of Materials (SBOM) ist ein maschinenlesbares Inventar aller Komponenten eines Softwareartefakts und spielt eine entscheidende Rolle in der Sicherheit der Software-Lieferkette. Trotz der erkannten Vorteile in der Schwachstellenbewältigung haben viele Organisationen Schwierigkeiten bei der Erstellung von SBOMs. Regulierungen machen SBOMs zunehmend zu einer Voraussetzung für den Softwarevertrieb.\nHauptinhalt Ein SBOM ist eine strukturierte Auflistung aller Komponenten, Bibliotheken und Module, die in einem Softwareartefakt enthalten sind. Bei containerisierten Anwendungen , wie beispielsweise einem auf Alpine Linux basierenden Containerbild, sind zahlreiche Systempakete und deren Abhängigkeiten beteiligt. Ein SBOM beantwortet die grundlegende Frage, welche Software tatsächlich in der Produktion läuft. Es erfasst die gesamte Abhängigkeitsstruktur und enthält wichtige Metadaten zu jeder Komponente, wie Version, Lizenz und Herkunft.\n", "image": "https://ayedo.de/what-is-an-sbom-and-why-cant-you-ship-without-one.png", "date_published": "2026-06-23T16:48:20Z", "date_modified": "2026-06-23T16:48:20Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["docker","security","cloud-native","software-delivery","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/agent-auth-a-lawyers-day-in-court/", "url": "https://ayedo.de/news/agent-auth-a-lawyers-day-in-court/", "title": "Agent Auth: Ein Tag im Gericht für Anwälte", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eAgenten in KI-Systemen benötigen eine ausgeklügelte Authentifizierung und Autorisierung, um im Namen von Benutzern zu agieren. Die Implementierung einer Agentenplattform erfordert starke Identitätsverwaltung, Delegationstokens und die Durchsetzung von Richtlinien, um die Sicherheit und Nachvollziehbarkeit der Aktionen zu gewährleisten.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eKünstliche Intelligenz (KI) Agenten können als erweiterte Mikroservices betrachtet werden, die zusätzliche Anforderungen an Authentifizierung, Richtlinien und Beobachtbarkeit stellen. Diese Agenten agieren im Namen verschiedener Benutzer, was eine präzise Identitätsverwaltung erfordert. Die Identität des Agenten sowie die Identität des Benutzers, für den der Agent tätig ist, müssen klar definiert und verifiziert werden.\u003c/p\u003e\n\u003cp\u003eEin anschauliches Beispiel zur Veranschaulichung dieser Konzepte ist die Analogie zu einem Anwalt, der einen Mandanten vor Gericht vertritt. Der Anwalt muss zunächst seine Identität nachweisen, was der Agentenidentität entspricht. Anschließend muss er darlegen, für wen er tätig ist, was der Identität des Mandanten entspricht. Der Anwalt präsentiert dann Dokumente, die seine Berechtigung zur Vertretung des Mandanten in diesem speziellen Fall belegen. In Agentensystemen erfolgt dies häufig durch ein On-Behalf-Of (OBO) Token, das Informationen über die Identität des Mandanten, die Identität des Agenten sowie die delegierten Berechtigungen und den Umfang der Delegation enthält.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus ist es entscheidend, dass die Agenten nicht nur über gültige Delegationen verfügen, sondern dass auch die angeforderten Aktionen den geltenden Richtlinien entsprechen. Dies erfordert eine umfassende \u003ca href=\"/compliance/\"\u003eRichtlinieneinhaltung\u003c/a\u003e\n, um sicherzustellen, dass die Berechtigungen nicht missbraucht werden.\u003c/p\u003e\n\u003cp\u003eUm diese Komplexität zu bewältigen, benötigt eine Agentenplattform eine robuste Infrastruktur, die folgende Funktionen bereitstellt:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eEtablierung starker Agentenidentitäten\u003c/li\u003e\n\u003cli\u003eÜbertragung von Mandantenidentitäten über Anfragen hinweg\u003c/li\u003e\n\u003cli\u003eAusgabe und Validierung von Delegationstokens\u003c/li\u003e\n\u003cli\u003eDurchsetzung von Autorisierungsrichtlinien und -bereichen\u003c/li\u003e\n\u003cli\u003eBereitstellung von Nachverfolgbarkeit und Audit-Protokollen für Agentenaktionen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEin KI-natives Gateway spielt hierbei eine zentrale Rolle. Anstatt dass jeder Agent unabhängig Identitätspropagation, Delegationsüberprüfung, Richtlinieneinhaltung und Auditing implementiert, können diese Funktionen zentralisiert werden. Das Agenten-Gateway und das Mesh agieren als zentrale Stelle, die sicherstellt, dass Identitäten verifiziert, Delegationen gültig, Richtlinien durchgesetzt und Aktionen nachvollziehbar sind.\u003c/p\u003e\n\u003cp\u003eDurch die Kombination mit bestehenden Technologien wie SPIFFE, cert-manager, Istio und agentgateway kann eine Agentenplattform geschaffen werden, die es Agenten ermöglicht, sich auf die Geschäftslogik zu konzentrieren, während die Plattform sich um Identität, Delegation, Richtlinieneinhaltung und Beobachtbarkeit kümmert. Eine solche Plattform könnte auch in einer \u003ca href=\"/kubernetes/\"\u003ecloud-native\u003c/a\u003e\n Umgebung implementiert werden, um die Flexibilität und Skalierbarkeit zu erhöhen.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Implementierung einer Agentenplattform erfordert nicht nur technisches Fachwissen, sondern auch ein tiefes Verständnis für Sicherheitsarchitekturen. Starke Identitätsmanagement- und Authentifizierungsmechanismen sind entscheidend, um die Integrität und Sicherheit der Agenteninteraktionen zu gewährleisten. Zudem müssen Richtlinien dynamisch verwaltet und anpassbar sein, um den sich ständig ändernden Anforderungen gerecht zu werden.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung von Agenten in KI-Systemen erfordert eine präzise Authentifizierung und Autorisierung, um die Sicherheit und Nachvollziehbarkeit zu gewährleisten. Zukünftige Entwicklungen könnten weitere Optimierungen in der Interoperabilität und Effizienz der Agentenplattformen ermöglichen.\u003c/p\u003e\n", "summary": "TL;DR Agenten in KI-Systemen benötigen eine ausgeklügelte Authentifizierung und Autorisierung, um im Namen von Benutzern zu agieren. Die Implementierung einer Agentenplattform erfordert starke Identitätsverwaltung, Delegationstokens und die Durchsetzung von Richtlinien, um die Sicherheit und Nachvollziehbarkeit der Aktionen zu gewährleisten.\nHauptinhalt Künstliche Intelligenz (KI) Agenten können als erweiterte Mikroservices betrachtet werden, die zusätzliche Anforderungen an Authentifizierung, Richtlinien und Beobachtbarkeit stellen. Diese Agenten agieren im Namen verschiedener Benutzer, was eine präzise Identitätsverwaltung erfordert. Die Identität des Agenten sowie die Identität des Benutzers, für den der Agent tätig ist, müssen klar definiert und verifiziert werden.\n", "image": "https://ayedo.de/agent-auth-a-lawyers-day-in-court.png", "date_published": "2026-06-23T11:00:00Z", "date_modified": "2026-06-23T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","security","development","kubernetes","digital-sovereignty"], "language": "de" },{ "id": "https://ayedo.de/news/building-jaegers-clickhouse-backend-8-6x-compression-on-10-million-spans/", "url": "https://ayedo.de/news/building-jaegers-clickhouse-backend-8-6x-compression-on-10-million-spans/", "title": "Aufbau von Jaegers ClickHouse-Backend: 8,6× Kompression bei 10 Millionen Spans", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie Integration von ClickHouse in Jaeger v2.18.0 ermöglicht eine effiziente Speicherung und Abfrage von Tracedaten mit einer beeindruckenden Kompression von 8,6×. ClickHouse, als spaltenorientierte OLAP-Datenbank, bietet hohe Schreibgeschwindigkeiten und schnelle analytische Abfragen, was insbesondere für die Überwachung komplexer Microservices von Bedeutung ist.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eJaeger, eine verteilte Tracing-Plattform der \u003ca href=\"https://cncf.io/\" target=\"_blank\" rel=\"noopener\"\u003eCloud Native Computing Foundation\u003c/a\u003e\n (CNCF), hat mit der Version 2.18.0 die Unterstützung für \u003ca href=\"/kubernetes/\"\u003eClickHouse\u003c/a\u003e\n eingeführt. Diese Entscheidung basiert auf den wiederholten Anfragen der Nutzer nach einer leistungsfähigen Speicherlösung für Tracedaten. ClickHouse ist speziell für die Anforderungen von Telemetrie und Big Data ausgelegt, indem es große, append-only Schreibströme effizient verarbeiten und komplexe analytische Aggregationen in Millisekunden durchführen kann.\u003c/p\u003e\n\u003cp\u003eDie Hauptproblematik beim Tracing besteht darin, große Mengen semi-strukturierter Ereignisdaten zu speichern und diese schnell nach verschiedenen Dimensionen zu durchsuchen. Bisherige Lösungen wie Cassandra und Elasticsearch haben ihre Dienste geleistet, bringen jedoch hohe operationale Kosten und Komplexität beim Skalieren mit sich. ClickHouse hingegen bietet eine spaltenorientierte Speicherung, die sich besonders gut für die repetitiven Muster von Tracedaten eignet. Diese Wiederholungen, wie etwa häufige Dienstnamen und Statuscodes, werden durch die spaltenorientierte Struktur optimal komprimiert.\u003c/p\u003e\n\u003cp\u003eEin bemerkenswerter Vorteil von ClickHouse ist die signifikante Kompression der Tracedaten. In Benchmarks wurde ein Kompressionsverhältnis von 8,6× auf der Spans-Tabelle erreicht, was vor allem auf die Wiederholung von Werten in den Spalten zurückzuführen ist. Diese Effizienz ermöglicht es, Tracedaten nicht nur zu speichern, sondern auch in Echtzeit zu analysieren. Jaeger v2.18.0 bietet nun native ClickHouse-Methoden zur Leistungsüberwachung, die es Teams erlauben, zentrale Gesundheits- und Leistungsmetriken direkt aus ihren Tracedaten zu generieren, ohne auf externe Metrik-Pipelines angewiesen zu sein.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung des Schemas für ClickHouse war eine komplexe Aufgabe, da es optimiert werden musste für die häufigsten Abfragemuster von Jaeger, wie die Suche nach Trace-IDs, Service- und Operationsnamen sowie Zeitbereichsabfragen. Die Wahl des Primärschlüssels ist entscheidend, da dieser nicht nur die Sortierreihenfolge auf der Festplatte definiert, sondern auch die Effizienz der Abfragen beeinflusst. Es standen zwei Strategien zur Auswahl: eine Optimierung für die Rückgabe von Traces oder eine Optimierung für Suchanfragen. Letztendlich wurde die Entscheidung getroffen, den Primärschlüssel nach (service_name, name, start_time) zu sortieren, um die Suchperformance zu verbessern, was jedoch die Rückgabe von Traces beeinträchtigen kann.\u003c/p\u003e\n\u003cp\u003eDarüber hinaus wurde das Schema so gestaltet, dass es den Anforderungen des \u003ca href=\"/compliance/\"\u003eOpenTelemetry-Datenmodells\u003c/a\u003e\n entspricht, was zusätzliche Anpassungen erforderte. Diese Entscheidungen sind in einem detaillierten Dokument festgehalten, das die Architekturentscheidungen für die Implementierung von ClickHouse in Jaeger beschreibt.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Integration von ClickHouse in Jaeger stellt einen bedeutenden Fortschritt für die Speicherung und Analyse von Tracedaten dar. Mit dieser neuen Architektur können Teams ihre Microservices effektiver überwachen und die Effizienz ihrer Datenanalysen erheblich steigern. Die kontinuierliche Entwicklung und Optimierung dieser Technologien wird entscheidend sein, um den steigenden Anforderungen an die Überwachung komplexer Systeme gerecht zu werden.\u003c/p\u003e\n", "summary": "TL;DR Die Integration von ClickHouse in Jaeger v2.18.0 ermöglicht eine effiziente Speicherung und Abfrage von Tracedaten mit einer beeindruckenden Kompression von 8,6×. ClickHouse, als spaltenorientierte OLAP-Datenbank, bietet hohe Schreibgeschwindigkeiten und schnelle analytische Abfragen, was insbesondere für die Überwachung komplexer Microservices von Bedeutung ist.\nHauptinhalt Jaeger, eine verteilte Tracing-Plattform der Cloud Native Computing Foundation (CNCF), hat mit der Version 2.18.0 die Unterstützung für ClickHouse eingeführt. Diese Entscheidung basiert auf den wiederholten Anfragen der Nutzer nach einer leistungsfähigen Speicherlösung für Tracedaten. ClickHouse ist speziell für die Anforderungen von Telemetrie und Big Data ausgelegt, indem es große, append-only Schreibströme effizient verarbeiten und komplexe analytische Aggregationen in Millisekunden durchführen kann.\n", "image": "https://ayedo.de/building-jaegers-clickhouse-backend-8-6x-compression-on-10-million-spans.png", "date_published": "2026-06-23T11:00:00Z", "date_modified": "2026-06-23T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","development","kubernetes","digital-sovereignty","software-delivery"], "language": "de" },{ "id": "https://ayedo.de/news/telemetry-that-matters-designing-sustainable-high-impact-observability-pipelines/", "url": "https://ayedo.de/news/telemetry-that-matters-designing-sustainable-high-impact-observability-pipelines/", "title": "Telemetrie, die zählt: Nachhaltige, wirkungsvolle Observability-Pipelines entwerfen", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie zunehmende Komplexität von Systemarchitekturen führt zu einer Überflutung mit Telemetriedaten, die oft nicht sinnvoll genutzt werden. Um nachhaltige und effektive Observability-Pipelines zu schaffen, sollten Teams gezielt definieren, welche Metriken notwendig sind, um die Systemgesundheit zu überwachen und Vorfälle schnell zu analysieren. Der Übergang zu einem \u003ca href=\"/kubernetes/\"\u003eObservability-Mesh\u003c/a\u003e\n und die Abwägung zwischen automatischer und manueller Instrumentierung sind entscheidend für den Erfolg.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie \u003ca href=\"/kubernetes/\"\u003eCloud-native\u003c/a\u003e\n Gemeinschaft steht vor der Herausforderung, dass die Erfassung von Telemetriedaten oft zu einer Überflutung mit Informationen führt, die nicht alle von Bedeutung sind. Historisch gesehen war die Strategie, alles zu instrumentieren und später herauszufiltern, weit verbreitet. Studien zeigen jedoch, dass etwa 50 % der gesammelten Metriken niemals abgefragt oder genutzt werden. Diese unkontrollierte Datensammlung führt nicht nur zu höheren Speicherkosten, sondern auch zu einer erhöhten Komplexität und Belastung für die Ingenieure, insbesondere während aktiver Vorfälle.\u003c/p\u003e\n\u003cp\u003eEin oft übersehener Aspekt ist die „grüne“ Observability. Jede gespeicherte, indizierte und verarbeitete Metrik verbraucht Ressourcen, was nicht nur Kosten verursacht, sondern auch den ökologischen Fußabdruck der Cloud-nativen Plattformen erhöht. Daher ist es wichtig, Observability als ein zentrales Designkriterium von Anfang an zu betrachten. Teams sollten klar definieren, wie ein gesundes System aussieht und welche Signale erforderlich sind, um strukturelle Abweichungen zu erkennen, bevor Code in die Produktion geht.\u003c/p\u003e\n\u003cp\u003eIm Falle eines Produktionsvorfalls ist es entscheidend, nicht alle Daten zu betrachten, sondern gezielt die Informationen zu finden, die notwendig sind, um die Auswirkungen auf die Nutzer schnell zu bewerten und die Ursache zu lokalisieren. Moderne Frameworks wie \u003ca href=\"/kubernetes/\"\u003eOpenTelemetry\u003c/a\u003e\n helfen dabei, diese Datenpunkte in zentrale Signale zu organisieren: Traces, Metriken, Logs und Profile. Anstatt diese Elemente isoliert zu betrachten, bewegt sich die Gemeinschaft hin zu einem Observability-Mesh, in dem Metriken direkt auf Traces verweisen, Traces relevante Logs einbetten und Logs auf Ressourcenprofile zurückgreifen. Diese Vernetzung reduziert den Aufwand für Kontextwechsel erheblich.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Erzeugung und Verarbeitung dieser Daten erfordert standardisierte Schichten, einschließlich semantischer Konventionen für einheitliche Labels, API-Einstiegspunkte und offene Protokolle wie OTLP. Bei der Instrumentierung von Anwendungen müssen Teams zwischen automatischer und manueller Instrumentierung abwägen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eZero-Code Instrumentierung\u003c/strong\u003e ermöglicht eine schnelle Erfassung von Telemetriedaten ohne Änderungen am Quellcode. Diese Methode eignet sich besonders für schnelle Rollouts oder unzugängliche Drittanbieter-Software, birgt jedoch das Risiko, unmanagebare Datenmengen zu generieren, wenn sie nicht richtig konfiguriert ist.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cstrong\u003eManuelle Instrumentierung\u003c/strong\u003e gibt Ingenieuren die Kontrolle, um Tracing präzise um spezifische Geschäftslogik zu modellieren. Diese Methode ermöglicht eine kohärente Erzählung über Kausalität, ist jedoch zeitaufwendig und kann komplex sein.\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie Entwicklung nachhaltiger Observability-Pipelines erfordert ein gezieltes Vorgehen bei der Datensammlung und -verarbeitung. Ein bewusster Umgang mit Telemetriedaten kann nicht nur die Effizienz steigern, sondern auch die Umweltbelastung verringern. Der Fokus auf ein Observability-Mesh und die richtige Wahl zwischen automatischer und manueller Instrumentierung werden entscheidend für den zukünftigen Erfolg in der Cloud-nativen Entwicklung sein.\u003c/p\u003e\n", "summary": "TL;DR Die zunehmende Komplexität von Systemarchitekturen führt zu einer Überflutung mit Telemetriedaten, die oft nicht sinnvoll genutzt werden. Um nachhaltige und effektive Observability-Pipelines zu schaffen, sollten Teams gezielt definieren, welche Metriken notwendig sind, um die Systemgesundheit zu überwachen und Vorfälle schnell zu analysieren. Der Übergang zu einem Observability-Mesh und die Abwägung zwischen automatischer und manueller Instrumentierung sind entscheidend für den Erfolg.\nHauptinhalt Die Cloud-native Gemeinschaft steht vor der Herausforderung, dass die Erfassung von Telemetriedaten oft zu einer Überflutung mit Informationen führt, die nicht alle von Bedeutung sind. Historisch gesehen war die Strategie, alles zu instrumentieren und später herauszufiltern, weit verbreitet. Studien zeigen jedoch, dass etwa 50 % der gesammelten Metriken niemals abgefragt oder genutzt werden. Diese unkontrollierte Datensammlung führt nicht nur zu höheren Speicherkosten, sondern auch zu einer erhöhten Komplexität und Belastung für die Ingenieure, insbesondere während aktiver Vorfälle.\n", "image": "https://ayedo.de/telemetry-that-matters-designing-sustainable-high-impact-observability-pipelines.png", "date_published": "2026-06-22T11:00:00Z", "date_modified": "2026-06-22T11:00:00Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","operations","software-delivery","development","kubernetes"], "language": "de" },{ "id": "https://ayedo.de/news/kubecon-cloudnativecon-openinfra-summit-and-pytorch-conference-unite-in-china-to-scale-ai/", "url": "https://ayedo.de/news/kubecon-cloudnativecon-openinfra-summit-and-pytorch-conference-unite-in-china-to-scale-ai/", "title": "KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference vereinen sich in China, um KI zu skalieren", "content_html": "\u003ch2 id=\"tldr\"\u003eTL;DR\u003c/h2\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference finden vom 7. bis 9. September 2026 im Shanghai International Convention Center statt. Diese Veranstaltung vereint führende Open-Source-Communities, um die Integration von \u003ca href=\"/kubernetes/\"\u003eCloud-Native\u003c/a\u003e\n Infrastrukturen mit KI-Workflows zu fördern und die Entwicklung von produktionstauglicher KI zu standardisieren.\u003c/p\u003e\n\u003ch2 id=\"hauptinhalt\"\u003eHauptinhalt\u003c/h2\u003e\n\u003cp\u003eDie bevorstehende Veranstaltung in Shanghai stellt ein bedeutendes Ereignis dar, da sie die erste gemeinsame Konferenz von KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference ist. Diese Zusammenkunft zielt darauf ab, die wachsende Nachfrage nach der Integration von Cloud-Native-Plattformen mit KI-Modell-Workflows zu adressieren. China spielt eine zentrale Rolle in der Open-Source-Entwicklung und ist der zweitgrößte Beitragende zu CNCF-Projekten weltweit.\u003c/p\u003e\n\u003cp\u003eDie Veranstaltung wird von der \u003ca href=\"/kubernetes/\"\u003eCloud Native Computing Foundation\u003c/a\u003e\n (CNCF), der OpenInfra Foundation und der PyTorch Foundation organisiert. Diese Organisationen bündeln ihre Expertise, um eine Plattform zu schaffen, die die gesamte Open-Source-Infrastruktur abdeckt. Jonathan Bryce, der Geschäftsführer der CNCF und der OpenInfra Foundation, betont die Notwendigkeit, die verschiedenen Schichten der Infrastruktur zusammenzubringen, um den neuen Anforderungen gerecht zu werden, die KI-Workloads an Hardware und Nutzungsmuster stellen.\u003c/p\u003e\n\u003cp\u003eEin zentrales Ziel der Konferenz ist es, eine nahtlose Integration der verschiedenen Komponenten zu ermöglichen. Dies reicht von der Virtualisierung und Speicherung über Kubernetes bis hin zu den Trainings- und Inferenzframeworks von PyTorch. Durch diese Integration sollen KI-Workloads nicht nur experimentell, sondern auch portabel, skalierbar und betrieblich zuverlässig sein.\u003c/p\u003e\n\u003cp\u003eMark Collier, Geschäftsführer der PyTorch Foundation, hebt hervor, dass moderne KI-Infrastrukturen für das Training, die Inferenz und eine Vielzahl von KI-Beschleunigern entscheidend sind. Die Zusammenarbeit zwischen den Communities ist notwendig, um KI-Lösungen in großem Maßstab zu realisieren und von der Forschung in die Produktion zu überführen.\u003c/p\u003e\n\u003cp\u003eDie zweitägige technische Agenda umfasst zahlreiche Tracks, die von einem unabhängigen Programmkomitee kuratiert wurden. Diese Tracks konzentrieren sich auf spezielle Bereiche wie KI-Infrastruktur, Plattformengineering und Hardwareunterstützung. Keynotes und Breakout-Sessions bieten Einblicke in reale Fallstudien, die zeigen, wie führende Unternehmen Produktionsumgebungen skalieren und die betriebliche Zuverlässigkeit aufrechterhalten.\u003c/p\u003e\n\u003cp\u003eZu den hervorgehobenen Tracks gehören Themen wie der gesamte KI-Lebenszyklus, von der Modellierung mit PyTorch bis hin zu agentischen Workflows, sowie die Bereitstellung von Cloud-Infrastruktur und Virtualisierung für leistungsstarkes KI-Computing. Weitere Sessions befassen sich mit der Orchestrierung von KI-Workloads in \u003ca href=\"/kubernetes/\"\u003ecloud-nativen\u003c/a\u003e\n Umgebungen mithilfe von Kubernetes.\u003c/p\u003e\n\u003ch2 id=\"technische-detailsimplikationen\"\u003eTechnische Details/Implikationen\u003c/h2\u003e\n\u003cp\u003eDie Veranstaltung wird die Zusammenarbeit zwischen Entwicklern und Technikern fördern, um die Herausforderungen der KI-Integration in Cloud-Native-Umgebungen anzugehen. Die behandelten Themen werden sowohl die technologische Entwicklung als auch die betriebliche Implementierung von KI-Lösungen in Unternehmen vorantreiben. Die Integration von OpenStack, Kubernetes und PyTorch wird als Schlüssel zur Realisierung effizienter und skalierbarer KI-Anwendungen angesehen.\u003c/p\u003e\n\u003ch2 id=\"fazitausblick\"\u003eFazit/Ausblick\u003c/h2\u003e\n\u003cp\u003eDie KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference 2026 in Shanghai stellt einen wichtigen Schritt in der Weiterentwicklung von KI-gestützten Cloud-Native-Lösungen dar. Die enge Zusammenarbeit der verschiedenen Open-Source-Communities wird entscheidend sein, um die Herausforderungen der nächsten Generation von KI-Workloads erfolgreich zu meistern.\u003c/p\u003e\n", "summary": "TL;DR Die KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference finden vom 7. bis 9. September 2026 im Shanghai International Convention Center statt. Diese Veranstaltung vereint führende Open-Source-Communities, um die Integration von Cloud-Native Infrastrukturen mit KI-Workflows zu fördern und die Entwicklung von produktionstauglicher KI zu standardisieren.\nHauptinhalt Die bevorstehende Veranstaltung in Shanghai stellt ein bedeutendes Ereignis dar, da sie die erste gemeinsame Konferenz von KubeCon + CloudNativeCon, OpenInfra Summit und PyTorch Conference ist. Diese Zusammenkunft zielt darauf ab, die wachsende Nachfrage nach der Integration von Cloud-Native-Plattformen mit KI-Modell-Workflows zu adressieren. China spielt eine zentrale Rolle in der Open-Source-Entwicklung und ist der zweitgrößte Beitragende zu CNCF-Projekten weltweit.\n", "image": "https://ayedo.de/kubecon-cloudnativecon-openinfra-summit-and-pytorch-conference-unite-in-china-to-scale-ai.png", "date_published": "2026-06-18T20:31:13Z", "date_modified": "2026-06-18T20:31:13Z", "authors": [{"name":"Mira","url":"https://ayedo.de/"}], "tags": ["cloud-native","kubernetes","development","automation","digital-sovereignty"], "language": "de" }, ] }