By submitting this form, you agree to our 

A practical guide to AI artifacts and LLMOps

Securing non-deterministic systems

 will be the first Kubernetes major release of 2026, and it’s full of really exciting updates for security, AI hardware, and more! As always, removing enhancements with the status of “

” we are seeing 80 enhancements in all listed within the 

Kubernetes 1.36 brings a whole bunch of useful enhancements, including 36 changes tracked as ‘

’ in this Kubernetes release. From these, just 

 are currently graduating to stable, such as 

 enhancements graduating to that GA status.

 features are also listed in the enhancements tracker, one of which introduces the ability to report when a PVC was last used in 

. A simple by powerful use-case where users can now see if a PVC is sitting unused, so in larger clusters this would really help DevOps teams to get rid of any unused and unwanted PVCs.

As always, let’s jump into all of the major graduations, deferred enhancements and deprecations scheduled for Kubernetes 1.36.

Here are a few of the changes that Cloudsmith employees are most excited about in this release:


It’s becoming a regular comment in these recent Kubernetes release notes, but the DRA API is seeing a LOT of exciting enhancements in the 1.36 update. [

 all updated in this release]. This led the Cloudsmith team to add dedicated 

 updates. Anyways, this specific DRA enhancement is exciting because it brings more granularity and automation to hardware management, allowing admins to take specific devices offline for maintenance without disrupting the entire cluster. By introducing taints and tolerations for hardware, similar to what we already have for pod deployments, we can all benefit from automatically rescheduling pods away from failing devices while still letting specialised test pods access them for daily troubleshooting activities.

Nigel Douglas - Head of Developer Relations


I am absolutely thrilled to see OCI image volumes finally hitting Stable status in Kubernetes 1.36 because, as a Product Manager working on the OCI format support at Cloudsmith, I can see this enhancement turning existing container registries into universal artifact hubs. For years, dev teams have been forced into the so-called fat image anti-pattern, where they’re basically bundling massive 

, static assets, and binary plugins directly into their application images, which ultimately creates a nightmare for security patching and bloats deployment times. By graduating this to Stable, we’re now seeing a native, high-performance way to decouple user data from your logic. Devs can now push Hugging Face LLM weights or commercial signatures as independent OCI artifacts and mount them as a 

 just as easily as a ConfigMap. This doesn't just simplify CI/CD pipelines by allowing platform teams to swap content without rebuilding the base engine, but it also drastically shrinks your potential attack surface for the platform teams who are managing these deployments. It’s a massive win for the ecosystem that transforms the OCI registry from a basic storage location for apps into a more dynamic, structured delivery system for any content that a pod needs to succeed.

#5793 Manifest-based Admission Control configuration


As a CSM, I’m genuinely stoked for this 1.36 feature because it finally lets platform teams secure their actual admission control configs. When we think about moving mission-critical policies from the API to static files on the control plane disk, platform teams can now prevent the scary security blindspot where the cluster was vulnerable during the startup. Based on what I'm hearing from the teams I work with, this means vital guardrails (like blocking privileged containers) are now immune to accidental 

 crashes. It’s a massive win for their platform stability, providing platform engineers with a somewhat tamper-proof approach to keeping the 

 secure from the very first second the API server wakes up.

Mutable Container Resources when Job is suspended


This proposal seeks to enhance Kubernetes Batch Job management by relaxing the immutability of a Job’s Pod template while it is in a 

 flag, this change would allow higher-level queue controllers to mutate resource specifications (specifically 

) before a Job is unsuspended and pods are created. By allowing these updates, cluster administrators and automated controllers can dynamically optimise resource allocation based on real-time cluster capacity, current queue priorities, and actual workload utilisation, ensuring that expensive hardware like GPUs is used efficiently.

The design ensures that these mutations are only permitted when a Job is fully suspended and has no active pods, mitigating the risk of disrupting running workloads. While the proposal does not include implementing a specific queue controller or supporting in-place pod updates, it provides the necessary API primitives for external tools (like 

) to perform checkpointing and resizing. This flexibility allows a Job to be suspended, its resource requests lowered to match actual usage, and then resumed, thereby improving overall cluster throughput and reducing resource waste.

Add Recreate Update Strategy to StatefulSet


