Контейнерный кублет и жизненный цикл локального диска - PullRequest
Новая
       57

Контейнерный кублет и жизненный цикл локального диска

1 голос
/ 16 февраля 2020

Платформа: OEL 7.7 + kube 1.15.5 + docker 19.03.1

Мы создаем хранилище объектов с кодированием стирания на k8s, используя подход контейнерного кублета. Нам нелегко придумать жизнеспособный подход к жизненному циклу диска. Как и сейчас, мы должны предоставить аргумент «extra_binds» для кублета, который указывает базовую точку монтирования, где монтируются наши блочные устройства. (80 твердотельных накопителей на узел, отформатированные как ext4)

Это все работает нормально. Создание PV и развертывание приложений работает нормально. Наша проблема возникает, когда PV C удаляется, и мы хотим очистить диски, которые были использованы, и снова сделать диски доступными.

Пока единственное, что работает, это оцепление этот узел, удалите лишние привязки из kubelet, сбросьте узел, перенастройте блочное устройство, заново добавьте привязки kubelet. Очевидно, это слишком неуклюже для производства. Для начала прыгающий кубелет не вариант.

Как только PV используется, что-то блокирует это блочное устройство, даже если проверка lsof на голой металлической системе показывает, что ручки не открыты. Я не могу размонтировать или создать новую файловую систему на устройстве. Просто подпрыгивающий kubelet не освобождает «замок».

Кто-нибудь, использующий плоскость управления kubernetes в контейнере, с приложением, использующим локальные диски подобным образом? Кто-нибудь нашел приемлемый способ обойти эту проблему?

Наш долгосрочный план - написать оператор, который управляет дисками, но даже с оператором я не понимаю, как это может решить эту проблему.

Спасибо за любую помощь,

1 Ответ

0 голосов
/ 17 февраля 2020

Сначала посмотрите на ваши Finalizers: 

$ kubectl describe pvc <PVC_NAME> | grep Finalizers
$ kubectl describe pv <PV_NAME> | grep Finalizers

, если они установлены на Finalizers: [kubernetes.io/pvc-protection] ( объяснено здесь ), что означает, что они защищены и вам нужно отредактировать это, например, используя:

$ kubectl patch pvc <PVC_NAME> -p '{"metadata":{"finalizers":null}}'

Что касается принудительного удаления PersistentVolumes, вы можете попробовать

$ kubectl delete pv <PV_NAME> --force --grace-period=0

Также, пожалуйста, проверьте VolumeAttachment все еще существуют $ kubectl get volumeattachment, поскольку они могут быть заблокированы.

Я также помню, что была проблема с стеком Kubernetes PV отказывается связываться после удаления / повторного создания заявив, что pv содержит uid из pvc, что было заявлено. Вы можете проверить это, отобразив целые yaml из pv:

$ kubectl get pv <PV_NAME> -o yaml и выполнив поиск: 

  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: packages-pvc
    namespace: default
    resourceVersion: "10218121"
    uid: 1aede3e6-eaa1-11e9-a594-42010a9c0005

Вам потребуется предоставить дополнительную информацию о вашем кластере k8s и pv, pvc конфигурации, чтобы я мог go глубже изучить ее или даже протестировать.

...