Ця стаття була опублікована більше року тому. Старіші статті можуть містити застарілу інформацію. Перевірте, чи інформація на цій сторінці не втратила актуальності з моменту її публікації.

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.