The cloud native landscape is undergoing one of its most consequential reorganizations in years. In the span of a single month, the community has seen the retirement of a foundational networking controller, a fundamental rethink of how AI agents should run on Kubernetes, a new protocol for managing observability at massive scale, and a broad effort to evolve platform engineering for an AI-native future. These are not isolated developments. They are signals that the entire stack is maturing — and being rebuilt — to handle what comes next.
The Ingress-NGINX Retirement Forces a Rethink
In March 2026, the Kubernetes SIG Network officially retired the community-maintained ingress-nginx controller. It was a moment many operators had been dreading. The controller had been a default choice for years, but its end-of-life left organizations facing unpatched CVEs, zero new features, and no community support.
The retirement is often misunderstood. The Ingress API itself is not going away. It remains supported and widely used. What ended was the specific community controller. That distinction matters, because it gives teams two viable paths forward — and a real architectural choice.
The first path is a lateral move: swap the controller while keeping the Ingress API. Projects like Contour, an Envoy-based controller, allow teams to preserve their existing Ingress YAML resources by changing the ingress class. The trade-off is familiar: proprietary nginx annotations must be manually translated or rebuilt using Contour’s CRDs. It is lower effort but ultimately a stopgap. The Ingress API is feature-frozen. It will not evolve.
The second path is the architectural evolution: migrating to the Gateway API. The Gateway API is the upstream-backed successor to Ingress, designed with a role-oriented paradigm that separates infrastructure concerns from application routing. Platform teams manage Gateways. Application teams manage HTTPRoutes. Traffic splitting, advanced header matching, and secure cross-namespace routing are built into the core specification, not bolted on via vendor annotations.
For teams with the engineering cycles, the Gateway API is the future-proof choice. For those under immediate pressure, a lateral move buys time. The important thing is that the decision is now being forced by a real event, not a theoretical deprecation timeline.
AI Agents Challenge the Pod Abstraction
While networking controllers were hitting end-of-life, another question was surfacing across the ecosystem: Is a Kubernetes Pod really the right unit for an AI agent?
It is a question that would have sounded strange just two years ago. Pods have been the universal deployment unit in Kubernetes since its inception. They provide process isolation, identity via ServiceAccounts, network policies, and observability. For traditional microservices, the abstraction is perfect.
But AI agents are not traditional microservices. An agent may wake up, execute for a few minutes, spawn subagents in parallel, pause for human approval, and then go completely idle. Keeping a dedicated Pod alive for every potential agent is wasteful. More importantly, an agent’s lifetime is often measured in seconds or minutes, not days. The Pod lifecycle — create, run, terminate — is too heavy for that pattern.
The response emerging from the community is a new abstraction called agent-substrate, introduced by projects like kagent. Rather than mapping each agent directly to a Pod, agent-substrate introduces a control plane that sits above Kubernetes. Kubernetes still manages the underlying Pods, networking, storage, and compute. But the agent-substrate layer manages the lifecycle and placement of AI actors onto execution workers.
The mental model is analogous to Kubernetes itself. A WorkerPool is like a NodePool. Workers are like Nodes. ActorTemplates define how an Actor should execute, much like a PodTemplate. The key difference: an Actor is a logical entity that can be scheduled onto a Worker when work arrives and removed when execution completes. Workers remain long-running Pods. Actors are lightweight execution units that share them.
This separation allows a cluster to support far more AI agents than it could ever support as individual Pods. It also raises deeper questions about whether an agent’s identity should be tied to a Pod or Service at all — or whether it should belong to the ActorTemplate and be portable across execution workers. The implications go beyond scheduling efficiency. They touch identity, multi-tenancy, and governance for autonomous systems.
OpenTelemetry Grows Up With OpAMP
As the compute layer gets rethought, so does observability. OpenTelemetry has become the dominant standard for telemetry collection, but running it at scale introduces a management challenge few teams anticipated.
Organizations are not running handfuls of collectors. They are deploying them everywhere — massive gateway collectors doing heavy processing, lightweight edge collectors on embedded devices, point-of-sale machines, laptops collecting Windows events for security tracking. The scale ranges from dozens to millions of collectors. Before OpAMP, each organization built its own management protocol. HTTP long polling. WebSockets. Protobufs. JSON. The fragmentation was unsustainable.
Enter OpAMP, the Open Agent Management Protocol. OpAMP is a standardized network protocol that lets a central backend remotely configure agents, push updates, monitor their health, and collect status information — all in real time over WebSocket or HTTP connections. It uses just two messages: server-to-agent and agent-to-server, defined with Protocol Buffers.
The architecture is intentionally simple. An OpAMP extension reports current configuration and health status. An OpAMP supervisor sits alongside the collector, accepting changes from a management platform, writing new configurations to disk, restarting the collector, and — critically — reverting to the last known good configuration if the new one fails. As one maintainer put it: the goal is to avoid breaking telemetry pipelines remotely.
OpAMP’s power extends beyond the OpenTelemetry Collector itself. The protocol’s configuration payload is intentionally generic — just a map of name-value pairs — which means it can manage SDKs, Kubernetes deployments via the OpAMP Bridge, and eventually any agent that needs remote management. Companies like Nike have already built enterprise-grade OpAMP implementations for their scale. The pattern is proven.
Platform Engineering Evolves for AI-Native Workloads
These infrastructure changes do not exist in a vacuum. They are being driven by a broader shift in what platform teams are being asked to support. The era of Platform Engineering 1.0 — golden paths, internal developer platforms, self-service infrastructure — delivered real value. But the rapid adoption of AI technologies is creating requirements those platforms were never designed to handle.
The emerging model, which practitioners are calling Platform Engineering 2.0, extends the platform’s scope in five directions:
AI-native platform capabilities become first-class citizens. GPU and TPU allocation, model serving, MCP gateways, and agentic guardrails are no longer afterthoughts. They are provisioned, governed, and protected from the ground up.
Multi-persona experience expands beyond developers to data scientists, ML engineers, FinOps practitioners, and — notably — AI agents themselves. Agents are recognized as non-human platform consumers with their own access controls, scopes, and governance needs.
Embedded FinOps moves cost intelligence from bolt-on dashboards to provisioning-time decisioning. Financial accountability becomes a platform primitive. Every operator makes cost-aware decisions by default.
Security shifts down into the platform and runtime layers, complementing shift-left practices. AI-specific attack vectors — shadow AI sprawl, prompt injection, model poisoning, inference data leaks — are addressed through model registry governance, data isolation, and inference auditing.
Composable by design means platform capabilities are delivered as modular, API-first building blocks. Teams can swap one CNCF-compliant tool for another without cascading changes. The platform can be repaved quickly as the ecosystem evolves.
CNCF is also actively working on the foundational layer for this shift. Its Data Storage in Cloud Native AI white paper, released in early July, directly addresses the massive data bottlenecks that occur when moving AI and ML workloads into cloud native infrastructure. The paper acknowledges what many operators already know: data-heavy, stateful workloads do not fit neatly into the stateless microservices model that Kubernetes was originally built for.
What This Means for Practitioners
For teams operating cloud native infrastructure today, the message is clear: the stack is not static. The Ingress retirement is not a one-off event. It is a pattern. Abstractions that served us well for a decade are being questioned — not because they failed, but because the workloads they support have changed.
The convergence of these trends suggests a few practical priorities:
- Audit your networking layer now. If you are still on ingress-nginx, you are running unsupported software. Evaluate Contour for a short-term bridge, or Gateway API for a long-term foundation.
- Experiment with agent-specific abstractions. If your organization is deploying AI agents, test whether agent-substrate or similar patterns can reduce resource waste and improve lifecycle management.
- Plan for observability scale. If your collector count is growing, adopt OpAMP early. Building your own management protocol is technical debt you do not need.
- Treat platform engineering as a product — but expand the user base. Your platform consumers now include data scientists, AI agents, and compliance teams. Design for them explicitly.
The cloud native ecosystem has always evolved through replacement, not accumulation. The retirement of one controller and the emergence of another abstraction is how the stack stays relevant. The difference now is the pace. AI workloads are not a future concern. They are the current forcing function — and the infrastructure is responding in real time.