Compartilhar via

Erros ao montar um compartilhamento de arquivos do Azure

  • Artigo

Este artigo fornece possíveis causas e soluções para erros que causam falha na montagem de um compartilhamento de arquivos do Azure.

Sintomas

Implante um recurso do Kubernetes, como uma Deployment e um StatefulSet, em um ambiente do AKS (Serviço de Kubernetes do Azure). A implantação criará um pod que monta um PVC (PersistentVolumeClaim) referenciando um compartilhamento de arquivo do Azure.

No entanto, o pod permanece no status ContainerCreating. Ao executar o kubectl describe pods comando, você pode ver um dos seguintes erros na saída do comando, o que faz com que a operação de montagem falhe:

Consulte a saída a seguir para ver um exemplo:

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)

Observação

  • Se a conta de armazenamento estiver acessível publicamente, o nome do host exibido na saída será storage-account-name.file.core.windows.net>.<
  • Se a conta de armazenamento estiver configurada de forma privada com um link privado, ponto de extremidade ou zona DNS, o nome do host será storage-account-name.privatelink.file.core.windows.net>.<

Antes da solução de problemas

De acordo com a mensagem na saída, conforme mostrado no exemplo a seguir, identifique a conta de armazenamento e o compartilhamento de arquivo. Os valores serão usados nas etapas posteriores da solução de problemas.

mount "//<nome-da-conta-de-armazenamento.file.core.windows.net/>< nome-do-compartilhamento-de-arquivos-pv>"

Confira as seções a seguir para ver as possíveis causas e soluções.

Erro de montagem (2): Arquivo ou diretório não existe

Esse erro indica que não há conectividade entre o cluster do AKS e a conta de armazenamento.

Solução de problemas inicial

O Arquivo do Azure depende do protocolo SMB (porta 445). Verifique se a porta 445 e/ou o endereço IP da conta de armazenamento não estão bloqueados.

Para verificar o endereço IP da conta de armazenamento, execute um comando DNS (Sistema de Nomes de Domínio), como nslookup, dig ou host. Por exemplo:

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

Para verificar se há conectividade entre o cluster do AKS e a conta de armazenamento, entre no nó ou pod e execute o comando nc ou telnet:

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

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

Possíveis causas para erro de montagem(2)

Observação

  • As causas 1, 2 e 4 se aplicam a cenários de conta de armazenamento pública e privada.
  • A causa 3 aplica-se apenas ao cenário público.

Causa 1: o compartilhamento de arquivos não existe

Para verificar se o compartilhamento de arquivos existe, siga estas etapas:

  1. Pesquise contas de armazenamento no portal do Azure e acesse sua conta de armazenamento.

    Captura de tela da lista de contas de armazenamento no portal do Azure.

  2. Selecione Compartilhamentos de arquivos em Armazenamento de dados na conta de armazenamento e verifique se o PersistentVolumeClaim associado no arquivo yaml do pod, implantação ou statefulset existe em Compartilhamentos de arquivos.

    Captura de tela da seleção de compartilhamentos de arquivos na conta de armazenamento.

Solução: verifique se o compartilhamento de arquivo existe

Para resolver esse problema, verifique se o compartilhamento de arquivo associado ao PV/PVC existe.

Causa 2: o Grupo de Segurança de Rede bloqueia o tráfego entre o AKS e a conta de armazenamento

Verifique a saída do nc comando or telnet mencionado na seção Solução de problemas inicial. Se um tempo limite for exibido, verifique o NSG (Grupo de Segurança de Rede) e se o endereço IP da conta de armazenamento não está bloqueado.

Para verificar se o NSG bloqueia o endereço IP da conta de armazenamento, siga estas etapas:

  1. No portal do Azure, acesse Observador de Rede e selecione Diagnóstico de NSG.

  2. Preencha os campos usando os valores a seguir:

    • Protocolo: Qualquer
    • Direção: Saída
    • Tipo de fonte: endereço IPv4/CIDR
    • Endereço IPv4/CIDR: o endereço IP de uma instância associada ao nó do AKS
    • Endereço IP de destino: o endereço IP da conta de armazenamento
    • Porto de destino: 445

  3. Selecione o botão Verificar e verifique o status do tráfego .