Starting in Kubernetes 1.36, the introduction of the 

 for StatefulSets addresses a long-standing 

 that has plagued users since 2018. Previously, if a StatefulSet update was triggered with a broken configuration (such as a non-existent Docker image), the controller would wait indefinitely for the failing Pod to become 

 before proceeding. Even if a user reverted the configuration to a known-good state, the StatefulSet would refuse to manage or fix the broken Pod because it was stuck in a validation loop, forcing administrators to manually delete the Pod to unblock the controller.

 strategy (moving to Alpha in this update) provides a more aggressive alternative to the standard RollingUpdate. It allows the StatefulSet controller to prioritise reaching the desired state by terminating existing Pods before creating new ones, effectively bypassing the 

 deadlock. This change transforms what was previously documented as a known issue into a manageable configuration, ensuring that automated CI/CD pipelines and operators can recover from misconfigurations without manual human intervention.

WAS: Integrate Workload APIs with Job controller


The feature represents a major step in Kubernetes' evolution to natively support complex batch and AI/ML workloads. Historically, Kubernetes scheduled individual Pods independently, which caused issues for distributed training jobs that require all participants to start simultaneously (gang scheduling). This feature introduces the 

 object to act as a bridge between high-level controllers (like the Job controller) and the scheduler. By integrating these, the Job controller can now automatically generate a Workload representation of itself, allowing the scheduler to understand the resource requirements and scheduling constraints of the entire group of pods rather than treating them as isolated units.

For the Kubernetes 1.36 Alpha update, the proposal focuses on standardising this integration and refining the API surface. Key changes include introducing the PodGroup as a standalone runtime object and renaming the embedded field within the Workload spec to 

 to ensure a cleaner, more extensible hierarchy. Specifically for the Job controller, the 1.36 update aims to enable the creation of Workload and PodGroup objects by default for 

 Jobs (those where parallelism does not change). This release also seeks to resolve a critical debate on 

, which is whether the release team should maintain separate 

 policies or to unify them into a single parameter where a 

 equal to the total replicas represents strict gang scheduling.

 marked a simple, formal separation of two different KEPs that were previously managed as a single unit: 

 (the Deployment pod replacement policy). The split was justified because the #3973 enhancement which introduced the 

 field to track pods in the process of shutting down moved through the development cycle faster than the more complex pod replacement policy. By decoupling them, the 

 team can now track their graduation through Alpha, Beta, and Stable stages independently, preventing the progress of one from being stalled by the other.

The merged changes include updated documentation and readiness reviews (PRRs for short) for both features. Key technical discussions during the PR focused on ensuring proper version skew policies, specifically requiring that the 

 to avoid status synchronisation issues. While the terminating replicas feature is already seeing implementation in recent releases, the specific API and logic for the pod replacement policy remain in progress, now neatly organised under its own dedicated proposal for future tracking in the 1.36 update.

Graduating to stable, Mutating Admission Policies introduce a declarative, in-process alternative to traditional mutating admission webhooks by leveraging 

. This enhancement allows cluster administrators to define resource modifications (such as injecting sidecar containers, enforcing image pull policies, or setting default labels) directly within Kubernetes using 

 objects. By using CEL's object instantiation alongside 

, the API server can perform these mutations internally, significantly reducing the operational overhead, latency, and webhook fatigue associated with maintaining external infrastructure.

Beyond simplicity, this native approach offers superior performance and reliability. Because the mutations are in-process, the 

 can introspect changes to optimise execution order and safely re-run policies to ensure 

. While it does not aim for 100% feature parity with webhooks, specifically excluding external calls, it covers the vast majority of common use cases while providing a safety field to validate that mutations remain consistent. This move effectively brings the power and efficiency of 

 to the mutation phase, creating a more robust and integrated policy management framework within the Kubernetes ecosystem.

This proposal introduces a mechanism to mitigate 

 in Kubernetes by allowing controllers to detect when their local cache lags behind the API server. Currently, controllers in the 

) rely on eventually consistent watch streams, which can lead to spurious reconciles or incorrect decisions (like scaling or deleting resources) based on outdated data. To solve this, the enhancement proposes an opt-in read-after-write guarantee. By tracking the 

 of objects after a write and updating the 

