The Memory Wall Is Real. Kubernetes v1.37 Just Gave You a Way Around It.
Memory is the constraint nobody talks about until the cluster is on fire.
For years, Kubernetes took a firm position on swap memory. Swap is what happens when a computer runs out of RAM and starts using disk storage as overflow. It is slower than RAM, sometimes dramatically so, but it exists on almost every Linux server. Kubernetes, built for predictable performance and fast container scheduling, explicitly disabled it. Trying to run Kubernetes on a node with swap enabled would cause the node to fail its readiness check and refuse to join the cluster.
That policy made sense when Kubernetes was primarily running stateless web services. Predictable latency mattered more than memory headroom. If an app needed more RAM, you scaled horizontally. More pods, more nodes, problem solved. The math worked cleanly.
Then came the AI workloads.
Large language models, vector databases, AI inference servers, and agentic systems do not scale like web applications. They need substantial memory to start up, they need it immediately, and they often have spiky usage patterns that resist the resource limits you set in advance. A single AI inference container might need 40 gigabytes of RAM just to load a model. If the node only has 32 gigabytes free, Kubernetes evicts the pod. The workload dies. You add more hardware. The cycle repeats.
The Kubernetes project just changed this. In Kubernetes v1.37, node swap support has graduated to Beta and is now enabled by default. Clusters can be configured to use swap memory for containers that need it, giving workloads breathing room when physical RAM runs tight. The platform now has a pressure release valve instead of a hard wall.
The right way to think about this is not “Kubernetes got sloppy about memory management.” Swap still has real trade-offs. Workloads that hit swap frequently will see higher latency. You still need to set memory limits for your containers, manage node capacity deliberately, and decide which workloads can tolerate slower memory access. Good capacity planning does not go away.
What changes is what happens at the edge. Instead of killing a container the moment it exceeds available RAM, the cluster can absorb a spike, keep the workload running, and give you time to respond. For AI inference pipelines, batch jobs, and model-serving containers with variable memory demands, that distinction is the difference between a degraded experience and a crashed one.
For teams running Kubernetes clusters that host AI workloads, this is worth testing now. The feature is on by default in v1.37, but configuring it properly for your node types and workload profiles takes some deliberate setup. Getting ahead of this before you hit the memory wall in production is the right move.