Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Приложения, работающие в Службе Azure Kubernetes (AKS), могут нуждаться в хранении и извлечении данных. Хотя некоторые рабочие нагрузки приложений могут использовать локальное и быстрое хранение на ненужных пустых узлах, для других требуется хранилище, которое сохраняется в течение времени на более стандартных томах данных в пределах платформы Azure.
Может потребоваться несколько модулей pod:
- Совместно использовать одни и те же тома данных.
- Повторно подключите тома данных, если модуль pod переносится на другой узел.
Также может потребоваться собирать конфиденциальные данные или сведения о конфигурации приложения в pod.
В этой статье приводится обзор ключевых понятий хранения данных приложений в AKS:
Определение размера диска ОС по умолчанию
Временные диски ОС
Если вы выберете номер SKU виртуальной машины, поддерживающий диски эфемерной ОС, но не укажете размер диска ОС, AKS по умолчанию создает диск эфемерной ОС с размером, который масштабируется в соответствии с общим временным хранилищем номера SKU виртуальной машины, при условии, что временное хранилище составляет не менее 128GiB. Например, Standard_D8ds_v5
SKU с временным диском размером 300GiB по умолчанию получит 300GiB временный диск ОС, если параметры диска не заданы.
Если вы хотите использовать временное хранилище SKU виртуальной машины, необходимо указать размер диска ОС во время развертывания, в противном случае он используется по умолчанию.
Внимание
Размер диска операционной системы по умолчанию используется только в новых кластерах или пулах узлов, где поддерживаются временные диски ОС и размер диска ОС по умолчанию не указан. Размер диска ОС по умолчанию может повлиять на производительность или стоимость кластера. Невозможно изменить размер диска ОС после создания кластера или пула узлов. Это изменение размера по умолчанию «Ephemeral» влияет на кластеры или пулы узлов, созданные в марте 2025 года или позже.
Управляемые диски ОС
При создании кластера или добавлении нового пула узлов в существующий кластер число виртуальных ЦП по умолчанию определяет размер диска ОС. Количество виртуальных ЦП основано на номере SKU виртуальной машины. В следующей таблице перечислены размеры дисков ОС по умолчанию для каждого номера SKU виртуальной машины:
Ядра SKU виртуальной машины (виртуальные ЦП) | Уровень диска ОС по умолчанию | Резервируемые IOPS | Подготовленная пропускная способность (Мбит/с) |
---|---|---|---|
1–7 | P10/128G | 500 | 100 |
8–15 | P15/256G | 1 100 | 125 |
16–63 | P20/512G | 2300 | сто пятьдесят |
64+ | P30/1024G | 5 000 | 200 |
Внимание
Размер диска управляемой ОС по умолчанию используется только в новых кластерах или пулах узлов, если диски Эфемерной ОС не поддерживаются, а размер диска ОС по умолчанию не указан. Размер диска ОС по умолчанию может повлиять на производительность или стоимость кластера. Невозможно изменить размер диска ОС после создания кластера или пула узлов. Это управляемое изменение размера по умолчанию влияет на кластеры или пулы узлов, созданные в июле 2022 г. или позже.
Временный диск ОС
По умолчанию Azure автоматически реплицирует диск операционной системы для виртуальной машины в хранилище Azure, чтобы избежать потери данных при перемещении виртуальной машины на другой узел. Однако, так как контейнеры не предназначены для сохранения локального состояния, это поведение обеспечивает ограниченное значение, предоставляя некоторые недостатки. К этим недостаткам относятся, но они не ограничиваются, более медленной подготовкой узлов и более высокой задержкой чтения и записи.
Напротив, временные диски ОС хранятся только на предоставляющем удаленный доступ компьютере — фактически как на временном диске. Благодаря этой конфигурации вы получаете более низкую задержку чтения и записи вместе с более быстрым масштабированием узлов и обновлениями кластера.
Примечание.
Если вы явно не запрашиваете управляемые диски Azure для ОС, AKS по умолчанию устанавливает временную (эфемерную) ОС, если это возможно для данной конфигурации пула узлов.
Требования к размеру и рекомендации для временных дисков ОС доступны в документации по виртуальным машинам Azure. Ниже приведены некоторые общие рекомендации по размеру:
Если вы решили использовать размер виртуальной машины AKS по умолчанию Standard_DS2_v2 SKU с размером диска ОС по умолчанию 100 ГиБ, размер виртуальной машины по умолчанию поддерживает эфемерную ОС, но имеет только 86 ГиБ кэша. Эта конфигурация по умолчанию будет использоваться для управляемых дисков, если ее явно не указать. Если вы запрашиваете эфемерную ОС, вы получите ошибку проверки.
Если вы запрашиваете тот же SKU Standard_DS2_v2 с диском для ОС объемом 60 ГиБ, эта конфигурация по умолчанию будет использовать эфемерную ОС. Запрошенный размер 60 ГиБ меньше максимального размера кэша 86 ГиБ.
Если выбрать номер SKU Standard_D8s_v3 с диском ОС размером 100 ГБ, этот размер виртуальной машины поддерживает эфемерную ОС и имеет 200 ГиБ кэша. Если тип диска ОС не указан, пул узлов по умолчанию получит эфемерную ОС.
В последнем поколении серии виртуальных машин нет выделенного кэша, но только временного хранилища. Например, если выбран размер виртуальной машины Standard_E2bds_v5 с размером диска ОС по умолчанию 100 ГиБ, он поддерживает временные диски ОС, но имеет только 75 ГБ временного хранилища. Эта конфигурация по умолчанию будет использоваться для управляемых дисков ОС, если она не указана явным образом. Если вы запрашиваете временный диск ОС, вы получите ошибку проверки.
Если вы запрашиваете тот же размер виртуальной машины Standard_E2bds_v5 с диском ОС 60 ГиБ, эта конфигурация по умолчанию используется для временных дисков ОС. Запрошенный размер 60 ГиБ меньше максимального временного хранилища 75 ГиБ.
Если выбрать номер SKU Standard_E4bds_v5 с диском ОС 100 ГиБ, этот размер виртуальной машины поддерживает эфемерную ОС и имеет 150 ГиБ временного хранилища. Если вы не указываете тип диска ОС, по умолчанию Azure назначает временный диск ОС пулу узлов.
Ключи, управляемые клиентом
Вы можете управлять шифрованием для диска эфемерной ОС с помощью собственных ключей в кластере AKS. Дополнительные сведения см. в статье Об использовании управляемого клиентом ключа с диском Azure в AKS.
Объемы
Kubernetes обычно рассматривает отдельные модули pod как временные, освобождаемые ресурсы. Для использования и сохранения данных внутри приложений предусмотрены различные подходы. Том представляет способ хранения, извлечения и сохранения данных подов в течение жизненного цикла приложения.
Традиционные тома создаются как ресурсы Kubernetes, обслуживаемые службой хранилища Azure. Вы можете вручную создавать тома данных для назначения подам напрямую или позволить Kubernetes автоматически создавать их. Тома данных могут использовать: Azure Disk, Azure Files, Azure NetApp Files или Azure Blobs.
Примечание.
В зависимости от SKU используемой виртуальной машины, драйвер CSI диска Azure может иметь ограничение на количество томов на узел. Для некоторых высокопроизводительных виртуальных машин (например, 16 ядер) ограничение составляет 64 тома на узел. Чтобы определить ограничение на номер SKU виртуальной машины, просмотрите столбец "Максимальное количество дисков данных" для каждого предлагаемого номера SKU виртуальной машины. Список предлагаемых номеров SKU виртуальных машин и их соответствующих подробных ограничений емкости см. в разделе "Размеры виртуальных машин общего назначения".
Чтобы определить, что лучше подходит для вашей рабочей нагрузки — Azure Files или Azure NetApp Files, ознакомьтесь с информацией в статье Сравнение Azure Files и Azure NetApp Files.
Диск Azure
Используйте Azure Disk для создания ресурса DataDisk Kubernetes. Типы дисков включают:
- SSD уровня "Премиум" (рекомендуется для большинства рабочих нагрузок)
- Ультра диски
- Стандартные SSD-диски
- стандартные жесткие диски
Совет
Для большинства рабочих нагрузок и рабочих нагрузок разработки используйте диски SSD класса Premium.
Так как диск Azure подключен как ReadWriteOnce, он доступен только одному узлу. Для томов хранилища, которые доступны подами на нескольких узлах одновременно, используйте Azure Files.
Файлы Azure
Используйте Файлы Azure для монтирования общей папки на базе Server Message Block (SMB) версии 3.1.1 или сетевой файловой системы (NFS) версии 4.1. Файлы Azure позволяют совместно использовать данные между несколькими узлами и модулями pod, а также использовать:
- Хранилище Azure категории "Премиум", использующее твердотельные накопители (SSD) высокой производительности
- Хранилище Azure категории Standard, использующее обычные жесткие диски
Файлы Azure NetApp
- Хранилище Ультра
- Хранилище класса Premium
- Стандартное хранилище
Хранилище BLOB-объектов Azure
Хранилище BLOB-объектов Azure позволяет создать контейнер хранилища BLOB-объектов и подключить его с помощью протокола NFS версии 3.0 или BlobFuse.
- Блочные блоб-объекты
Типы томов
Тома Kubernetes представляют собой не только традиционный диск для хранения и извлечения информации. Тома Kubernetes также можно использовать для внедрения данных в модуль для использования контейнерами.
Распространенные типы томов в Kubernetes включают:
пустая директория
Этот том обычно используется в качестве временного хранилища для pod. Все контейнеры в pod могут обращаться к данных в томе. Данные, записанные в этот тип тома, сохраняются только в течение срока существования пода. После удаления pod том также удаляется. Как правило, этот том использует базовое локальное дисковое хранилище узла, но может существовать и только в памяти узла.
секрет
Вы можете использовать секретные тома для внедрения конфиденциальных данных в поды, например пароли.
- Создайте секрет с помощью API Kubernetes.
- Определите под или развертывание и запросите определённый секрет.
- Секреты предоставляются только узлам, на которых запланирован под, который их требует.
- Секрет хранится в tmpfs, а не записывается на диск.
- При удалении последнего модуля pod на узле, требующего секрета, секрет удаляется из tmpfs узла.
- Секреты хранятся в заданном пространстве имен и доступны только для podов в том же пространстве имен.
configMap
Вы можете использовать configMap для внедрения свойств в pod'ы, таких как сведения о конфигурации приложения. Определите информацию о конфигурации приложения в качестве ресурса Kubernetes, чтобы в этом формате ее было легко обновлять и применять к новым экземплярам pod по мере развертывания.
Как и в случае использования секрета:
- Создайте ConfigMap с помощью API Kubernetes.
- Запрашивайте ConfigMap при определении pod или при развертывании.
- ConfigMaps хранятся в заданном пространстве имён и доступны только подам в том же пространстве имён.
Постоянные тома
Тома определяются и создаются в ходе жизненного цикла pod. Они существуют только до удаления pod. Нередко pod-ы ожидают, что их хранилище сохранится при переносе на другой хост во время события обслуживания, особенно в StatefulSets. Постоянный том — это ресурс хранилища, для создания и управления которым используется API Kubernetes. Этот том может существовать после истечения времени существования отдельного pod.
Для предоставления постоянного тома можно использовать следующие службы хранилища Azure:
Как указано в разделе томов, выбор дисков Azure или Azure Files часто определяется необходимостью параллельного доступа к данным или уровнем производительности.
Администратор кластера может статически создать постоянный том, или том можно создавать динамически с помощью сервера API Kubernetes. Если модуль pod запланирован и запрашивает хранилище, которое сейчас недоступно, Kubernetes может создать базовое хранилище дисков Azure или файлов и подключить его к pod. Динамическая подготовка использует класс хранилища для определения типа ресурса, который необходимо создать.
Внимание
Постоянные тома не могут использоваться совместно подами Windows и Linux из-за различий в поддержке файловых систем между двумя операционными системами.
Если вы хотите полностью управляемое решение для доступа на уровне блоков к данным, рассмотрите возможность использования хранилища контейнеров Azure вместо драйверов CSI. Хранилище контейнеров Azure интегрируется с Kubernetes, обеспечивая динамическую и автоматическую подготовку постоянных томов. Хранилище контейнеров Azure поддерживает диски Azure, временные диски и Azure Elastic SAN (предварительная версия) в качестве резервного хранилища, предлагая гибкость и масштабируемость для приложений с отслеживанием состояния, работающих в кластерах Kubernetes.
Классы хранилищ
Чтобы указать различные уровни хранилища, например "Премиум" или "Стандартный", можно создать класс хранилища.
Класс хранилища также определяет политику восстановления. При удалении постоянного тома, политика возврата управляет поведением базового ресурса службы хранения Azure. Базовый ресурс можно удалить или сохранить для использования с будущими pod'ами.
Для кластеров, использующих хранилище контейнеров Azure, вы увидите дополнительный класс acstor-<storage-pool-name>
хранилища. Также создается внутренний класс хранилища.
Для кластеров с помощью драйверов интерфейса хранилища контейнеров (CSI) создаются следующие дополнительные классы хранилища:
Класс хранения | Описание |
---|---|
managed-csi |
Использует локально избыточное хранилище Azure Standard SSD (LRS) для создания управляемого диска. Политика освобождения гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, который его использовал. Класс хранилища также настраивает постоянные тома так, чтобы их можно было расширять. Можно изменить запрос на постоянный том, чтобы указать новый размер. Начиная с версии 1.29 Kubernetes, в кластерах Azure Kubernetes Service (AKS), развернутых в нескольких зонах доступности, этот класс хранилища использует зонально-избыточное хранилище Azure Standard SSD (ZRS) для создания управляемых дисков. |
managed-csi-premium |
Использует локально избыточное хранилище Azure Premium (LRS) для создания управляемого диска. Политика освобождения также гарантирует, что базовый диск Azure удаляется при удалении постоянного тома, который его использовал. Аналогичным образом, этот класс хранения позволяет расширять постоянные тома. Начиная с версии Kubernetes 1.29, в кластерах службы Azure Kubernetes Service (AKS), развернутых в нескольких зонах доступности, этот класс хранилища использует зонально избыточное хранилище Azure Premium (ZRS) для создания управляемых дисков. |
azurefile-csi |
Использует хранилище Azure уровня "Стандартный" для создания общей папки Azure. Политика возврата гарантирует, что базовое файловое хранилище Azure удаляется при удалении постоянного тома, использовавшего его. |
azurefile-csi-premium |
Использует хранилище Azure Premium для создания общей папки Azure. Политика возврата гарантирует, что базовое файловое хранилище Azure удаляется при удалении постоянного тома, использовавшего его. |
azureblob-nfs-premium |
Использует хранилище Azure класса Premium для создания контейнера хранилища BLOB-объектов Azure и подключения с помощью протокола NFS версии 3. Политика восстановления гарантирует, что базовый контейнер хранилища BLOB-объектов Azure удаляется при удалении устойчивого тома, который его использовал. |
azureblob-fuse-premium |
Использует хранилище Azure класса Premium для создания контейнера хранилища BLOB-объектов Azure и подключения с помощью BlobFuse. Политика восстановления гарантирует, что базовый контейнер хранилища BLOB-объектов Azure удаляется при удалении устойчивого тома, который его использовал. |
Если для постоянного тома не указан класс хранилища, используется класс хранилища по умолчанию. При запросе постоянных томов убедитесь, что они используют именно то хранилище, которое вам нужно.
Внимание
Начиная с Kubernetes версии 1.21 AKS использует драйверы CSI по умолчанию, а миграция CSI включена. Хотя существующие постоянные тома в дереве продолжают функционировать, начиная с версии 1.26 AKS больше не будет поддерживать тома, созданные с помощью драйвера в дереве и хранилища, подготовленного для файлов и дисков.
Класс default
будет таким же, как класс managed-csi
.
Эффективно начиная с Kubernetes версии 1.29, при развертывании кластеров Службы Azure Kubernetes (AKS) в нескольких зонах доступности, AKS теперь использует хранилище с избыточностью по зонам (ZRS) для создания управляемых дисков во встроенных классах хранилища. ZRS обеспечивает синхронную репликацию управляемых дисков Azure в нескольких зонах доступности Azure в выбранном регионе. Эта стратегия избыточности повышает устойчивость приложений и защищает данные от сбоев центра обработки данных.
Однако важно отметить, что хранилище с избыточностью между зонами (ZRS) обходится дороже, чем локальное избыточное хранилище (LRS). Если оптимизация затрат является приоритетом, можно создать класс хранилища с параметром, заданным skuname
для LRS. Затем можно использовать новый класс хранилища в запросе на выделение постоянного тома (PVC).
Вы можете создать класс хранилища для других нужд с помощью kubectl
. В следующем примере используются управляемые диски уровня "Премиум" и указывается, что базовый диск Azure должен храниться при удалении модуля pod:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
Примечание.
AKS согласовывает классы хранения по умолчанию и перезаписывает любые изменения, внесенные в эти классы хранения.
Дополнительные сведения о классах хранилища см. в разделе StorageClass в Kubernetes.
запросы на постоянный том.
Запрос на постоянный том (ПВХ) запрашивает хранение класса хранения, режима доступа и размера. Сервер API Kubernetes может динамически подготавливать базовый ресурс хранения Azure, если существующий ресурс не может удовлетворить запрос на основе определенного класса хранилища.
Определение pod включает в себя подключение тома после его присоединения к pod.
После назначения доступного ресурса хранилища пакету pod, запрашивающего хранилище, постоянный том привязан к утверждению постоянного тома. Постоянные тома сопоставляются с утверждениями в сопоставлении 1:1.
В следующем примере манифеста YAML показан запрос постоянного тома, который использует класс хранилища managed-premium и запрашивает Azure диск размером 5Gi.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: azure-managed-disk
spec:
accessModes:
- ReadWriteOnce
storageClassName: managed-premium-retain
resources:
requests:
storage: 5Gi
При создании определения Pod также следует указать:
- Запрос на постоянный том для получения требуемого хранилища.
- Подключение тома для приложений, чтобы они могли читать и записывать данные.
В следующем примере YAML-манифеста показано, как предыдущий запрос на постоянный том может использоваться для подключения тома по пути /mnt/azure.
kind: Pod
apiVersion: v1
metadata:
name: nginx
spec:
containers:
- name: myfrontend
image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
volumeMounts:
- mountPath: "/mnt/azure"
name: volume
volumes:
- name: volume
persistentVolumeClaim:
claimName: azure-managed-disk
Для монтажа тома в контейнере Windows укажите букву диска и путь. Например:
...
volumeMounts:
- mountPath: "d:"
name: volume
- mountPath: "c:\k"
name: k-dir
...
Следующие шаги
Советы по лучшим практикам см. в разделах Лучшие практики хранения и резервного копирования в AKS и Соображения по хранению в AKS.
Дополнительные сведения о хранилище контейнеров Azure см. в следующих статьях:
Дополнительные сведения об использовании драйверов CSI см. в следующих статьях:
- Драйверы Container Storage Interface (CSI) для Azure дисков, Azure файлов и хранилища Blob-объектов Azure в службе Azure Kubernetes
- Использование драйвера Azure Disk CSI в Службе Azure Kubernetes
- Драйвер Azure Files CSI в Службе Kubernetes Azure
- Использование драйвера CSI хранилища Blob Azure в службе Azure Kubernetes
- Настройка Azure NetApp Files с помощью Службы Azure Kubernetes
Дополнительные сведения о ключевых понятиях Kubernetes и AKS приведены в следующих статьях:
Azure Kubernetes Service