поведение тома kubernetes hostPath в кластере с числом узлов не более одного

Question

Если у меня есть развертывание с несколькими репликами, использующими постоянное утверждение тома (pvc) / или постоянный том (pv)
Насколько я понимаю, все реплики будут иметь одинаковые pv. Верно ли это первое утверждение?

Если за pvc у нас есть hostPath pv, я понимаю, что оно не поддерживается, когда число узлов кластера> 1, так как мы не можем синхронизировать c громкость. Таким образом, это сделало бы первое утверждение ложным!
Могу ли я по-прежнему использовать hostPath, рискуя тем, что если планировщики развернуты в другом узле планировщиком, они не будут иметь одинаковое содержимое?

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

Answer 1

Насколько я понимаю, все реплики будут иметь одинаковый pv.

Это правильно. При создании HostPath PV или локального хранилища PV все реплики будут работать как положено. Но с kubernetes вы можете динамически создавать PersistentVolume (используя StorageClasses). Проблема второго подхода заключается в том, что том будет привязан только к одному модулю, а остальные ваши реплики могут выдать следующую ошибку:

Multi-Attach error for volume "pvc-XXXX" Volume is already used by pod(s) YYYY

(я говорю , может , потому что это зависит по типу тома).

Если за pv c у нас есть hostPath pv, я понимаю, что он не поддерживается, когда номер узла кластера> 1, так как мы не можем синхронизироваться c том.

Я не уверен, что вы понимаете идею томов hostPath. Тома HostPath используются для доступа к данным на хостах. Считается плохой практикой использовать hostpath для хранения данных приложения. HostPath обычно используется только с daemonsets и очень специфичными для приложения c рабочими нагрузками.

Чтобы ответить на часть syn c; Вы правы, вы не можете синхронизировать c hostPaths, если он не указывает на монтированное хранилище NFS или подобное.

Чтобы исправить это, существует локальный постоянный том, где мы определяем сходство между узлом, в котором том находится и под, используя громкость. Так что планировщик всегда развертывает модуль на узле (предотвращает, в частности, потерю данных). Что произойдет, если у нас будет несколько реплик, будут ли все реплики развернуты на одном узле?

Да, все реплики будут развернуты на одном узле. Это не лучший вариант, потому что когда указанный узел c выходит из строя, все реплики вашего приложения go отключаются вместе с ним, и приложение больше не может называться высокодоступным.