# Обмеження томів на вузлі

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

---

<!-- overview -->

Ця сторінка описує максимальну кількість томів, які можна прикріпити до вузла для різних хмарних постачальників.

Хмарні постачальники, такі як Google, Amazon і Microsoft, зазвичай мають обмеження на те, скільки томів можна прикріпити до вузла. Важливо, щоб Kubernetes дотримувався цих обмежень. В іншому випадку Podʼи, заплановані на вузлі, можуть застрягти в очікуванні прикріплення томів.

<!-- body -->

## Типові обмеження Kubernetes {#kubernetes-default-limits}

У планувальнику Kubernetes є типові обмеження на кількість томів, які можна прикріпити до вузла:

| Хмарний сервіс | Максимальна кількість томів на вузол |
|----------------|-------------------------------------|
| [Amazon Elastic Block Store (EBS)](https://aws.amazon.com/ebs/) | 39 |
| [Google Persistent Disk](https://cloud.google.com/persistent-disk/) | 16 |
| [Microsoft Azure Disk Storage](https://azure.microsoft.com/en-us/services/storage/main-disks/) | 16 |

## Обмеження динамічних томів {#dynamic-volume-limits}








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



Обмеження динамічних томів підтримуються для наступних типів.

- Amazon EBS
- Google Persistent Disk
- Azure Disk
- CSI

Для томів, керованих вбудованими втулками томів, Kubernetes автоматично визначає тип вузла і накладає відповідне максимальне обмеження кількості томів для вузла. Наприклад:

- У [Google Compute Engine](https://cloud.google.com/compute/), до вузла може бути приєднано до 127 томів, [залежно від типу вузла](https://cloud.google.com/compute/docs/disks/#pdnumberlimits).

- Для дисків Amazon EBS на типах екземплярів M5,C5,R5,T3 та Z1D Kubernetes дозволяє приєднувати тільки 25 томів до вузла. Для інших типів інстансів на [Amazon Elastic Compute Cloud (EC2)](https://aws.amazon.com/ec2/), Kubernetes дозволяє приєднувати 39 томів до вузла.

- На Azure до вузла може бути приєднано до 64 дисків, залежно від типу вузла. Докладніше див. [Sizes for virtual machines in Azure](https://docs.microsoft.com/en-us/azure/virtual-machines/windows/sizes).

- Якщо драйвер сховища CSI рекламує максимальну кількість томів для вузла (використовуючи `NodeGetInfo`), <a class='glossary-tooltip' title='Компонент панелі управління, що відстежує створені Podʼи, які ще не розподілені по вузлах, і обирає вузол, на якому вони працюватимуть.' data-bs-toggle='tooltip' data-bs-placement='top' href='/uk/docs/reference/generated/kube-scheduler/' target='_blank' aria-label='kube-scheduler'>kube-scheduler</a> дотримується цього обмеження. Див. [специфікації CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#nodegetinfo) для отримання додаткових деталей.

- Для томів, керованих вбудованими втулками, які були перенесені у драйвер CSI, максимальна кількість томів буде тією, яку повідомив драйвер CSI.

### Mutable CSI Node Allocatable Count {#mutable-csi-node-allocatable-count}








  <div class="feature-state-notice feature-stable" title="Функціональна можливість: MutableCSINodeAllocatableCount">
              <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
              <code>Kubernetes v1.36 [stable]</code>(стандартно увімкнено)</div>


Драйвери CSI можуть динамічно регулювати максимальну кількість томів, які можуть бути приєднані до вузла під час виконання. Це підвищує точність планування та зменшує ймовірність збоїв у плануванні через зміну доступності ресурсів.

Це альфа-версія функції і стандартно вона вимкнена.

Щоб скористатися цією можливістю, вам слід увімкнути функціональну можливість `MutableCSINodeAllocatableCount` в наступних компонентах:

- `kube-apiserver`
- `kubelet`

#### Періодичні оновлення {#periodic-updates}

Якщо увімкнено, драйвери CSI можуть запитувати періодичні оновлення своїх лімітів томів, встановивши поле `nodeAllocatableUpdatePeriodSeconds` у специфікації `CSIDriver`. Наприклад:

```yaml
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: hostpath.csi.k8s.io
spec:
  nodeAllocatableUpdatePeriodSeconds: 60
```

Kubelet періодично викликатиме точку доступу `NodeGetInfo` відповідного драйвера CSI, щоб оновити максимальну кількість приєднаних томів, використовуючи інтервал, вказаний у полі `nodeAllocatableUpdatePeriodSeconds`. Мінімально допустиме значення для цього поля — 10 секунд.

Якщо операція приєднання тому завершиться невдало з помилкою `ResourceExhausted` (код gRPC 8), Kubernetes негайно оновить лічильник виділених томів для цього вузла. Додатково, kubelet позначає уражені поди як Failed, що дозволяє їх контролерам обробляти відтворення. Це запобігає застряганню подів у стані `ContainerCreating`.

### Запобігання розміщенню Podʼа без драйвера CSI {#preventing-pod-placement-without-csi-driver}








  <div class="feature-state-notice feature-alpha" title="Функціональна можливість: VolumeLimitScaling">
              <span class="feature-state-name">СТАН ФУНКЦІОНАЛУ:</span> 
              <code>Kubernetes v1.35 [alpha]</code>(стандартно вимкнено)</div>


Якщо функціональну можливість [`VolumeLimitScaling`](/docs/reference/command-line-tools-reference/feature-gates#VolumeLimitScaling) увімкнено і драйвер CSI має відповідний обʼєкт `CSIDriver` з встановленим `spec.preventPodSchedulingIfMissing` у true, тоді планувальник запобігатиме розміщенню подів на вузлах, де ще не встановлено драйвер CSI. Наприклад:

```yaml
apiVersion: storage.k8s.io/v1
kind: CSIDriver
metadata:
  name: hostpath.csi.k8s.io
spec:
  preventPodSchedulingIfMissing: true
```

Це обмеження застосовується лише до подів, які потребують відповідного тома CSI.

### Ліміти приєднання томів CSI та автомасштабування кластера {#csi-volume-attach-limits-and-cluster-autoscaler}

Якщо опція `--enable-csi-node-aware-scheduling` увімкнена в cluster-autoscaler, тоді cluster-autoscaler може точно обчислити кількість вузлів, необхідних для задоволення подів, що перебувають в стані очікування та потребують томів CSI.

Якщо ви використовуєте cluster-autoscaler у вашому кластері Kubernetes, ми не рекомендуємо запобігати розміщенню подів за допомогою поля `PreventPodSchedulingIfMissing`, якщо опція командного рядка `--enable-csi-node-aware-scheduling` у cluster-autoscaler також не увімкнена. Основна причина цього обмеження, поки функціональна можливість `VolumeLimitScaling` залишається в альфа-версії, полягає в тому, що запобігання розміщенню подів може порушити симуляцію планування, яку виконує cluster-autoscaler, якщо cluster-autoscaler ще не знає про ліміти томів CSI. Ми очікуємо, що це обмеження зникне, коли опція `--enable-csi-node-aware-scheduling` стане увімкненою стандартно у cluster-autoscaler.

Опція командного рядка `--enable-csi-node-aware-scheduling` у cluster-autoscaler може бути увімкнена незалежно від стану функціональної можливості `VolumeLimitScaling` у Kubernetes. Ми рекомендуємо увімкнути її, якщо ваш кластер використовує томи CSI і ви стикаєтеся з проблемами, повʼязаними з надмірним скупченням подів на вузлі, коли новий вузол додається за допомогою cluster-autoscaler, оскільки поточна версія cluster-autoscaler не обчислює правильну кількість вузлів, необхідних для задоволення всіх подів в стані очікування.