Compartir a través de

Errores al montar un recurso compartido de archivos de Azure

  • Artículo

En este artículo se proporcionan posibles causas y soluciones de errores que provocan un error en el montaje de un recurso compartido de archivos de Azure.

Síntomas

Implemente un recurso de Kubernetes, como una implementación o un objeto StatefulSet en un entorno de Azure Kubernetes Service (AKS). La implementación creará un pod que monte un objeto PersistentVolumeClaim (PVC) que haga referencia a un recurso compartido de archivos de Azure.

Sin embargo, el pod permanece en el estado ContainerCreating. Al ejecutar el kubectl describe pods comando, es posible que vea uno de los siguientes errores en la salida del comando, lo que hace que se produzca un error en la operación de montaje:

Consulte la salida siguiente como ejemplo:

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)

Nota:

  • Si la cuenta de almacenamiento es accesible públicamente, el nombre de host que se muestra en la salida será storage-account-name.file.core.windows.net>.<
  • Si la cuenta de almacenamiento está configurada de forma privada con un vínculo privado, un punto de conexión o una zona DNS, el nombre de host será storage-account-name.privatelink.file.core.windows.net>.<

Antes de solucionar problemas

Según el mensaje de la salida, como se muestra en el ejemplo siguiente, identifique la cuenta de almacenamiento y el recurso compartido de archivos; los valores se usarán en los pasos de solución de problemas posteriores.

mount "//<storage-account-name.file.core.windows.net/>< pv-fileshare-name>"

Consulte las siguientes secciones para ver posibles causas y soluciones.

Error de montaje(2): No se encontró el archivo o directorio.

Este error muestra que no hay conectividad entre el clúster de AKS y la cuenta de almacenamiento.

Solución inicial de problemas

Azure File se basa en el protocolo SMB (puerto 445). Asegúrese de que el puerto 445 o la dirección IP de la cuenta de almacenamiento no estén bloqueados.

Para comprobar la dirección IP de la cuenta de almacenamiento, ejecute un comando del Sistema de nombres de dominio (DNS) como nslookup, dig o host. Por ejemplo:

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

Para comprobar si hay conectividad entre el clúster de AKS y la cuenta de almacenamiento, acceda al nodo o pod y ejecute los comandos nc o telnet:

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

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

Posibles causas del error de montaje(2)

Nota:

  • Las causas 1, 2 y 4 se aplican a escenarios de cuenta de almacenamiento públicos y privados.
  • La causa 3 solo se aplica al escenario público.

Causa 1: el recurso compartido de archivos no existe

Para comprobar si existe el recurso compartido de archivos, complete estos pasos:

  1. Busque cuentas de Storage en Azure Portal y acceda a la cuenta de almacenamiento.

    Captura de pantalla de la lista de cuentas de almacenamiento en Azure Portal.

  2. Seleccione Recursos compartidos de archivos en Almacenamiento de datos en la cuenta de almacenamiento y compruebe si existe el elemento PersistentVolumeClaim asociado en el archivo yaml del pod, la implementación o el conjunto con estado en Recursos compartidos de archivos.

    Captura de pantalla de la selección de recursos compartidos de archivos en la cuenta de almacenamiento.

Solución: asegurarse de que el recurso compartido de archivos existe

Para resolver este problema, asegúrese de que el recurso compartido de archivos asociado al PV o a la PVC existe.

Causa 2: El grupo de seguridad de red bloquea el tráfico entre AKS y la cuenta de almacenamiento

Compruebe la salida del nc comando o telnet mencionado en la sección Solución de problemas inicial. Si se muestra un tiempo de espera, compruebe el Grupo de seguridad de red (NSG) y asegúrese de que la dirección IP de la cuenta de almacenamiento no esté bloqueada.

Para comprobar si el NSG bloquea la dirección IP de la cuenta de almacenamiento, siga estos pasos:

  1. En Azure Portal, vaya a Network Watcher y seleccione Diagnóstico de NSG.

  2. Rellene los campos con los siguientes valores:

    • Protocolo: Cualquiera
    • Dirección: saliente
    • Tipo de origen: dirección IPv4/CIDR
    • Dirección IPv4/CIDR: la dirección IP de una instancia asociada al nodo de AKS
    • Dirección IP de destino: la dirección IP de la cuenta de almacenamiento
    • Puerto de destino: 445

  3. Seleccione el botón Comprobar y compruebe el estado del tráfico .

