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

Ошибки при подключении общей папки Azure

  • Статья

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

Симптомы

Вы развертываете ресурс Kubernetes, например Deployment или StatefulSet, в среде Службы Azure Kubernetes (AKS). При развертывании будет создан модуль pod, который подключает заявку PersistentVolumeClaim (PVC), ссылающуюся на общую папку Azure.

Однако модуль pod остается в состоянии ContainerCreating. При выполнении kubectl describe pods команды в выходных данных команды может появиться одна из следующих ошибок, что приводит к сбою операции подключения:

В качестве примера см. следующие выходные данные:

MountVolume.MountDevice failed for volume "\<pv-fileshare-name>"
rpc error: code = Internal desc =
volume(\<storage-account's-resource-group>#\<storage-account-name>#\<pv/fileshare-name>#) > mount "//\<storage-account-name>.file.core.windows.net/\<pv-fileshare-name>" on "/var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-fileshare-name>/globalmount" failed with
mount failed: exit status 32
Mounting command: mount
Mounting arguments: -t cifs -o dir_mode=0777,file_mode=0777,uid=0,gid=0,mfsymlinks,cache=strict,actimeo=30,\<masked> //\<storage-account-name>.file.core.windows.net/\<pv-name> /var/lib/kubelet/plugins/kubernetes.io/csi/pv/\<pv-name>/globalmount
Output: mount error(\<error-id>): \<error-description>
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs) and kernel log messages (dmesg)

Примечание.

  • Если учетная запись хранения общедоступна, имя узла, отображаемое в выходных данных, будет <именем учетной записи> хранения.file.core.windows.net.
  • Если учетная запись хранения настроена в частном порядке с помощью приватного канала, конечной точки или зоны DNS, имя узла будет именем <учетной записи> хранения.privatelink.file.core.windows.net.

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

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

подключение "//<storage-account-name.file.core.windows.net/< pv-fileshare-name>>"

Возможные причины и решения см. в следующих разделах.

Ошибка подключения(2): нет такого файла или каталога.

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

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

Файл Azure использует протокол SMB (порт 445). Убедитесь, что порт 445 и (или) IP-адрес учетной записи хранения не заблокированы.

Чтобы проверить IP-адрес учетной записи хранения, выполните команду службы доменных имен (DNS), например nslookup, dig или host. Например:

nslookup <storage-account-name>.file.core.windows.net

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

nc -v -w 2 <storage-account-name>.file.core.windows.net 445

telnet <storage-account-name>.file.core.windows.net 445

Возможные причины ошибки подключения (2)

Примечание.

  • Причины 1, 2 и 4 относятся к сценариям с общедоступными и частными учетными записями хранения.
  • Причина 3 относится только к общедоступному сценарию.

Причина 1. Общая папка не существует

Чтобы проверить, существует ли общая папка:

  1. Поиск учетных записей хранения в портал Azure и доступ к учетной записи хранения.

    Снимок экрана: список учетных записей хранения в портал Azure.

  2. Выберите общие папки в хранилище данных в учетной записи хранения и проверьте, существует ли связанный файл PersistentVolumeClaim в yaml-файле pod, развертывания или набора с отслеживанием состояния в общих папках.

    Снимок экрана: выбор общих папок в учетной записи хранения.

Решение. Проверьте наличие общей папки

Чтобы решить эту проблему, убедитесь, что общая папка, связанная с PV/PVC, существует.

Причина 2. Группа безопасности сети блокирует трафик между AKS и учетной записью хранения

Проверьте выходные данные nc команды, telnet упомянутые в разделе "Первоначальное устранение неполадок ". Если отображается время ожидания, проверьте группу безопасности сети (NSG) и убедитесь, что IP-адрес учетной записи хранения не заблокирован.

