The cloud-native landscape brings incredible advantages, but it also introduces new security challenges, making safeguarding a top priority. In the traditional policy enforcement model, manual management leaves organizations vulnerable to inevitable breaches due to human error – a matter of 'when,' not 'if.' Enter Policy-as-Code (PaC), a game-changing approach that leverages code to define and manage policies, transforming rules and conditions into actionable directives. By keeping policy definitions in source code control, whenever a change is made, it can be tested, validated, and then executed. The goal of PaC is not to detect policy violations but to prevent them. In this session we delve into the practical implementation of a Policy-as-Code strategy for your organization using Rönd and Open Policy Agent, two powerful open-source projects that could help you to redefine your security paradigm.

Practical Policy-as-Code with OPA and a Managed Sidecar Container

The increasing complexity of software development presents significant risks and inefficiencies, especially for large enterprises. That’s why companies require a structured approach to streamline software delivery, with a focus on platform engineering and internal developer platforms. While existing literature often discusses platform engineering in terms of DevOps tool integration and infrastructure provisioning, its scope extends far beyond these aspects. To truly enhance service scalability and quality, platforms must prioritize data encapsulation and composability. This means addressing not just the IT infrastructure, but the entire organizational framework. Infrastructure management represents only the tip of the iceberg; to drive a successful platform engineering initiative, factors like data management and composability are equally crucial. Let’s delve into the unspoken truths of platform engineering by examining the fundamental principles necessary for a successful platform initiative.

Platform Engineering Untold Truths: Is It Just an Infrastructure Matter?

In a context where the ICT sector alone produces around the 1.4% of global CO2 emissions, adopting mindful resource usage is of paramount importance. One of the most challenging aspects about green software is understanding where to start. Before delving into more complex things, a good starting point is to raise awareness of the hidden ‘zombies’ within our infrastructure and then proceed to eliminate them. In this session, we’ll explore what green software is, its environmental and economic implications and how kube-green (an open source project listed in the CNCF landscape) immediately help us make our cloud infrastructures more sustainable.

An Open-Source First Step to Greenify Your Cloud Environments

The cloud-native landscape brings incredible advantages, but it also introduces new security challenges, making safeguarding a top priority. In the traditional policy enforcement model, manual management leaves organizations vulnerable to inevitable breaches due to human error – a matter of ‘when,’ not ‘if.’ Enter Policy-as-Code (PaC), a game-changing approach that leverages code to define and manage policies, transforming rules and conditions into actionable directives. By keeping policy definitions in source code control, whenever a change is made, it can be tested, validated, and then executed. The goal of PaC is not to detect policy violations but to prevent them. In this session we delve into the practical implementation of a Policy-as-Code strategy for your organization using Rönd and Open Policy Agent, two powerful open-source projects that could help you to redefine your security paradigm implementing an RBAC authorization mechanism over your APIs.

A Policy-as-Code Approach to RBAC Authorization

Platform engineering, digital platforms, platform maturity, platform-as-product… When we hear these terms, we often focus on the ‘what’: understanding what platform engineering is, what we mean by digital platforms, and what it means to apply a product mindset to platforms. However, mere knowledge of the ‘what’ is often not enough; the most curious among us have often asked about the ‘how’: how do I begin my journey into the world of digital platforms? Well, if you have ever found yourself hitting a wall when trying to understand how to start your journey in adopting a digital platform, you have found the workshop that suits you! In this interactive workshop, using a Platform Journey Map, we will play the role of a Solution Architect who has to guide real companies through their platform adoption journey. Yes, you heard that right, we will be playing, because the journey is presented as a board game where the players, our fantastic Solution Architects, must conquer spaces to mature their platform. In this workshop, we won’t just talk about digital platforms as mere orchestrators of infrastructure, but there will also be room to discuss software lifecycle, architecture modernization, business composability, and market use cases.

WORKSHOP | The Game of Platforms: A Guided Journey into the World of Digital Platforms

In today’s technological landscape, the synergy between Cloud Native technologies and Artificial Intelligence (AI) opens the stage to a myriad of unexplored challenges and opportunities. Dynamic, always-on and highly scalable infrastructures, typical of the Cloud Native paradigm, seamlessly integrate with AI’s need to rapidly prototype solutions and access vast computational resources. The convergence of these two worlds has exposed some gaps in the Cloud Native ecosystem that need to be addressed. At the same time, AI opens numerous opportunities for innovation that are yet to be explored. This talk will delve into the Cloud Native Artificial Intelligence (CNAI) paradigm as a holistic approach to unlocking the full potential of the cloud in managing AI workloads and aim to anticipate the growth opportunities that lie ahead for the Cloud Native world.

Challenges and Takeaways of Managing AI Workloads on Cloud

In rapidly expanding cloud-native ecosystem, managing distributed architectures feels like navigating stormy seas with waves of telemetry data. Yet this data can offer vital insights to sail smoothly. This session will explore strategies to avoid drowning, improving DevEx, and more. The cloud-native ecosystem has grown exponentially in the last few years, as has the complexity of the distributed architectures being built. In a context where keeping up with technology requires a substantial amount of computational power and data, monitoring our cloud-native applications has become a constant struggle against the storm. The ever-increasing volume of traces, metrics, events, and logs generated by our systems is a double-edged sword: on one hand, if not managed correctly, becoming a distraction from needed insights. On the other hand, if approached with care and thought, providing organizations the chance to sail calm cloud-native seas. In this session, we will discover how to avoid drowning in the sea of monitoring data, instead understanding how to provide insights while using only what is needed. We will explore the emerging scenarios on the horizon, abandoning the oars and testing the waters of artificial intelligence as it applies to our observability use cases. We will discuss how to leverage monitoring data, conversational DevEx, and anomaly prediction, among other topics, in this talk.

Finding Observability and DevEx Tranquility Sailing the Monitoring Data Seas

As a crucial part of a platform adoption journey, it’s essential to choose the right metrics to gain a clear, comprehensive view and drive success. While DORA metrics are valuable for platform teams, assessing platform adoption solely based on deployment frequency doesn’t make sense. Reflecting on our expertise, we’ve learned that measuring platform success involves two types of KPIs: progress metrics and outcome metrics. In this talk, we’ll explore how measuring both allows us to identify patterns and correlations between technical improvements and business success. By combining these two sets of KPIs, we gain a comprehensive view of the platform’s value. This approach helps stakeholders quantify the platform’s technical contributions while also understanding its influence on key business objectives. Ultimately, it enables us to set meaningful milestones for future improvements and effectively communicate the platform’s value across the organization.

From DORA to the SPACE and Beyond: Metrics to Drive Platform Engineering Initiatives

