Состояние PV / PVC после удаления стручка в Кубернетесе - PullRequest
Новая
       68

Состояние PV / PVC после удаления стручка в Кубернетесе

1 голос
/ 16 октября 2019

У меня есть кластер Kubernetes с несколькими развернутыми модулями (DB, Frontend, Redis). Часть, которую я не могу полностью понять, - это то, что происходит с PVC после удаления модуля.

Например, если я удаляю POD_A, связанный с CLAIM_A, я знаю, что CLAIM_A не удаляется автоматически. Если я затем попытаюсь воссоздать POD, он снова подключается к тому же PVC, но все данные отсутствуют.

Может кто-нибудь объяснить, что происходит, я посмотрел официальную документацию, но не имеет никакого смыслана данный момент.

Любая помощь приветствуется.

1 Ответ

0 голосов
/ 17 октября 2019

ПВХ имеют срок службы независимо от стручков. Если PV все еще существует, это может быть связано с тем, что для ReclaimPolicy установлено значение Retain, и в этом случае он не будет удален, даже если PVC исчезнет.

PersistentVolumes может иметь различные политики восстановления, включая «Сохранить», «Переработать» и «Удалить». Для динамически предоставляемых PersistentVolumes политикой возврата по умолчанию является «Удалить». Это означает, что динамически подготовленный том автоматически удаляется, когда пользователь удаляет соответствующий PersistentVolumeClaim. Такое автоматическое поведение может быть неуместным, если том содержит ценные данные. Обратите внимание, что ПОЛИТИКА ПОЛУЧЕНИЯ имеет значение Удалить (значение по умолчанию), которая является одной из двух политик возврата, другая - Сохранить. (Третья политика Recycle устарела). В случае удаления PV удаляется автоматически при удалении PVC, и данные на PVC также будут потеряны.

В этом случае более целесообразно использовать политику «Сохранить». С помощью политики «Сохранить», если пользователь удаляет сообщение PersistentVolumeClaim, соответствующее PersistentVolume не удаляется. Вместо этого он перемещается в фазу «Выпущено», где все его данные можно восстановить вручную.

Это также может происходить, когда постоянный том защищен. Вы должны быть в состоянии проверить это:

Команда: 

$ kubectl describe pvc PVC_NAME | grep Finalizers

Вывод: 

Finalizers:    [kubernetes.io/pvc-protection]

Это можно исправить, установив для финализаторов значение null, используя патч kubectl:

$ kubectl patch pvc PVC_NAME -p '{"metadata":{"finalizers": []}}' --type=merge

РЕДАКТИРОВАТЬ:

PersistentVolume может быть смонтирован на хосте любым способом, поддерживаемым поставщиком ресурсов. Каждый PV получает свой собственный набор режимов доступа, описывающих его возможности.

Режимы доступа:

  • ReadWriteOnce - том может монтироваться как чтение-запись одним узлом
  • ReadOnlyMany - том может быть подключен только для чтения многими узлами
  • ReadWriteMany - том может быть подключен как чтение-запись многими узлами

ВCLI, режимы доступа сокращены до:

  • RWO - ReadWriteOnce
  • ROX - ReadOnlyMany
  • RWX - ReadWriteMany

Так что еслиВы воссоздали модуль pod и планировщик, поместив его на другой узел, и PV установил политику восстановления, установленную на ReadWriteOnce. Это нормально, что вы не можете получить доступ к своим данным.

Заявки используют те же соглашения, что и тома, при запросе хранилища с определенными режимами доступа. Мой совет - отредактировать режим доступа PV в ReadWriteMany. 

$ kubectl edit pv your_pv

Вы должны обновить режим доступа в PersistentVolume, как показано ниже 

   accessModes:
      - ReadWriteMany
...