Kubernetes 1.30 Production Guide: Configuring LimitedSwap and DRA on High-Performance Nodes

The "No Swap" Era is Over. Finally.

For the last decade, the first thing every Systems Architect did when provisioning a Kubelet was swapoff -a. It was a ritual. If you didn't do it, the Kubelet wouldn't even start. The argument was always the same: "Swap kills performance. If you swap, you're already dead."

That logic worked when we were running on spinning rust HDDs with 150 IOPS. It does not hold up in 2025, where NVMe storage is standard. With Kubernetes 1.30 (codenamed "Uwubernetes"—yes, really), the Node Memory Swap feature finally matured enough for serious production use. This is the single most critical update for reliability engineering in this release.

We are seeing this heavily adopted across Norwegian enterprise clusters, specifically to mitigate the "noisy neighbor" problem without over-provisioning RAM by 40%.

Implementing LimitedSwap

The goal isn't to run your database on disk. The goal is to give the kernel a safety valve before the OOMKiller starts shooting critical processes. In 1.30, the NodeSwap feature gate is enabled by default, but you must explicitly configure the behavior.

The LimitedSwap mode is what you want. It allows Pods to use swap only up to their memory limit, preventing a single leaking container from thrashing the entire node.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
  NodeSwap: true
memorySwap:
  swapBehavior: LimitedSwap

War Story: We recently migrated a high-traffic Magento cluster hosting a major Oslo retail event. Before 1.30, sudden spikes in PHP worker memory usage would trigger immediate OOM kills, dropping 50-100 user sessions instantly. By enabling LimitedSwap on CoolVDS NVMe instances, we absorbed those 2-second spikes into swap. Latency increased by 12ms for those seconds, but zero requests were dropped. That is the trade-off professionals make.

Dynamic Resource Allocation (DRA): Beyond the GPU Hype

If you are running ML workloads or video rendering pipelines, the old Device Plugin API was a nightmare of opaque strings. You requested a "gpu", and the scheduler had no idea if that meant a weak integrated chip or a dedicated A100. It just passed the string to the kubelet.

Kubernetes 1.30 introduced Structured Parameters for DRA. This allows the scheduler to make intelligent decisions based on actual hardware attributes (memory size, driver version, topology) before binding the Pod to a node.

Here is how you define a claim in 2025 production:

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
  name: rendering-gpu-claim
spec:
  resourceClassName: nvidia-gpu
  parametersRef:
    kind: GpuConfig
    name: high-memory-profile

This requires your underlying infrastructure to actually expose these capabilities. This is why we standardize on KVM virtualization at CoolVDS; unlike shared container environments (LXC/OpenVZ), KVM allows us to pass through hardware capabilities that DRA can actually see and manage.

Sidecars Are No Longer Ruining Your Autoscaling

Before 1.30, the Horizontal Pod Autoscaler (HPA) looked at the aggregate resource usage of a Pod. This was flawed by design.

Consider a Pod with two containers:

1. Application (Go): High CPU usage, needs scaling.
2. Log Shipper (Fluentd): Low CPU usage.

If your Go app was redlining at 90% CPU, but the log shipper was idling at 1%, the average Pod CPU might sit at 45%. The HPA would do nothing, and your users would see 502 errors.

Kubernetes 1.30 stabilized Container Resource Based Autoscaling. You can now target the specific container that matters.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-scaler
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend-api
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: ContainerResource
    containerResource:
      name: cpu
      container: application
      target:
        type: Utilization
        averageUtilization: 75

This configuration ignores the sidecar entirely. If the main application container hits 75%, it scales. Simple, logical, and years overdue.

The Infrastructure Reality Check

Software advances like LimitedSwap and DRA are useless if the underlying metal is weak. Enabling swap on a VPS with shared, throttled HDD I/O is suicide. The kernel will spend more time waiting for I/O than executing code (high iowait).

This is where the choice of hosting provider becomes a technical decision, not just a financial one.

Pro Tip: To safely use Swap in production, your disk random Read/Write latency must be under 1ms. Run fio on your current node. If 4k random writes are slower than 5ms, disable swap immediately.

At CoolVDS, our Norwegian clusters are built on pure NVMe arrays. When you enable LimitedSwap on our nodes, you are paging to storage that responds in microseconds, not milliseconds. Combined with our direct peering at NIX (Norwegian Internet Exchange), you reduce both disk and network latency bottlenecks simultaneously.

Action Plan for June 2025:

1. Audit your kubelet config for NodeSwap. Enable it on non-critical clusters first.
2. Rewrite HPA manifests for pods with heavy sidecars (service mesh proxies, loggers).
3. Verify your storage I/O capabilities. If your provider's disk latency fluctuates, do not enable swap.

Stop letting legacy constraints dictate your 2025 architecture. Test a CoolVDS NVMe instance today and see how Kubernetes 1.30 performs when the hardware actually keeps up.