Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.
Kubernetes v1.34: Відновлення після збою розширення тома (GA)
Чи робили ви коли-небудь друкарську помилку при розширенні ваших постійних томів у Kubernetes? Хотіли вказати 2TB, але вказали 20TiB? Ця, здавалося б, незначна проблема була досить важкою для виправлення, і проєкту знадобилося майже 5 років, щоб її виправити. Автоматичне відновлення після розширення сховища існує вже деякий час у бета-версії; однак, з випуском v1.34, ми перевели її в загальну доступність.
Хоча завжди було можливо відновитися після збою розширення томів вручну, зазвичай це вимагало доступу адміністратора кластера і це було виснажливо (див. вказане посилання для отримання додаткової інформації).
Що, якщо ви зробите помилку, а потім відразу усвідомите це? З Kubernetes v1.34 ви можете зменшити запитуваний розмір PersistentVolumeClaim (PVC) і, якщо розширення до раніше запитуваного розміру не завершилося, ви можете змінити запитуваний розмір. Kubernetes автоматично працюватиме над його виправленням. Будь-яка квота, спожита невдалим розширенням, буде повернена користувачу, а повʼязаний PersistentVolume повинен бути змінений на останній вказаний вами розмір.
Розгляньмо приклад того, як усе це працює.
Зменшення розміру PVC для відновлення після невдалого розширення
Уявіть, що у вас закінчується місце на диску для одного з ваших серверів бази даних, і ви хочете розширити PVC з раніше вказаного 10TB до 100TB, але ви зробили помилку і вказали 1000TB.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1000TB # новий вказаний розмір - але неправильний!
Тепер у вас може закінчитися місце на диску в масиві дисків або просто вичерпані виділені квоти у вашого постачальника хмари. Але припустимо, що розширення до 1000TB ніколи не відбудеться.
У Kubernetes v1.34 ви можете просто виправити свою помилку і запитати новий розмір PVC, менший за помилковий, за умови, що він все ще більший за початковий розмір фактичного PersistentVolume.
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: myclaim
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 100TB # Правильний розмір; має бути більшим за 10TB.
# Не можна зменшити том нижче його фактичного розміру.
Це не вимагає втручання адміністратора. Ще краще, будь-яка надлишкова квота Kubernetes, яку ви тимчасово спожили, буде автоматично повернена.
Цей механізм відновлення після збоїв має одну умову: будь-який новий розмір, який ви вказуєте для PVC, повинен бути все ще більшим за початковий розмір у .status.capacity. Оскільки Kubernetes не підтримує зменшення ваших обʼєктів PV, ви ніколи не зможете опуститися нижче розміру, який спочатку був виділений для вашого запиту PVC.
Поліпшене оброблення помилок і спостережуваність розширення томів
Реалізація того, що може виглядати як відносно незначна зміна, також вимагала від нас майже повністю переробити те, як працює розширення томів під капотом у Kubernetes. Існують нові поля API, доступні в обʼєктах PVC, які ви можете контролювати, щоб спостерігати за прогресом розширення томів.
Поліпшена спостережуваність за розширенням у процесі
Ви можете запитати .status.allocatedResourceStatus['storage'] PVC, щоб відстежувати прогрес операції розширення томів. Для типового блочного тома це має переходити між ControllerResizeInProgress, NodeResizePending і NodeResizeInProgress і ставати nil/порожнім, коли розширення томів завершено.
Якщо з якоїсь причини розширення томів до запитаного розміру неможливе, воно повинно відповідно перебувати в станах, таких як ControllerResizeInfeasible або NodeResizeInfeasible.
Ви також можете спостерігати за розміром, до якого прагне Kubernetes, спостерігаючи за pvc.status.allocatedResources.
Поліпшене оброблення помилок і звітність
Kubernetes тепер повинен повторно спробувати ваші невдалі розширення томів повільніше, він повинен робити менше запитів як до системи зберігання, так і до Kubernetes apiserver.
Помилки, виявлені під час розширення томів, тепер повідомляються як умови в обʼєктах PVC і, на відміну від подій, мають зберігатися. Kubernetes тепер заповнить pvc.status.conditions ключами помилок ControllerResizeError або NodeResizeError, коли розширення томів не вдається.
Виправлення давніх помилок у робочих процесах зміни розміру
Ця можливість також дозволила нам виправити давні помилки в робочих процесах зміни розміру, такі як Kubernetes issue #115294. Якщо ви помітите, що щось не працює, будь ласка, повідомте про свої помилки на https://github.com/kubernetes/kubernetes/issues, разом з деталями про те, як відтворити проблему.
Робота над цією функцією протягом її життєвого циклу була складною, і було б неможливо досягти GA без зворотного звʼязку від @msau42, @jsafrane і @xing-yang.
Всі учасники, які працювали над цим, також цінують внесок, наданий @thockin і @liggitt на різних самітах контрибʼюторів Kubernetes.