Monitoring the behavior of a system is essential to ensuring its long-term effectiveness. However, managing an end-to-end observability stack can feel like stepping into quicksand, without a clear plan you’re risking sinking deeper into system complexities. In this talk, we’ll explore how combining two worlds—developer platforms and observability—can help tackle the feeling of being off the beaten cloud native path. We’ll discuss how to build paved paths, ensuring that  adopting new developer tooling feels as seamless as possible. Further, we’ll show how to avoid getting lost in the sea of telemetry data generated by our systems. Implementing the right strategies and centralizing data on a platform ensures both developers and SREs stay on top of things. Practical examples are used to map out creating your very own Internal Developer Platform (IDP) with observability integrated from day 1.

When Platform Engineers Meet SREs: The Birth of Observability-as-a-Service Superpowers

Observability-as-a-Service: When Platform Engineers and SREs Join Forces

As the technology landscape evolves and the need for adaptability to solve modern problems grows, Function-as-a-Service (FaaS) has emerged as a pivotal strategy to meet the elasticity demands of today’s systems. However, a pressing question remains: how can we make our functions truly portable, with minimal overhead, while achieving the high level of dynamism promised by FaaS? The answer already exists, and you don’t need the Infinity Gems to make it happen. All you need is wasmCloud, a CNCF incubating project, and a few tips to take the right path in building your own FaaS platform using WebAssembly (WASM). In this talk, we will dive into the world of Functions-as-a-Service, sharing insights on building a FaaS platform from the ground up with WASM and wasmCloud. We’ll provide practical examples and demonstrate how to create paved paths that empower developers to build high-performance functions—effortlessly, as if snapping their fingers.

Platform Engineers Assemble! Create Your FaaS Platform Using WASM

As the world shifts toward renewable energy, the need to align computing workloads with the availability of green resources has never been more critical. In this talk, we’ll explore how Kubernetes can serve as a “compass”, guiding workloads across space and time to optimize energy efficiency. By leveraging temporal shifting to align workloads with periods of peak renewable energy generation and spatial shifting to dynamically move workloads to regions with surplus green energy, we’ll demonstrate strategies that not only reduce carbon footprints but also enhance cost-efficiency. Through real-world examples and practical insights, this session will showcase how temporal and spatial scheduling innovations can transform Kubernetes into a powerful tool for sustainable cloud operations. Join us to discover how to navigate the intersection of technology and sustainability, paving the way for a greener, smarter future.

The Kubernetes Compass: Navigating Space and Time for Energy Efficiency

In this session, we’ll explore how platform engineering enables the seamless delivery of an AI-powered agentic architecture—from deploying open-source models to building and releasing a simple agent that interacts with real-world applications. Through a joint demo by Mia-Platform and ConfidentialMind, we’ll demonstrate how a GPU-powered cluster hosts both the ConfidentialMind Control Plane and the AI models, while the Mia-Platform Console serves as the unified entry point for developers. We’ll walk through the creation of a multi-tool agent built from templates available on the Mia-Platform Marketplace and powered by models deployed using the ConfidentialMind Control Plane. This agent interacts with our data to act as a shopping assistant for customers, providing product recommendations, stock availability, and suggestions for the nearest store based on the user’s location. Attendees will gain a clear understanding of how platform engineering practices simplify the complexities of AI model deployment, application development, and runtime management in a production-grade, scalable environment.

How Platform Engineering Streamlines the End-to-End Delivery of a Self-Hosted Agentic Architecture

Monitoring the behavior of a system is essential to ensuring its long-term effectiveness. However, managing an end-to-end observability stack can feel like stepping into quicksand. In this talk, we’ll explore how combining two worlds, developer platforms and observability, can help tackle the feeling of being off the beaten cloud native path. We’ll discuss how to build paved paths, ensuring that adopting new developer tooling feels as seamless as possible.

ROUNDTABLE | When Platform Engineers Meet SREs: The Birth of Observability-as-a-Service Superpowers

APIs are more than just tools; they are the foundation for building scalable and sustainable digital products. This talk explores how circular design principles can improve the way APIs are developed and used, enhancing the developer experience and delivering long-term value. Through real-world examples, we’ll explore how to leverage platforms designed to enable a circular API economy that emphasizes reusability, modularity, and interoperability to drive innovation, reduce technical waste, and foster collaboration. If you’re looking to build products that not only scale but also evolve gracefully and efficiently, this talk is for you. In API we trust!

In API We Trust: Circular Design for Scalable Platforms

Why keep your cluster alive when you’re not using it? Let it bite the dust, every night, and that’s just fine. With Crossplane and kube-green, you can unlock ephemeral environments that spin up when you code and shut down when you rest. Imagine a development setup that dynamically provisions complex infrastructure for testing, then automatically scales down during off-hours – like nights and weekends. In this talk, we’ll show you how Platform Engineering can orchestrate this smart, on-demand model, so developers can focus on building applications, not babysitting clusters. You’ll see the integration in action, explore the impact on cost, efficiency, and sustainability, and discover how to shift from static uptime to dynamic, eco-friendly infrastructure. Save money, reduce emissions, and let your clusters rest – because we will rock you, but not all night long.

Another Cluster Bites the Dust... and That's Just Fine!

Perché mantenere acceso il tuo cluster quando non lo stai usando? Fai in modo che si spenga ogni notte! Con Crossplane e kube-green, puoi creare ephemeral environments che si attivano quando lavori e si spengono quando ti riposi. Immagina una configurazione che faccia il provisioning dinamico di un’infrastruttura complessa per i test, per poi spegnersi automaticamente durante le ore non lavorative come durante la notte o nei fine settimana. In questo talk, ti mostreremo come un IDP (Internal Developer Platform) può aiutare ad orchestrare in modo intelligente e on-demand la tua infrastruttura, in modo che gli sviluppatori possano concentrarsi sul creare applicazioni e non sul fare da babysitter ai cluster. Vedrai come funziona l’integrazione, esplorerai l’impatto su costi, efficienza e sostenibilità e scoprirai come passare da un infrastruttura statica a una dinamica ed eco-friendly. Risparmia denaro, riduci le emissioni e lascia riposare i tuoi cluster. Perché we will rock you, ma non per tutta la notte.

Another Cluster Bites the Dust… E Va Bene Così!

Get ready for a provocative and engaging session that challenges the very notion of who, or what, can deliver a compelling presentation! In this talk, an AI agent will be built right before your eyes. Using the Google ADK framework and Gemini, this agent will scour the internet, prepare a presentation, and then deliver it. But here's where it gets really interesting: by the end of the session, you, the audience, will choose the topic the AI agent has to talk about. This raises some fascinating questions: Can the information it presents be trusted? What does this mean for the future of knowledge and communication when an AI can 'speak' with authority? Join us to find out if an AI can truly become the speaker in the room!

Can an AI Agent Give a Talk? Let's Find the Speaker in the Room!