, controllers can verify if their previous changes have propagated to the local cache before proceeding with the next reconciliation.

In practice, this logic will be integrated into the core processing loops of sensitive controllers, such as the DaemonSet controller. If a controller determines that its cache has not yet caught up to its last-written state, it will 

 the object with exponential backoff rather than performing a potentially erroneous reconcile. This targeted approach ensures consistency for specific resources without imposing a global performance penalty, though it requires careful handling of edge cases like controller restarts and cache resyncs to prevent permanent reconciliation stalls.

Separate kubectl user preferences from cluster configs


 feature introduces a dedicated configuration file (typically located at 

) designed to separate individual user preferences, such as command aliases and default flag settings, from the cluster credentials and server information stored in a standard 

. This separation allows users to maintain consistent local workflows (like enforcing interactive delete confirmations or silencing deprecation warnings) across multiple clusters without modifying shared or auto-generated connection files. The major change moving into 

, whereas it previously required manual activation. To support this promotion, the update introduces the 

 management command to help users programmatically view and edit their preferences, and it formalises security controls through a 

 to prevent the execution of untrusted binaries.

This relaxed ServiceName validation feature is an improvement designed to bring the naming constraints of Service resources into alignment with other standard Kubernetes objects. Historically, Services were restricted by a stricter 

), which prohibited names from starting with a numeric digit. This update transitions the validation to the more flexible 

 standard, finally allowing users to create Services with names like 

, the feature is moving from an opt-in experimental state to being 

. This graduation signifies that the community has successfully completed compatibility testing with downstream systems like DNS providers and Ingress controllers, and has verified that the change remains safe during cluster upgrades and downgrades by maintaining immutability checks on existing resource names.

Extend PodResources to include resources from DRA


 to bridge the visibility gap between the Kubernetes node and external monitoring tools. Historically, this API only allowed monitoring agents to see which CPUs or standard devices were assigned to a container. This feature extends that capability to include resources managed by the evolving DRA feature. By adding a 

 method for targeted pod queries, the Kubelet can now report specific DRA-allocated hardware (such as GPUs or FPGAs) directly to monitoring stacks like 

. To ensure this data remains available even if a DRA driver goes offline, the system implements a checkpointing mechanism within the 

, guaranteeing that resource assignments are preserved across Kubelet restarts.

The primary benefit of this enhancement is 

granular observability for next-gen hardware

. Platform operators can now access per-pod metrics for DRA-managed resources, which is essential for accurate billing, performance tuning, and troubleshooting in AI/ML workloads. Since the feature is graduating to Stable in v1.36, the community can expect full production-ready reliability with a guaranteed 

 requests over a rolling 5-minute window as well as low-latency response times (P99 < 100ms). The graduation to GA means the 

, allowing third-party ecosystem tools to officially rely on stable gRPC fields without the risk of breaking changes or experimental instability.

This is a security-focused refinement of how Kubernetes handles network addressing, specifically targeting the stricter validation of 

 across the API. Historically, Kubernetes relied on older Go functions that were overly permissive, allowing ambiguous formats like IPv4 addresses with leading zeros (for example: 

), which different systems might interpret differently (octal vs. decimal), potentially leading to security vulnerabilities like 

. For platform teams, this is highly beneficial because it eliminates many IP address risks and ensures consistency between Kubernetes and underlying network plugins (Calico and Cilium) and OS-level libraries. To maintain stability, the plan uses 

, which prevents new invalid entries without breaking existing workloads, which means that teams can update a service’s labels without being forced to immediately fix a legacy IP field. This move toward canonical formats (like standardised IPv6 strings) simplifies long-term maintenance, auditing, and observability, as platform engineers can now trust that network data is unambiguous and follows a single source of truth format across the entire cluster.

API for external signing of Service Account tokens


This KEP proposes a transition from static, file-based Service Account key management to a more dynamic integration with external providers like 

 loads signing keys from the local disk at startup, a method that lacks flexibility and poses a security risk, as any user with filesystem access could exfiltrate the signing material. By introducing a new 

) accessible via a Unix domain socket, Kubernetes can delegate JWT signing and public key retrieval to an external plugin. This shift enables seamless key rotation without requiring an API server restart and ensures that sensitive private keys never reside in the cluster’s local memory or storage.

