Приложение Kubernetes, которое использует хранилище локальных узлов для хранения изменяемого состояния (как в Kubernetes 101 example) теряет свое хранилище при обновлении приложения. Это побочный эффект типичного Подход к развертыванию обновления открытия новых капсул и отказа от старых. Это прискорбно, так как это означает повторное копирование данных (возможно, сотни гигабайт) на каждый узел, даже если данные часто уже находятся в недоступном томе. Это сильно замедляет обновления.
Что может сделать прикладной программист, чтобы это оптимизировать? Некоторые атрибуты модуля могут быть обновлено на месте, но это касается только небольшой части обновлений. Постоянные тома по своей сути являются удаленными, а не локальными, поэтому они не могут быть сопоставлены и не будут иметь такой же производительности, как локальное хранилище; и у них ненадлежащим образом есть время жизни, независимое от развертывания, которому они должны принадлежать. Выпуск № 9043 обсуждает проблему, но, похоже, не приходит к консенсусу; и, в любом случае, иногда модуль можно заменить на том же узле, но не обновить на месте. Выпуск № 7562 начали это обсуждать, но это превратилось в обсуждение постоянных томов. Выпуск # 598 связано, но это действительно для тех случаев, когда вы предпочитаете, чтобы модуль оставался неназначенным ни одному узлу, а не запускал его с пустым каталогом.
В соответствии с текущим дизайном Kubernetes локальное хранилище должно всегда рассматриваться как эфемерный, как контейнер или стручок. Не только из-за подобных сценариев, но и из-за того, что ваш модуль может выйти из строя и быть перенесен в любой момент. Из объемная документация:
Когда Pod удаляется из узла по какой-либо причине, данные в emptyDir удаляются навсегда.
...
Вот некоторые варианты использования emptyDir:
- временное пространство, например, для сортировки слиянием на диске
- контрольная точка долгого вычисления для восстановления после сбоев
- хранение файлов, которые извлекает контейнер диспетчера содержимого, в то время как контейнер веб-сервера обслуживает данные
Постоянные диски GCE SSD довольно быстрые, но если вам действительно нужна производительность локального хранилища, то временно копируйте данные из постоянного хранилища для работы с ним.
Вы можете рассмотреть возможность использования hostPath или локального PV, если вы можете терпеть ограничения, которые он накладывает.
Это должно позволить вам получить преимущества в производительности от mmapping (поскольку том является локальным). Однако вам нужно учитывать несколько вещей:
и у них ненадлежащим образом есть время жизни, независимое от развертывания, которому они должны принадлежать.
Еще одна вещь, на которую вы можете захотеть обратить внимание, - это ваш выбор объекта - по крайней мере, на мой взгляд, развертывание должно быть без состояния.
Наборы состояний обычно лучше подходят для случаев, когда вам действительно нужно какое-то состояние (а наборы состояний имеют иную интерпретацию скользящих обновлений, чем развертывания) и предоставляют некоторую помощь в управлении PV.