Я настраиваю учетную запись хранения, чтобы я мог Динамически создавать и использовать постоянный том с Azure Файлами в Azure Kubernetes Service (AKS) . Для этого:
- Иметь PV и PV C для базы данных
- Место для хранения файлов приложения
AKS создает учетная запись хранения в группе ресурсов MC_<resource-group>_<aks-name>_<region>, которая создается автоматически. Однако эта учетная запись хранения уничтожается при изменении размера узла / виртуальной машины (а не количества узлов), поэтому ее не следует использовать, поскольку вы потеряете свои файлы и базу данных, если вам нужен размер узла / виртуальная машина с большим количеством ресурсов.
Эта документация, как и любая другая, с которой я действительно сталкивался, говорит о том, что лучше всего подходит для метода подключения:
- Publi c конечная точка (все сети)
- Publi c конечная точка (выбранные сети)
- Частная конечная точка
Первый вариант звучит как плохая идея.
Второй вариант позволяет мне выберите виртуальную сеть, и есть два варианта:
MC_<resource-group>_<aks-name>_<region> ... опять же, не кажется хорошей идеей, потому что, если размер узла / ВМ изменяется, соединение будет сломался. aks-vnet-<number> ... не уверен, что это такое, но похоже, что он является частью предыдущей группы ресурсов, поэтому также будет уничтожен в ранее упомянутом сценарии.
Третий вариант содержит несколько вариантов сома К ним относится второй вариант.
Итак, как мне безопасно настроить AKS для совместного использования файлов с приложением и сохранения файлов базы данных?
EDIT
Рассматривая как «Брандмауэры и виртуальные сети», так и «Частные соединения конечных точек» для учетной записи хранения, которая поставляется с узлом AKS, похоже, что она просто настроена для «Все сети» ... так что, возможно, если бы это были мои фактические PV и PV C будут сохранены, разве это не проблема? Можно использовать некоторую ясность на топи c.