El estado de tráfico puede ser Permitido o Denegado. El estado Denegado significa que el grupo de seguridad de red está bloqueando el tráfico entre el clúster de AKS y la cuenta de almacenamiento. Si se deniega el estado, se mostrará el nombre del grupo de seguridad de red.

Solución: permitir la conectividad entre AKS y la cuenta de almacenamiento

Para resolver este problema, haga los cambios que correspondan en el nivel de NSG para permitir la conectividad entre el clúster de AKS y la cuenta de almacenamiento en el puerto 445.

Causa 3: la aplicación virtual bloquea el tráfico entre AKS y la cuenta de almacenamiento

Si usa una aplicación virtual (normalmente un firewall) para controlar el tráfico saliente del clúster de AKS (por ejemplo, la aplicación virtual tiene una tabla de rutas aplicada en la subred del clúster de AKS y la tabla de rutas tiene rutas que envían tráfico hacia la aplicación virtual), la aplicación virtual puede bloquear el tráfico entre el clúster de AKS y la cuenta de almacenamiento.

Para aislar el problema, agregue una ruta en la tabla de rutas de la dirección IP de la cuenta de almacenamiento para enviar el tráfico hacia Internet.

Para confirmar qué tabla de rutas controla el tráfico del clúster de AKS, siga estos pasos:

  1. Vaya al clúster de AKS en Azure Portal y seleccione Propiedades>Grupo de recursos de infraestructura.
  2. Acceda al conjunto de escalado de máquinas virtuales (VMSS) o a una máquina virtual en un conjunto de disponibilidad si usa este tipo de conjunto de máquinas virtuales.
  3. Seleccione Redes virtuales o subredes> e identifique la subred del clúster de AKS. En el lado derecho, verá la tabla de rutas.

Para agregar la ruta en la tabla de rutas, siga los pasos descritos en Creación de una ruta y rellene los siguientes campos:

  • Prefijo de dirección: <storage-account's-public-IP>/32
  • Tipo de próximo salto:Internet

Esta ruta enviará todo el tráfico entre el clúster de AKS y la cuenta de almacenamiento a través de la red pública de Internet.

Después de agregar la ruta, pruebe la conectividad mediante los comandos nc o telnet y vuelva a realizar la operación de montaje.

Solución: asegurarse de que la aplicación virtual permite el tráfico entre AKS y la cuenta de almacenamiento

Si la operación de montaje se realiza correctamente, se recomienda hablar con el equipo de redes para garantizar que la aplicación virtual puede permitir el tráfico entre el clúster de AKS y la cuenta de almacenamiento en el puerto 445.

Causa 4: se usa el grupo de nodos habilitado para FIPS

Si usa un grupo de nodos habilitado para el Estándar federal de procesamiento de información (FIPS), se producirá un error en la operación de montaje porque el FIPS deshabilita algunos módulos de autenticación, lo que impide el montaje de un recurso CIFS compartido. Este comportamiento está previsto y no es específico de AKS.

Para resolver el problema, recurra a una de las siguientes soluciones:

Solución 1: programar pods en nodos en un grupo de nodos que no sea FIPS

El FIPS está deshabilitado de forma predeterminada en grupos de nodos de AKS y solo puede habilitarse al crearse el grupo de nodos mediante el parámetro --enable-fips-image.

Para resolver el error, puede programar los pods en los nodos de un grupo de nodos distinto a FIPS.

Solución 2: crear un pod que se pueda programar en un nodo habilitado para FIPS

