# Локальне тимчасове сховище LLMS index: [llms.txt](/llms.txt) --- Вузли мають локальне тимчасове сховище, яке підтримується локально підключеними пристроями з можливістю запису або, інколи, оперативною памʼяттю. «Тимчасове» означає, що немає довгострокової гарантії щодо довговічності. Podʼи використовують тимчасове локальне сховище для тимчасового простору, кешування та журналів. Kubelet може надавати тимчасовий простір для Podʼів, використовуючи локальне тимчасове сховище для монтування томів [`emptyDir`](/docs/concepts/storage/volumes/#emptydir) у контейнери. Kubelet також використовує цей тип сховища для зберігання [журналів контейнерів на рівні вузлів](/docs/concepts/cluster-administration/logging/#logging-at-the-node-level), образів контейнерів та шарів з можливістю запису запущених контейнерів.

Увага:

Якщо вузол виходить з ладу, дані в його тимчасовому сховищі можуть бути втрачені. Ваші застосунки не можуть очікувати жодних SLA щодо продуктивності (наприклад, дискових операцій введення-виведення за секунду) від локального тимчасового сховища.

Примітка:

Щоб квота ресурсів працювала на ephemeral-storage, потрібно виконати дві дії:

Якщо користувач не вказав обмеження ресурсу ephemeral-storage у специфікації Podʼа, квота ресурсів не застосовується до ephemeral-storage.

Kubernetes дозволяє відстежувати, резервувати та обмежувати обсяг тимчасового локального сховища, яке може використовувати Pod. ## Конфігурації для локального тимчасового сховища {#configurations} Kubernetes підтримує наступні способи налаштування локального тимчасового сховища на вузлі:

У цій конфігурації ви розміщуєте всі різні типи тимчасових локальних даних (томи emptyDir, записувані шари, образи контейнерів, журнали) в одній файловій системі.

Kubelet також записує журнали контейнерів на рівні вузла і обробляє їх аналогічно тимчасовому локальному сховищу.

Kubelet записує журнали у файли всередині своєї налаштованої теки журналів (типово /var/log) і має базову теку для інших локально збережених даних (типово /var/lib/kubelet).

Зазвичай і /var/lib/kubelet, і /var/log знаходяться в кореневій файловій системі, і kubelet розроблений з урахуванням такої структури.

Ваш вузол може мати стільки інших файлових систем, які не використовуються для Kubernetes, скільки вам заманеться.

Для тимчасових даних, що генеруються запущеними Podʼами, як-от журнали та томи emptyDir, на вузлі використовується одна файлова система. Цю файлову систему також можна використовувати для інших даних, наприклад для системних журналів, що не повʼязані з Kubernetes; вона навіть може виступати в ролі кореневої файлової системи.

Kubelet також записує журнали контейнерів на рівні вузла у першу файлову систему і обробляє їх аналогічно тимчасовому локальному сховищу.

Ви також використовуєте окрему файлову систему, що базується на іншому логічному пристрої зберігання даних. У цій конфігурації середовище виконання контейнерів зберігає як шари образу контейнера, так і шари, доступні для запису, у цій другій файловій системі. Налаштуйте це місце зберігання у середовищі виконання контейнерів, а не в kubelet.

Перша файлова система не містить жодних шарів образів або шарів, що підлягають запису.

Ваш вузол може мати стільки інших файлових систем, які не використовуються для Kubernetes, скільки вам заманеться.

У цій конфігурації шари образів контейнерів знаходяться на окремій файловій системі, а шари, доступні для запису контейнера, знаходяться на тій же файловій системі, що й тимчасові дані kubelet, такі як журнали та томи emptyDir.

Ця конфігурація вимагає підтримки сигналів виселення containerfs. Для отримання додаткової інформації про функціональну можливість та середовища виконання контейнерів, які підтримують цю конфігурацію, дивіться розділ «Сигнали файлової системи» у статті Виселення в наслідок тиску на вузол.

