# Обсяг сховища

LLMS index: [llms.txt](/llms.txt)

---

<!-- overview -->

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








  <div class="feature-state-notice feature-stable">
      <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span>
      <code>Kubernetes v1.24 [stable]</code>
    </div>
  



Ця сторінка описує, як Kubernetes відстежує обсяг сховища та як планувальник використовує цю інформацію для [планування Podʼів](/docs/concepts/scheduling-eviction/) на вузлах, які мають доступ до достатнього обсягу сховища для решти томів, яких не вистачає. Без відстеження обсягу сховища планувальник може вибрати вузол, у якого немає достатнього обсягу для виділення тому, і буде потрібно кілька повторних спроб планування.

## Перш ніж ви розпочнете

Kubernetes v1.36 включає підтримку API на рівні кластера для відстеження обсягу сховища. Для використання цього ви також повинні використовувати драйвер CSI, який підтримує відстеження обсягу. Консультуйтесь з документацією драйверів CSI, які ви використовуєте, щоб дізнатися, чи ця підтримка доступна, і як її використовувати. Якщо ви не використовуєте Kubernetes v1.36, перевірте документацію для цієї версії Kubernetes.

<!-- body -->

## API

Існують дві API-розширення для цієї функції:

- Обʼєкти [CSIStorageCapacity](/docs/reference/kubernetes-api/config-and-storage-resources/csi-storage-capacity-v1/): їх виробляє драйвер CSI в просторі імен, де встановлено драйвер. Кожен обʼєкт містить інформацію про обсяг для одного класу сховища і визначає, які вузли мають доступ до цього сховища.
- [Поле `CSIDriverSpec.StorageCapacity`](/docs/reference/kubernetes-api/config-and-storage-resources/csi-driver-v1/#CSIDriverSpec): якщо встановлено значення `true`, планувальник Kubernetes буде враховувати обсяг сховища для томів, які використовують драйвер CSI.

## Планування {#scheduling}

Інформація про обсяг сховища використовується планувальником Kubernetes у випадку, якщо:

- Pod використовує том, який ще не був створений,
- цей том використовує <a class='glossary-tooltip' title='StorageClass надає можливість адміністраторам описати різні доступні типи сховищ.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/concepts/storage/storage-classes' target='_blank' aria-label='StorageClass'>StorageClass</a>, який посилається на драйвер CSI та використовує [режим привʼязки тому](/docs/concepts/storage/storage-classes/#volume-binding-mode) `WaitForFirstConsumer`, і
- обʼєкт `CSIDriver` для драйвера має `StorageCapacity` зі значенням `true`.

У цьому випадку планувальник розглядає тільки вузли для Podʼів, які мають достатньо вільного обсягу сховища. Ця перевірка є дуже спрощеною і порівнює тільки розмір тому з обсягом, вказаним в обʼєктах `CSIStorageCapacity` з топологією, що включає вузол.

Для томів з режимом привʼязки `Immediate` драйвер сховища вирішує де створити том, незалежно від Podʼів, які використовуватимуть том. Планувальник потім планує Podʼи на вузли, де том доступний після створення.

Для [ефемерних томів CSI](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) планування завжди відбувається без врахування обсягу сховища. Це ґрунтується на припущенні, що цей тип тому використовується лише спеціальними драйверами CSI, які є локальними для вузла та не потребують значних ресурсів там.

## Перепланування {#rescheduling}

Коли вузол був обраний для Pod з томами `WaitForFirstConsumer`, це рішення все ще є попереднім. Наступним кроком є те, що драйверу зберігання CSI буде запропоновано створити том з підказкою, що том повинен бути доступний на вибраному вузлі.

Оскільки Kubernetes може вибрати вузол на підставі застарілої інформації про обсяг, існує можливість, що том насправді не може бути створений. Вибір вузла скидається, і планувальник Kubernetes спробує знову знайти вузол для Podʼа.

## Обмеження {#limitations}

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

Одна ситуація, коли планування може назавжди зазнати відмови, це коли Pod використовує кілька томів: один том вже може бути створений в сегменті топології, в якому не залишилося достатньо обсягу для іншого тому. Потрібне ручне втручання для відновлення, наприклад, збільшення обсягу або видалення вже створеного тому.

## Що далі

- Докладніша інформація щодо концепції дизайну доступна у [Storage Capacity Constraints for Pod Scheduling KEP](https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/1472-storage-capacity-tracking/README.md).