Чтобы проверить, блокирует ли NSG IP-адрес учетной записи хранения, выполните следующие действия:

  1. В портал Azure перейдите к Наблюдатель за сетями и выберите диагностику NSG.

  2. Заполните поля следующими значениями:

    • Протокол: любой
    • Направление: исходящий трафик
    • Тип источника: IPv4-адрес/CIDR
    • IPv4-адрес/CIDR: IP-адрес экземпляра, связанного с узлом AKS.
    • IP-адрес назначения: IP-адрес учетной записи хранения
    • Порт назначения: 445

  3. Нажмите кнопку "Проверить " и проверьте состояние трафика .

Состояние трафика может быть разрешено или запрещено. Состояние "Отказано" означает, что группа безопасности сети блокирует трафик между кластером AKS и учетной записью хранения. Если состояние отказано, будет отображаться имя группы безопасности сети.

Решение. Разрешите подключение между AKS и учетной записью хранения

Чтобы решить эту проблему, внесите соответствующие изменения на уровне NSG, чтобы разрешить подключение между кластером AKS и учетной записью хранения через порт 445.

Причина 3. Виртуальный модуль блокирует трафик между AKS и учетной записью хранения

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

Чтобы локализовать проблему, добавьте маршрут в таблицу маршрутов для IP-адреса учетной записи хранения, чтобы отправлять трафик в Интернет.

Чтобы узнать, какая таблица маршрутов управляет трафиком кластера AKS:

  1. Перейдите в кластер AKS в портал Azure и выберите группу ресурсов инфраструктуры свойств>.
  2. Получите доступ к масштабируемому набору виртуальных машин (VMSS) или к виртуальной машине в группе доступности, если вы используете такой тип набора виртуальных машин.
  3. Выберите подсети виртуальной сети или подсети> и определите подсеть кластера AKS. Справа вы увидите таблицу маршрутов.

Чтобы добавить маршрут в таблицу маршрутов, выполните действия, описанные в разделе Создание маршрута и заполните следующие поля:

  • Префикс адреса: <общедоступный IP-адрес> учетной записи хранения/32
  • Тип следующего прыжка:Интернет

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

После добавления маршрута проверьте возможность подключения с помощью команды nc или telnet и повторите операцию подключения.

Решение. Убедитесь, что виртуальный модуль разрешает трафик между AKS и учетной записью хранения

Если операция подключения выполнена успешно, мы рекомендуем вам проконсультироваться с командой по сетям, чтобы убедиться, что виртуальный модуль может разрешить трафик между кластером AKS и учетной записью хранения через порт 445.

Причина 4. Используется пул узлов с поддержкой FIPS

Если вы используете пул узлов с поддержкой FIPS, операция подключения завершится ошибкой, так как FIPS отключает некоторые модули проверки подлинности, что предотвращает подключение общего ресурса CIFS. Такое поведение является ожидаемым и не специфичным для AKS.

Чтобы устранить эту проблему, используйте одно из следующих решений:

Решение 1. Планирование pod на узлах в пуле узлов без поддержки FIPS

Функция FIPS отключена по умолчанию в пулах узлов AKS и может быть включена только во время создания пула узлов с использованием параметра --enable-fips-image.

Чтобы устранить эту ошибку, можно запланировать pod на узлах в пуле узлов без поддержки FIPS.

Решение 2. Создание pod с возможностью планирования на узле с поддержкой FIPS

Чтобы создать pod с возможностью планирования на узле с поддержкой FIPS:

  1. Используйте драйвер CSI файла Azure для создания пользовательского экземпляра StorageClass, использующего протокол NFS.

    В качестве примера см. следующий файл YAML:

    kind: StorageClass 
apiVersion: storage.k8s.io/v1 
metadata: 
  name: azurefile-sc-fips 
provisioner: file.csi.azure.com 
reclaimPolicy: Delete 
volumeBindingMode: Immediate 
allowVolumeExpansion: true 
parameters: 
  skuName: Premium_LRS 
  protocol: nfs

    Номер SKU имеет значение Premium_LRS в файле YAML, так как для NFS требуется номер SKU Premium. Дополнительные сведения см. в разделе Динамическая подготовка.

    Так как используется номер SKU Premium, минимальный размер общей папки составляет 100 ГБ. Дополнительные сведения см. в разделе Создание класса хранения.

  2. Создайте ПВХ, ссылающийся на пользовательский класс storageClass azurefile-sc-fips.

    В качестве примера см. следующий файл YAML:

    apiVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
  name: azurefile-pvc-fips 
