Is swap or zswap a good fit for short-lived memory spikes in k3s?

I would still investigate the application before relying on infrastructure to absorb a five-times memory spike. Common options include processing data incrementally, reducing concurrency or batch size, spilling intermediate data to disk, and avoiding unnecessary dataframe copies. That said, if the algorithm genuinely requires all of the data in memory, then the remaining options are provisioning for the peak, queueing or limiting large studies, or accepting slower execution through swap.

There is an important container-runtime detail here: host swap does not automatically save a pod that has a strict memory limit. If the container reaches its cgroup memory.max, it can be killed even when the node has plenty of swap available. The kubelet and cluster must be configured to allow swap, and the pod needs an appropriate memory policy or a limit high enough to cover the expected peak. Test this on the exact k3s and operating-system versions you plan to use rather than assuming node swap will be available to every workload.

A local NVMe-backed swap area is much more sensible than remote or network storage for a short burst, but do not allocate swap as a substitute for unlimited capacity. Leave enough RAM for the operating system and other pods, and set limits on how many large studies can run concurrently. A single study may survive paging, while several simultaneous studies could still exhaust RAM, swap, and CPU.

Swap can work for this kind of bursty workload, but expect a major performance hit if the study starts actively paging. zswap is usually preferable to plain swap because it compresses pages in RAM before writing them to disk, reducing storage I/O. The CPU cost of compression may be worthwhile when the spike is brief and you have spare CPU capacity. Monitor swap-in, swap-out, CPU usage, latency, and whether the node becomes unresponsive.