Para crear un pod que se pueda programar en un nodo habilitado para FIPS, complete estos pasos:

  1. Use el controlador CSI de Azure File para crear una StorageClass personalizada que emplee el protocolo NFS.

    El siguiente archivo YAML puede servir de ejemplo:

    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

    La SKU se establece en Premium_LRS en el archivo YAML porque la SKU Premium se necesita en NFS. Para obtener más información, consulte Aprovisionamiento dinámico.

    Debido a la SKU Premium, el tamaño mínimo del recurso compartido de archivos es de 100 GB. Para más información, consulte Creación de una clase de almacenamiento.

  2. Cree una PVC que haga referencia a storageClass personalizada azurefile-sc-fips.

    El siguiente archivo YAML puede servir de ejemplo:

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

  3. Cree un pod que monte el PVC azurefile-pvc-fips.

    El siguiente archivo YAML puede servir de ejemplo:

    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

Error de montaje(13): Permiso denegado

Estas son posibles causas de este error:

Nota:

  • La causa 1 se aplica a escenarios públicos y privados.
  • La causa 2 solo se aplica al escenario público.
  • La causa 3 solo se aplica al escenario privado.
  • La causa 4 se aplica a escenarios públicos y privados.
  • La causa 5 se aplica a escenarios públicos y privados.
  • La causa 6 se aplica a escenarios públicos y privados.

Causa 1: El secreto de Kubernetes no hace referencia al nombre o la clave de la cuenta de almacenamiento correctos

Si el recurso compartido de archivos se crea dinámicamente, se crea automáticamente un recurso secreto de Kubernetes con el nombre "azure-storage-account-account-name-secret<>".

Si el recurso compartido de archivos se crea manualmente, el recurso secreto de Kubernetes se debe crear manualmente.

Independientemente del método de creación, si el nombre de la cuenta de almacenamiento o la clave a la que se hace referencia en el secreto de Kubernetes no coincide con el valor real, se producirá el error "Permiso denegado" en la operación de montaje.

Posibles causas de error de coincidencia

  • Si el secreto de Kubernetes se crea manualmente, puede producirse un error tipográfico durante la creación.

  • Si se realiza una operación de rotación de clave en el nivel de cuenta de almacenamiento, los cambios no se reflejarán en el nivel de secreto de Kubernetes. De este modo se producirá un error de coincidencia entre el valor de clave en el nivel de cuenta de almacenamiento y el valor en el nivel de secreto de Kubernetes.

    Si se produce una operación de rotación de clave, se mostrará una operación con el nombre "Regenerar claves de cuenta de almacenamiento" en el registro de actividad de la cuenta de almacenamiento. Tenga en cuenta el período de retención de 90 días para el registro de actividad.

Comprobación del error de coincidencia

Para comprobar el error de coincidencia, siga estos pasos:

  1. Busque y acceda a la cuenta de almacenamiento en el Azure Portal. Seleccione Claves de acceso Mostrar claves> en la cuenta de almacenamiento. Podrá ver el nombre de la cuenta de almacenamiento y las claves asociadas.

    Captura de pantalla del nombre y las claves de la cuenta de almacenamiento.

  2. Vaya al clúster de AKS, seleccione Secretos de configuración>y busque y acceda al secreto asociado.

    Captura de pantalla de la búsqueda y selección de la cuenta de almacenamiento.

  3. Seleccione Mostrar (el icono de ojo) y compare los valores del nombre de la cuenta de almacenamiento y la clave asociada con los valores del paso 1.

    Captura de pantalla que muestra el nombre y la clave de la cuenta de almacenamiento en un secreto.

    Antes de seleccionar Mostrar, los valores del nombre de la cuenta de almacenamiento y la clave asociada se codifican en cadenas base64. Después de seleccionar Mostrar, los valores se descodifican.

Si no tiene acceso al clúster de AKS en el Azure Portal, realice el paso 2 en el nivel kubectl:

  1. Obtenga el archivo YAML del secreto de Kubernetes y ejecute el siguiente comando para obtener los valores del nombre de la cuenta de almacenamiento y la clave de la salida:

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

  2. Utilice el comando echo para descodificar los valores del nombre de la cuenta de almacenamiento y la clave y compararlos con los valores del nivel de cuenta de almacenamiento.

    Este es un ejemplo para descodificar el nombre de la cuenta de almacenamiento:

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

    Captura de pantalla del comando que descodifica el nombre de la cuenta de almacenamiento.

Solución: ajuste el secreto de Kubernetes y vuelva a crear los pods