To maintain consistency and security, the 

 remains responsible for assembling the JWT claims and headers, while the external signer only provides the signature. This architecture prevents claim divergence and ensures that externally signed tokens remain compatible with existing OIDC discovery endpoints. While the proposal introduces a new 

 flag, it preserves backward compatibility by keeping existing file-based flags as mutually exclusive options. Potential performance overhead from socket communication will be mitigated through benchmarking, and access to the signing socket will be restricted via standard Unix file permissions to prevent unauthorised token generation.

Kubernetes 1.36 introduces a brand-new conditional authorisation capability, which is a framework that allows authorisation decisions to depend on the actual data within a resource (like specific fields or labels) rather than just its metadata. Currently, Kubernetes authorisers (like 

) are basically blind to the content of a request body. This KEP bridges that gap by using a two-phase evaluation process. 

In the first phase, the authoriser performs 

 response containing a set of requirements (for example, " only Allow if 

In the second phase, these conditions are enforced during the 

 stage, where the API server finally decodes the object and has access to the necessary field data to make a concrete decision.

This architecture solves several long-standing limitations by providing a unified, cohesive policy model that spans both authorisation and admission. It eliminates the need for administrators to essentially over-grant their permissions in RBAC only to restrict them later with separate tools like 

By propagating conditions through the request chain, the system ensures atomicity (the decision is based on a single snapshot of policy) and improves user experience, as users can see exactly why they are restricted via 

 lookups. Concretely, the enhancement extends the 

 API, enabling both in-tree and out-of-tree authorisers to implement fine-grained controls, like restricting which fields user can update or which 

 a CSR can use without compromising API server's performance or security.

Constrained impersonation helps Kubernetes move away from the unrestricted legacy model where an impersonator automatically inherits all permissions of the target user. To mitigate these security risks (especially for controllers and per-node agents) impersonators must now possess two distinct sets of permissions: 

The authority to impersonate a specific identity (

Right to perform specific actions on behalf of that identity (

This opt-in mechanism ensures that even if a controller is compromised, its impersonation power is limited to specific resources and verbs. In the below 

 example, a controller can be restricted to impersonating only the specific node it is running on by using the downward API to identify itself and configuring the client as follows:

By introducing these prefixed verbs like 

, platform engineers can now define highly specific RBAC roles. This setup ensures that an impersonator can only execute a request if both the impersonator has the 

 permission for the action and the impersonated principal has the underlying permission to perform the task itself.

Kubernetes 1.36 is addressing a long-standing recovery gap where encrypted API resources become undeletable due to missing keys or data corruption. Currently, if a single object in 

 fails to decrypt or decode, listing that resource type fails entirely, forcing admins to bypass the Kubernetes API and manually manipulate the database, which is a really risky and complex process. To solve this, the proposal introduces a way to identify these broken resources and provides a new 

 that allows for their removal even when their content remains unreadable.

However, this unconditional delete is a high-risk operation. Since the system cannot read the object's metadata, deleting it bypasses standard safety features like finalisers and 

, potentially leaving orphaned system processes (like running Pods) behind. To mitigate this, the design includes a new 

 for better diagnostics and requires explicit confirmation through 

 prompts and server-side admission layers to ensure administrators understand the impact before purging malformed data.

This enhancement introduces support for user namespaces, a critical isolation feature that maps containerised user and group IDs to different, unprivileged IDs on the host. By allowing a process to hold root privileges within a pod while remaining unprivileged on the underlying node, the KEP significantly bolsters node-to-pod and pod-to-pod isolation. This ensures that even if a process achieves a container breakout or possesses elevated capabilities like 

, its impact is strictly confined to the namespace, preventing it from exercising administrative control over the host or other pods.

The implementation specifically addresses and mitigates several high-severity vulnerabilities where container escapes or privilege escalations previously threatened host integrity. Key CVEs resolved or dampened by this update include:

Nigel Douglas

Head of Developer Relations

Kubernetes 1.36 – What you need to know

Thousands of platform engineers and security experts are heading to KubeCon + CloudNativeCon Europe 2026, making it the definitive cloud-native event in Europe. Stop by Cloudsmith at Booth 570 to say hello and check out our activities throughout the week. There’s 

With hundreds of talks on the schedule, it can be hard to know where to start. Here is our curated roadmap to ensure you get the most out of your time on the ground.

📍 RAI Amsterdam (Europaplein 24, 1078 GZ Amsterdam, Netherlands)
👋 Booth 570
🗓️ March 24 - 26, 2026

 (Thales SIX GTS France) will dive into the messy reality of the Software Bill of Materials (SBOM). They plan to pull back the curtain on why current open-source and cloud-based tools (despite all their promises) frequently generate conflicting package lists and inconsistent vulnerability reports when tasked with scanning complex container images.

This talk is particularly electrifying for the security community because it tackles the compliance anxiety triggered by the EU’s Cyber Resilience Act (CRA). As the CRA shifts SBOMs from a nice-to-have transparency initiative to a legal necessity for software lifecycles, the industry is waking up to a major problem, which is inconsistent data. By dissecting the technical roots of these discrepancies, Bufalino and Blaise aren't just pointing out flaws, they will also be providing a roadmap for developers to ensure their tooling is actually CRA-compliant. For anyone navigating the shift toward a transparent and trustworthy software supply chain, this session offers the technical clarity needed to turn these metaphorical bombs into secure builds.

2. Modelpack: Standardising the packaging and distribution of AI/ML Models

, a Distinguished Architect at Red Hat, tackles one of the most pressing bottlenecks in modern infrastructure: the chaotic fragmentation of AI/ML integration within the cloud-native ecosystem. Block, a seasoned expert in helping organisations scale open-source solutions, will break down how the current wild west of competing formats and runtimes is actively stifling innovation. He will introduce 

, a CNCF Sandbox project designed to act as the universal translator for AI/ML artifacts, allowing them to finally speak the same language as established tools like Kubernetes, ORAS, and Harbor.

The security and DevOps communities are closely watching this session because it addresses the Day 2 operations nightmare of managing AI at scale. As AI moves from experimental notebooks to production-grade Kubernetes clusters, the lack of standardisation creates massive technical debt and security blind spots. Block’s exploration of ModelPack and emerging artifact standards offers a glimpse into a future where AI models are managed with the same consistency and rigour as container images. For anyone struggling to bridge the gap between data science and cloud-native engineering, this talk provides the blueprint for a unified, scalable, and manageable AI supply chain.

3. Kubernetes security at Shopify scale: Automating security across an infrastructure monrepo

In this session, Senior Infrastructure Security Engineers 

 will pull back the curtain on how one of the world’s largest e-commerce platforms secures its massive infrastructure monorepo. Drawing from their deep backgrounds in cloud defense and 5G network security, Wu and Garg will detail the high-stakes challenge of managing thousands of services where a single misconfiguration could impact millions of merchants. They will demonstrate how Shopify moved beyond manual checkbox security by building an automated pipeline that combines Semgrep for static analysis and Open Policy Agent (OPA) for real-time policy enforcement.

This talk is a must-attend for the security community because it provides a battle-tested blueprint for solving the velocity vs. security dilemma we’re all too familiar with. While many orgs struggle with friction between DevOps and Security teams, Shopify’s approach shows how to bake guardrails directly into the developer workflow without slowing down deployment. Attendees will gain rare insights into the so-called rough patches of scaling open-source security tools and leave with a practical framework for automating risk detection across complex, high-traffic Kubernetes environments.


4. To upstream or not? Why becoming the maintainer of your dependencies matters

, a Principal Software Engineer at Elastic and an OpenTelemetry code owner, dives into the strategic heart of modern software engineering. Markou moves beyond the typical 

 narrative to present a pragmatic, business-first case for active maintenance. By sharing a high-stakes story of an OTel component saved from the brink of deprecation, he demonstrates how moving from a passive consumer to an active contributor transformed a potential technical debt nightmare into a rapid-response tool for solving critical customer issues.

This talk is a vital wake-up call for the security and observability communities because it addresses the growing crisis of software supply chain sustainability. In an era where a single abandoned dependency can lead to massive security vulnerabilities or operational outages, Markou provides a concrete example to share with your manager on why upstreaming isn't just altruism, it also can be treated as sensible risk management. For teams building on CNCF projects, this session offers a masterclass in how staying present in the ecosystem pays dividends in architectural control, security posture, and long-term engineering velocity.


5. How to add a new language feature to OPA

Adding features to a widely adopted language like Rego involves more than just a simple pull request. In this lightning session, Apple's 

 explores the full-stack impact of introducing new syntax, from the initial parser modifications to updating the broader ecosystem of editor tools. Learn the specific engineering hurdles involved in upgrading a mature security project without disrupting the developer experience. At Cloudsmith, we’re huge fans of Open Policy Agent and Rego, so we can’t wait to hear what Charlie has in store for us.

6. Platform Engineering 2.0: Just-enough Kubernetes and AI-native DevOps

 and a seasoned authority on platform patterns, tackles the industry's growing complexity bloat. Drawing from 20 years of experience and the literal scars of re-architecting internal platforms at one of the world’s largest travel sites, Vohra argues that the future of infrastructure isn't about building more, it’s really about building just enough. She will break down how to transition from heavy, static systems to lean, right-sized architectures using k3s, Gateway API, and ambient mesh, while layering in AIOps via Kubeflow and Prometheus to transform raw automation into true system intelligence.

This talk is a critical touchstone for the DevOps and platform communities because it offers a pragmatic exit ramp from the scale at all costs mentality that leads to massive cloud waste and operational blindness. Vohra’s AI-native approach is a blueprint for creating self-optimising ecosystems that align infrastructure directly with business value. For engineering leaders and architects feeling the weight of over-engineered clusters, this session aims to be a masterclass in staying lean, staying smart, and evolving platforms to be adaptive rather than just additive.

7. AI Agents & Platform Engineering: Efficiency boost or new source of trouble?

In the blockbuster panel, an elite group of industry leaders from 

 converges to debate the most disruptive shift in DevOps history. Featuring heavyweights like from the industry, this vendor-neutral discussion moves past the hype to ask the hard questions: Can non-deterministic AI agents actually keep pace with AI-accelerated developers, or are we just inviting unpredictable trouble into our production clusters? The panel will tackle the minimum viable platform foundation required for AI success, the shifting cost implications of agents in production, and how to build human trust in systems that don't always behave the same way twice.

This session is arguably the must-see event for the modern platform engineer because it addresses the looming intelligence gap in infrastructure. As developers pump out code at record speeds, the platform team is traditionally treated as the bottleneck. This panel explores whether AI agents are the ultimate scaling solution or a new category of technical debt. By bringing together perspectives from global tech giants and international organisations, attendees will walk away with a high-level framework for defining golden metrics for AI effectiveness and a roadmap for navigating the transition from static automation to dynamic, agent-led collaboration.

8. In Falco’s nest: The evolution of cloud native runtime security

In the maintainer track session, Falco contributors 

 (Kong) provide a deep-dive update on the CNCF’s de facto standard for runtime threat detection. The core of their presentation focuses on the highly anticipated Falco Operator, a game-changer designed to automate the deployment and management of security sensors across massive, distributed clusters, effectively lowering the barrier to entry for enterprise-scale security.

For the security community, this talk is a vital look at the roadmap for high-throughput runtime defense. As cloud-native environments become more complex and data-heavy, traditional security tools often struggle with performance overhead; Rozzo and Lacuku will demonstrate the specific optimisations that allow Falco to maintain deep visibility without sacrificing system reliability. Beyond the code, this session also is a great opportunity to see how the Falco ecosystem is integrating with the broader CNCF landscape, offering attendees a first look at the features that will define Cloud Detection & Response (CDR) in the coming year.

9. What LLMs do, and don’t, know about securing Kubernetes

, explores the practical (and often perilous) intersection of Generative AI and cluster orchestration. McCune, a veteran KubeCon speaker and a foundational voice in container security, will present the results of his deep-dive research into whether Large Language Models (LLMs) can actually be trusted with the sensitive credentials. Rather than just discussing theory, Rory will aim to demonstrate how LLMs handle specific Kubernetes security tasks, revealing where they provide genuine architectural insight and where they tend to hallucinate dangerous misconfigurations that could leave an organisation exposed.

This talk is a critical reality check for the security community as AI-assisted DevOps moves from a trend to a standard operating procedure. McCune will break down how advanced techniques like improved prompting and 

 reasoning can significantly shift the safety of an LLM's output, while also highlighting the so-called no-go zones where human expertise remains non-negotiable. For security architects and engineers, this session provides a vital framework for auditing AI-generated IaC templates, ensuring that the speed of AI doesn't come at the cost of a catastrophic security breach.

10. Audit-ready Kubernetes: How Chase UK leveraged policy-as-code for continuous compliance

 and co-creator of Kyverno, provide a rare under the hood look at building a cloud platform within the high-stakes world of regulated retail banking. Goyal, who manages the end-to-end Kubernetes ecosystem for Chase UK, will detail how his team transformed a massive compliance undertaking into a streamlined, automated engine. By leveraging Kyverno, OpenReports, and Grafana, they successfully shifted security left, allowing their backend engineers to ship code at speed while maintaining a real-time policy-as-code safety net that satisfies stringent financial regulators.

This talk is a beacon for the security and compliance communities because it addresses the ultimate white whale of enterprise DevOps: reducing audit times from weeks to minutes. Bugwadia’s deep perspective as a Kubernetes 

 co-chair, combined with Goyal’s real-world production perspective from JP Morgan Chase, offers a definitive guide on how to empower security teams to write independent policies without bottlenecking development. For any platform team operating in a regulated sector (or simply running mission-critical workloads) this session provides a proven framework for turning compliance from a manual, fear-driven process into a better, more transparent, and scalable process.

Catch lightning talks, hands-on demos, and prizes while learning how to secure every artifact in your supply chain.

Join Cloudsmith in Amsterdam at KubeCon Europe 2026

13 KubeCon Europe 2026 sessions not to miss

 is fast approaching, and it’s a loaded update! Removing enhancements with the status of “

” we have 59 Enhancements in all listed within the 

Kubernetes 1.35 brings a whole bunch of useful enhancements, including 30 changes tracked as ‘

 are graduating to stable, such as the addition of Kubelet option to specify the maximum age an image that will be kept around before it’s garbage collected. This is beneficial to cluster admins because unused images can now be garbage collected in a timely manner, no longer occupying disk space forever.

 features are also listed in the enhancements tracker, one of which introduces some new authorisation rules to restrict impersonation on specified resources with specified actions. We also see support for in-place resizing of pod-level resources, support for restarting all containers within the pod when a container exits as a 

This is the most detailed Cloudsmith release notes to date, and our team is really excited about this release and everything that comes with it! Let’s jump into all of the major features, changes, and deprecations in Kubernetes 1.35.

I’m excited to see structured auth config graduate to stable in Kubernetes 1.35 because it marks a major step forward in making cluster authentication both more flexible and maintainable. The current flag-based OIDC setup has long been a pain point, as it’s hard to extend, oftentimes difficult to manage, and is limited in how it maps identity claims. Moving to a versioned, structured configuration not only modernises this critical component but also unlocks long-requested capabilities like supporting multiple client IDs, richer claim mappings, and dynamic reloading of authentication settings without restarting the API server. This enhancement brings much-needed clarity and power to authentication workflows, simplifies life for operators, and sets a strong foundation for future innovations in identity and access control in Kubernetes.

Nigel Douglas - Head of Developer Relations


The feature I’m happy to see graduating to beta status in Kubernetes 1.35 is the binding conditions within Dynamic Resource Allocation. This looks to be a significant step towards making Kubernetes the definitive platform for demanding AI/ML workloads. This improvement provides the critical intelligence for schedulers to handle complex, disaggregated hardware like fabric-attached GPUs robustly, preventing failed deployments and enabling more efficient, dynamic resource allocation. The beta graduation signals that this powerful feature is almost stable and ready for broader adoption within the ecosystem, hopefully paving the way for more resilient, dedicated AI infra in Kubernetes.

#3673 Kubelet limit of Parallel Image Pulls

We are all delighted to see this new Stable update address the existing, ineffective method Kubernetes currently uses to limit container image pulls on a node. The existing QPS (Queries Per Second) and Burst limits are really confusing as they only control the rate of requests to the container runtime, not the number of concurrent pulls. This can sadly lead to an unlimited number of simultaneous downloads, potentially overwhelming a node's disk I/O and network bandwidth. This new change adds a more intuitive kubelet config field called 

. This setting establishes a clear, node-level limit on how many images can be pulled at the same time. Any pull request that exceeds this limit will be blocked until an ongoing pull completes - improving how cluster admins manage their resource consumption.

maxUnavailable for StatefulSets rolling updates

 strategies. Previously, when updating a StatefulSet, pods were terminated and recreated strictly one at a time, which could be very slow. This enhancement allows users to specify the maximum number of pods that can be unavailable during an update, either as an absolute number or a percentage. This means multiple pods can be updated simultaneously, dramatically speeding up the rollout process.


The primary motivation is to make StatefulSet updates faster and more flexible, bringing them closer to the functionality of Deployments. This is particularly useful for stateful applications that can tolerate multiple replicas being down at once (like a cluster with many followers) or for applications with long startup times (like cache loading). By allowing parallel updates, this feature helps users who prefer the stable network identities of StatefulSets but need the faster rollout capabilities typically associated with Deployments. The default value for 

, ensuring backward compatibility and maintaining the safe, one-by-one update behaviour for applications that require it.


 field to the Kubernetes Job specification. Its primary purpose is to delegate the management and status synchronisation of a Job to an external controller, effectively telling the default Kubernetes Job controller to ignore it. This is a lightweight, per-Job mechanism designed to prevent conflicts when another system needs to take control. The main motivation for this is to support 

, a multi-cluster job dispatcher that runs a "mirror" copy of a Job on a separate worker cluster while managing the original Job on a central management cluster. The 

 field allows the MultiKueue controller to sync the status from the worker cluster back to the management cluster without the default controller interfering.

, meaning it can only be set when the Job is created and cannot be changed later. This choice was made to avoid complex issues and potential errors, such as "leaking" pods, which could occur if control of a running Job were switched between different controllers. This approach provides clear ownership throughout the Job's lifecycle and follows a pattern already used by other Kubernetes resources, making it a stable and predictable solution for developers of custom batch processing systems.

Mutable Container Resources when Job is suspended


This Kubernetes enhancement proposes allowing users to modify the container resource requirements (like CPU and memory) on a job's template while that job is suspended. Currently, this is not possible. The primary motivation is to give users, particularly those using queuing systems like 

, the flexibility to adjust a job's resource needs before it resumes, which can improve scheduling efficiency. While a proof-of-concept exists for standard resources, the implementation faces a significant hurdle with the newer Dynamic Resource Allocation (

) framework, as its resource templates are immutable, and a clear path forward for DRA support is still under discussion.


Initially, the team considered releasing this feature directly as a 'beta' version, enabled by default, viewing the risk as low. However, concerns arose about completing the necessary comprehensive testing within a short development cycle. Specifically, addressing potential race conditions, such as one user updating resources while another unsuspends the job was deemed critical but complex to test reliably. Given these challenges and the potential for unforeseen consequences when loosening API validation rules, the consensus shifted. It looks like the feature will now be introduced in an 'alpha' stage to allow for more iteration and the development of robust test coverage, ensuring the feature is stable and safe before being promoted.

 aims to address the version skew issues within Kubernetes clusters during upgrades or downgrades by ensuring that clients always interact with a complete view of the cluster's capabilities. To achieve this, the proposal introduces a proxying mechanism where an API server, upon receiving a request for a built-in resource it cannot serve locally, identifies and forwards the request to a peer server that can. This prevents misleading "404 Not Found" errors. Simultaneously, the feature implements 

Cloudsmith Blog

Kubernetes 1.36 – What you need to know

13 KubeCon Europe 2026 sessions not to miss

Kubernetes 1.35 – What you need to know

13 sessions not to miss at KubeCon and CloudNativeCon 2025

Kubernetes 1.34 – What you need to know

Kubernetes 1.33 – What you need to know

KubeCon London 2025 Recap: Cloud-Native Insights on Security, Wasm, and More

Cloudsmith is headed to Salt Lake City for KubeCon North America 2024