.available`):
1. `nodefs`: Основна файлова система вузла, використовується для локальних дискових томів, томів `emptyDir`, які не підтримуються памʼяттю, зберігання логів, ефемерного зберігання та іншого. Наприклад, `nodefs` містить `/var/lib/kubelet`.
1. `imagefs`: Опціональна файлова система, яку середовища виконання контейнерів можуть використовувати для зберігання образів контейнерів (які є шарами тільки для читання). Якщо окремої файлової системи `containerfs` немає, файлова система образів також зберігає шари контейнера, доступні для запису.
1. `containerfs`: Опціональна файлова система, яку середовища виконання контейнерів можуть використовувати для зберігання записуваних шарів контейнерів. Коли використовується `containerfs`, файлова система `imagefs` може бути розділена так, щоб зберігати лише образи (шари тільки для читання) і більше нічого.
Ці ідентифікатори описують файлові системи так, як їх бачить kubelet. Вони не завжди означають три різні точки монтування: у звичайних конфігураціях два або всі три ідентифікатори можуть посилатися на одну й ту ж базову файлову систему.
Примітка:
СТАН ФУНКЦІОНАЛУ:
Kubernetes v1.31 [beta](стандартно увімкнено)
Функція split image filesystem, яка забезпечує підтримку файлової системи containerfs, додає кілька нових сигналів виселення, порогів та метрик. Щоб використовувати containerfs, у випуску Kubernetes v1.36 потрібно увімкнути функціональну можливість KubeletSeparateDiskGC. Наразі підтримка файлової системи containerfs доступна лише в CRI-O (версія 1.29 або вище).
Примітка:
Kubelet не використовує клас
QoS Podʼа для визначення порядку виселення. Ви можете використовувати клас QoS для оцінки найбільш ймовірного порядку виселення Podʼа при відновленні ресурсів, таких як памʼять. Класифікація QoS не застосовується до запитів EphemeralStorage, тому вищезазначений сценарій не буде застосовуватися, якщо вузол, наприклад, перебуває під
DiskPressure.
Примітка:
У Kubernetes v1.36, ви не можете встановити власне значення для метрики containerfs.available. Конфігурація для цієї конкретної метрики буде встановлена автоматично, щоб відображати значення, задані для nodefs або imagefs, залежно від конфігурації.
У деяких випадках виселення підтримує лише невелику кількість виділеного ресурсу. Це може призвести до того, що kubelet постійно стикається з пороговими значеннями для виселення та виконує кілька виселень.
Ви можете використовувати прапорець `--eviction-minimum-reclaim` або [файл конфігурації kubelet](/docs/tasks/administer-cluster/kubelet-config-file/) для налаштування мінімальної кількості відновлення для кожного ресурсу. Коли kubelet помічає нестачу ресурсу, він продовжує відновлення цього ресурсу до тих пір, поки не відновить кількість, яку ви вказали.
Наприклад, наступна конфігурація встановлює мінімальні кількості відновлення:
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
memory.available: "500Mi"
nodefs.available: "1Gi"
imagefs.available: "100Gi"
evictionMinimumReclaim:
memory.available: "0Mi"
nodefs.available: "500Mi"
imagefs.available: "2Gi"
```
У цьому прикладі, якщо сигнал `nodefs.available` досягає порога виселення, kubelet відновлює ресурс до тих пір, поки сигнал не досягне порога в 1 ГіБ, а потім продовжує відновлення мінімальної кількості 500 МіБ до тих пір, поки доступне значення nodefs збереження не досягне 1,5 ГіБ.
Аналогічно, kubelet намагається відновити ресурс `imagefs` до тих пір, поки значення `imagefs.available` не досягне `102 ГіБ`, що представляє 102 ГіБ доступного сховища для образів контейнерів. Якщо кількість сховища, яку може відновити kubelet, менше за 2 ГіБ, kubelet нічого не відновлює.
Стандартно `eviction-minimum-reclaim` є `0` для всіх ресурсів.
## Поведінка в разі вичерпання памʼяті на вузлі {#node-out-of-memory-behavior}
Якщо вузол зазнає події _out of memory_ (OOM) до того, як kubelet зможе відновити памʼять, вузол залежить від реагування [oom_killer](https://lwn.net/Articles/391222/).
Kubelet встановлює значення `oom_score_adj` для кожного контейнера на основі QoS для Podʼа.
| Якість обслуговування | `oom_score_adj` |
|--------------------|-----------------------------------------------------------------------------------|
| `Guaranteed` | -997 |
| `BestEffort` | 1000 |
| `Burstable` | _мін(макс(2, 1000 - (1000 × memoryRequestBytes) / machineMemoryCapacityBytes), 999)_ |
Примітка:
Kubelet також встановлює значення oom_score_adj рівне -997 для будь-яких контейнерів у Podʼах, які мають пріоритет system-node-critical.
Якщо kubelet не може відновити памʼять до того, як вузол зазнає OOM, `oom_killer` обчислює оцінку `oom_score` на основі відсотка памʼяті, яку він використовує на вузлі, а потім додає `oom_score_adj`, щоб отримати ефективну оцінку `oom_score` для кожного контейнера. Потім він примусово завершує роботу контейнера з найвищим показником.
Це означає, що спочатку припиняється робота контейнерів у Podʼах низького QoS, які споживають велику кількість памʼяті в порівнянні з їх запитами на планування.
На відміну від виселення Podʼа, якщо роботу контейнера було припинено через вичерпання памʼяті, kubelet може перезапустити його відповідно до його `restartPolicy`.
## Поради {#node-pressure-eviction-good-practices}
У наступних розділах описано найкращі практики конфігурації виселення.
### Ресурси, доступні для планування, та політики виселення {#schedulable-resources-and-eviction-policies}
При конфігурації kubelet з політикою виселення слід переконатися, що планувальник не буде розміщувати Podʼи, які спричинять виселення через те, що вони безпосередньо викликають тиск на памʼять.
Розгляньте такий сценарій:
- Обсяг памʼяті вузла: 10 ГіБ
- Оператор бажає зарезервувати 10% обсягу памʼяті для системних служб (ядро, `kubelet`, тощо)
- Оператор бажає виселяти Podʼи при використанні памʼяті на рівні 95%, щоб зменшити випадки виснаження системи.
Для цього kubelet запускається наступним чином:
```none
--eviction-hard=memory.available<500Mi
--system-reserved=memory=1.5Gi
```
У цій конфігурації прапорець `--system-reserved` резервує 1,5 ГіБ памʼяті для системи, що становить `10% від загальної памʼяті + кількість порогу виселення`.
Вузол може досягти порогу виселення, якщо Pod використовує більше, ніж його запит, або якщо система використовує більше 1 ГіБ памʼяті, що знижує значення `memory.available` нижче 500 МіБ і спричиняє спрацювання порогу.
### DaemonSets та виселення через тиск на вузол {#daemonset}
Пріоритет Podʼа — це основний фактор при прийнятті рішень про виселення. Якщо вам не потрібно, щоб kubelet виселяв Podʼи, які належать до DaemonSet, встановіть цим Podʼам достатньо високий пріоритет, вказавши відповідний `priorityClassName` в специфікації Podʼа. Ви також можете використовувати менший пріоритет або типове значення, щоб дозволити запускати Podʼи з цього DaemonSet тільки тоді, коли є достатньо ресурсів.
## Відомі проблеми {#known-issues}
У наступних розділах описані відомі проблеми, повʼязані з обробкою вичерпання ресурсів.
### kubelet може не сприймати тиск на памʼять одразу {#kubelet-may-not-observe-memory-pressure-right-away}
Стандартно, kubelet опитує cAdvisor, щоб регулярно збирати статистику використання памʼяті. Якщо використання памʼяті збільшується протягом цього інтервалу швидко, kubelet може не помітити `MemoryPressure` настільки швидко, і буде викликаний `OOM killer`.
Ви можете використовувати прапорець `--kernel-memcg-notification`, щоб увімкнути API сповіщення `memcg` в kubelet і отримувати повідомлення негайно, коли перетинається поріг.
Якщо ви не намагаєтеся досягти екстремального використання, але не перескочити розумний рівень перевикористання, розумним обходом для цієї проблеми є використання прапорців `--kube-reserved` та `--system-reserved` для виділення памʼяті для системи.
### active_file памʼять не вважається доступною памʼяттю {#active-file-memory-is-not-considered-as-available-memory}
В Linux ядро відстежує кількість байтів файлової памʼяті в активному списку останніх використаних (LRU) як статистику `active_file`. Kubelet розглядає області памʼяті `active_file` як непіддаються вилученню. Для робочих навантажень, що інтенсивно використовують локальне сховище з блоковою підтримкою, включаючи ефемерне локальне сховище, кеші ядра файлів та блоків означає, що багато недавно доступних сторінок кеша, ймовірно, будуть враховані як `active_file`. Якщо достатньо цих буферів блоків ядра перебувають на активному списку LRU, kubelet може сприйняти це як високе використання ресурсів та позначити вузол як такий, що страждає від тиску на памʼять — спровокувавши виселення Podʼів.
Для отримання додаткової інформації дивіться [https://github.com/kubernetes/kubernetes/issues/43916](https://github.com/kubernetes/kubernetes/issues/43916).
Ви можете обійти цю проблему, встановивши для контейнерів, які ймовірно виконують інтенсивну діяльність з операцій введення/виведення, однакове обмеження памʼяті та запит памʼяті. Вам потрібно оцінити або виміряти оптимальне значення обмеження памʼяті для цього контейнера.
## Що далі
- Дізнайтеся про [Виселення, ініційоване API](/docs/concepts/scheduling-eviction/api-eviction/)
- Дізнайтеся про [Пріоритет та випередження Podʼів](/docs/concepts/scheduling-eviction/pod-priority-preemption/)
- Дізнайтеся про [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/)
- Дізнайтеся про [Якість обслуговування](/docs/tasks/configure-pod-container/quality-service-pod/) (QoS)
- Подивіться на [Eviction API](/docs/reference/generated/kubernetes-api/v1.36/#create-eviction-pod-v1-core)