Generative AI is rapidly changing how we build software. With powerful language models (LLMs) and the growing availability of smaller, more accessible models (SLMs), we are entering a new phase of development where intelligent agents play a central role. Just like we once moved from procedural programming to object-oriented programming, we are now moving toward a model where software is built around interactions between AI agents. In this new approach, APIs are essential. They are how agents connect to the outside world, talk to each other, and work with existing systems. In this talk, we’ll look at how to design software based on agent interactions, with a special focus on how APIs make this possible. We’ll explore how generative models can power agents that use APIs, expose APIs, and coordinate tasks through APIs. You’ll also learn practical patterns for building systems where multiple agents collaborate effectively using clear and well-defined interfaces.

SLMs and the Agents Revolution: Rethinking How Software Is Built

Explore how to efficiently serve Large Language Models on Kubernetes clusters, covering resource optimization, scaling strategies, and best practices for platform engineers managing AI workloads in production environments.

Serving LLMs on Kubernetes: A Golden Path for Platform Engineers

Learn advanced techniques for optimizing Kubernetes clusters for energy efficiency, including intelligent scheduling, resource management, and sustainable cloud-native practices that reduce environmental impact while maintaining performance.

Join industry leaders in a panel discussion about the evolution of developer portals, exploring trends in developer experience, platform engineering, and the tools that will shape the future of software development workflows.

PANEL | The Future of Developer Portals

Similar to previous Kubernetes releases, v1.35 introduces new stable, beta, and alpha features, consisting of 60 enhancements. Of those, 17 have graduated to Stable, 19 have graduated to Beta, and 22 are entering Alpha. Tune in to see the latest and greatest from the Kubernetes v1.35 Release Team!

Cloud Native Live: Kubernetes v1.35 Release

We love ArgoCD, but it creates a classic 'map vs. territory' problem. We treat Git as our 'map', our single source of truth. But the cluster is the 'territory', and it's often more complex than the map shows. This becomes a crisis with the 3 AM hotfix: an SRE fixes production, changing the territory. ArgoCD, loyal to the map, sees this as drift and helpfully overwrites the fix, re-breaking the cluster. The problem is that Git isn't our Truth, it's our Intention. This talk introduces a pragmatic solution: Cluster-Scoped Snapshotting. We’ll show a simple pattern that dumps the entire live cluster state (the 'territory') into its own 'reality' Git repo. To automate this, we wrote a small open-source tool called Kalco, but the pattern is the real takeaway. This 'reality' repo gives us a powerful 'pre-flight diff' in our CI pipeline, comparing our 'intention' (the app repo) against the 'truth' (the snapshot repo). This simple check lets us bootstrap existing clusters, create a complete audit log, and stop our pipeline before it merges a change that conflicts with a critical live fix.

Your Cluster is Lying to ArgoCD (And How to Catch It)

We have spent the last five years building 'Golden Paths' to help developers deploy faster. But the moment the application hits production, the path ends. We leave developers alone with a dashboard of squiggly lines and ask them to 'fix the performance'. This is not Platform Engineering; this is just fancy provisioning. The next evolution of the Internal Developer Platform (IDP) isn't about deploying code, it's about optimizing it. In this talk, we will explore how to build a Continuous Optimization Layer directly into your platform. We will see how to pipe Prometheus telemetry back into the deployment manifest, creating a closed loop where the platform automatically suggests runtime tuning, from Kubernetes limits to application runtime flags, without the developer ever touching a YAML file.

The Self-Improving Platform: Closing the Loop Between Telemetry and Tuning

Beyond Deployment: Mapping the Reality of Day 2 Operations in Platform Engineering

Observability gets tricky when you take Kubernetes to the Edge. Sending full traces and metrics upstream doesn’t scale when every byte and millisecond count. This talk introduces an ultra-optimized OpenTelemetry Micro-Collector strategy built for Edge environments. It demonstrates how to minimize overhead without losing visibility by applying smart data reduction techniques like Tail-Based Sampling and Lossless Batching directly on the device, ensuring that only high-value telemetry such as errors and slow requests leave the Edge. The session covers how to deploy a lightweight DaemonSet tuned for K3s or MicroK8s using the OpenTelemetry Collector Contrib, integrate Fluent Bit for unified log ingestion, and maintain data integrity during disconnections. It shows what it takes to make observability truly sustainable in constrained Edge environments.

Making Observability Work at the Edge

As CNCF efforts evolve beyond infrastructure, improving the developer experience has become a central focus. The rebooted CNCF Technical Advisory Groups introduced TAG Developer Experience (TAG DevEx) to drive concrete, impactful outcomes across projects and their communities. This panel will showcase how TAG DevEx reduces friction in developer workflows, advances best practices, and delivers resources that benefit contributors and end users alike. We’ll highlight key initiatives and how TAG DevEx helps maintainers adopt a developer-first mindset. We’ll also discuss our ongoing efforts, including research around success stories and pain points from adopting secure coding practices, the emerging role of agentic AI in development, and a working group defining a specification for declaring application integration dependencies. Join us to learn how TAG DevEx is shaping the next generation of cloud native developer experience—and how you can get involved.

The Next Chapter of Developer Experience: TAG DevEx in Action

Mettere in piedi un’infrastruttura solida è solo l’inizio. La vera sfida è scalarla senza che i costi o la complessità gestionale vadano fuori controllo. In questo talk vedremo perché il Platform Engineering e l’Autonomous Optimization sono le due facce della stessa medaglia. Scopriremo come una moderna Internal Developer Platform (IDP) permetta di costruire i 'binari' (un’infrastruttura standardizzata e sicura) e come l'integrazione di sistemi di ottimizzazione autonoma agisca da 'pilota automatico', usando l'IA per decidere i parametri migliori in tempo reale. Smetti di combattere con i file YAML: impara a progettare un sistema che non solo funziona, ma impara a dare il massimo spendendo il minimo.

Da Zero a Cento: Costruire un’Infrastruttura che si Auto-Ottimizza

Modern runtimes like Java, Go, and Node.js face a critical 'resource gap'. They require a massive CPU burst for JIT compilation or dependency loading, only to settle into a much leaner steady state seconds later. Historically, we had to over-provision Pods for this peak, wasting thousands of cores across clusters. With In-Place Pod Resize in Kubernetes v1.35, we can finally implement a startup boost strategy. This session moves beyond the theory to show the technical 'how-to' where we will demonstrate how to build a reactive workflow that provisions high initial resources and then 'shrinks' the footprint silently via the resize sub-resource. Beyond the 'how-to', we must address the 'shrinkage trap' and explain how to time the resource reclamation to avoid aggressive CPU throttling immediately after boot. We will compare different implementation patterns including sidecar-driven patches, a dedicated boost-operator, and the native Vertical Pod Autoscaler, ensuring your applications don't just start fast but stay stable. Stop paying for peak startup power during hours of steady-state operation.

Stop Overprovisioning for Application Startup