spec: 
  accessModes: 
    - ReadWriteMany 
  storageClassName: azurefile-sc-fips 
  resources: 
    requests: 
      storage: 100Gi

  3. Создайте модуль pod, который подключает ПВХ azurefile-pvc-fips.

    В качестве примера см. следующий файл YAML:

    kind: Pod 
apiVersion: v1 
metadata: 
  name: azurefile-pod-fips 
spec: 
  containers: 
  - name: azurefile-pod-fips 
    image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine 
    resources: 
      requests: 
        cpu: 100m 
        memory: 128Mi 
      limits: 
        cpu: 250m 
        memory: 256Mi 
    volumeMounts: 
    - mountPath: "/mnt/azure" 
      name: volume 
  volumes: 
    - name: volume 
      persistentVolumeClaim: 
        claimName: azurefile-pvc-fips

Ошибка подключения(13): Отказ в разрешении

Возможные причины этой ошибки:

Примечание.

  • Причина 1 относится к общедоступному и частному сценариям.
  • Причина 2 относится только к общедоступному сценарию.
  • Причина 3 относится только к частному сценарию.
  • Причина 4 относится к общедоступному и частному сценариям.
  • Причина 5 применяется к общедоступным и частным сценариям.
  • Причина 6 применяется к общедоступным и частным сценариям.

Причина 1. Секрет Kubernetes не ссылается на правильное имя или ключ учетной записи хранения

Если общая папка создается динамически, ресурс секрета Kubernetes автоматически создается с именем azure-storage-account-storage-storage-account-name-name-secret<>.

Если общая папка создается вручную, ресурс секрета Kubernetes также следует создать вручную.

Независимо от метода создания, если имя учетной записи хранения или ключ, на который ссылается секрет Kubernetes, не соответствует фактическому значению, операция подключения завершится ошибкой "Отказано в разрешении".

Возможные причины несоответствия

  • Если секрет Kubernetes создается вручную, возможна опечатка.

  • Если операция смены ключа выполняется на уровне учетной записи хранения, изменения не будут отражены на уровне секрета Kubernetes. Это приведет к несоответствию между значением ключа на уровне учетной записи хранения и значением на уровне секрета Kubernetes.

    Если выполняется операция смены ключа, в журнале действий учетной записи хранения будет отображаться операция с именем "Повторное создание ключей учетной записи хранения". Учитывайте, что период хранения журнала действий составляет 90 дней.

Проверка несоответствия

Для проверки несоответствия сделайте следующее:

  1. Найдите учетную запись хранения и перейдите к ней на портале Azure. Выберите "Ключи доступа" "Показать ключи>" в учетной записи хранения. Отобразится имя учетной записи хранения и связанные с ней ключи.

    Снимок экрана: имя учетной записи хранения и ключи.

  2. Перейдите в кластер AKS, выберите "Секреты конфигурации>", а затем выполните поиск и доступ к связанному секрету.

    Снимок экрана: поиск и выбор учетной записи хранения.

  3. Выберите "Показать " (значок глаза) и сравните значения имени учетной записи хранения и связанного ключа со значениями на шаге 1.

    Снимок экрана: имя учетной записи хранения и ключ в секрете.

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

Если у вас нет доступа к кластеру AKS на портале Azure, выполните шаг 2 на уровне kubectl:

  1. Получите YAML-файл секрета Kubernetes, а затем выполните следующую команду, чтобы получить значения имени учетной записи хранения и ключа из выходных данных:

    kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>

  2. С помощью команды echo декодируйте значения имени и ключа учетной записи хранения. Затем сравните их со значениями на уровне учетной записи хранения.

    Ниже приведен пример декодирования имени учетной записи хранения:

    echo -n '<storage account name>' | base64 --decode ;echo

    Снимок экрана: команда, которая декодирует имя учетной записи хранения.

