Устранение неполадок с хранилищем контейнеров Azure

Статья
12/18/2024

Хранилище контейнеров Azure — это облачная служба управления томами, развертывания и оркестрации, созданная изначально для контейнеров. Используйте эту статью, чтобы устранить распространенные проблемы с хранилищем контейнеров Azure и найти решения проблем.

Устранение ошибок установки

Не удается установить хранилище контейнеров Azure из-за отсутствия конфигурации

После выполнения az aks createможет появиться сообщение о сбое установки хранилища контейнеров Azure. Создается кластер AKS. Запустите az aks update вместе с --enable-azure-container-storage тем, чтобы включить хранилище контейнеров Azure.

Это сообщение означает, что хранилище контейнеров Azure не было установлено, но кластер AKS (Служба Azure Kubernetes) был создан правильно.

Чтобы установить хранилище контейнеров Azure в кластере и создать пул носителей, выполните следующую команду. Замените <cluster-name> и <resource-group> собственными значениями. Замените <storage-pool-type> на azureDisk, ephemeraldisk или elasticSan.

az aks update -n <cluster-name> -g <resource-group> --enable-azure-container-storage <storage-pool-type>

Не удается установить хранилище контейнеров Azure из-за ограничений Политика Azure

Если Политика Azure ограничения существуют, служба хранилища контейнеров Azure может завершиться ошибкой. В частности, хранилище контейнеров Azure использует привилегированные контейнеры. Вы можете настроить Политика Azure для блокировки привилегированных контейнеров. Если они заблокированы, установка хранилища контейнеров Azure может завершиться сбоем или сбоем, и в таких журналах могут возникнуть ошибки gatekeeper-controller :

