Kubernetes 1.35 Powers Serverless Compute Momentum in 2026

A Fragmented Story With One Common Thread

On the surface, “serverless compute release notes” describes several unrelated update logs: Databricks tweaking its managed Spark environment, the Kubernetes project cutting a new minor version, and CNCF certifying projects like Knative and KEDA as production-ready 169. But taken together, these releases describe a single industry shift — serverless computing is no longer a rival to Kubernetes, it is increasingly built on top of it, or modeled after the operational discipline Kubernetes has popularized 10.

Databricks continues to push serverless compute as a continuously updated, versionless product on AWS. Rather than letting customers choose and manually upgrade a runtime, Databricks automatically rolls out environment updates, pairing a stable Spark Connect client interface with a backend it can revise for performance, security, and bug fixes without breaking existing applications 1. This mirrors a broader pattern across the serverless market: providers are absorbing more operational responsibility — patching, fleet management, runtime versioning — so that developers interact with an interface rather than infrastructure.

Kubernetes' Release Cadence Keeps Expanding the Substrate

While Databricks iterates its own managed layer, Kubernetes itself keeps evolving the primitives that make elastic, serverless-style platforms possible. The project currently maintains three active minor release branches — 1.35, 1.36, and 1.37 — each receiving roughly a year of patch support before reaching end of life, with 1.37.0 as the newest release and 1.38 already in planning 6.

Two features from the 1.35 cycle are particularly relevant to serverless economics. First, In-Place Pod Resize graduated to stable after more than six years of development, letting CPU and memory allocations for a running pod change without deleting and recreating it — a shift that reduces disruption for stateful services, batch jobs, and latency-sensitive workloads, and unlocks smoother vertical autoscaling for tools like the Vertical Pod Autoscaler 13. Second, Kubernetes 1.35 introduced the first phase of “workload aware scheduling,” an initiative spanning multiple special interest groups aimed at making scheduling and workload management more responsive, with future work targeting preemption and autoscaling more broadly 14.

Neither feature is marketed as “serverless,” but both make the underlying substrate more capable of supporting elastic, self-managing platforms — the same qualities that serverless computing promises to abstract away from developers.

Knative and KEDA: The Missing Serverless Behaviors

Kubernetes alone does not deliver a serverless experience; it needs higher-level layers to handle routing, event delivery, and scale-to-zero behavior. That is the role CNCF-hosted projects Knative and KEDA play, and both reached major maturity milestones recently.

Knative, created at Google in 2018 and accepted into CNCF as an incubating project in 2022, graduated to full CNCF status on October 8, 2025 79. CNCF describes it as a Kubernetes-native serverless and event-driven application layer built from three components: Knative Serving for HTTP-triggered autoscaling (including scale-to-zero), Knative Eventing for CloudEvents-based routing, and Knative Functions for simplified function deployment 3710. The graduation announcement drew endorsements from cloud providers and users including Scaleway, Alibaba Cloud, Y Meadows, and Gojek, all citing autoscaling and cost efficiency as primary motivations for adoption 9. CNCF's roadmap for the project points toward deeper AI integration, a new RequestReply resource bridging synchronous and asynchronous workloads, adoption of the Gateway API, and a shift to OpenTelemetry for observability 9.

KEDA, the Kubernetes Event-Driven Autoscaler, graduated from CNCF earlier, in August 2023, after being built as a Microsoft-Red Hat collaboration in 2019 8. Unlike Knative's HTTP-centric model, KEDA scales workloads based on external event sources — message queues, databases, and custom metrics — and works alongside Kubernetes' native Horizontal Pod Autoscaler rather than replacing it 810. At graduation, CNCF said KEDA supported more than 60 scalers and nine authentication providers, with production users including FedEx, Grafana Labs, Reddit, and Xbox; more recent technical guides put the scaler count above 70 810. Comparative analyses frame Knative as the more comprehensive serverless platform for new applications, while KEDA is positioned as a lighter-weight way to add event-driven elasticity to existing deployments 10.

Platform Engineering Struggles to Keep Pace

Even as the technical building blocks mature, organizational adoption is uneven. A CNCF and SlashData report found that only 28% of organizations have a dedicated platform engineering team, while 41% rely on multi-team collaboration and the remainder have no formalized approach at all 1112. A related CNCF survey of 420 developers, presented at KubeCon + CloudNativeCon Europe, found similarly fragmented practices, with just 19% of organizations building AI workflows maintaining a separate dedicated platform for that work 12. The same survey highlighted strong developer confidence in specific tools — Armada, Helm, GitHub Actions, kro, and cert-manager all received high reliability ratings — suggesting the tooling ecosystem is maturing faster than organizational structures are adapting to it 1112.

That gap matters because serverless adoption inside Kubernetes shops increasingly depends on internal developer platforms exposing curated, self-service paths rather than raw Kubernetes APIs. CNCF's broader annual survey found that 82% of container users now run Kubernetes in production, up from 66% in 2023, and that 59% of organizations describe most of their development as cloud native 15. Among the most mature “innovator” organizations, 58% use GitOps extensively, compared with just 23% of less mature adopters 15. Kubernetes, in other words, has become close to universal infrastructure even as the practices for managing it responsibly remain inconsistent.

Market Growth and Divergent Framings

Market researchers continue to project substantial growth for serverless computing broadly, with one estimate putting the market at $21.9 billion in 2024 and forecasting expansion to $44.7 billion by 2029, driven by cloud scalability demands, AI and automation trends, and continued remote work 4. Vendor and community coverage frames this growth differently depending on the audience: enterprise case studies, such as Liberty Mutual's public embrace of serverless as “a whole new paradigm,” emphasize business transformation 2; infrastructure vendors like Cloudflare are extending serverless platforms to support containerized workloads such as media and data processing at the edge, blurring the line between “serverless” and “container” compute entirely 3; and framework providers like Serverless Framework continue iterating around AWS Lambda enhancements, reflecting the earlier, function-centric definition of serverless that predates the Kubernetes-based approaches now gaining ground 5.

The Bottom Line

No single announcement defines the current moment in serverless computing. Instead, the story is one of convergence: Kubernetes is absorbing capabilities — resizable pods, workload-aware scheduling — that make elastic infrastructure more efficient, while CNCF projects like Knative and KEDA supply the routing, eventing, and autoscaling logic serverless platforms require 91314. Managed providers like Databricks are meanwhile pushing serverless further into data engineering and AI workloads through continuously updated, versionless environments 1. The unresolved question for platform teams is not whether to adopt Kubernetes or serverless, but which workloads should be exposed through Kubernetes directly, which should be hidden behind a serverless interface, and who within the organization owns that boundary 1112.