Два роки тому я написав статтю, в якій зосередився на CPU в Kubernetes. Якщо ви ще не читали її, обов’язково подивіться! Це чудова стаття😊. Коротко кажучи, я пояснив, як працюють запити та ліміти CPU, і коли слід використовувати ліміти CPU, а коли — ні.
Але коли мова йде про пам'ять в Kubernetes, стандартною практикою завжди було встановлювати requests.memory рівним limits.memory. Це гарантує, що кожен под гарантовано отримає пам'ять, яку запитує, що запобігає несподіваним завершенням роботи через OOM killer. Однак реальні додатки іноді зазнають тимчасових піків пам'яті або працюють в середовищах, де додавання більшої фізичної пам'яті неможливо.
З випуском node swap як бета-функції в Kubernetes 1.28 (яку, сподіваюся, ви вже використовуєте), встановлення запитів пам'яті рівним лімітам більше не є єдиним життєздатним варіантом. Це оновлення дозволяє більш гнучко керувати пам'яттю, дозволяючи кластерам обробляти несподівані вимоги до пам'яті без необхідності в перевищенні ресурсів.
У цій статті я покажу, як працювати зі swap у EKS, коли це може бути корисно, чому потрібно бути обережним, і деякі інші нюанси. Готуйте свої пісочниці, бо це стаття з практичними вправами!
Розуміння Swap в Kubernetes
Що таке Swap?
Swap — це функція управління пам'яттю, яка дозволяє системі використовувати дисковий простір як доповнення до фізичної пам'яті (RAM). Коли пам'ять системи повністю використовується, неактивні сторінки пам'яті можуть бути переміщені в swap-простір, звільняючи RAM для активних процесів. Цей механізм забезпечує буфер при нестачі пам'яті, дозволяючи системам обробляти навантаження, які перевищують їх фізичну пам'ять.
Чому використовувати Swap з Kubernetes?
У середовищах Kubernetes використання swap може запропонувати кілька переваг, особливо при обробці несподіваних піків пам'яті та покращенні стабільності вузлів. Ось деякі ключові причини, чому ви могли б розглянути можливість увімкнення swap у ваших кластерах Kubernetes:
- Покращена стабільність вузлів: Завдяки таким удосконаленням, як cgroupsv2 і алгоритмам управління пам'яттю, таким як
oomd, наявність невеликої кількості swap може покращити обробку тиску на ресурси та відновлення. Це може запобігти раптовим завершенням роботи подів, надаючи додаткову пам'ять під час короткочасних піків. - Гнучкість пам'яті: Swap дозволяє кластерам ефективніше керувати навантаженням, особливо в сценаріях, коли додавання більшої фізичної пам'яті є занадто дорогим або еластичне масштабування неможливе. Наприклад, для розгортань на місці або на «голих» серверах swap може знизити необхідність в перевищенні пам'яті.
- Підтримка довготривалих додатків: Деякі додатки, такі як Java і Node.js, покладаються на swap для оптимальної роботи під час ініціалізації. Swap може безпечно обробляти пам'ять, що використовується під час запуску, без впливу на використання ресурсів довготривалих додатків.
- Локальна розробка та швидкі сховища: У локальних середовищах розробки або в однонодових кластерах з швидким сховищем (наприклад, NVMe), swap може забезпечити переваги в продуктивності, ефективно керуючи використанням пам'яті без значного навантаження.
Нюанси та впливи на продуктивність
Хоча swap може бути корисним, важливо розуміти його обмеження та потенційні недоліки:
- Зменшена передбачуваність: Swap вносить непередбачуваність у продуктивність системи. Доступ до swap-простору значно повільніший, ніж доступ до RAM, часто на кілька порядків величини.
Це може призвести до несподіваних зниження продуктивності. - Обмежений контроль над використанням swap: Увімкнення swap змінює поведінку системи під час тиску на пам'ять, не дозволяючи додаткам безпосередньо керувати, які частини їх пам'яті мають бути переміщені в swap-простір.
- Ризики безпеки: Простір swap може становити загрозу для безпеки, якщо його не належним чином управляти. Чутливі дані можуть бути записані на диск у swap-просторі. Щоб зменшити цей ризик, настійно рекомендується шифрувати простір swap.
- Не є заміною для достатньої кількості пам'яті: Swap не слід використовувати як основне рішення для управління пам'яттю. Найкраще використовувати його як запобіжну міру для обробки несподіваних короткочасних піків пам'яті, а не як постійний метод для управління вимогами пам'яті робочих навантажень.
Найкращі практики для використання Swap в Kubernetes
З огляду на компроміси, ось кілька найкращих практик, коли ви розглядаєте використання Swap у своїх кластерах Kubernetes:
- Бенчмаркінг перед продакшн: Завжди проводьте бенчмаркінг ваших вузлів і додатків, щоб зрозуміти вплив swap у вашому конкретному середовищі. Це допомагає приймати обґрунтовані рішення щодо увімкнення swap і налаштування його параметрів.
- Використання LimitedSwap: Реалізація LimitedSwap може зменшити деякі ризики, пов'язані з використанням swap. Встановивши запити пам'яті рівними ліміту пам'яті, ви можете запобігти доступу контейнерів до swap-простору, що зменшує ймовірність проблем з конкурентними навантаженнями та непередбачуваним використанням ресурсів.
- Шифруйте простір swap: Для вирішення проблем з безпекою переконайтеся, що ваш простір swap шифрований. Це захистить чутливі дані від витоків у разі несанкціонованого доступу до диска.
- Використовуйте швидке сховище: Якщо ви вирішили використовувати swap, віддавайте перевагу швидким носіям, таким як SSD або NVMe диски, щоб мінімізувати вплив на продуктивність. Повільне сховище для swap може значно погіршити продуктивність додатків.
І тепер найцікавіше — побачимо Swap в дії
Перед тим, як почати, переконайтеся, що у вас працює кластер sandbox на Amazon EKS версії 1.28 або пізнішої та Karpenter версії 0.37 або вище. Якщо у вас його немає, ви можете використовувати цей Terraform код для налаштування: Terraform AWS EKS Blueprints — Karpenter
Крок 1: Створення Karpenter NodeClass і NodePool з AL2023 та конфігурацією Swap
На першому кроці ви налаштуєте Karpenter NodeClass і NodePool, використовуючи Amazon Linux 2023 (AL2023). AL2023 вибрано, оскільки застарілий Amazon Linux 2 (AL2) не підтримує cgroupv2, що необхідно для увімкнення функціональності swap. Крім того, ця конфігурація включає підтримку NVMe (якщо доступно) та налаштовує swap файл для ефективного оброблення піків пам'яті.
role: Оновіть це поле вашим IAM ролем для надання необхідних прав вузлам.subnetSelectorTerms&securityGroupSelectorTerms: Змініть значення тегів, щоб вони відповідали вашим конкретним підмережам і групам безпеки, забезпечуючи запуск вузлів у правильному мережевому середовищі.instanceStoragePolicy: Ця політика форматує та активує instance storage, якщо він доступний, надаючи набагато швидше сховище, ніж EBS.userData: Цей скрипт створює 10ГБ swap файл на локальному сховищі інстанса, якщо це можливо; якщо ні, він використовує кореневий диск. Крім того, він оновлює kubelet, щоб увімкнути функцію NodeSwap.NodePool: NodePool налаштовано на використання NodeClass з увімкненим swap, працює на спотових інстансах і включає taints для контролю того, які навантаження можуть бути заплановані на ці вузли. Ви можете змінити налаштування NodePool, щоб адаптувати їх до вашого середовища.
Крок 2: Розгортання пам'яттєвоємного завдання для спрацьовування OOM Kill
На цьому кроці ви розгорнете Kubernetes завдання, яке використовує stress-ng для використання 2ГБ пам'яті, що перевищує дозволений ліміт.
Под налаштовано з обома параметрами requests.memory та limits.memory, встановленими на 512Mi, щоб гарантувати, що він не може використовувати простір swap. Крім того, використовується селектор вузла, щоб інструктувати Karpenter про надання вузла з лише 1 ГБ оперативної пам'яті.
Збережіть та застосуйте маніфест, а потім зачекайте, поки вузол та под стануть готовими. Ви повинні побачити, що под отримує статус OOMKilled, як і очікувалося, через кілька секунд після запуску.
Крок 3: Розгортання пам'яттєвоємного завдання, що використовує Swap
На цьому кроці ви розгорнете те ж саме завдання, але дозволите поду використовувати простір swap, встановивши запит пам'яті на 512Mi і ліміт на 3Gi. Ми будемо використовувати ту ж саму інстанцію з 1 ГБ RAM, що менше, ніж те, що под спробує використати.
Збережіть та застосуйте маніфест, а потім зачекайте, поки вузол та под стануть готовими. Ви повинні побачити, що под завершиться успішно, оскільки він використовує пам'ять swap замість того, щоб бути вбитим.
Як моніторити використання Swap
Щоб ефективно моніторити використання swap у вашому кластері Kubernetes, ви можете використовувати наступні метрики Prometheus:
machine_swap_bytes
- Опис: Показує загальний розмір swap-диска, виділений на кожному вузлі.
- Використання: Допомагає зрозуміти загальну ємність swap, доступну на кожному вузлі.
node_memory_SwapFree_bytes
- Опис: Показує кількість вільного простору swap на кожному вузлі.
- Використання: Це дозволяє вам моніторити, скільки простору swap залишилося невикористаним, щоб переконатися, що ваші вузли не вичерпали простір для swap.
Висновок
Як завжди, я закликаю вас вивчати та експериментувати з вашими робочими навантаженнями перед застосуванням цієї технології до ваших продуктивних кластерів. Swap може бути корисним інструментом, але він може вплинути на вашу продуктивність, тому слід застосовувати його обережно.
Мені було б цікаво почути у коментарях, чи використовуєте ви swap і в яких випадках він приносить користь у вашій організації.
Перекладено з: How to Enable Swap in Your EKS Cluster in Under 5 Minutes