O status do tráfego pode ser Permitido ou Negado. O status Negado significa que o NSG está bloqueando o tráfego entre o cluster do AKS e a conta de armazenamento. Se o status for Negado, o nome do NSG será mostrado.

Solução: permitir a conectividade entre o AKS e a conta de armazenamento

Para resolver esse problema, faça alterações adequadamente no nível do NSG para permitir a conectividade entre o cluster do AKS e a conta de armazenamento na porta 445.

Causa 3: a Solução de Virtualização bloqueia o tráfego entre o AKS e a conta de armazenamento

Se você estiver usando uma Solução de Virtualização (geralmente um firewall) para controlar o tráfego de saída do cluster do AKS (por exemplo, a Solução de Virtualização tem uma tabela de rotas aplicada na sub-rede do cluster do AKS e a tabela de rotas tem rotas que enviam tráfego para a Solução de Virtualização), a Solução de Virtualização pode bloquear o tráfego entre o cluster do AKS e a conta de armazenamento.

Para isolar o problema, adicione uma rota na tabela de rotas para o endereço IP da conta de armazenamento para enviar o tráfego para a Internet.

Para confirmar qual tabela de rotas controla o tráfego do cluster do AKS, siga estas etapas:

  1. Vá para o cluster do AKS no portal do Azure e selecione Grupo de recursos de infraestrutura de propriedades>.
  2. Acesse o VMSS (conjunto de dimensionamento de máquinas virtuais) ou uma VM em um conjunto de disponibilidade se você estiver usando esse tipo de conjunto de VMs.
  3. Selecione Sub-redes de rede/sub-rede>virtual e identifique a sub-rede do cluster do AKS. No lado direito, você verá a tabela de rotas.

Para adicionar a rota na tabela de rotas, siga as etapas em Criar uma rota e preencha os seguintes campos:

  • Prefixo de endereço: <storage-account's-public-IP>/32
  • Tipo de próximo salto:Internet

Essa rota enviará todo o tráfego entre o cluster do AKS e a conta de armazenamento por meio da Internet pública.

Depois de adicionar a rota, teste a conectividade usando o comando nc ou telnet e execute a operação de montagem novamente.

Solução: verifique se a Solução de Virtualização permite o tráfego entre o AKS e a conta de armazenamento

Se a operação de montagem for bem-sucedida, recomendamos que você consulte sua equipe de rede para garantir que a Solução de virtualização possa permitir o tráfego entre o cluster do AKS e a conta de armazenamento na porta 445.

Causa 4: o pool de nós habilitado para FIPS é usado

Se você usar um pool de nós habilitado para FIPS, a operação de montagem falhará porque o FIPS desabilita alguns módulos de autenticação, o que impede a montagem de um compartilhamento CIFS. Esse comportamento é esperado e não é específico do AKS.

Para resolver o problema, use uma das seguintes soluções:

Solução 1: agendar pods em nós em um pool de nós não FIPS

O FIPS é desabilitado por padrão em pools de nós do AKS e só pode ser habilitado durante a criação do pool de nós usando o parâmetro --enable-fips-image.

Para resolver o erro, você pode agendar os pods em nós em um pool de nós não FIPS.

Solução 2: criar um pod que possa ser agendado em um nó habilitado para FIPS

