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

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

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

Типові обмеження Kubernetes

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

Обмеження динамічних томів

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

• Amazon EBS
• Google Persistent Disk
• Azure Disk
• CSI

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

• У Google Compute Engine, до вузла може бути приєднано до 127 томів, залежно від типу вузла.

• Для дисків Amazon EBS на типах екземплярів M5,C5,R5,T3 та Z1D Kubernetes дозволяє приєднувати тільки 25 томів до вузла. Для інших типів інстансів на Amazon Elastic Compute Cloud (EC2), Kubernetes дозволяє приєднувати 39 томів до вузла.

• На Azure до вузла може бути приєднано до 64 дисків, залежно від типу вузла. Докладніше див. Sizes for virtual machines in Azure.

• Якщо драйвер сховища CSI рекламує максимальну кількість томів для вузла (використовуючи NodeGetInfo), kube-scheduler дотримується цього обмеження. Див. специфікації CSI для отримання додаткових деталей.

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

Mutable CSI Node Allocatable Count

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

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

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

• kube-apiserver
• kubelet

Періодичні оновлення

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

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

Якщо функціональну можливість VolumeLimitScaling увімкнено і драйвер CSI має відповідний обʼєкт CSIDriver з встановленим spec.preventPodSchedulingIfMissing у true, тоді планувальник запобігатиме розміщенню подів на вузлах, де ще не встановлено драйвер CSI. Наприклад:

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

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

Ліміти приєднання томів CSI та автомасштабування кластера

Якщо опція --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 не обчислює правильну кількість вузлів, необхідних для задоволення всіх подів в стані очікування.