Кластеры Kubernetes часто сталкиваются с ограничениями по памяти раньше, чем с ограничениями по ЦП, что усугубляется новыми рабочими нагрузками на основе агентского ИИ. Эти ИИ-нагрузки требуют значительного объема памяти для запуска и выполнения недоверенного кода, а затем остаются в режиме ожидания. Эта неиспользуемая память дорого обходится и ограничивает количество подов, которые может разместить узел. Подкачка памяти, особенно при использовании быстрых NVMe SSD, может решить эту проблему, выгружая неактивную память. Поддержка подкачки в Kubernetes, которая теперь общедоступна, позволяет узлам размещать больше подов. Тестирование на сборках CI/CD, изолированных браузерах и средах выполнения Python продемонстрировало увеличение плотности до трех раз при минимальном влиянии на задержку. Исторически подкачка избегалась из-за проблем с учетом памяти и медленных задержек диска. Однако cgroup v2 и быстрые NVMe SSD решают эти проблемы, делая подкачку жизнеспособным решением. Традиционные рабочие нагрузки, такие как сборка ядра, могут выдерживать сниженные лимиты памяти при включенной подкачке. Рабочие нагрузки с высокой плотностью, такие как браузеры без графического интерфейса, демонстрируют значительное увеличение плотности подов при использовании подкачки. Изолированные среды выполнения Python также выигрывают от подкачки, позволяя проводить в три раза больше одновременных сессий. Включение подкачки на узле включает настройку kubelet и использование локальных дисков облачного провайдера. Рабочие нагрузки с QoS Burstable могут использовать подкачку для динамической балансировки памяти. В конечном итоге, быстрая подкачка выгружает неактивные состояния памяти, увеличивая плотность подов и утилизацию узлов для агентских рабочих нагрузок.