Kubernetes v1.33: Покращення в розподілі Pod та обліку CSI ресурсів

Надійне планування станісних застосунків значною мірою залежить від точних даних про доступність ресурсів на вузлах. У версії Kubernetes v1.33 представлено альфа функцію під назвою Змінний облік доступних ресурсів CSI на вузлі, яка дозволяє драйверам Container Storage Interface (CSI) динамічно оновлювати максимальну кількість томів, яку може обробляти вузол. Постійно узгоджуючи фактичну ємність з поглядом планувальника, ця функція значно підвищує точність планування та зменшує ймовірність помилок під час налаштування подів через застарілі обмеження томів.

Передумови

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

• Операції з зовнішніми томами: Ручні дії з підключення/відключення поза контролем Kubernetes (хмарна консоль, CLI).
• Динамічне виділення апаратних ресурсів: GPU, SR-IOV мережеві картки або NVMe пристрої, які споживають слоти підключення або лінії PCIe.
• Взаємодія між кількома драйверами: Підключення одного драйвера CSI зменшує доступність для іншого (наприклад, AWS EBS проти AWS FSx для Lustre).

Коли Kubernetes базує планування на застарілих даних про ємність, поди, що запитують нові томи, можуть застрягати в стані ContainerCreating або зазнавати невдачі з неясними помилками. Адміністраторам доводиться вручну узгоджувати використання томів або закривати вузли, що впливає на надійність кластера.

Динамічна адаптація обмежень томів CSI

Нова функціональна можливість MutableCSINodeAllocatableCount надає драйверам CSI можливість коригувати обмеження на рівні вузлів під час виконання. Kubelet об’єднує ці оновлення в підсумок status.allocatable вузла, гарантуючи, що планувальник завжди бачить актуальну ємність для підключення.

Як це працює

При активації Kubelet і kube-apiserver координують два механізми оновлення:

• Періодичні оновлення: Драйвери CSI встановлюють nodeAllocatableUpdatePeriodSeconds (мінімум 10 секунд). Kubelet викликає gRPC NodeGetInfo на кожному інтервалі. Поле NodeGetInfoResponse.maxVolumes використовується для оновлення кількості доступних ресурсів вузла.
• Реактивні оновлення: У разі будь-якої невдачі підключення тома, що повертає gRPC ResourceExhausted (код 8), Kubelet негайно викликає NodeGetInfo для виправлення ємності. Це запобігає повторним спробам планування з недійсним обмеженням.

Активація функції

Щоб протестувати змінний облік доступних ресурсів CSI у кластері v1.33, виконайте такі кроки:

1. Редагуйте маніфест kube-apiserver (або командний рядок), щоб включити --feature-gates=MutableCSINodeAllocatableCount=true.
2. Перезапустіть kubelet з увімкненою тією ж функцією.
3. Додайте анотацію до вашого об’єкта драйвера CSI:

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

Це інструктує Kubelet опитувати NodeGetInfo кожні 60 секунд, оновлюючи .status.allocatable[kubernetes.io/ephemeral-storage] відповідно до maxVolumes. Мінімальні інтервали нижче 10 секунд відхиляються для уникнення тиску на API.

Негайні оновлення при невдачах підключення

Крім періодичного оновлення, Kubernetes швидко реагує на помилки ResourceExhausted. Коли драйвер CSI повертає gRPC код 8 під час підключення тома, планувальник активує запит NodeGetInfo для негайного узгодження звітної кількості доступних ресурсів. Це проактивне виправлення запобігає повторним спробам планування та підтримує здоров’я кластера.

Вплив на продуктивність та масштабованість

Активація частих оновлень пов’язана з додатковими витратами на ЦП та мережу — кожен виклик NodeGetInfo є легким gRPC запитом, але в масштабі (тисячі вузлів) це може збільшити навантаження на сервер API CO. Бенчмарки Kubernetes у ранніх користувачів показують:

• приблизно 30% зменшення затримки запуску подів для statefulsets на вузлах з високим обігом томів.
• незначні витрати на ЦП (<0.5% на Kubelet) при використанні 30-секундних інтервалів оновлення.
• Рекомендація: розподіліть інтервали оновлення між вузлами (наприклад, додайте джиттер), щоб зменшити навантаження на сервер API.

Згідно з словами керівника SIG-Storage Junjie Zhou, “Після переходу в бета-версію ми очікуємо інтегрувати цей механізм у логіку інвалідизації кешу планувальника, що ще більше зменшить вік застарілих станів.”

Сумісність і шлях оновлення

Функція змінного обліку доступних ресурсів вимагає підтримки специфікацій CSI >=1.7 для maxVolumes у NodeGetInfoResponse. Основні хмарні драйвери — AWS EBS, Azure Disk, GCP PD — вже в процесі інтеграції необхідного коду. Перед оновленням:

• Переконайтеся, що ваш драйвер реалізує maxVolumes у NodeGetInfo (перевірте журнали драйвера на наявність переговорів щодо можливостей).
• Протестуйте у тестовому кластері з різними типами томів (блокові та файлові системи).
• Ознайомтеся з примітками до випуску драйвера CSI на предмет можливих критичних змін у відображенні gRPC помилок.

Найкращі практики та усунення неполадок

Щоб максимально використати змінні облікові дані:

• Увімкніть MetricsEndpoint на вашому драйвері CSI, щоб відображати затримки та показники успіху NodeGetInfo.
• Налаштуйте сповіщення Prometheus для повторних помилок gRPC ResourceExhausted.
• Використовуйте kubectl describe node , щоб перевіряти зміни .status.allocatable[kubernetes.io/volumes-attach] з часом.

Якщо ви помічаєте сплески запитів до API, розгляньте можливість збільшення nodeAllocatableUpdatePeriodSeconds або поступового впровадження оновлень.

Майбутні напрямки

Ця альфа-функція закладає основу для більш розширеного управління ємністю вузлів. У майбутніх випусках Kubernetes планується:

• Перевести MutableCSINodeAllocatableCount у бета-версію в v1.34, з GA, запланованим на v1.35.
• Впровадити плагін-інформатор CSIStorageCapacity, що дозволить планувальнику кешувати динамічні обмеження зберігання на масштабі кластера.
• Розширити реактивні оновлення, включивши виклики NodeGetVolumeStats, що надають реальні показники використання для епhemeral томів.

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

Джерело: Блог Kubernetes