Para criar um pod que possa ser agendado em um nó habilitado para FIPS, siga estas etapas:

  1. Use o driver CSI de Arquivo do Azure para criar um StorageClass personalizado que usa o protocolo NFS.

    Veja o seguinte arquivo YAML como exemplo:

    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

    O SKU é definido como Premium_LRS no arquivo YAML porque o SKU Premium é necessário para o NFS. Para saber mais, consulte Provisionamento dinâmico.

    Devido ao SKU Premium, o tamanho mínimo do compartilhamento de arquivos é de 100 GB. Para obter mais informações, consulte Criar uma classe de armazenamento.

  2. Crie uma PVC que faça referência ao StorageClass personalizado azurefile-sc-fips.

    Veja o seguinte arquivo YAML como exemplo:

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

  3. Crie um pod que monta o PVC azurefile-pvc-fips.

    Veja o seguinte arquivo YAML como exemplo:

    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

Erro de montagem (13): Permissão negada

As possíveis causas para esse erro incluem:

Observação

  • A causa 1 se aplica a cenários públicos e privados.
  • A causa 2 aplica-se apenas ao cenário público.
  • A causa 3 aplica-se apenas a cenários privados.
  • A causa 4 se aplica a cenários públicos e privados.
  • A causa 5 se aplica a cenários públicos e privados.
  • A causa 6 se aplica a cenários públicos e privados.

Causa 1: o segredo do Kubernetes não faz referência ao nome ou à chave da conta de armazenamento correta

Se o compartilhamento de arquivos for criado dinamicamente, um recurso secreto do Kubernetes será criado automaticamente com o nome "azure-storage-account-storage-account-name-secret<>".

Se o compartilhamento de arquivo for criado manualmente, o recurso secreto do Kubernetes deverá ser criado manualmente.

Independentemente do método de criação, se o nome da conta de armazenamento ou a chave referenciada no segredo do Kubernetes for incompatível com o valor real, a operação de montagem falhará com o erro "Permissão negada".

Possíveis causas para a incompatibilidade

  • Se o segredo do Kubernetes for criado manualmente, um erro de digitação poderá ocorrer durante a criação.

  • Se uma operação "Girar chave" for executada no nível da conta de armazenamento, as alterações não serão refletidas no nível do segredo do Kubernetes. Isso irá causar uma incompatibilidade entre o valor da chave no nível da conta de armazenamento e o valor no nível do segredo do Kubernetes.

    Se ocorrer uma operação "Girar chave", uma operação com o nome "Regenerar chaves da conta de armazenamento" será exibida no log de atividades da conta de armazenamento. Lembre-se do período de retenção de 90 dias para o log de atividades.

Verificar incompatibilidade

Para verificar a incompatibilidade, siga estas etapas:

  1. Procure e acesse a conta de armazenamento no portal do Azure. Selecione Chaves>de acesso Mostrar chaves na conta de armazenamento. Você verá o nome da conta de armazenamento e as chaves associadas.

    Captura de tela do nome e das chaves da conta de armazenamento.

  2. Vá para o cluster do AKS, selecione Segredos de Configuração>e, em seguida, pesquise e acesse o segredo associado.

    Captura de tela da pesquisa e seleção da conta de armazenamento.

  3. Selecione Mostrar (o ícone de olho) e compare os valores do nome da conta de armazenamento e da chave associada com os valores na Etapa 1.

    A captura de tela mostra o nome da conta de armazenamento e a chave em um segredo.

    Antes de selecionar Mostrar, os valores do nome da conta de armazenamento e da chave associada são codificados em cadeias de caracteres base64. Depois de selecionar Mostrar, os valores são decodificados.

Se você não tiver acesso ao cluster do AKS no portal do Azure, execute a Etapa 2 no nível kubectl:

  1. Obtenha o arquivo YAML do segredo do Kubernetes e execute o seguinte comando para obter os valores do nome da conta de armazenamento e a chave da saída:

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

  2. Use o comando echo para decodificar os valores do nome da conta de armazenamento e da chave e compará-los com os valores no nível da conta de armazenamento.

    Aqui está um exemplo para decodificar o nome da conta de armazenamento:

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

    Captura de tela do comando que decodifica o nome da conta de armazenamento.

Solução: ajuste o segredo do Kubernetes e recrie os pods

