Что происходит с томом HostPath kubernetes в случае смерти и повторного подъема модуля на другом узле?

Question

Что происходит с громкостью HostPath kubernetes в случае смерти и повторного подъема модуля на другом узле?

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

Каково правильное решение, чтобы предотвратить это?

Answer 1

Тома хост-пути являются своего рода «аварийной штриховкой». Там нет особой настойчивости, жизненного цикла или чего-либо еще, связанного с ними. Если модуль переупорядочен на другом узле, то

1. Он увидит содержимое того же каталога хостов на другом узле, который может совпадать или не совпадать, и

2. Если вы храните данные приложения в этом каталоге хоста на первом узле, они фактически станут "потерянными".

Это делает путь к хосту объемы не подходят для нормальных данных приложения; выберите практически любой другой тип хранилища.

Место, где я видел их эффективное использование, - это место, где вам действительно нужно управлять некоторыми данными, которые обычно живут в хост-системе. Например, стандартное развертывание fluentd Kubernetes запускает fluentd в наборе демонов для сбора журналов из /var/lib/docker/containers на каждом узле кластера; это данные, управляемые демоном хоста Docker, а не каким-либо конкретным контейнером. Поскольку он управляется набором демонов, он запускается на каждом узле, поэтому, если узел удаляет свои журналы и его перенаправитель журналов уходит с ним на go, и это вполне ожидаемо.

Answer 2

Несколько лучшим решением, чем HostPath, является использование local PersistentVolumes

Локальные тома могут использоваться только в качестве статически созданного PersistentVolume. Подготовка Dynami c пока не поддерживается. По сравнению с томами hostPath локальные тома можно использовать в долговременном и переносимом режиме без ручного планирования Pod на узлы, поскольку система знает об ограничениях узлов тома, просматривая сходство узлов в PersistentVolume.

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

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

Локальный PersistentVolume требует ручной очистки и удаления пользователем, если внешний статус c поставщик не используется для управления жизненным циклом тома.