Horizontal scaling is often the default response to increased load on Kubernetes, but it can mask deeper inefficiencies within the single pod. At EssilorLuxottica, we discovered that adding more replicas often just scales the waste. If a single pod isn't optimized, you aren't scaling, you are just over-spending until you hit the HPA maxReplicas limit and the system eventually fails. In this interactive 'choose your own adventure' session, we will re-live our optimization journey. The audience will decide the configuration: should we tweak the runtime heap or the K8s resource limits? Using data from our actual experiments, we’ll see the impact on throughput and costs, explaining the technical 'why' behind each result. We’ll show that true efficiency comes from the synergy between runtime settings and pod configurations. You’ll learn how to integrate automated experimentation into your delivery process to replace guesswork with data. This approach allowed us to reduce memory by 56% and costs by 30% while ensuring the system remains stable under load.

Stop Hiding Kubernetes Pod Inefficiencies With Horizontal Scaling

There is a silent war happening in your organization. The Finance team demands lower cloud bills, Product demands faster features, and Reliability demands zero downtime. Only a platform that helps you build efficient service by design could solve it.

Making Efficiency a Platform Capability


[Published by VMBlog](https://vmblog.com/bylines/making-efficiency-a-platform-capability/)

In most companies, there is a constant battle happening between three distinct forces.

On one side, you have the **FinOps** team. They are looking at the cloud bill and demanding we cut costs. On the other side, you have the **Product** teams. They want features delivered fast and the application to be lightning-quick for users. And then there is the **SRE** team. Their main goal is to make sure the site never goes down, which often means they are afraid of changing things too quickly.

The problem is that the person caught in the middle of this three-way fight is the Developer.

We expect developers to write quality business code, but also to satisfy the cost team (don't waste CPU!), the performance team (make it fast!), and the reliability team (don't break production!). We try to solve this by creating "Best Practices" blueprints including long checklists, and then meetings and spreadsheets. But this approach fails. It creates overhead and "cognitive load", too much information for one person to handle. The teams end up working in silos, fighting over priorities, and often, nobody is happy.

To fix this organizational mess, we need to stop drowning humans, rather empower them. We need to stop relying on manual checklists and start building a platform where balancing cost, performance, and reliability is not manual, but an **invisible capability of the platform itself**, working for the humans.

We can do this by automating the feedback loop at two specific points: before the code ships, and after it goes live.

## From Static Validation to Automated Tuning

The industry has done a great job of "shifting left" on security and unit testing. We wouldn't dream of merging code that fails a syntax check. Yet, we routinely merge code that completely changes the performance profile of our application without adjusting the infrastructure that runs it.

When a developer changes the code, it creates a ripple effect. A new library might change how the application behaves, perhaps increasing the pressure on the Heap or changing the garbage collection pattern. If we don't adjust the container limits to match, we risk crashes. If we don't update the [Horizontal Pod Autoscaler (HPA)](https://kubernetes.io/docs/concepts/workloads/autoscaling/horizontal-pod-autoscale/) triggers, the application might scale too slowly under load. And if the underlying Node Instance type is computed-optimized while the new code is memory-hungry, we are simply burning money.

Imagine a platform capability that acts as a smart optimization engine for the entire stack. When a developer opens a Pull Request, the platform uses [Argo Workflows](https://argoproj.github.io/workflows/) to orchestrate a series of rapid experiments. Driving this process is a **Reinforcement Learning** engine. It analyzes the results of each iteration, how the code, the runtime, and the infrastructure interacted. If the first test showed low latency but high memory waste, the engine learns from this and intelligently selects the next set of parameters to test, perhaps adjusting the Heap or the HPA trigger.

It simulates reality, converging on an **optimal configuration** before the code ever reaches production. By validating this interplay automatically, the pipeline stops being a simple "Pass/Fail" gate. It becomes a tuning engine that ensures the code, the runtime, and the infrastructure are working in harmony.

This way, the developer has the confidence that they are shipping a production-ready artifact, not just lines of code, eliminating the anxiety of deployment day.

![](/images/blog/making-efficiency-a-platform-capability/img-1.png) 

## Closing the Loop with Intelligent Analysis

While tuning ahead of the release is crucial for establishing a solid baseline, performance **simulations are never a perfect mirror of reality.** The most valuable data we have is the **actual behavior of our applications under real user traffic**.

Most organizations treat production metrics as a fire alarm: something to look at only when things break. But a mature platform uses these metrics as a constant feedback loop to optimize the system. This goes far beyond standard autoscaling. We aren't just trying to replicate a [Vertical Pod Autoscaler (VPA)](https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/) that reacts blindly to CPU spikes.

We are looking to build an intelligent analysis engine that understands the context of a release. When we deploy a new version, perhaps using a [Canary rollout](https://www.cncf.io/blog/2023/05/04/mastering-deployment-strategies-a-comprehensive-guide-to-blue-green-canary-and-more/) strategy via [Argo Rollouts](https://argoproj.github.io/rollouts/), we should capture performance data for that specific "fresh" state over a defined period, say, one week after release.

By analyzing this specific time window, we get a clear picture of how the new code behaves under real user traffic compared to the previous version and the platform can then generate a recommendation. If the new version is consistently using only 10% of its requested CPU during its first week, the system shouldn't just log it but, it should generate a tangible artifact, like a Pull Request (like having a [*Dependabot*](https://github.blog/news-insights/product-news/keep-all-your-packages-up-to-date-with-dependabot/) but for efficiency), suggesting a "right-sized" configuration for the next deployment.

Blindly considering only Kubernetes is where many platforms fall short: they focus entirely on Kubernetes resources (CPU/Memory requests and limits) and ignore what is happening *inside* the container.

You cannot effectively tune a container's limit if the application runtime is misconfigured. For example, if you lower the memory limit of a Java container but leave the JVM Heap size too high, the application will crash (OOMKill). If you squeeze the CPU limit of a Node.js application without understanding its event loop behavior, you introduce latency.

Our feedback loop must correlate container metrics with runtime metrics. The recommendation shouldn't just be "lower your memory limit" but it should be: "your JVM heap usage is stable at 512MB, but you requested 4GB. We recommend lowering the container limit to 1GB *and* adjusting the *\-Xmx* flag to 512MB".

When we optimize at the workload level, we trigger a positive ripple effect throughout the entire cluster.

If we accurately tune the requests and limits based on this analysis, we provide the HPA with cleaner signals: if the requests are wrong, the HPA scales too early (waste) or too late (downtime).

Furthermore, accurate workload sizing directly impacts the density of our clusters. When pods are bloated with unnecessary resource requests, the scheduler cannot fit them efficiently, forcing us to spin up more nodes than we actually need. Optimized pods mean higher density, fewer nodes, and significantly lower cloud bills. 

![](/images/blog/making-efficiency-a-platform-capability/img-2.png)

## Forecasting and Capacity Planning

Once we have this deep, historical data on workload behavior, we can zoom out from the single microservice to the entire infrastructure.

By analyzing usage trends over longer periods, months or a full year, we can move from reactive tuning to proactive forecasting identifying seasonal patterns and predict when specific clusters will face pressure allowing us to make smarter decisions about the underlying hardware.

For example, by looking at the aggregate "allocatable vs. allocated" capacity ratio over time, we might realize that our current node instance types are inefficient. We might be paying for high-memory instances when our aggregate workload is actually CPU-bound.

We stop guessing what hardware we need and start letting the data dictate the infrastructure supply.

## Why Efficiency As A Platform Capability?

ThoughtWorks has introduced the concept of "[Fitness Functions](https://www.thoughtworks.com/radar/techniques/architectural-fitness-function)" as automated checks that ensure the system satisfies architectural goals (like performance, security, or stability) as it evolves.

I believe we can all agree on that. The big question is how to get there.

To build a platform that ensures performance, security, and stability, we need to build a platform that improves itself. Performance and reliability need to become capabilities provided by the platform, autonomous, continuous, and invisible to the human, albeit at their service.

By implementing these two entry points, rigid performance gates in the pipeline and intelligent, runtime-aware feedback loops in production, we remove the cognitive load from our developers and solve the **delicate balance between costs, performance and reliability**. We don't ask them to be experts in Kubernetes resource management or capacity planning. We simply provide a "[paved path that handles the heavy lifting](https://netflixtechblog.com/full-cycle-developers-at-netflix-a08c31f83249)", as Dianne Marsh (Director of Engineering @ Netflix) defines platforms.

If we accomplish this, the tension between velocity and excellence disappears. Speed becomes safe, and efficiency becomes automatic. That is the true promise of a modern platform.


[Published by Medium on Javarevisited](https://medium.com/javarevisited/i-watched-a-microsoft-java-champion-talk-about-k8s-efficiency-here-is-what-i-learned-c4811d10f7d4)

![](https://miro.medium.com/v2/resize:fit:640/format:webp/1*ll2hKizQntwQn_7EYfYImg.png)

Java is the backbone of enterprise software, and Kubernetes is the operating system of the cloud. It would be logical to assume that by 2026, these two giants would work perfectly together out of the box. Yet, after attending a [recent deep-dive session](https://akamas.io/events/java-on-kubernetes-lessons-in-performance-engineering-with-akamas-and-microsoft/) between [**Bruno Borges**](https://www.linkedin.com/in/brunocborges/) (Principal Product Manager at Microsoft and Java Champion) and [**Stefano Doni**](https://www.linkedin.com/in/stefanodoni/) (CTO at [Akamas](https://akamas.io/)), I realized that this assumption is costing companies a fortune in **wasted resources** and **performance issues**.

[Analyzing telemetry from thousands of production JVMs](https://akamas.io/resources/the-state-of-java-on-kubernetes-2026-why-defaults-are-killing-your-performance/), the data they presented was sobering: the vast majority of Java workloads on Kubernetes are running with *default configurations* that are actively damaging applications.

Here are the four critical lessons I took away from the session.

## Lesson 1: “Container-Aware” doesn’t mean “Container-Optimized”

The first major misconception is about memory configuration. We are often led to believe that modern Java versions are “container-aware”, which implies the JVM sees container limits and configures itself optimally. In reality, the JVM is aware of the limits but operates on a **conservative** configuration. If an explicit heap size is not set, the JVM typically defaults to using only **25%** of the memory limit for the heap.

This default configuration leads to a huge waste of resources. For instance, if a container has 1 GB of RAM, the JVM may allocate only 256 MB of heap size. This practice is common, with the majority of surveyed JVMs running with no more than 1 GB of RAM and 1 CPU.

> “Yes, if you don’t set the heap size, you are wasting resources, and as we saw in the data, most containers have at least 1 GB of RAM and with 1 GB of RAM, you’re allocating 256 MB of heap size.” — Bruno Borges

This conservative default is a legacy of an era when the JVM was designed to share server resources and avoid consuming all available memory. However, in a containerized environment where resources are guaranteed, this conservative behavior prevents the JVM from maximizing resource utilization.

## Lesson 2: “Micro-Containers” are a latency trap

The trend of using “Micro-Containers”, often assigning less than one CPU, creates a fundamental architectural conflict for Java. Java is a highly multi-threaded engine, relying on background threads for core tasks like **Garbage Collection (GC)** and the **Just-In-Time (JIT)** compiler.

You have to imagine the Kubernetes CPU limit not as a speed limit, but as a *time quota*. If you give a container half a CPU (500m), you get 50 milliseconds of runtime every 100 milliseconds. But Java is a Just-In-Time (JIT) compiled language: when compilation starts, it consumes that quota instantly.If the JVM is not given enough CPU, all utilization may go to GC or JIT, preventing the business code from running. The result is application freezing and high latency, which developers often mistake for high user load.

> “You think it’s because of too many users are hitting the web service when in reality it’s because the garbage collector is working and that’s where CPU throttling is happening.” — Bruno Borges

## Lesson 3: Scaling out can make things worse

Adding more pods (horizontal scaling) can worsen performance if each pod is too small. The JVM is a highly multi-threaded engine that requires resources for internal management threads, such as the GC and JIT compiler. In a small container, these internal threads fight the business logic for limited CPU. If the JVM is not given enough CPU, it spends most of its time performing its own internal work, not the business work.

The data presented in the webinar showed that a strategy of using small containers and many replicas can actually **result in resource waste**.

> “I would say that’s that’s okay, but do consider if running slightly bigger containers with slightly fewer instances will give you the same amount of resource utilization. You’re still using the same amount of CPU and memory, but will give you much better performance because now the JVM has room to breathe. The JVM has room to operate at a more stable level.” — Bruno Borges

A strategy of slightly increasing the CPU for existing replicas instead of drastically increasing the replica count is recommended for most of the JVM workloads.

## Lesson 4: The “silent” GC switch

A significant trap lies in Garbage Collector (GC) ergonomics. The JVM automatically selects its default GC algorithm based on the amount of memory and CPU it detects. If developers test their applications in generous staging environments, the JVM is likely to use a high-performance GC, like G1GC. However, if that same code is deployed to small, “cost-optimized” production containers with insufficient CPU or memory, the JVM may silently downgrade to the single-threaded **SerialGC**.

SerialGC is rarely explicitly configured by developers. While it can be fine for most applications, it often leads to severe tail latency due to its “stop the world” mechanism. The core issue is the unexpected switch from the tested runtime to a different one.

> “The default depends on how much memory and how much CPU you have, which again if it’s not enough CPU or memory you actually default to Serial GC, which can be great for most applications.” — Bruno Borges

This silent GC downgrade prevents developers from comparing performance against a consistent baseline.

## Stop Guessing

The conclusion of the discussion wasn’t to suggest a single magic flag. The point is that manual tuning at scale has become impossible. You cannot solve the three-variable equation of throughput, latency, and cost by guessing.

![](https://miro.medium.com/v2/resize:fit:640/format:webp/1*pd1rqA_XRA7laBugN3UypA.png)

This is where [**Akamas Insights**](https://akamas.io/insights/) comes into play. Instead of manually auditing YAML files, Akamas connects to your observability stack and runs a comprehensive, automated health check. It tells you immediately where you are wasting memory due to the “25% trap”, where CPU throttling is killing your latency, and how to right-size your containers to stop flying blind.


[Published by Akamas](https://akamas.io/resources/the-state-of-java-on-kubernetes-2026-why-defaults-are-killing-your-performance/)

Java is the backbone of enterprise software, and Kubernetes is the standard for deployment. You would assume that by 2026, these two technologies would work perfectly together out of the box.

The data confirms Java’s dominance: according to the [**Azul State of Java Survey 2025**](https://www.qbssoftware.com/wp-content/uploads/2025/04/Azul-report-State-of-Java-2025.pdf), **68% of enterprises** report that the majority of their applications run on the JVM. Furthermore, [**New Relic’s 2024 State of the Java Ecosystem**](https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem) found that adoption of container-friendly Java versions like Java 17 and 21 has surged by nearly **300%**, proving that Java is being aggressively modernized for the cloud.

Unfortunately, while adoption is high, performance and efficiency are low.

In our [**recent webinar**](https://akamas.io/events/java-on-kubernetes-lessons-in-performance-engineering-with-akamas-and-microsoft/), **Stefano Doni** (CTO at Akamas) and **Bruno Borges** (Principal Program Manager at Microsoft and Java Champion) analyzed the state of the industry. After reviewing data from thousands of JVMs running in production environments globally, the verdict was clear: **the majority of Java workloads on Kubernetes are running with “default” settings that are actively hurting performance and wasting money.**

Here is a look at what the data says, why “safe” defaults are dangerous in the cloud, and how you can fix it.

## How Are We Configuring JVMs?

The premise of modern DevOps is automation and efficiency. However, the reality is that most organizations are “lifting and shifting” their Java applications into containers without adjusting the Java Virtual Machine (JVM) configuration.

This isn’t a new problem, but it is getting worse. During the session, **Bruno Borges** referenced historical data from **New Relic**, highlighting that for years, over 65% of workloads lacked explicit Garbage Collection (GC) tuning.  
  
But that was about 5 years ago. How is the situation now? **Stefano Doni** then presented **Akamas’s 2025 research**, analyzing thousands of Java workloads being optimized in our platform. The data confirms that despite the maturity of Kubernetes and Java, these bad habits persist today.

![Bar chart showing distribution of explicitly configured garbage collectors in Java workloads on Kubernetes](https://akamas.io/wp-content/uploads/2026/02/java-kubernetes-benchmark-throughput-latency-2.png-2-e1770733384950-1024x630.png)

Bar chart showing distribution of explicitly configured garbage collectors in Java workloads on Kubernetes

According to our data:

- **60% of JVMs have an unset Garbage Collector.** This means the JVM picks a default algorithm that might not be optimized for your specific container size or latency requirements.
- **The majority of Heap configurations are unset.** Most developers rely on the JVM’s automatic memory management.
- **Most containers are too small.** A significant number of JVMs run with **less than 1 CPU or less than 1 GiB of RAM**, which is a major bottleneck for Java’s multi-threaded architecture.
![Bar chart showing distribution of CPU core allocations in Java Kubernetes pods](https://akamas.io/wp-content/uploads/2026/02/java-garbage-collector-configurations-2025.png-e1770733435167-1024x623.png)

Bar chart showing distribution of CPU core allocations in Java Kubernetes pods

![Bar chart showing JVM max heap size distribution in Kubernetes environments](https://akamas.io/wp-content/uploads/2026/02/pod-cpu-core-distribution-kubernetes-java.png-e1770733463674-1024x626.png)

Bar chart showing JVM max heap size distribution in Kubernetes environments

Why is this happening? As Bruno Borges highlighted, many developers assume *“the JVM will tune itself”*. While the JVM *ergonomics* are smart, they were originally designed for large, shared physical servers, not for the constrained resources of isolated Kubernetes pods.

> *Ergonomics is the process by which the Java Virtual Machine (JVM) and garbage collection tuning, such as behavior-based tuning, improve application performance. The JVM provides platform-dependent default selections for the garbage collector, heap size, and runtime compiler. These selections match the needs of different types of applications while requiring less command-line tuning. In addition, behavior-based tuning dynamically tunes the sizes of the heap to meet a specified behavior of the application.*
[*Oracle Java Documentation*](https://docs.oracle.com/en/java/javase/25/gctuning/ergonomics.html)

The reality is that default JVM heuristics are far from optimal and can have an invisible but significant impact on your workloads.

### Wasting Cloud Resources

The most common mistake is leaving the Heap Size unset (no ***\-Xmx*** or ***\-XX:MaxRAMPercentage***).

Modern JVMs (Java 10+) are “container-aware”, meaning they attempt to self-configure based on the resources assigned to the container. However, this default behavior is incredibly conservative. For typical production containers (specifically those allocated above 512MB of memory), the JVM defaults to utilizing only **25% of the container memory limit** for the Heap.

*Note: For very small containers (<256MB), the JVM acts differently, taking up to 50%, but most enterprise workloads fall into the larger category where the 25% rule applies.*

This default creates a paradoxical situation regarding resource efficiency. Imagine you configure a pod with **2GB of memory requests and limits**. You are reserving 2GB of cluster capacity for that container. However, because you relied on defaults, the JVM sees that limit but decides to allocate only **512MB** to your application’s heap, the remaining 1.5GB is technically available for **non-heap memory** but a typical microservice rarely requires 1.5GB of overhead. You are effectively leaving almost 75% of your available memory “on the table” paying for capacity your application is strictly forbidden from touching.

Beyond the waste, this configuration directly undermines performance and stability. Because the heap is artificially restricted to a small fraction of the available memory, your application fills it up much faster than necessary. This triggers frequent and aggressive Garbage Collection cycles to reclaim space, leading to CPU spikes and potential latency issues, even though the container itself has plenty of free memory available.

## What happens when you leave your GC Unset?

The selection of a Garbage Collector (GC) is the single most impactful factor on application latency and throughput.The research data indicates that nearly 60% of Java workloads leave the Garbage Collector type unset. This forces the JVM to rely on its ergonomics to choose an algorithm for you.

By default, modern Java versions prefer the **G1GC** collector, designed for high throughput and low latency. However, the JVM only enables G1GC if it detects enough resources (at least **2 CPUs** and **1791MB of RAM)**.

![JVM ergonomics in Kubernetes: automatic garbage collector selection based on memory and CPU thresholds](https://akamas.io/wp-content/uploads/2026/02/jvm-max-heap-size-distribution.png-1024x570.png)

JVM ergonomics in Kubernetes: automatic garbage collector selection based on memory and CPU thresholds

If you deploy a microservice with a standard “cost-saving” configuration of **1 CPU or less**, the JVM silently downgrades the Garbage Collector to **SerialGC**. Unlike G1GC, which runs concurrently, SerialGC performs memory cleanup using a **single thread**, freezing your application entirely for the duration of the collection.

When a container is just large enough to select G1GC (perhaps with exactly two CPUs) you hit a frustrating technical paradox. Because G1GC is designed for parallelism, it spins up a suite of worker threads to clean memory; however, in such a constrained environment, these threads end up crowding the very few cores available. Instead of streamlining the process, the CPU wastes valuable cycles managing the constant **context switching** between your application’s logic and the swarm of background GC threads.

This convenience of “automatic” selection is actually a double-edged sword: it often chooses a GC that isn’t optimal for your specific performance or footprint goals, and it does so silently. Because the JVM shifts its entire memory management strategy based on an apparently unrelated setting like the CPU limit, it can introduce performance penalties that are incredibly difficult to diagnose. Then, relying on these defaults means ignoring the delicate dance between threads and cores, leaving you at risk of either bottlenecking a node with a single-threaded bottleneck or choking a small node with multi-threaded overhead.

## The High Cost of “Micro-Containers”

One of the most pervasive trends is the deployment of JVMs with **less than 1 CPU**. While this might look efficient on a spreadsheet, and is often chosen to reduce the “blast radius” by spreading instances, it creates a fundamental architectural conflict for Java. This strategy forces a difficult trade-off between resource efficiency (cost) and the actual stability of the application.

It is crucial to understand that a Kubernetes CPU limit is not a “speed limit” that slows down the processor; it is a **“time quota”** enforced by the Linux kernel’s **Completely Fair Scheduler (CFS)**. Typically, the kernel divides time into 100ms windows. If you assign a container a limit of **500m (0.5 CPU)**, you are granting it exactly **50ms of runtime** every 100ms. But your JVM can use all of the CPUs of your K8s node. Once that quota is exhausted, the kernel drastically throttles the container: it simply freezes all threads until the next window begins.

This mechanism is disastrous for Java due to its **multi-threaded nature,** it is not just running your code: it is constantly running background threads for the **Just-In-Time (JIT)** compiler and the **Garbage Collector**.

When your application starts or encounters a new “hot” code path, the JIT compiler kicks in to transform bytecode into optimized machine code. This process is inherently CPU-intensive. In a micro-container, a JIT burst can easily consume the entire 50ms quota in the blink of an eye. The result is that the Linux kernel forcibly pauses your application for the remaining 50ms of the window. To your users, this looks like application latency, but it is actually an OS-enforced sleep where no code is executing.

Enforcing this issue is the sheer density of threads within the JVM. Even a simple application spawns dozens of threads: Garbage Collection threads, Compiler threads and your application threads. When you constrain a Java pod to less than 1 CPU, all these threads are forced to fight for those microscopic time slices. The background maintenance tasks, which are supposed to be invisible helpers, become active obstructors of your business logic.

This contention damages performance regardless of which Garbage Collector you use. For modern concurrent collectors (like G1GC, ZGC and Shenandoah) that attempt to clean memory in the background (spawning multiple worker threads named ***ParallelGCThreads*** and ***ConcGCThreads*** to mark and evacuate objects), tight CPU limits force the Kubernetes scheduler to throttle threads, slowing down user requests to allow the GC to proceed. Furthermore, when the inevitable “ *Stop-The-World* ” pause occurs, a phase required by all collectors, the lack of available CPU cycles means the cleanup work takes significantly longer to complete.

This explains the findings from the benchmarks discussed by Bruno Borges. When comparing **six small replicas** (1 CPU each) against **two larger replicas** (3 CPUs each), the results **revealed a clear performance gap**. Even with the exact same total CPU capacity, the two larger replicas delivered significantly better throughput and lower tail latency because by giving the JVM “breathing room” (larger CPU limits), you reduce the statistical probability of hitting these CPU throttling walls and ensure that background threads can execute on separate cores without freezing the request processing threads.

![Latency and throughput benchmark comparing different Kubernetes container configurations for Java workloads](https://akamas.io/wp-content/uploads/2026/02/jvm-ergonomics-gc-selection-kubernetes.png-1024x576.png)

Latency and throughput benchmark comparing different Kubernetes container configurations for Java workloads

## The Ecosystem Is Reacting

The industry is aware of these challenges, and during the webinar, Bruno Borges shared several exciting initiatives aimed at mitigating them.

Tools like the **Azure Command Launcher for Java** (“jaz”) are being developed to automate the configuration of JVM flags based on the environment, effectively “tuning” the startup command for you. Furthermore, projects within the OpenJDK ecosystem, such as **Project Leyden** and **CRaC (Coordinated Restore at Checkpoint)**, are making strides to drastically reduce startup times and memory footprint through static images and snapshotting.

These advancements will help developers start on the right foot. However, they do not eliminate the fundamental need to manage the complex performance and efficiency trade-offs when running Java applications in Kubernetes. Even with a perfectly tuned startup command or a faster boot time, once your application is running under load, the tension between memory, CPU, and latency remains.

## Stop Guessing, Start Measuring

The days of manual tuning are over. Even well-intentioned attempts to “fix” these issues manually often backfire.

Real efficiency requires finding a delicate balance between **Throughput, Latency, and Footprint**. Improving one often comes at the expense of the others.

- **Maximize Throughput?** You might need a larger heap, increasing your **Footprint**.
- **Minimize Footprint?** You risk squeezing the JVM, destroying your **Latency**.

To solve this puzzle, you cannot look at the JVM in isolation. You must align the **JVM Configurations** with the **Kubernetes Container resources** **and HPA scaling policies** simultaneously. It is a trade-off between wasting money on over-provisioning or risking reliability issues with under-provisioning. And it has to be done for all your Java workloads, in a continuous fashion, as traffic changes and new releases are deployed to production.

You don’t need to solve this multi-variable equation manually. You can use **[Akamas Insights](https://akamas.io/insights/)** to run a comprehensive health check of your Java applications on your Kubernetes clusters. By connecting to your existing observability tool (like Prometheus, DataDog and Dynatrace), Akamas Insights analyzes the full picture, JVM metrics, container limits and actual usage, to tell you exactly where you are sacrificing reliability for cost, or vice versa.

**Stop flying blind: [Get your free Application Health Score](https://akamas.io/get-insights/) with Akamas Insights now**


[Published by Medium on AWS In Plain Engligh](https://aws.plainenglish.io/kubernetes-1-35-in-place-pod-resizing-guide-no-restarts-896eff23157b)

![](https://miro.medium.com/v2/resize:fit:640/format:webp/1*eROKKyWTO0JcgYCuWI_TnQ.png)

The ability to change the size of a running Pod feels like a feature that should have existed from day one. However, in the world of Kubernetes, resources like CPU and memory were considered immutable for a very long time. If you got your capacity planning wrong, your only option was to destroy the workload and start over. With the release of [Kubernetes 1.35](https://kubernetes.io/blog/2025/12/17/kubernetes-v1-35-release/), the platform finally embraces the idea that applications are dynamic and that our infrastructure should be able to adapt to them without forcing a reboot.

## A Feature Years in the Making

This capability did not appear overnight. The community began working on [In-Place Pod Resizing](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/1287-in-place-update-pod-resources) way back in version **1.27**. It started as an Alpha feature, which means it was experimental and hidden behind special feature gates because it was risky. Changing the resource limits of a running process on Linux is technically complex. If the Kubelet tries to shrink memory too aggressively, the application might crash immediately. Over the last few years, the Kubernetes team has slowly refined how the Kubelet talks to the container runtime to ensure safety. Now, in version 1.35, the feature has finally reached General Availability (GA). This means it is considered stable, safe, and ready for critical production environments.

## How It Works Under the Hood

To understand the magic, we need to look at what happens when you actually request a change. In the past, you would update the Pod specification directly, which confused the system into thinking you wanted a new Pod. In Kubernetes 1.35, the process is much more deliberate. You do not touch the main Pod spec; instead, you send a request to a special “subresource” called `resize`. This tells the Kubernetes API server that your intention is strictly to adjust resources, not to redeploy the application.

Once the API server accepts your request, the Kubelet (the agent running on the specific node where your Pod lives) takes over. The Kubelet acts like a strict traffic controller. First, it looks at the available capacity on the machine. It calculates if there is enough free CPU or memory to satisfy your new request. If the node is full, the Kubelet will not kill other Pods to make room. Instead, it places your request in a “ *Pending* ” state. Your Pod continues running with its old limits, patiently waiting in line until enough resources on that specific node become free.

If the node does have space, the Kubelet proceeds to the next step. It talks to the Container Runtime (like containerd or CRI-O) using the Container Runtime Interface. It instructs the runtime to update the Linux Control Groups (cgroups) for that specific process. Think of cgroups as invisible walls that define how much of the computer a program can use. The runtime simply moves these walls further out, instantly giving the application access to more CPU cycles or memory pages. If you have configured a `resizePolicy` that requires a restart, the Kubelet will reboot the container; otherwise, the change happens silently while the code keeps running.

![](https://miro.medium.com/v2/resize:fit:640/format:webp/1*s2zg9FGCC034JMXYVRg3hg.png)


## The Java Paradox: CPU vs. Memory

Considering the Pod size it’s not enough, we have to look at how applications actually behave, and there is no better example than the Java Virtual Machine (JVM). Java applications have a unique personality. When they first start up, they are incredibly hungry for CPU power because of the **JIT Compiler**. Once they are up and running, they often settle down and use less CPU.In the past, this created a difficult choice. You either gave the Java app a huge amount of CPU just for the first five minutes (wasting money for the rest of the day), or you gave it a small amount of CPU and watched it take twenty minutes to start up. With In-Place Resizing, you get the best solution. You can launch the Pod with high CPU limits to ensure a fast startup. Once the application is ready, an autoscaler (like the [VPA](https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/)) can quietly reduce the CPU limit down to a maintenance level. The application stays online, the customers stay happy, and your cloud bill goes down.

However, memory is a completely different story, and this is where you must be careful. While Kubernetes can easily give a container more memory, the application inside might not notice. For example, when a Java app starts, it looks at the available memory and decides how big its *Heap* should be.

> If you launch the JVM using default settings (without setting `*-Xmx*` or `*-XX:MaxRAMPercentage*`), the default Heap size, based on JVM heuristics, will be 25% of the available memory (the Pod's memory limit).

It usually makes this decision only once. If you double the container’s memory an hour later, the JVM will still stick to its original, smaller Heap size. It does not automatically expand just because the room got bigger. In these cases, you still need to restart the container so the application can recalculate its settings.

> Java and other runtimes do not currently support on-the-fly memory resizing. There is an [ongoing conversation](https://bugs.openjdk.org/browse/JDK-8359211) with the Java community to make this possible.

While expanding memory requires care, shrinking it is even more complex. You cannot simply take away RAM that an application is currently using to store data. When you ask Kubernetes to lower a memory, the Kubelet performs a ‘best-effort’ safety check. It looks at how much memory the container is actually using at that exact moment. If your app is using 4GB and you try to lower the limit to 2GB, the system will not kill the container. Instead, the resize operation will hang. The status will remain stuck in ‘ *InProgress* ’ indefinitely, waiting for the application to voluntarily free up that space. Unlike CPU, which can be throttled instantly, memory cannot be reclaimed until the application decides to let it go.

This is why Kubernetes 1.35 allows you to set different policies for different resources, letting you resize CPU instantly while requiring a restart for memory changes.

## Real-World Limitations

While this feature is a game-changer, it cannot break the laws of physics. The most obvious limitation is the physical capacity of the node. If your server is full and you ask to double the size of a Pod, the resize operation will simply stop and wait. Kubernetes cannot create hardware out of thin air, and it will not automatically move the Pod to a different node to make room for the new size. You have to wait for other workloads on that specific machine to finish and free up space.

There is also a strict rule regarding the [*Quality of Service*](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) (QoS) class that you must respect. Kubernetes classifies every Pod as Guaranteed, Burstable, or BestEffort based on its configuration, and this classification is permanent for the life of the Pod. For example, if you deploy a critical workload as ‘Guaranteed’ (where the resource request exactly equals the limit), you cannot change just one of those values later. If you try to increase the limit without also increasing the request, you would technically be changing the Pod’s class to ‘Burstable,’ which is forbidden. The API server will reject your command immediately to prevent you from accidentally breaking your own production guarantees.

There are also operating system limitations to consider. Currently, this smooth resizing capability relies heavily on how Linux manages processes specifically through *cgroups v2*. This means that if you are running Windows containers in your cluster, you are left out of the party for now. Windows nodes still require the traditional recreation of Pods to apply new resource specs.

## The Future of Autoscaling

Ultimately, this update paves the way for a much smarter generation of autoscalers. We are moving away from the era where the [Vertical Pod Autoscaler](https://kubernetes.io/docs/concepts/workloads/autoscaling/vertical-pod-autoscale/) was difficult to use because it caused too many disruptions. We are entering a time where our clusters can breathe. They can expand during traffic spikes and shrink during quiet hours, all while the application logic continues to run uninterrupted. It has been a long road from Alpha to GA, but Kubernetes 1.35 has finally made the dream of elastic, restart-free scaling (almost) a reality.

Personal website of Graziano Casto, DevRel Engineer at Akamas, CNCF TAG DevEx Tech Lead, Kubernetes Blog Maintainer.

Graziano Casto — DevRel Engineer

Graziano Casto

Senior DevRel Engineer at Akamas, Tech Lead at CNCF TAG Developer Experience, Kubernetes Blog Maintainer, and Open Source advocate specializing in Cloud Native technologies.

Graziano Casto

Writing

Speaking