Можно ли изменить постоянный объем?

Я запускаю развертывание MySQL на Kubernetes, но похоже, что выделенное пространство было недостаточно, изначально я добавил постоянный том 50GB, и теперь я хотел бы расширить его до 100GB.

Я уже видел, что постоянное требование к томам неизменно после создания, но могу ли я как-то просто изменить постоянный том, а затем воссоздать свое требование?

ОТВЕТЫ

Ответ 1

Да, по состоянию на 1.11 постоянные тома могут быть изменены на определенных облачных провайдеров. Чтобы увеличить размер тома:

  1. Отредактируйте размер PVC с помощью kubectl edit pvc $your_pvc
  2. Завершите стручок, используя объем.

Как только модуль, использующий том, завершается, файловая система расширяется, и размер PV увеличивается. Смотрите ссылку выше для деталей.

Ответ 2

В Kubernetes 1.9 (alpha in 1.8) можно использовать для некоторых типов томов: gcePersistentDisk, awsElasticBlockStore, Cinder, glusterfs, rbd

Требуется включить классы плагина PersistentVolumeClaimResize для плагина и хранения, чье поле allowVolumeExpansion установлено равным true.

См. официальные документы в https://kubernetes.io/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims

Ответ 3

Нет, Kubernetes не поддерживает автоматическое изменение размера тома.

Изменение размера диска в настоящий момент является полностью ручным процессом.

Предполагая, что вы создали объект PV Kubernetes с заданной емкостью, а PV привязан к ПВХ, а затем подключен/подключен/подключен к node для использования модулем. Если вы увеличите размер тома, стручки будут продолжать использовать диск без проблем, однако у них не будет доступа к дополнительному пространству.

Чтобы включить дополнительное пространство на томе, вы должны вручную изменить размер разделов. Вы можете сделать это, следуя инструкциям здесь. Вам нужно сначала удалить модули, ссылающиеся на том, чтобы дождаться его отсоединения, чем вручную подключить/подключить том к некоторому экземпляру виртуальной машины, к которому у вас есть доступ, и выполнить необходимые шаги для его изменения.

Открытая проблема # 35941 для отслеживания запроса функции.

Ответ 4

В терминах изменения размера PVC/PV, которые все еще не поддерживаются в k8, хотя я считаю, что он потенциально может прийти в 1.9

Возможно достичь такого же конечного результата, имея дело с PVC/PV и (например, GCE PD, хотя..

Например, у меня было развертывание gitlab с PVC и динамически подготовленным PV через ресурс StorageClass. Вот шаги, которые я выполнил:

  • Сделайте снимок PD (если вы заботитесь о данных)
  • Убедитесь, что ReclaimPolicy для PV является "Сохранить", при необходимости исправьте, как описано здесь: https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/
  • kubectl describe pv <name-of-pv> (полезно при создании манифеста PV позже)
  • Удалить развертывание /pod (возможно, не обязательно, но кажется более чистым)
  • Удалить PVC и PV
  • Убедитесь, что PD распознан как не используемый ничем (например, консоль google, страница compute/disks)
  • Изменить размер PD с помощью облачного провайдера (например, с помощью GCE это можно сделать на более раннем этапе, даже если диск используется).
  • Создать манифест манифеста k8s PersistentVolume (это ранее выполнялось динамически с использованием ресурса StorageClass). В спецификации PersistentVolume yaml я определил "gcePersistentDisk: pdName: <name-of-pd>" вместе с другими деталями, которые я захватил на шаге 3. убедитесь, что вы обновили spec.capacity.storage до новой емкости, в которой вы хотите, чтобы PV имел (хотя это и не существенно, и здесь нет никакого эффекта, вы можете обновить емкость/значение хранилища в своем манифесте PVC для потомков)
  • kubectl apply (или эквивалент) для воссоздания вашего развертывания /pod, PVC и PV

Примечание: некоторые шаги могут быть не важны, например, удаление некоторых существующих ресурсов развертывания /pod.., хотя я лично предпочитаю их удалять, поскольку я знаю, что ReclaimPolicy является Retain, и у меня есть моментальный снимок.

Ответ 5

Это поддерживается в gcePersistentDisk 1.8 и выше для некоторых типов томов, включая gcePersistentDisk и awsBlockStore, если в кластере включены определенные экспериментальные функции.

Для других типов томов это должно быть сделано вручную на данный момент. Кроме того, поддержка для того, чтобы делать это автоматически, когда модули находятся в сети (приятно!), Появится в будущей версии (в настоящее время намечено на 1.11):

На данный момент это шаги, которые я выполнил, чтобы сделать это вручную с AzureDisk тома AzureDisk (для управляемых дисков), который в настоящее время не поддерживает постоянное изменение размера диска (но для этого также AzureDisk поддержка):

  1. Убедитесь, что у PV есть политика возврата "Сохранить".
  2. Удалите набор с сохранением состояния и связанные с ним модули. Kubernetes должен выпустить PV, хотя статусы PV и PVC останутся Bound. Особое внимание уделите наборам с состоянием, которые управляются оператором, таким как Prometheus - возможно, потребуется временно отключить оператора. Также может быть возможно использовать Scale чтобы делать по одной капсуле за раз. Это может занять несколько минут, наберитесь терпения.
  3. Измените размер основного хранилища для PV с помощью API или портала Azure.
  4. Смонтируйте базовое хранилище на виртуальной машине (такой как мастер Kubernetes), добавив их в качестве "диска" в настройках виртуальной машины. В ВМ используйте e2fsck и resize2fs для изменения размера файловой системы на PV (при условии, что ext3/4 FS). Размонтируйте диски.
  5. Сохраните конфигурацию JSON/YAML связанного PVC.
  6. Удалить связанный ПВХ. PV должен измениться на статус Released.
  7. Отредактируйте YAML-конфигурацию PV, после чего статус PV должен быть Available:
    1. укажите новый размер тома в spec.capacity.storage,
    2. удалите spec.claimref uid и resourceVersion и
    3. удалить status.phase.
  8. Отредактируйте сохраненную конфигурацию PVC:
    1. удалите поле metadata.resourceVersion,
    2. удалите метаданные pv.kubernetes.io/bind-completed и pv.kubernetes.io/bound-by-controller аннотации и
    3. измените поле spec.resources.requests.storage на обновленный размер PV, и
    4. удалить все поля внутри status.
  9. Создайте новый ресурс, используя отредактированную конфигурацию PVC. PVC должен начаться в состоянии Pending, но PV и PVC должны относительно быстро перейти в Bound.
  10. Воссоздайте StatefulSet и/или измените конфигурацию Stateful Set, чтобы перезапустить модули.

Ответ 6

Да, возможно, после версии 1.8 взгляните на расширение объема здесь

Расширение объема было введено в версии 1.8 в качестве функции Alpha