Si el valor del nombre o la clave de la cuenta de almacenamiento en el secreto de Kubernetes no coincide con el valor de Claves de acceso de la cuenta de almacenamiento, ajuste el secreto de Kubernetes en el nivel de secreto de Kubernetes mediante la ejecución del comando siguiente:

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

El valor del nombre de la cuenta de almacenamiento o la clave agregada en la configuración del secreto de Kubernetes debe ser un valor codificado en base64. Para obtener el valor codificado, use el comando echo.

Este es un ejemplo para codificar el nombre de la cuenta de almacenamiento:

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

Para obtener más información, consulte Administración de secretos mediante kubectl.

Una vez que el secreto azure-storage-account-<storage-account-name>-secret de Kubernetes tenga los valores correctos, vuelva a crear los pods. De lo contrario, esos pods seguirán usando los valores antiguos que ya no son válidos.

Causa 2: La red virtual y la subred de AKS no están permitidas para la cuenta de almacenamiento

Si la red de la cuenta de almacenamiento está limitada a redes seleccionadas, pero la red virtual y la subred del clúster de AKS no se agregan a las redes seleccionadas, se producirá el error "Permiso denegado" en la operación de montaje.

Solución: Permitir la red virtual y la subred de AKS para la cuenta de almacenamiento

  1. Identifique el nodo que hospeda el pod defectuoso mediante la ejecución del comando siguiente:

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

    Compruebe el nodo desde la salida del comando:

    Captura de pantalla del comando que puede identificar el nodo y la salida.

  2. Vaya al clúster de AKS en Azure Portal, seleccione Propiedades>Grupo de recursos de infraestructura, acceda a VMSS asociado con el nodo y, a continuación, active Red virtual o subred para identificar la red virtual y la subred.

    Captura de pantalla del valor de red virtual o subred.

  3. Acceda a la cuenta de almacenamiento en el Azure Portal. Seleccionar Redes. Si Permitir el acceso desde está establecido en Redes seleccionadas, compruebe si se agregan la red virtual y la subred del clúster de AKS.

    Captura de pantalla de la lista de redes seleccionadas vacía.

    Si no se agregan la red virtual y la subred del clúster de AKS, seleccione Agregar red virtual existente. En la página Agregar redes, escriba la red virtual y la subred del clúster de AKS y seleccione Agregar>guardar.

    Captura de pantalla de la adición de redes a la cuenta de almacenamiento.

    Los cambios pueden tardar unos minutos en surtir efecto. Una vez agregada la red virtual y la subred, compruebe si el estado del pod cambia de ContainerCreating a Running.

    Captura de pantalla de la salida del comando que muestra el estado actual del pod.

Causa 3: La conectividad se realiza a través de un vínculo privado, pero los nodos y el punto de conexión privado están en redes virtuales diferentes

Cuando el clúster de AKS y la cuenta de almacenamiento están conectados a través de un vínculo privado, se usa una conexión de punto de conexión privado aprobada.

Captura de pantalla de la conexión de punto de conexión privado.

En este escenario, si el punto de conexión privado y el nodo de AKS están en la misma red virtual, podrá montar un recurso compartido de archivos de Azure.

Si el punto de conexión privado y el clúster de AKS están en redes virtuales diferentes, se producirá el error "Permiso denegado" en la operación de montaje.

Entre en el nodo y compruebe si el nombre de dominio completo (FQDN) se resuelve a través de una dirección IP pública o privada. Para ello, ejecute el siguiente comando:

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

Si el FQDN se resuelve a través de una dirección IP pública (consulte la siguiente captura de pantalla), cree un vínculo de red virtual para la red virtual del clúster de AKS en el nivel de zona DNS privada ("privatelink.file.core.windows.net"). Tenga en cuenta que ya se ha creado automáticamente un vínculo de red virtual para la red virtual del punto de conexión privado de la cuenta de almacenamiento.

Captura de pantalla que muestra el FQDN se resuelve mediante una dirección IP pública.

