Kubernetes v1.35: Змінювана спорідненість вузлів PersistentVolume (альфа)
API спорідненості вузлів PersistentVolume зʼявився ще в Kubernetes v1.10. Він широко використовується для позначення того, що томи можуть бути не однаково доступними для всіх вузлів у кластері. Раніше це поле було незмінним, а тепер воно стало змінюваним у Kubernets v1.35 (альфа). Ця зміна відкриває можливості для більш гнучкого управління томами в режимі онлайн.
Для чого робити спорідненість вузлів змінюваною?
Це викликає очевидне запитання: чому зараз зробити спорідненість вузлів змінюваною? Хоча робочі навантаження без збереження стану, такі як Deployments, можна вільно змінювати, і зміни будуть автоматично впроваджуватися шляхом повторного створення кожного Podʼа, PersistentVolumes (PV) мають стан і їх не можна легко створити заново без втрати даних.
Однак постачальники послуг зберігання даних розвиваються, а вимоги до зберігання змінюються. Зокрема, зараз багато постачальників пропонують диски регіонального рівня. Деякі з них навіть підтримують міграцію в режимі реального часу з дискових зон на диски регіонального рівня без переривання робочих навантажень. Ця зміна може бути реалізована за допомогою API VolumeAttributesClass, який нещодавно перейшов у статус GA в версії 1.34. Однак навіть якщо том переміщено до регіонального сховища, Kubernetes все одно не дозволяє планувати Podʼи до інших зон через спорідненість вузлів, записану в обʼєкті PV. У цьому випадку можна змінити спорідненість вузлів PV з:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/zone
operator: In
values:
- us-east1-b
на:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: topology.kubernetes.io/region
operator: In
values:
- us-east1
Іншим прикладом є те, що постачальники іноді пропонують диски нового покоління. Нові диски не завжди можна додати до старих вузлів у кластері. Ця доступність також може бути представлена через спорідненість вузлів PV і гарантує, що Podʼи можна запланувати на правильні вузли. Але коли диск оновлюється, нові Podʼи, що використовують цей диск, все одно можуть бути заплановані на старі вузли. Щоб цього уникнути, можна змінити спорідненість вузлів PV з:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: provider.com/disktype.gen1
operator: In
values:
- available
на:
spec:
nodeAffinity:
required:
nodeSelectorTerms:
- matchExpressions:
- key: provider.com/disktype.gen2
operator: In
values:
- available
Отже, тепер це можна змінювати, що є першим кроком до більш гнучкого управління томів онлайн. Хоча це проста зміна, яка видаляє одну перевірку з API-сервера, нам ще далеко до повної інтеграції з екосистемою Kubernetes.
Спробуйте
Ця функція підходить вам, якщо ви є адміністратором кластера Kubernetes, а ваш постачальник сховища дозволяє здійснювати онлайн-оновлення, якими ви хочете скористатися, але ці оновлення можуть вплинути на доступність тому.
Зверніть увагу, що зміна спорідненості вузлів PV сама по собі не змінить доступність базового тому. Перед використанням цієї функції спочатку необхідно оновити базовий том у постачальника сховища та зрозуміти, які вузли матимуть доступ до тому після оновлення. Після цього можна ввімкнути цю функцію та синхронізувати спорідненість вузлів PV.
Наразі ця функція перебуває в стадії альфа-тестування. Вона є стандартно вимкненою і може бути предметом змін. Щоб її випробувати, увімкніть можливість MutablePVNodeAffinity в APIServer, після чого ви зможете редагувати поле PV spec.nodeAffinity. Зазвичай PV можуть редагувати лише адміністратори, тому переконайтеся, що ви маєте відповідні дозволи RBAC.
Гонитва між оновленням і плануванням
Існує лише кілька факторів поза межами Podʼа, які можуть вплинути на рішення щодо планування, і спорідненість вузлів PV є одним з них. Можна дозволити більшій кількості вузлів отримати доступ до тому, послабивши спорідненість вузлів, але при спробі посилити спорідненість вузлів виникає стан конкуренції: незрозуміло, як планувальник побачить змінений PV у своєму кеші, тому існує невеликий проміжок часу, коли планувальник може розмістити Pod на старому вузлі, який більше не має доступу до тому. У цьому випадку Pod застрягне в стані ContainerCreating.
Одним зі способів усунення цієї проблеми, який зараз обговорюється, є відмова kubelet у запуску Podʼів, якщо порушується спорідненість вузлів PersistentVolume. Ця функція ще не реалізована. Тому, якщо ви пробуєте це зараз, стежте за наступними Podʼами, які використовують оновлений PV, і переконайтеся, що вони заплановані на вузли, які мають доступ до тому. Якщо ви оновлюєте PV і відразу запускаєте нові Podʼи в скрипті, це може не працювати як передбачалося.
Майбутня інтеграція з CSI (Container Storage Interface)
Наразі адміністратор кластера може змінювати як спорідненість вузлів PV, так і базовий том у постачальнику сховища. Однак ручні операції є помилковими та трудомісткими. Бажано з часом інтегрувати це з VolumeAttributesClass, щоб користувач без привілеїв міг змінювати свій PersistentVolumeClaim (PVC) для запуску оновлень на стороні сховища, а спорідненість вузлів PV оновлювалася автоматично в разі потреби без втручання адміністратора кластера.
Ми будемо раді отримати відгуки від користувачів та розробників драйверів сховищ
Як зазначалося раніше, це лише перший крок.
Якщо ви є користувачем Kubernetes, ми хотіли б дізнатися, як ви використовуєте (або будете використовувати) спорідненість вузлів PV. Чи є для вас корисним оновлення її в режимі онлайн?
Якщо ви розробник драйверів CSI, чи готові ви реалізувати цю функцію? Як би ви хотіли, щоб виглядав API?
Надішліть свої відгуки у:
- Каналі Slack #sig-storage.
- Списку розсилки kubernetes-sig-storage.
- В тікеті KEP Mutable PersistentVolume Node Affinity.
З будь-якими запитаннями або конкретними питаннями, повʼязаними з цією функцією, звертайтеся до спільноти SIG Storage.