На сторінці [Виселення в наслідок тиску на вузол](/docs/concepts/scheduling-eviction/node-pressure-eviction/#filesystem-signals) ці файлові системи позначаються як `nodefs`, `imagefs` та `containerfs`. Ці назви не завжди відповідають окремим точкам монтування. Kubelet може вимірювати використання локального сховища, якщо ви налаштовуєте вузол із використанням однієї з підтримуваних конфігурацій для локального тимчасового сховища. Якщо у вас інша конфігурація, kubelet не застосовує обмеження ресурсів для тимчасового локального сховища.

Примітка:

Kubelet відстежує томи tmpfs emptyDir як використання памʼяті контейнера, а не як локальне тимчасове сховище.

Примітка:

Kubelet може відстежувати тимчасове сховище лише на файлових системах, за якими він спостерігає через підтримувані схеми розміщення. Якщо ви монтуєте додаткові файлові системи за такими шляхами, як /var/lib/kubelet, /var/log або тека зберігання середовища виконання контейнерів поза цими схемами розміщення, kubelet може неправильно повідомляти про тимчасове сховище.
## Встановлення запитів та обмежень для локального тимчасового сховища {#requests-limits} Ви можете вказати `ephemeral-storage` для управління локальним тимчасовим сховищем. Кожен контейнер Podʼа може вказати одне або обидва з наступного: * `spec.containers[].resources.limits.ephemeral-storage` * `spec.containers[].resources.requests.ephemeral-storage` Обмеження та запити для `ephemeral-storage` вимірюються в байтах. Ви можете виразити обсяг сховища як просте ціле число або як число з фіксованою комою, використовуючи один із таких суфіксів: E, P, T, G, M, k. Ви також можете використовувати еквіваленти степеня двійки: Ei, Pi, Ti, Gi, Mi, Ki. Наприклад, усі наведені нижче величини мають приблизно однакове значення: - `128974848` - `129e6` - `129M` - `123Mi` Зверніть увагу на регістр суфіксів. Якщо ви запитуєте `400m` тимчасового сховища, це запит на 0,4 байта. Той, хто це ввів, мабуть, мав на увазі 400 мебібайтів (`400Mi`) або 400 мегабайтів (`400M`). У наступному прикладі Pod має два контейнери. Кожен контейнер має запит на 2 ГБ локального тимчасового сховища. Кожен контейнер має обмеження в 4 ГБ локального тимчасового сховища. Отже, Pod має запит на 4 ГБ локального тимчасового сховища та обмеження в 8 ГБ локального тимчасового сховища. 500 Mi цього обмеження може бути використано томом `emptyDir`. ```yaml apiVersion: v1 kind: Pod metadata: name: frontend spec: containers: - name: app image: images.my-company.example/app:v4 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" volumeMounts: - name: ephemeral mountPath: "/tmp" - name: log-aggregator image: images.my-company.example/log-aggregator:v6 resources: requests: ephemeral-storage: "2Gi" limits: ephemeral-storage: "4Gi" volumeMounts: - name: ephemeral mountPath: "/tmp" volumes: - name: ephemeral emptyDir: sizeLimit: 500Mi ``` ## Як плануються Podʼи з запитами на тимчасове сховище {#how-pods-with-ephemeral-storage-requests-are-scheduled} Коли ви створюєте Pod, планувальник Kubernetes вибирає вузол, на якому буде працювати Pod. Кожен вузол має максимальний обсяг локального тимчасового сховища, який він може надати для Podʼів. Докладнішу інформацію див. у розділі [Node Allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). Планувальник гарантує, що сума запитів на ресурси запланованих контейнерів буде меншою за місткість вузла. ## Управління споживанням тимчасового сховища {#resource-emphemeralstorage-consumption} Якщо kubelet управляє локальним тимчасовим сховищем як ресурсом, то kubelet вимірює використання сховища в: - томах `emptyDir`, за винятком томів _tmpfs_ `emptyDir` - теках, що містять журнали на рівні вузла - шарах контейнерів, доступних для запису Якщо Pod використовує більше тимчасового сховища, ніж ви дозволяєте, kubelet встановлює сигнал виселення, який запускає виселення Pod. Для ізоляції на рівні контейнера, якщо шар контейнера з можливістю запису та використання журналів перевищує його обмеження сховища, kubelet позначає Pod для виселення. Для ізоляції на рівні Podʼа kubelet обчислює загальний ліміт памʼяті Podʼа, підсумовуючи ліміти для контейнерів у цьому Pod. У цьому випадку, якщо сума використання локальної тимчасової памʼяті з усіх контейнерів, а також томів `emptyDir` Podʼа перевищує загальний ліміт памʼяті Podʼа, то kubelet також позначає Pod для виселення.

Увага:

Якщо kubelet не вимірює локальне тимчасове сховище, то Pod, який перевищує свій локальний ліміт сховища, не буде вилучений за порушення лімітів локальних ресурсів сховища.

Однак, якщо простір файлової системи для записуваних шарів контейнерів, журналів на рівні вузла або томів emptyDir стає недостатнім, вузол сам позначає себе taints як такий, що має недостатньо локального сховища, і ця позначка викликає вилучення будь-яких Podʼів, які не толерують цю позначку.

Дивіться підтримувані конфігурації для тимчасового локального сховища.

Kubelet підтримує різні способи вимірювання використання сховища Podʼа:

Kubelet виконує регулярні, заплановані перевірки, які сканують кожен том emptyDir, теку журналів контейнера та записуваний шар контейнера.

Сканування вимірює, скільки місця використовується.

Примітка:

У цьому режимі kubelet не відстежує відкриті дескриптори файлів для видалених файлів.

Якщо ви (або контейнер) створюєте файл у томі emptyDir, щось відкриває цей файл, а ви видаляєте файл, поки він ще відкритий, то інод для видаленого файлу залишається, поки ви не закриєте цей файл, але kubelet не класифікує простір як використовуваний.

СТАН ФУНКЦІОНАЛУ: Kubernetes v1.31 [beta](стандартно вимкнено)

Квоти проєктів — це функція на рівні операційної системи для управління використанням сховища у файлових системах. За допомогою Kubernetes ви можете увімкнути квоти проєктів для моніторингу використання сховища. Переконайтеся, що файлова система, яка підтримує томи emptyDir на вузлі, забезпечує підтримку квот проєктів. Наприклад, XFS та ext4fs пропонують квоти проєктів.

Примітка:

Квоти проєктів дозволяють моніторити використання сховища; вони не застосовують обмеження.

Kubernetes використовує ідентифікатори проєктів, починаючи з 1048576. Використовувані ідентифікатори зареєстровані в /etc/projects та /etc/projid. Якщо ідентифікатори проєктів у цьому діапазоні використовуються в системі для інших цілей, їх необхідно зареєструвати в /etc/projects та /etc/projid, щоб Kubernetes не використовував їх.

Квоти є швидшими та точнішими, ніж сканування тек. Коли тека призначається проєкту, всі файли, створені в цій теці, створюються в цьому проєкті, і ядро має лише відстежувати, скільки блоків використовується файлами в цьому проєкті. Якщо файл створено та видалено, але він має відкритий дескриптор файлу, він продовжує споживати простір. Відстеження квот точно фіксує цей простір, тоді як сканування тек пропускає простір, який використовують видалені файли.

Щоб використовувати квоти для відстеження використання ресурсів подом, под повинен знаходитися в просторі імен користувача. У просторі імен користувача ядро обмежує зміни projectID у файловій системі, забезпечуючи надійність метрик зберігання, розрахованих за допомогою квот.

Якщо ви хочете використовувати квоти проєкту, вам слід:

Якщо ви не хочете використовувати квоти проєкту, вам слід:

## Що далі * Прочитайте про [квоти проєктів](https://www.linux.org/docs/man8/xfs_quota.html) у XFS.