Решение. Настройте секрет Kubernetes и повторно создайте модули pod.

Если значение имени учетной записи хранения или ключа в секрете Kubernetes не соответствует значению ключей Доступа в учетной записи хранения, настройте секрет Kubernetes на уровне секрета Kubernetes, выполнив следующую команду:

kubectl edit secret <secret-name> -n <secret-namespace>

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

Вот пример кодирования имени учетной записи хранения:

echo -n '<storage account name>'| base64 | tr -d '\n' ; echo

Дополнительные сведения см. в статье Управление секретами с помощью kubectl.

Когда для секрета Kubernetes azure-storage-account-<storage-account-name>-secret будут установлены правильные значения, повторно создайте модули pod. Иначе эти модули pod будут по-прежнему использовать старые значения, которые больше не являются допустимыми.

Причина 2. Виртуальная сеть и подсеть AKS не разрешены для учетной записи хранения

Если сеть учетной записи хранения ограничена выбранными сетями, но виртуальная сеть и подсеть кластера AKS не добавлены в них, операция подключения завершится ошибкой "Отказано в разрешении".

Решение. Разрешите виртуальную сеть и подсеть AKS для учетной записи хранения

  1. Определите узел, на котором размещен неисправный модуль pod, выполнив следующую команду:

    kubectl get pod <pod-name> -n <namespace> -o wide

    Проверьте узел в выходных данных команды:

    Снимок экрана: команда, которая может удостоверять узел и выходные данные.

  2. Перейдите в кластер AKS в портал Azure, выберите группу ресурсов инфраструктуры свойств>, перейдите к vmSS, связанному с узлом, а затем проверьте виртуальную сеть или подсеть, чтобы определить виртуальную сеть и подсеть.

    Снимок экрана: значение виртуальной сети или подсети.

  3. Перейдите к учетной записи хранилища на портале Azure. Выберите Сети. Если для параметра "Разрешить доступ" задано значение "Выбранные сети", проверьте, добавляется ли виртуальная сеть и подсеть кластера AKS.

    Снимок экрана: список пустых выбранных сетей.

    Если виртуальная сеть и подсеть кластера AKS не добавлены, выберите "Добавить существующую виртуальную сеть". На странице "Добавление сетей" введите виртуальную сеть и подсеть кластера AKS, а затем нажмите кнопку "Добавить>сохранить".

    Снимок экрана: добавление сетей в учетную запись хранения.

    Для вступления изменений в силу может потребоваться несколько минут. После добавления виртуальной сети и подсети проверьте, изменяется ли состояние pod с ContainerCreating на "Выполнение".

    Снимок экрана: выходные данные команды, показывающие текущее состояние pod.

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

При подключении кластера AKS и учетной записи хранения через приватный канал используется утвержденное подключение к частной конечной точке.

Снимок экрана: подключение к частной конечной точке.

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

Если частная конечная точка и кластер AKS находятся в разных виртуальных сетях, операция подключения завершится ошибкой "Отказано в разрешении".

Войдите в узел и проверьте, как разрешается полное доменное имя (FQDN): через общедоступный или через частный IP-адрес. Для этого выполните следующую команду:

nslookup <storage-account-name>.privatelink.file.core.windows.net

Если полное доменное имя разрешается через общедоступный IP-адрес (см. следующий снимок экрана), создайте связь для виртуальной сети кластера AKS на уровне частной зоны DNS (privatelink.file.core.windows.net). Обратите внимание, что для виртуальной сети частной конечной точки учетной записи хранения связь уже автоматически создана.

Снимок экрана: полное доменное имя разрешено общедоступным IP-адресом.