Se o valor do nome ou da chave da conta de armazenamento no segredo do Kubernetes não corresponder ao valor em Chaves de acesso na conta de armazenamento, ajuste o segredo do Kubernetes no nível do segredo do Kubernetes executando o seguinte comando:

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

O valor do nome da conta de armazenamento ou da chave adicionada na configuração de segredo do Kubernetes deve ser um valor codificado em base64. Para obter o valor codificado, use o comando echo.

Aqui está um exemplo para codificar o nome da conta de armazenamento:

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

Para obter mais informações, consulte Gerenciando segredos usando kubectl.

Depois que o segredo azure-storage-account-<storage-account-name>-secret do Kubernetes tiver os valores certos, recrie os pods. Caso contrário, esses pods continuarão usando os valores antigos que não são mais válidos.

Causa 2: a VNET e a sub-rede do AKS não são permitidas para a conta de armazenamento

Se a rede da conta de armazenamento estiver limitada a redes selecionadas, mas a VNET e a sub-rede do cluster do AKS não forem adicionadas às redes selecionadas, a operação de montagem falhará com o erro "Permissão negada".

Solução: permitir a VNET e a sub-rede do AKS para a conta de armazenamento

  1. Identifique o nó que hospeda o pod defeituoso executando o seguinte comando:

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

    Verifique o nó na saída do comando:

    Captura de tela do comando que pode identificar o nó e a saída.

  2. Vá para o cluster do AKS no portal do Azure, selecione o grupo de recursos Propriedades>de Infraestrutura, acesse o VMSS associado ao nó e marque Rede virtual/sub-rede para identificar a VNET e a sub-rede.

    Captura de tela do valor da rede virtual/sub-rede.

  3. Acesse a conta de armazenamento no portal do Azure. Selecione Rede. Se Permitir acesso de estiver definido como Redes selecionadas, verifique se a VNET e a sub-rede do cluster do AKS foram adicionadas.

    Captura de tela da lista de redes selecionadas vazia.

    Se a VNET e a sub-rede do cluster do AKS não forem adicionadas, selecione Adicionar rede virtual existente. Na página Adicionar redes, digite a VNET e a sub-rede do cluster do AKS e selecione Adicionar>Salvar.

    Captura de tela da adição de redes à conta de armazenamento.

    Pode levar alguns minutos para que as alterações entrem em vigor. Depois que a VNET e a sub-rede forem adicionadas, verifique se o status do pod muda de ContainerCreating para Running.

    Captura de tela da saída do comando que mostra o status atual do pod.

Causa 3: a conectividade é por meio de um link privado, mas os nós e o ponto de extremidade privado estão em VNETs diferentes

Quando o cluster do AKS e a conta de armazenamento são conectados por meio de um link privado, uma conexão de ponto de extremidade privado aprovada é usada.

Captura de tela da conexão de ponto de extremidade privado.

Nesse cenário, se o ponto de extremidade privado e o nó do AKS estiverem na mesma VNET, você poderá montar um compartilhamento de arquivos do Azure.

Se o ponto de extremidade privado e o cluster do AKS estiverem em VNETs diferentes, a operação de montagem falhará com o erro "Permissão negada".

Entre no nó e verifique se o FQDN (nome de domínio totalmente qualificado) foi resolvido por meio de um endereço IP público ou privado. Para fazer isso, execute o seguinte comando:

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

Se o FQDN for resolvido por meio de um endereço IP público (consulte a captura de tela a seguir), crie um link de rede virtual para a VNET do cluster do AKS no nível da zona DNS privada ("privatelink.file.core.windows.net"). Observe que um link de rede virtual é criado automaticamente para a VNET do ponto de extremidade privado da conta de armazenamento.

Captura de tela que mostra que o FQDN é resolvido por um endereço IP público.

Para criar um link de rede virtual, siga estas etapas:

  1. Acesse a zona DNS privada e selecione Links de>rede virtual Adicionar.

    A captura de tela mostra um link de rede virtual adicionado à conta de armazenamento.

  2. Preencha os campos e selecione a VNET do cluster do AKS para redes virtuais. Para saber como identificar a VNET do cluster do AKS, consulte a seção Solução: permitir a VNET e a sub-rede do AKS para a conta de armazenamento.

    A captura de tela mostra como adicionar link de rede virtual.

  3. Clique em OK.

