
[Published by Kubernetes co-authored with Aakanksha Bhende, Arujjwal Negi, Chad M. Crowell, Swathi Rao](https://kubernetes.io/blog/2025/11/26/kubernetes-v1-35-sneak-peek/)

As the release of Kubernetes v1.35 approaches, the Kubernetes project continues to evolve. Features may be deprecated, removed, or replaced to improve the project's overall health. This blog post outlines planned changes for the v1.35 release that the release team believes you should be aware of to ensure the continued smooth operation of your Kubernetes cluster(s), and to keep you up to date with the latest developments. The information below is based on the current status of the v1.35 release and is subject to change before the final release date.

### Deprecations and removals for Kubernetes v1.35

#### cgroup v1 support

On Linux nodes, container runtimes typically rely on cgroups (short for "control groups"). Support for using cgroup v2 has been stable in Kubernetes since v1.25, providing an alternative to the original v1 cgroup support. While cgroup v1 provided the initial resource control mechanism, it suffered from well-known inconsistencies and limitations. Adding support for cgroup v2 allowed use of a unified control group hierarchy, improved resource isolation, and served as the foundation for modern features, making legacy cgroup v1 support ready for removal. The removal of cgroup v1 support will only impact cluster administrators running nodes on older Linux distributions that do not support cgroup v2; on those nodes, the `kubelet` will fail to start. Administrators must migrate their nodes to systems with cgroup v2 enabled. More details on compatibility requirements will be available in a blog post soon after the v1.35 release.

To learn more, read [about cgroup v2](https://kubernetes.io/docs/concepts/architecture/cgroups/);  
you can also track the switchover work via [KEP-5573: Remove cgroup v1 support](https://kep.k8s.io/5573).

#### Deprecation of ipvs mode in kube-proxy

Many releases ago, the Kubernetes project implemented an [ipvs](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-ipvs) mode in `kube-proxy`. It was adopted as a way to provide high-performance service load balancing, with better performance than the existing `iptables` mode. However, maintaining feature parity between ipvs and other kube-proxy modes became difficult, due to technical complexity and diverging requirements. This created significant technical debt and made the ipvs backend impractical to support alongside newer networking capabilities.

The Kubernetes project intends to deprecate kube-proxy `ipvs` mode in the v1.35 release, to streamline the `kube-proxy` codebase. For Linux nodes, the recommended `kube-proxy` mode is already [nftables](https://kubernetes.io/docs/reference/networking/virtual-ips/#proxy-mode-nftables).

You can find more in [KEP-5495: Deprecate ipvs mode in kube-proxy](https://kep.k8s.io/5495)

#### Kubernetes is deprecating containerd v1.y support

While Kubernetes v1.35 still supports containerd 1.7 and other LTS releases of containerd, as a consequence of automated cgroup driver detection, the Kubernetes SIG Node community has formally agreed upon a final support timeline for containerd v1.X. Kubernetes v1.35 is the last release to offer this support (aligned with containerd 1.7 EOL).

This is a final warning that if you are using containerd 1.X, you must switch to 2.0 or later before upgrading Kubernetes to the next version. You are able to monitor the `kubelet_cri_losing_support` metric to determine if any nodes in your cluster are using a containerd version that will soon be unsupported.

You can find more in the [official blog post](https://kubernetes.io/blog/2025/09/12/kubernetes-v1-34-cri-cgroup-driver-lookup-now-ga/#announcement-kubernetes-is-deprecating-containerd-v1-y-support) or in [KEP-4033: Discover cgroup driver from CRI](https://kep.k8s.io/4033)

The following enhancements are some of those likely to be included in the v1.35 release. This is not a commitment, and the release content is subject to change.

#### Node declared features

When scheduling Pods, Kubernetes uses node labels, taints, and tolerations to match workload requirements with node capabilities. However, managing feature compatibility becomes challenging during cluster upgrades due to version skew between the control plane and nodes. This can lead to Pods being scheduled on nodes that lack required features, resulting in runtime failures.

The *node declared features* framework will introduce a standard mechanism for nodes to declare their supported Kubernetes features. With the new alpha feature enabled, a Node reports the features it can support, publishing this information to the control plane through a new `.status.declaredFeatures` field. Then, the `kube-scheduler`, admission controllers and third-party components can use these declarations. For example, you can enforce scheduling and API validation constraints, ensuring that Pods run only on compatible nodes.

This approach reduces manual node labeling, improves scheduling accuracy, and prevents incompatible pod placements proactively. It also integrates with the Cluster Autoscaler for informed scale-up decisions. Feature declarations are temporary and tied to Kubernetes feature gates, enabling safe rollout and cleanup.

Targeting alpha in v1.35, *node declared features* aims to solve version skew scheduling issues by making node capabilities explicit, enhancing reliability and cluster stability in heterogeneous version environments.

To learn more about this before the official documentation is published, you can read [KEP-5328](https://kep.k8s.io/5328).

#### In-place update of Pod resources

Kubernetes is graduating in-place updates for Pod resources to General Availability (GA). This feature allows users to adjust `cpu` and `memory` resources without restarting Pods or Containers. Previously, such modifications required recreating Pods, which could disrupt workloads, particularly for stateful or batch applications. Previous Kubernetes releases already allowed you to change infrastructure resources settings (requests and limits) for existing Pods. This allows for smoother [vertical scaling](https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/), improves efficiency, and can also simplify solution development.

The Container Runtime Interface (CRI) has also been improved, extending the `UpdateContainerResources` API for Windows and future runtimes while allowing `ContainerStatus` to report real-time resource configurations. Together, these changes make scaling in Kubernetes faster, more flexible, and disruption-free. The feature was introduced as alpha in v1.27, graduated to beta in v1.33, and is targeting graduation to stable in v1.35.

You can find more in [KEP-1287: In-place Update of Pod Resources](https://kep.k8s.io/1287)

#### Pod certificates

When running microservices, Pods often require a strong cryptographic identity to authenticate with each other using mutual TLS (mTLS). While Kubernetes provides Service Account tokens, these are designed for authenticating to the API server, not for general-purpose workload identity.

Before this enhancement, operators had to rely on complex, external projects like SPIFFE/SPIRE or cert-manager to provision and rotate certificates for their workloads. But what if you could issue a unique, short-lived certificate to your Pods natively and automatically? KEP-4317 is designed to enable such native workload identity. It opens up various possibilities for securing pod-to-pod communication by allowing the `kubelet` to request and mount certificates for a Pod via a projected volume.

This provides a built-in mechanism for workload identity, complete with automated certificate rotation, significantly simplifying the setup of service meshes and other zero-trust network policies. This feature was introduced as alpha in v1.34 and is targeting beta in v1.35.

You can find more in [KEP-4317: Pod Certificates](https://kep.k8s.io/4317)

#### Numeric values for taints

Kubernetes is enhancing [taints and tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/) by adding numeric comparison operators, such as `Gt` (Greater Than) and `Lt` (Less Than).

Previously, tolerations supported only exact (`Equal`) or existence (`Exists`) matches, which were not suitable for numeric properties such as reliability SLAs.

With this change, a Pod can use a toleration to "opt-in" to nodes that meet a specific numeric threshold. For example, a Pod can require a Node with an SLA taint value greater than 950 (`operator: Gt`, `value: "950"`).

This approach is more powerful than Node Affinity because it supports the NoExecute effect, allowing Pods to be automatically evicted if a node's numeric value drops below the tolerated threshold.

You can find more in [KEP-5471: Enable SLA-based Scheduling](https://kep.k8s.io/5471)

#### User namespaces

When running Pods, you can use `securityContext` to drop privileges, but containers inside the pod often still run as root (UID 0). This simplicity poses a significant challenge, as that container UID 0 maps directly to the host's root user.

Before this enhancement, a container breakout vulnerability could grant an attacker full root access to the node. But what if you could dynamically remap the container's root user to a safe, unprivileged user on the host? KEP-127 specifically allows such native support for Linux User Namespaces. It opens up various possibilities for pod security by isolating container and host user/group IDs. This allows a process to have root privileges (UID 0) within its namespace, while running as a non-privileged, high-numbered UID on the host.

Released as alpha in v1.25 and beta in v1.30, this feature continues to progress through beta maturity, paving the way for truly "rootless" containers that drastically reduce the attack surface for a whole class of security vulnerabilities.

You can find more in [KEP-127: User Namespaces](https://kep.k8s.io/127)

#### Support for mounting OCI images as volumes

When provisioning a Pod, you often need to bundle data, binaries, or configuration files for your containers. Before this enhancement, people often included that kind of data directly into the main container image, or required a custom init container to download and unpack files into an `emptyDir`. You can still take either of those approaches, of course.

But what if you could populate a volume directly from a data-only artifact in an OCI registry, just like pulling a container image? Kubernetes v1.31 added support for the `image` volume type, allowing Pods to pull and unpack OCI container image artifacts into a volume declaratively.

This allows for seamless distribution of data, binaries, or ML models using standard registry tooling, completely decoupling data from the container image and eliminating the need for complex init containers or startup scripts. This volume type has been in beta since v1.33 and will likely be enabled by default in v1.35.

You can try out the beta version of [`image` volumes](https://kubernetes.io/docs/concepts/storage/volumes/#image), or you can learn more about the plans from [KEP-4639: OCI Volume Source](https://kep.k8s.io/4639).

### Want to know more?

New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in [Kubernetes v1.35](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.35.md) as part of the CHANGELOG for that release.

The Kubernetes v1.35 release is planned for **December 17, 2025**. Stay tuned for updates!

You can also see the announcements of changes in the release notes for:

- [Kubernetes v1.34](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md)
- [Kubernetes v1.33](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.33.md)
- [Kubernetes v1.32](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.32.md)
- [Kubernetes v1.31](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.31.md)
- [Kubernetes v1.30](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.30.md)

### Get involved

The simplest way to get involved with Kubernetes is by joining one of the many [Special Interest Groups](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) that align with your interests. Have something you’d like to broadcast to the Kubernetes community? Share your voice at our weekly [community meeting](https://github.com/kubernetes/community/tree/master/communication), and through the channels below. Thank you for your continued feedback and support.

- Follow us on Bluesky [@kubernetes.io](https://bsky.app/profile/kubernetes.io) for the latest updates
- Join the community discussion on [Discuss](https://discuss.kubernetes.io/)
- Join the community on [Slack](http://slack.k8s.io/)
- Post questions (or answer questions) on [Server Fault](https://serverfault.com/questions/tagged/kubernetes) or [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Share your Kubernetes [story](https://docs.google.com/a/linuxfoundation.org/forms/d/e/1FAIpQLScuI7Ye3VQHQTwBASrgkjQDSS5TP0g3AXfFhwSM9YpHgxRKFA/viewform)
- Read more about what’s happening with Kubernetes on the [blog](https://kubernetes.io/blog/)
- Learn more about the [Kubernetes Release Team](https://github.com/kubernetes/sig-release/tree/master/release-team)


[Published by DZONE](https://dzone.com/articles/infrastructure-crossplane-kube-green)

We were all sold a compelling vision of cloud computing: one filled with agility, endless scalability, and remarkable cost savings. Yet, for many of us in the trenches, the daily reality looks quite different. We find ourselves wrestling with an infrastructure model built on long-lived, static environments for development, testing, and staging. This old way of working has quietly become a massive drain on our resources, creating financial waste, operational headaches, and a growing list of security and environmental debts.

This isn't just one problem; it's a vicious cycle. The friction in our daily operations directly fuels the financial, security, and environmental burdens. To break free, we need more than just a new tool; we need to fundamentally rethink how we provision, manage, and consume infrastructure.

## The High Cost of 'Always-On'

The most obvious symptom of this broken model is the money it wastes. It's not a small number; research suggests a staggering [30-45% of all cloud spending is wasted on idle or over-provisioned resources](https://42on.com/the-hidden-costs-of-cloud-waste-how-to-optimize-your-cloud-resources-and-reduce-environmental-impact/). This isn't surprising when you think about it. Our staging, UAT, and dev environments are built to handle peak loads, but they spend most of their lives (nights, weekends, holidays) doing absolutely nothing. This leads to an abysmal average CPU utilization of just 12-15%, a clear sign that something is deeply inefficient. This problem is made worse by "cloud sprawl", where new resources pop up uncontrolled, increasing costs, security holes, and complexity.

This financial drain is a direct result of operational friction. Many of us are familiar with the "ticket-driven" culture: a developer needs an environment, so they file a ticket and wait. And wait. This manual, slow process creates bottlenecks that grind the entire development lifecycle to a halt. In a world of complex microservices, setting these environments up by hand isn't just slow; it's a recipe for errors. This model encourages us to keep these costly, complex environments running indefinitely, because tearing them down and rebuilding them is just too painful.

This persistence creates a huge security risk. Over time, these static environments suffer from "configuration drift." Manual tweaks, untracked updates, and inconsistent patching mean they no longer match production or even each other. They become, as one source aptly put it, a ["hive of duplicated data, exploitable vulnerabilities, and misconfigurations"](https://www.quali.com/glossary/ephemeral-environments/). Each one is a persistent attack surface, a liability that only grows with time.

## The Unseen Environmental Toll

The money we waste on idle resources is just the tip of the iceberg. Under the surface lies a massive, often ignored, environmental cost. Every idle virtual machine or database isn't just a line item on a bill; it's a physical server in a data center, burning electricity and pumping out CO2 for no reason. Data centers already consume about [1% of the world's electricity](https://www.researchgate.net/publication/390569272_The_Environmental_Impact_of_Cloud_Computing_Sustainability_in_the_Cloud), and that number is only going up.

To put this in perspective, a 2019 study found that training a single large AI model can produce the same carbon emissions as [more than 300 cross-country flights](https://www.forbes.com/councils/forbestechcouncil/2025/02/20/the-unsung-mechanics-how-ai-and-cloud-integration-drive-the-engine-of-sustainability/). This is the energy cost of our digital world. Beyond emissions, there's e-waste from constant hardware upgrades and the immense amount of water used for cooling. While cloud providers are more efficient than on-premise data centers, the core problem remains: we, the customers, are provisioning resources that sit idle, driving unnecessary environmental impact.

Let's make this real. Imagine a team of 10 engineers with a single, static staging environment. It runs 24/7, but they only use it for about 160 hours a month. For the other 560 hours, nearly 78% of the time, it's idle but still racking up costs. Using the CO2 calculator from the [kube-green project](https://kube-green.dev/), which assumes that a single pod produces about [11 kg of CO2eq per year](https://kube-green.dev/docs/FAQ/#how-much-co2-is-produced-by-a-pod), we can see the impact. If that staging environment runs 20 pods, it generates 220 kg of CO2eq annually. By simply shutting it down when it's idle, the team could prevent over 170 kg of CO2eq emissions. Now, scale that across an entire organization. The waste is enormous.

## The Ephemeral Revolution

This is where a new idea comes in: the ephemeral environment. It’s a complete shift in thinking. Instead of permanent, long-lived infrastructure, we move to on-demand, temporary workspaces that directly combat waste and friction. An ephemeral environment is a short-lived, isolated, and complete copy of your application, spun up for a specific task and automatically destroyed when you're done.

This approach is built on a few key ideas. First, it's **on-demand and automated**. Environments are created by events in your workflow, like opening a pull request, not by filing a ticket. What once took days now takes minutes. Second, each environment is **completely isolated**. This means no more "who broke the staging server?" A developer can test a new feature, run a database migration, or experiment with a dependency without affecting anyone else. This enables true parallel development.

Crucially, these are not just simple "preview environments". A true ephemeral environment achieves **production-parity**. It’s a full-fidelity clone of your production stack: backend services, databases, configurations, everything. This is how you kill the "it works on my machine" problem for good. Finally, these environments are both **shareable and disposable**. You get a unique URL to share with stakeholders for feedback on a live, running feature. When the pull request is merged, the entire environment is wiped away as if it never existed. This disposable nature is the key to its efficiency.

Adopting this model has a transformative impact. It dramatically boosts developer velocity by removing bottlenecks. Some organizations have seen [delivery times improve by up to 35%](https://ephemeralenvironments.io/) and overall velocity increase by as much as 10x. It fosters better collaboration because everyone, from product managers to QA, can interact with a tangible, running feature, not just mockups. This "shift-left" approach to testing also means you catch bugs earlier, significantly improving code quality and reducing the risk of production failures. The old static staging environment is a relic of an old era: costly, slow, and risky. The ephemeral model is its opposite: on-demand, fast, safe, and efficient.

## The Technology Pillars: Crossplane and kube-green

This vision of a fully ephemeral cloud requires the right technology. You need to be able to programmatically control not just your application containers, but the entire infrastructure ecosystem: databases, networks, storage, and more. This is where two key open-source projects come into play: Crossplane and kube-green.

Crossplane is the heart of this architecture. It’s a universal control plane that extends the Kubernetes API to manage any cloud resource, not just containers. This represents a profound shift from traditional [Infrastructure as Code (IaC)](https://dzone.com/articles/what-is-infrastructure-as-code) tools like Terraform to a new model: [Infrastructure as Data (IaD)](https://medium.com/@swarupdonepudi/infrastructure-as-data-iad-coincidence-2ca6c70f896e).

With traditional IaC, you run a command like terraform apply to make a one-time change. With Crossplane, you declare the desired state of your infrastructure in a YAML file and submit it to the Kubernetes API. From then on, Crossplane's controllers work continuously to ensure reality matches your declaration. If anything drifts, Crossplane automatically corrects it. This "self-healing" capability is a game-changer.

It works through a clever, layered architecture. **Providers** teach Crossplane how to talk to a specific API, like AWS or GCP. **Managed Resources** are the building blocks, representing a single piece of infrastructure like an S3 bucket or an RDS database. But the real magic is in **Compositions**. A platform team can use a Composition to bundle all the necessary Managed Resources into a single, high-level abstraction, like a PostgreSQLInstance. This blueprint can embed all the company's best practices for security, networking, and compliance.

Developers don't need to worry about that complexity. They simply request what they need by creating a **Claim**: a simple YAML asking for a PostgreSQLInstance for example. Crossplane sees the claim and provisions the entire, production-ready stack automatically. This is true developer self-service, and it's exactly what's needed for ephemeral environments. When a pull request is opened, a CI/CD pipeline can create a single Claim that tells Crossplane to spin up a dedicated database, message queue, and everything else the application needs. When the PR is closed, deleting that one Claim tears it all down.

While Crossplane manages the existence of the environment, [kube-green](https://kube-green.dev/) handles the efficiency within that existence. An ephemeral environment might live for a few days, but developers aren't working on it 24/7. kube-green is a simple, brilliant utility that solves this "last mile" problem by automatically hibernating resources on a schedule.

It operates as a Kubernetes operator that you configure with a **SleepInfo** resource in each namespace. You can tell it to shut things down at 8 PM on weekdays and wake them up at 8 AM, for example. When the sleep time hits, kube-green scales down your Deployments and suspends your CronJobs. When the wake-up time arrives, it brings everything back to its original state. This simple action can lead to huge savings. Adopters have reported [30-40% reductions in cloud costs](https://kube-green.dev/docs/adopters/) for non-production clusters. And because it reduces energy consumption, it has a direct, positive impact on your carbon footprint.

## The Synthesis: A New Blueprint for Efficiency

When you combine Crossplane's strategic, full-stack orchestration with kube-green's tactical, time-based optimization, you get something truly powerful. This synergy creates a multi-layered system of efficiency that aligns your infrastructure cost and carbon footprint with the actual, value-generating work of your development teams.

The workflow, driven by GitOps tools like ArgoCD, is beautifully simple. A developer opens a pull request. This triggers a CI pipeline that generates the manifests for the new environment, including a Crossplane Claim for the infrastructure and a kube-green SleepInfo for the schedule. These manifests are committed to a Git repository. ArgoCD sees the new files and applies them to your management cluster. Crossplane springs into action, provisioning the entire infrastructure stack, perhaps in a lightweight vCluster for perfect isolation. Once the infrastructure is ready, ArgoCD deploys the application code. When the PR is merged or closed, a CI job removes the manifests from Git, and the entire environment vanishes.

This creates a two-tiered optimization model. **Macro-optimization** from Crossplane ensures you only pay for infrastructure for the few days a PR is active, not for a permanent staging environment. **Micro-optimization** from kube-green then eliminates waste within that short lifespan by hibernating resources during non-working hours.

This points to an exciting point: a "deep sleep" model. Using kube-green's ability to patch any Kubernetes resource, you could have it not only scale down pods but also patch the Crossplane Claim itself, for example, telling it to scale a database cluster down to a single, low-cost node overnight. This would extend time-based optimization to the entire stateful infrastructure stack, achieving the ultimate form of on-demand efficiency.

## Getting Started on Your Journey

While this vision of a fully automated, per-PR ephemeral world is the goal, you don't have to build it all at once. The journey can start with a single, high-impact step. To make these concepts tangible, I've put together a [hands-on tutorial](https://github.com/graz-dev/crossplane-ephemeral-environments) that focuses on a pragmatic starting point: creating on-demand infrastructure that's only active when you need it.

The tutorial walks you through using Crossplane to provision an AWS EKS cluster and then using kube-green to put it on a sleep/wake schedule. It's a direct, practical way to tackle the biggest source of waste: idle resources.

If this vision for a more efficient cloud resonates with you, the best way to understand it is to build it. I invite you to check out the tutorial, [Ephemeral Cloud Resources with Crossplane and kube-green](https://github.com/graz-dev/crossplane-ephemeral-environments). Dive in, experiment with the code, and see the benefits for yourself. If you find it valuable, please give the repository a star on GitHub and share this article with your network.

## A Strategic Outlook for the Future

The shift to an ephemeral cloud model is more than a technical upgrade; it's a strategic evolution. It allows us to move from passively managing static resources to actively orchestrating dynamic, value-generating capabilities. The future of this model is even more exciting, driven by AI-powered optimization and the formalization of GreenOps.

New AI tools like StormForge and CAST AI are emerging that can analyze workloads to automatically tune resource configurations and predict demand. Imagine an AI that could predict a PR's review cycle to allocate resources more intelligently or manage energy use based on the real-time carbon intensity of the power grid.

This model is also a foundational practice for GreenOps, the discipline of bringing environmental accountability to cloud operations. As sustainability becomes a key business metric, the ability to measure and minimize the carbon footprint of software development will be a major differentiator.

For technology leaders, the path forward is clear. Treat your internal infrastructure as a product and invest in a platform team to build out this capability. Foster a culture of accountability by making cost and carbon data transparent to your engineering teams. And start small. Pick a single service and use it as a pilot project to prove the value and build expertise.

The combination of Crossplane and kube-green offers a powerful and pragmatic toolkit to begin this journey. By adopting this new blueprint, you can accelerate innovation while dramatically reducing your financial and environmental costs.

Welcome to the personal website of Graziano Casto.

Graziano Casto 👋🏻

Cloud Native Friday Newsletter

Pods & Platforms

Latest Articles

Kubernetes v1.35: Timbernetes (The World Tree Release)

Kubernetes v1.35 Sneak Peek

Kubernetes v1.34: Of Wind & Will (O' WaW)

The Ephemeral Cloud: A New Blueprint for Infrastructure Efficiency With Crossplane and kube-green

Upcoming Talks