Чтобы создать связь с виртуальную сеть, сделайте следующее:

  1. Перейдите к зоне Частная зона DNS и выберите "Добавить ссылки>виртуальной сети".

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

  2. Заполните поля и выберите виртуальную сеть кластера AKS для виртуальных сетей. Сведения о том, как определить виртуальную сеть кластера AKS, см. в разделе Решение. Разрешите виртуальную сеть и подсеть AKS для учетной записи хранения.

    Снимок экрана: добавление ссылки виртуальной сети.

  3. Нажмите кнопку ОК.

После добавления связи виртуальной сети имя FQDN должно быть разрешено через частный IP-адрес и операция подключения должна завершиться успешно. См. следующий снимок экрана:

Снимок экрана: разрешен частный IP-адрес.

Причина 4. Для учетной записи хранения задано обязательное шифрование, которое клиент не поддерживает

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

Версии AKS, предшествующие 1.25, работают на основе Ubuntu 18.04 LTS, которая использует ядро Linux 5.4 и поддерживает только алгоритмы шифрования AES-128-CCM и AES-128-GCM. Использование профиля Максимальная безопасность или профиля Пользовательский, который не поддерживает AES-128-GCM, приведет к сбоям сопоставления общих папок.

AKS 1.25 и более поздние версии работают на основе Ubuntu 22.04, которая использует ядро Linux 5.15 и поддерживает AES-256-GCM.

Решение. Разрешите использование алгоритма шифрования AES-128-GCM

Включите алгоритм AES-128-GCM с помощью профиля Максимальная совместимость или профиля Пользовательский, который поддерживает AES-128-GCM. Дополнительные сведения см. в разделе Параметры безопасности Файлов Azure.

Причина 5. Минимальное требование шифрования для учетной записи хранения не выполняется

Решение. Включение алгоритма шифрования AES-128-GCM для всех учетных записей хранения

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

Если вы хотите использовать только шифрование AES-256-GCM, сделайте следующее:

Linux

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

cifsConfPath="/etc/modprobe.d/cifs.conf"
echo "$(date) before change ${cifsConfPath}:"
cat ${cifsConfPath}

# Check if 'require_gcm_256' is already present in the configuration file
if ! grep -q "require_gcm_256" "${cifsConfPath}"; then

    # Load the CIFS module
    modprobe cifs

    # Set the parameter at runtime
    echo 1 > /sys/module/cifs/parameters/require_gcm_256

    # Persist the configuration
    echo "options cifs require_gcm_256=1" >> "${cifsConfPath}"

    echo "$(date) after changing ${cifsConfPath}:"
    cat "${cifsConfPath}"
else
    echo "require_gcm_256 is already set in ${cifsConfPath}"
fi

Вы также можете использовать daemonSet Kubernetes для принудительного применения AES-256 на каждом узле. См. следующий пример.

support-cifs-aes-256-gcm.yaml

Windows

Используйте команду Set-SmbClientConfiguration PowerShell, чтобы указать шифры шифрования, используемые клиентом SMB, и предпочтительный тип шифрования без подтверждения пользователя:

Set-SmbClientConfiguration -EncryptionCiphers "AES_256_GCM" -Confirm:$false

Примечание.

Этот EncryptionCiphers параметр доступен начиная с накопительного обновления 2022-06 для Windows Server версии 21H2 для систем на основе x64 (KB5014665) и накопительного обновления для Windows 11 версии 22H2 (KB5014668).

Причина 6. Профиль безопасности используется без включенной проверки подлинности NTLM версии 2

Если вы используете профиль максимальной безопасности или настраиваемый профиль безопасности без механизма проверки подлинности NTLM версии 2, операция подключения завершится ошибкой "Ошибка подключения(13): отклонено разрешение".

Решение. Включение проверки подлинности NTLM версии 2 или использование профиля "Максимальная совместимость"

Чтобы правильно подключить его в AKS, необходимо включить механизм проверки подлинности NTLM версии 2 для пользовательского профиля безопасности или использовать профиль обеспечения максимальной совместимости.

Дополнительная информация

Если возникают другие ошибки подключения, см. статью "Устранение неполадок Файлы Azure в Linux".

Свяжитесь с нами для получения помощи

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