<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:dc="http://purl.org/dc/elements/1.1/" version="2.0">
  <channel>
    <title>InfoQ - Cloud Native Computing Foundation</title>
    <link>https://www.infoq.com</link>
    <description>InfoQ Cloud Native Computing Foundation feed</description>
    <item>
      <title>Buildpacks Move the Container Hardening Control Point Away From the Dockerfile</title>
      <link>https://www.infoq.com/news/2026/08/buildpacks-dockerfile-patching/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=Cloud+Native+Computing+Foundation</link>
      <description>&lt;img src="https://res.infoq.com/news/2026/08/buildpacks-dockerfile-patching/en/headerimage/header-1786050230489.jpeg"/&gt;&lt;p&gt;Cloud Native Buildpacks, which graduated within the CNCF in July 2026, move base image choice out of per-service Dockerfiles into a single builder owned by platform engineering, enabling fleet-wide patching. BellSoft's hardened Paketo builder is the latest sign that vendors now treat the builder, not the Dockerfile, as the container security control point.&lt;/p&gt; &lt;i&gt;By Mark Silvester&lt;/i&gt;</description>
      <category>Application Security</category>
      <category>Cloud Native Computing Foundation</category>
      <category>Platform Engineering</category>
      <category>DevOps</category>
      <category>Architecture &amp; Design</category>
      <category>news</category>
      <pubDate>Mon, 10 Aug 2026 07:00:00 GMT</pubDate>
      <guid>https://www.infoq.com/news/2026/08/buildpacks-dockerfile-patching/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=Cloud+Native+Computing+Foundation</guid>
      <dc:creator>Mark Silvester</dc:creator>
      <dc:date>2026-08-10T07:00:00Z</dc:date>
      <dc:identifier>/news/2026/08/buildpacks-dockerfile-patching/en</dc:identifier>
    </item>
    <item>
      <title>Pods as Workers, Not Agents: Rethinking the Deployment Unit for AI Agents on Kubernetes</title>
      <link>https://www.infoq.com/news/2026/08/pod-deployment-unit-ai-agents/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=Cloud+Native+Computing+Foundation</link>
      <description>&lt;img src="https://res.infoq.com/news/2026/08/pod-deployment-unit-ai-agents/en/headerimage/header-1785763169197.jpeg"/&gt;&lt;p&gt;Running AI agents on Kubernetes raises a key question: should each agent get its own Pod? The kagent project argues no—agents are bursty, short-lived, can spawn subagents, and may wait for human approval, making one Pod per agent wasteful. Agent-substrate adds a control plane to schedule logical “Actors” onto long-lived worker Pods.&lt;/p&gt; &lt;i&gt;By Mark Silvester&lt;/i&gt;</description>
      <category>Agents</category>
      <category>AI Architecture</category>
      <category>Kubernetes</category>
      <category>Cloud Native Architecture</category>
      <category>Cloud Native Computing Foundation</category>
      <category>DevOps</category>
      <category>AI, ML &amp; Data Engineering</category>
      <category>Architecture &amp; Design</category>
      <category>Development</category>
      <category>news</category>
      <pubDate>Thu, 06 Aug 2026 06:00:00 GMT</pubDate>
      <guid>https://www.infoq.com/news/2026/08/pod-deployment-unit-ai-agents/?utm_campaign=infoq_content&amp;utm_source=infoq&amp;utm_medium=feed&amp;utm_term=Cloud+Native+Computing+Foundation</guid>
      <dc:creator>Mark Silvester</dc:creator>
      <dc:date>2026-08-06T06:00:00Z</dc:date>
      <dc:identifier>/news/2026/08/pod-deployment-unit-ai-agents/en</dc:identifier>
    </item>
  </channel>
</rss>
