# Kubernetes 1.33: Заповнювач томів перейшов у стан загальної доступності (GA)

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

---

_Заповнювачі томів_ у Kubernetes тепер загальнодоступні (GA)! Функціональна можливість `AnyVolumeDataSource` вважається увімкненою у Kubernetes v1.33, що означає, що користувачі можуть вказати будь-який відповідний [власний ресурс](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) в якості джерела даних для PersistentVolumeClaim (PVC).

Приклад використання dataSourceRef у PVC:

```yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc1
spec:
  ...
  dataSourceRef:
    apiGroup: provider.example.com
    kind: Provider
    name: provider1
```

## Що нового {#what-is-new}

У порівнянні з бета-версією є чотири основні покращення.

### Заповнювач Pod є опціональним {#populator-pod-is-optional}

Під час бета-версії учасники проєкту Kubernetes виявили потенційні витоки ресурсів при видаленні PersistentVolumeClaim (PVC) під час заповнення тома; ці витоки траплялися через обмеження в роботі з завершувачами. Напередодні переходу до стану загальної доступності проєкт Kubernetes додав підтримку видалення тимчасових ресурсів (PVC prime тощо), якщо видалено первинний PVC.

Для цього ми створили три нові функції на основі втулків:

* `PopulateFn()`: Виконує логіку заповнення даних, специфічну для провайдера.
* `PopulateCompleteFn()`: Перевіряє, чи успішно завершилася операція поповнення бази даних.
* `PopulateCleanupFn()`: Очищає тимчасові ресурси, створені функціями, специфічними для провайдера, після завершення заповнення даних

Приклад для провайдера додано до [lib-volume-populator/example](https://github.com/kubernetes-csi/lib-volume-populator/tree/master/example).

### Функції-мутатори для модифікації ресурсів Kubernetes {#mutator-functions-to-modify-the-kubernetes-resources}

Для GA, код контролера CSI для керування заповненням томів отримав `MutatorConfig`, що дозволяє визначати функції-мутатори для модифікації ресурсів Kubernetes. Наприклад, якщо прайм PVC не є точною копією PVC і вам потрібна інформація для драйвера, специфічна для провайдера, ви можете включити цю інформацію у додатковий `MutatorConfig`. Це дозволить вам налаштовувати обʼєкти Kubernetes у заповнювачі томів.

### Гнучка обробка метрик для постачальників {#flexible-metric-handling-for-providers}

Наша бета-версія виявила нову вимогу: необхідність агрегувати метрики не лише з lib-volume-populator, але й з інших компонентів у кодовій базі провайдера.

Щоб розвʼязати цю проблему, SIG Storage запровадила [менеджер метрик провайдера](https://github.com/kubernetes-csi/lib-volume-populator/blob/8a922a5302fdba13a6c27328ee50e5396940214b/populator-machinery/controller.go#L122). Це вдосконалення делегує реалізацію логіки метрик самому провайдеру, а не покладається виключно на lib-volume-populator. Ця зміна забезпечує більшу гнучкість і контроль над збором та агрегацією метрик, що дає змогу отримати більш повне уявлення про продуктивність провайдера.

### Очищення для тимчасових ресурсів {#clean-up-for-temporary-resources}

Під час бета-версії ми виявили потенційні протікання ресурсів при видаленні PersistentVolumeClaim (PVC) під час заповнення тому через обмеження в роботі з завершувачем. Ми вдосконалили заповнювач в цьому випуску GA, щоб він підтримував видалення тимчасових ресурсів (PVC prime тощо), якщо початковий PVC видалено.

## Як користуватися {#how-to-use-it}

Щоб спробувати, будь ласка, дотримуйтесь [інструкцій](/blog/2022/05/16/volume-populators-beta/#trying-it-out) з попереднього допису в блозі.

## Майбутні напрямки та потенційні функціональні запити {#future-directions-and-potential-feature-requests}

На наступному кроці є кілька потенційних запитів на доопрацювання заповнювача томів:

* Багаторазова синхронізація: поточна реалізація передбачає одноразову односпрямовану синхронізацію від джерела до місця призначення. Її можна розширити для підтримки багаторазової синхронізації, увімкнувши періодичну синхронізацію або дозволивши користувачам виконувати синхронізацію на вимогу
* Двонапрямна синхронізація: розширення багаторазової синхронізації, описаної вище, але з двонапрямною синхронізацією між джерелом і пунктом призначення
* Заповнення даних з пріоритетами: зі списком різних dataSourceRef, заповнення на основі пріоритетів
* Заповнення даних з декількох джерел одного постачальника: заповнення декількох різних джерел до одного місця призначення
* Заповнення даних з декількох джерел різних постачальників: заповнення з декількох різних джерел до одного місця призначення, обʼєднуючи заповнення з різних ресурсів в один конвеєр

Щоб переконатися, що ми створюємо щось справді цінне, Kubernetes SIG Storage буде радий почути про будь-які конкретні випадки використання цієї функції, які ви маєте на увазі. Якщо у вас виникли запитання або конкретні проблеми, повʼязані з заповнювачем томів, звертайтеся до [спільноти SIG Storage](https://github.com/kubernetes/community/tree/master/sig-storage).