Depois que o link de rede virtual for adicionado, o FQDN deverá ser resolvido por meio de um endereço IP privado e a operação de montagem deverá ser bem-sucedida. Consulte a captura de tela a seguir para obter um exemplo:

A captura de tela mostra que o endereço IP privado foi resolvido.

Causa 4: a conta de armazenamento é definida para exigir uma criptografia que o cliente não dá suporte

As Configurações de Segurança dos Arquivos do Azure contêm várias opções para controlar as configurações de segurança e criptografia nas contas de armazenamento. A restrição de métodos e algoritmos permitidos pode impedir que os clientes se conectem.

As versões do AKS anteriores à 1.25 são baseadas no Ubuntu 18.04 LTS, que usa o kernel Linux 5.4 e dá suporte apenas aos algoritmos de criptografia AES-128-CCM e AES-128-GCM. O perfil Segurança máxima ou um perfil Personalizado que desabilita o AES-128-GCM causará falhas no mapeamento de compartilhamento.

As versões 1.25 e posteriores do AKS são baseadas no Ubuntu 22.04, que usa o kernel Linux 5.15 e tem suporte para AES-256-GCM.

Solução: permitir que o algoritmo de criptografia AES-128-GCM seja usado

Habilite o algoritmo AES-128-GCM usando o perfil Compatibilidade máxima ou um perfil Personalizado que habilite o AES-128-GCM. Para obter mais informações, consulte Configurações de Segurança dos Arquivos do Azure.

Causa 5: o requisito mínimo de criptografia para uma conta de armazenamento não é atendido

Solução: habilitar o algoritmo de criptografia AES-128-GCM para todas as contas de armazenamento

Para montar ou acessar com êxito um compartilhamento de arquivos, o algoritmo de criptografia AES-128-GCM deve ser habilitado para todas as contas de armazenamento.

Se você quiser usar apenas a criptografia AES-256-GCM, faça o seguinte:

Linux

Use o script a seguir para verificar se o cliente dá suporte ao AES-256-GCM e aplicá-lo somente se ele suportar:

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

Você também pode usar um Kubernetes DaemonSet para impor AES-256 em cada nó. Consulte o seguinte exemplo:

suporte-cifs-aes-256-gcm.yaml

Windows

Use o comando Set-SmbClientConfiguration do PowerShell para especificar as criptografias usadas pelo cliente SMB e o tipo de criptografia preferencial sem confirmação do usuário:

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

Observação

O EncryptionCiphers parâmetro está disponível a partir da Atualização Cumulativa 2022-06 para Windows Server versão 21H2 para sistemas baseados em x64 (KB5014665) e a Atualização Cumulativa para Windows 11, versão 22H2 (KB5014668).

Causa 6: o perfil de segurança é usado sem a autenticação NTLM v2 habilitada

Quando você usa o perfil de segurança Máximo ou um perfil de segurança Personalizado sem o mecanismo de autenticação NTLM v2 habilitado, a operação de montagem falhará com o erro "Erro de montagem (13): Permissão negada".

Solução: habilite a autenticação NTLM v2 ou use o perfil "Compatibilidade máxima"

Para montá-lo corretamente no AKS, você precisa habilitar o mecanismo de autenticação NTLM v2 para o perfil de segurança personalizado ou usar o perfil de segurança de compatibilidade máxima.

Mais informações

Se você tiver outros erros de montagem, consulte Solucionar problemas de Arquivos do Azure no Linux.

Entre em contato conosco para obter ajuda

Se você tiver dúvidas ou precisar de ajuda, crie uma solicitação de suporte ou peça ajuda à comunidade de suporte do Azure. Você também pode enviar comentários sobre o produto para a comunidade de comentários do Azure.