Para crear el vínculo de red virtual, siga estos pasos:

  1. Acceda a la zona DNS privado y seleccione Vínculos>de red virtual Agregar.

    Captura de pantalla que muestra un vínculo de red virtual que se agrega a la cuenta de almacenamiento.

  2. Rellene los campos y seleccione la red virtual del clúster de AKS para redes virtuales. Para obtener información sobre cómo identificar la red virtual del clúster de AKS, consulte la sección Solución: Permitir la red virtual y la subred de AKS para la cuenta de almacenamiento.

    Captura de pantalla que muestra cómo agregar un vínculo de red virtual.

  3. Seleccione Aceptar.

Una vez agregado el vínculo de red virtual, el FQDN debe resolverse a través de una dirección IP privada y la operación de montaje debe realizarse correctamente. Consulte la captura de pantalla siguiente para obtener un ejemplo:

Captura de pantalla que muestra que se resuelve la dirección IP privada.

Causa 4: La cuenta de almacenamiento está establecida para requerir el cifrado que el cliente no admite

La configuración de seguridad de Azure Files contiene una serie de opciones para controlar la configuración de seguridad y cifrado en las cuentas de almacenamiento. Restringir los métodos y algoritmos permitidos puede impedir que los clientes se conecten.

Las versiones de AKS anteriores a la 1.25 se basan en Ubuntu 18.04 LTS, que usa el kernel de Linux 5.4 y solo admite los algoritmos de cifrado AES-128-CCM y AES-128-GCM. El perfil de seguridad máxima o un perfil personalizado que deshabilita AES-128-GCM provocará errores de asignación de recursos compartidos.

Las versiones 1.25 y posteriores de AKS se basan en Ubuntu 22.04, que usa el kernel de Linux 5.15 y admite AES-256-GCM.

Solución: Permitir que se use el algoritmo de cifrado AES-128-GCM

Habilite el algoritmo AES-128-GCM mediante el perfil de compatibilidad máxima o un perfil personalizado que habilite AES-128-GCM. Para obtener más información, consulte configuración de seguridad de Azure Files.

Causa 5: No se cumple el requisito de cifrado mínimo para una cuenta de almacenamiento

Solución: Habilitar el algoritmo de cifrado AES-128-GCM para todas las cuentas de almacenamiento

Para montar o acceder correctamente a un recurso compartido de archivos, el algoritmo de cifrado AES-128-GCM debe estar habilitado para todas las cuentas de almacenamiento.

Si desea usar solo el cifrado AES-256-GCM, haga lo siguiente:

Linux

Use el siguiente script para comprobar si el cliente admite AES-256-GCM y aplicarlo solo si lo hace:

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

También puede usar un daemonSet de Kubernetes para aplicar AES-256 en cada nodo. Observe el ejemplo siguiente:

support-cifs-aes-256-gcm.yaml

Windows

Use el comando Set-SmbClientConfiguration de PowerShell para especificar los cifrados de cifrado utilizados por el cliente SMB y el tipo de cifrado preferido sin confirmación del usuario:

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

Nota:

El EncryptionCiphers parámetro está disponible a partir de la actualización acumulativa 2022-06 para Windows Server versión 21H2 para sistemas basados en x64 (KB5014665) y la actualización acumulativa para Windows 11, versión 22H2 (KB5014668).

Causa 6: El perfil de seguridad se usa sin la autenticación NTLM v2 habilitada

Cuando se usa el perfil de seguridad máximo o un perfil de seguridad personalizado sin el mecanismo de autenticación NTLM v2 habilitado, la operación de montaje producirá el error "Error de montaje(13): Permiso denegado".

Solución: habilite la autenticación NTLM v2 o use el perfil "Compatibilidad máxima"

Para montarlo correctamente en AKS, debe habilitar el mecanismo de autenticación NTLM v2 para el perfil de seguridad personalizado o usar el perfil de seguridad de compatibilidad máxima.

Más información

Si experimenta algún otro error de montaje, consulte Solución de problemas de Azure Files en Linux.

Ponte en contacto con nosotros para obtener ayuda

Si tiene preguntas o necesita ayuda, cree una solicitud de soporte o busque consejo en la comunidad de Azure. También puede enviar comentarios sobre el producto con los comentarios de la comunidad de Azure.