$ kubectl logs -n gatekeeper-system deployment/gatekeeper-controller
... 
{"level":"info","ts":1722622443.9484184,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: prereq, securityContext: {\"privileged\": true, \"runAsUser\": 0}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-prereq-gt58x","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622443.9839077,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: metrics-exporter, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-metrics-exporter-286np","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0515249,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: csi-node, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-csi-node-7hcd7","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0729053,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: io-engine, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-io-engine-84hwx","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622444.0742755,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-x6q5n","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}
{"level":"info","ts":1722622449.2412128,"logger":"webhook","msg":"denied admission: Privileged container is not allowed: ndm, securityContext: {\"privileged\": true}","hookType":"validation","process":"admission","details":{},"event_type":"violation","constraint_name":"azurepolicy-k8sazurev2noprivilege-686dd8b209a774ba977c","constraint_group":"constraints.gatekeeper.sh","constraint_api_version":"v1beta1","constraint_kind":"K8sAzureV2NoPrivilege","constraint_action":"deny","resource_group":"","resource_api_version":"v1","resource_kind":"Pod","resource_namespace":"acstor","resource_name":"azurecontainerstorage-ndm-b5nfg","request_username":"system:serviceaccount:kube-system:daemon-set-controller"}

Чтобы устранить блокировку, необходимо добавить acstor пространство имен в список исключений Политика Azure. Политика Azure используется для создания и применения правил для управления ресурсами в Azure, включая кластеры AKS. В некоторых случаях политики могут блокировать создание модулей pod и компонентов службы хранилища контейнеров Azure. Дополнительные сведения о работе с Политика Azure для Kubernetes см. в Политика Azure для Kubernetes.

Чтобы добавить acstor пространство имен в список исключений, выполните следующие действия.

Создайте кластер Azure Kubernetes.
Включите Политика Azure для AKS.
Создайте политику, которую вы подозреваете, блокирует установку хранилища контейнеров Azure.
Попытайтесь установить хранилище контейнеров Azure в кластере AKS.
Проверьте журналы для модуля pod шлюза-контроллера, чтобы подтвердить любые нарушения политики.
acstor Добавьте пространство имен и azure-extensions-usage-system пространство имен в список исключений политики.
Повторите попытку установить хранилище контейнеров Azure в кластере AKS.

Не удается установить и включить хранилище контейнеров Azure в пулах узлов с запятыми

Вы можете настроить тоны узлов в пулах узлов, чтобы ограничить планирование модулей pod в этих пулах узлов. Установка и включение хранилища контейнеров Azure в этих пулах узлов может быть заблокирована, так как необходимые модули pod не могут быть созданы в этих пулах узлов. Поведение применяется как к пулу системных узлов при установке, так и к пулам пользовательских узлов при включении.

Вы можете проверить фрагменты узлов, используя следующий пример:

$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
  {
    "PoolName": "nodepoolx",
    "nodeTaints": [
      "sku=gpu:NoSchedule"
    ]
  }
]

Вы можете временно удалить эти тоны, чтобы разблокировать и настроить их обратно после установки и включения. Вы можете перейти к пулам узлов кластера > AKS на портале > Azure, щелкнуть пул узлов, удалить фрагменты в разделе "Таинты и метки". Или можно использовать следующую команду, чтобы удалить фрагменты и подтвердить изменение.

$ az aks nodepool update -g $resourceGroup --cluster-name $clusterName --name $nodePoolName --node-taints ""
$ az aks nodepool list -g $resourceGroup --cluster-name $clusterName --query "[].{PoolName:name, nodeTaints:nodeTaints}"
[
...
  {
    "PoolName": "nodepoolx",
    "nodeTaints": null
  }
]

Повторите установку или включение после успешного удаления узлов. После успешного завершения можно настроить тоны узлов, чтобы возобновить ограничения планирования pod.

Не удается задать тип пула носителей для NVMe

Если вы пытаетесь установить хранилище контейнеров Azure с временным диском, в частности с локальным NVMe в кластере, где SKU виртуальной машины не имеет дисков NVMe, вы получите следующее сообщение об ошибке: не удается задать параметр --storage-pool-option в качестве NVMe, так как ни один из пулов узлов не может поддерживать временный диск NVMe.

Чтобы устранить проблему, создайте пул узлов с номером SKU виртуальной машины с дисками NVMe и повторите попытку. См . оптимизированные для хранения виртуальные машины.

Устранение неполадок пула носителей

Чтобы проверить состояние пулов носителей, выполните команду kubectl describe sp <storage-pool-name> -n acstor. Ниже приведены некоторые проблемы, которые могут возникнуть.

Временный пул носителей не утверждает емкость, когда временные диски используются другими наборами управляющей программы.

Включение эфемерного пула носителей в пуле узлов с временным SSD или локальными дисками NVMe может не утверждать емкость этих дисков, если другие наборы управляющей программы используют их.

Выполните следующие действия, чтобы включить хранилище контейнеров Azure исключительно для управления этими локальными дисками:

Выполните следующую команду, чтобы просмотреть запрошенную емкость по эфемеральному пулу носителей:
```
$ kubectl get sp -A
NAMESPACE   NAME                 CAPACITY   AVAILABLE   USED   RESERVED   READY   AGE
acstor      ephemeraldisk-nvme   0          0           0      0          False   82s
```
В этом примере показана нулевая емкость, указанная пулом носителей ephemeraldisk-nvme .

Выполните следующую команду, чтобы подтвердить неисключаемые состояния этих локальных блочных устройств и проверить существующую файловую систему на дисках:

$ kubectl get bd -A
NAMESPACE   NAME                                           NODENAME                               SIZE            CLAIMSTATE   STATUS   AGE
acstor      blockdevice-1f7ad8fa32a448eb9768ad8e261312ff   aks-nodepoolnvme-38618677-vmss000001   1920383410176   Unclaimed    Active   22m
acstor      blockdevice-9c8096fc47cc2b41a2ed07ec17a83527   aks-nodepoolnvme-38618677-vmss000000   1920383410176   Unclaimed    Active   23m
$ kubectl describe bd -n acstor blockdevice-1f7ad8fa32a448eb9768ad8e261312ff
Name:         blockdevice-1f7ad8fa32a448eb9768ad8e261312ff
…
  Filesystem:
    Fs Type:  ext4
…

В этом примере показано, что блочные устройства имеют Unclaimed состояние и на диске есть существующую файловую систему.

Убедитесь, что вы хотите использовать хранилище контейнеров Azure для управления локальными дисками данных исключительно перед продолжением.
Остановите и удалите наборы управляющей программы или компоненты, которые управляют локальными дисками данных.
Войдите на каждый узел с локальными дисками данных.
Удалите существующие файловые системы со всех локальных дисков данных.

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

$ kubectl rollout restart daemonset -l app=ndm -n acstor
daemonset.apps/azurecontainerstorage-ndm restarted
$ kubectl rollout status daemonset -l app=ndm -n acstor --watch
…
daemon set "azurecontainerstorage-ndm" successfully rolled out

Подождите несколько секунд и проверьте, утверждает ли эфемерный пул носителей емкость из локальных дисков данных.

$ kubectl wait -n acstor sp --all --for condition=ready
storagepool.containerstorage.azure.com/ephemeraldisk-nvme condition met
$ kubectl get bd -A
NAMESPACE   NAME                                           NODENAME                               SIZE            CLAIMSTATE   STATUS   AGE
acstor      blockdevice-1f7ad8fa32a448eb9768ad8e261312ff   aks-nodepoolnvme-38618677-vmss000001   1920383410176   Claimed      Active   4d16h
acstor      blockdevice-9c8096fc47cc2b41a2ed07ec17a83527   aks-nodepoolnvme-38618677-vmss000000   1920383410176   Claimed      Active   4d16h
$ kubectl get sp -A
NAMESPACE   NAME                 CAPACITY        AVAILABLE       USED          RESERVED      READY   AGE
acstor      ephemeraldisk-nvme   3840766820352   3812058578944   28708241408   26832871424   True    4d16h

В этом примере пул ephemeraldisk-nvme носителей успешно утверждает емкость из локальных дисков NVMe на узлах.

Ошибка при попытке развернуть пул носителей дисков Azure

Если существующий пул носителей меньше 4 ТиБ (4096 ГиБ), его можно развернуть только до 4095 ГиБ. Если вы пытаетесь расширить предел, внутренний ПВХ отображает сообщение об ошибке о размерах диска или ограничениях типа кэширования. Остановите виртуальную машину или отключите диск и повторите операцию".

Чтобы избежать ошибок, не пытайтесь расширить текущий пул носителей за пределами 4095 ГиБ, если он изначально меньше 4 ТиБ (4096 ГиБ). Пулы носителей размером более 4 ТиБ можно расширить до максимально доступной емкости хранилища.

Это ограничение применяется только при использовании Premium_LRSномеров SKU , Standard_LRSStandardSSD_LRSи StandardSSD_ZRSPremium_ZRSдисков.

Сбой создания эластичной сети SAN

Если вы пытаетесь создать пул носителей Elastic SAN, может появиться сообщение о сбое создания Azure Elastic SAN: максимально возможное количество эластичных SAN для созданной подписки. Это означает, что вы достигнете ограничения на количество ресурсов Elastic SAN, которые можно развернуть в регионе для каждой подписки. Здесь можно проверить ограничение: целевые показатели масштабируемости и производительности elastic SAN. Рассмотрите возможность удаления существующих ресурсов Elastic SAN в подписке, которые больше не используются, или попробуйте создать пул носителей в другом регионе.

Не найдено блочных устройств

Если вы видите это сообщение, скорее всего, вы пытаетесь создать пул носителей временных дисков в кластере, где SKU виртуальной машины не содержит дисков NVMe.

Тип пула носителей уже включен

Если вы пытаетесь включить тип пула носителей, который существует, вы получите следующее сообщение: недопустимое --enable-azure-container-storage значение. Хранилище контейнеров Azure уже включено для типа <storage-pool-type> пула носителей в кластере. Можно проверить наличие существующих пулов носителей, созданных с помощью запуска kubectl get sp -n acstor.

Отключение типа пула носителей

При отключении типа пула носителей с помощью az aks update --disable-azure-container-storage <storage-pool-type> службы хранилища контейнеров Azure или удаления с помощью az aks update --disable-azure-container-storage allэтого типа вы получите следующее сообщение:

Отключение хранилища контейнеров Azure для типа <storage-pool-type> пула носителей принудительно удаляет все пулы носителей одного типа и влияет на приложения, использующие эти пулы носителей. Принудительное удаление пулов носителей также может привести к утечке ресурсов хранилища, которые используются. Хотите проверить, используется ли любой из пулов носителей типа <storage-pool-type> перед отключением хранилища контейнеров Azure? (Y/n)

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

Устранение неполадок тома

Ожидание создания pod из-за временных размеров тома за пределами доступной емкости

Временный том выделяется на одном узле. При настройке размера временных томов для модулей pod размер должен быть меньше доступной емкости временного диска одного узла. В противном случае создание pod находится в состоянии ожидания.

Используйте следующую команду, чтобы проверить, находится ли создание pod в состоянии ожидания.

$ kubectl get pods
NAME     READY   STATUS    RESTARTS   AGE
fiopod   0/1     Pending   0          17s

В этом примере модуль pod fiopod находится в Pending состоянии.

Используйте следующую команду, чтобы проверить, имеет ли модуль pod событие предупреждения для создания persistentvolumeclaim.

$ kubectl describe pod fiopod
...
Events:
  Type     Reason            Age   From               Message
  ----     ------            ----  ----               -------
  Warning  FailedScheduling  40s   default-scheduler  0/3 nodes are available: waiting for ephemeral volume controller to create the persistentvolumeclaim "fiopod-ephemeralvolume". preemption: 0/3 nodes are available: 3 Preemption is not helpful for scheduling..

В этом примере модуль pod отображает предупреждение о создании утверждения fiopod-ephemeralvolumeпостоянного тома.

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

$ kubectl describe pvc fiopod-ephemeralvolume
...
  Warning  ProvisioningFailed    107s (x13 over 20m)  containerstorage.csi.azure.com_aks-nodepool1-29463073-vmss000000_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx  failed to provision volume with StorageClass "acstor-ephemeraldisk-temp": rpc error: code = Internal desc = Operation failed: GenericOperation("error in response: status code '507 Insufficient Storage', content: 'RestJsonError { details: \"Operation failed due to insufficient resources: Not enough suitable pools available, 0/1\", message: \"SvcError :: NotEnoughResources\", kind: ResourceExhausted }'")

В этом примере Insufficient Storage показана причина сбоя подготовки томов.

Выполните следующую команду, чтобы проверить доступную емкость эфемерного диска одного узла.

$ kubectl get diskpool -n acstor
NAME                                CAPACITY      AVAILABLE     USED        RESERVED    READY   AGE
ephemeraldisk-temp-diskpool-jaxwb   75660001280   75031990272   628011008   560902144   True    21h
ephemeraldisk-temp-diskpool-wzixx   75660001280   75031990272   628011008   560902144   True    21h
ephemeraldisk-temp-diskpool-xbtlj   75660001280   75031990272   628011008   560902144   True    21h

В этом примере доступная емкость временного диска для одного узла составляет 75031990272 байт или 69 ГиБ.

Настройте размер хранилища томов меньше доступной емкости и повторно разверните модуль pod. См. раздел "Развертывание модуля pod с универсальным временным томом".

Не удается подключить том из-за хранения метаданных в автономном режиме

Хранилище контейнеров Azure использует etcdраспределенное, надежное хранилище key-value для хранения метаданных томов и управления ими для поддержки операций оркестрации томов. Для обеспечения высокой доступности etcd и устойчивости выполняется в трех модулях pod. Если запущено менее двух etcd экземпляров, хранилище контейнеров Azure останавливает операции оркестрации томов, сохраняя доступ к данным к томам. Хранилище контейнеров Azure автоматически обнаруживает, когда etcd экземпляр находится в автономном режиме и восстанавливает его. Однако если после перезапуска кластера AKS возникают ошибки оркестрации томов, возможно, что etcd экземпляр не удалось выполнить автоматическое восстановление. Следуйте инструкциям в этом разделе, чтобы определить состояние работоспособности etcd экземпляров.

Выполните следующую команду, чтобы получить список модулей pod.

kubectl get pods

Вы можете увидеть выходные данные, аналогичные приведенным ниже.

NAME     READY   STATUS              RESTARTS   AGE 
fiopod   0/1     ContainerCreating   0          25m

Описать модуль pod:

kubectl describe pod fiopod

Как правило, сообщения о сбоях тома отображаются, если хранилище метаданных находится в автономном режиме. В этом примере fiopod находится в состоянии ContainerCreating , а предупреждение FailedAttachVolume указывает, что создание ожидается из-за сбоя подключения тома.

Name:             fiopod 

Events: 

Type     Reason              Age                 From                     Message 

----     ------              ----                ----                     ------- 

Normal   Scheduled           25m                 default-scheduler        Successfully assigned default/fiopod to aks-nodepool1-xxxxxxxx-vmss000009

Warning  FailedAttachVolume  3m8s (x6 over 23m)  attachdetach-controller  AttachVolume.Attach failed for volume "pvc-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" : timed out waiting for external-attacher of containerstorage.csi.azure.com CSI driver to attach volume xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Чтобы проверить состояние экземпляров etcd , можно также выполнить следующую команду:

kubectl get pods -n acstor | grep "^etcd"

Вы должны увидеть выходные данные, аналогичные приведенным ниже, со всеми экземплярами в состоянии выполнения:

etcd-azurecontainerstorage-bn89qvzvzv                            1/1     Running   0               4d19h
etcd-azurecontainerstorage-phf92lmqml                            1/1     Running   0               4d19h
etcd-azurecontainerstorage-xznvwcgq4p                            1/1     Running   0               4d19h

Если выполняется менее двух экземпляров, том не подключается, так как хранилище метаданных находится в автономном режиме, а автоматическое восстановление завершилось сбоем. В этом случае отправьте запрос в службу поддержки Azure.

См. также

Часто задаваемые вопросы о хранилище контейнеров Azure

Поделиться через