Erros ao montar um compartilhamento de arquivos do Azure

Este artigo fornece possíveis causas e soluções para erros que fazem com que a montagem de um compartilhamento de arquivos do Azure falhe.

Sintomas

Você implanta um recurso do Kubernetes, como uma Implantação ou um StatefulSet, em um ambiente aks (Serviço de Kubernetes do Azure). A implantação criará um pod que monta um PVC (PersistentVolumeClaim) fazendo referência a um compartilhamento de arquivos do Azure.

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

• Erro de montagem(2): nenhum arquivo ou diretório desse tipo
• Erro de montagem(13): permissão negada

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)

Antes de solucionar problemas

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

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

Consulte as seções a seguir para obter possíveis causas e soluções.

Erro de montagem(2): nenhum arquivo ou diretório desse tipo

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 marcar o endereço IP da conta de armazenamento, execute um comando DNS (Sistema de Nomes de Domínio) como nslookup, digou host. Por exemplo:

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

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

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)

• Causa 1: o compartilhamento de arquivos não existe
• Causa 2: O NSG bloqueia o tráfego entre o AKS e a conta de armazenamento
• Causa 3: Dispositivo Virtual bloqueia o tráfego entre o AKS e a conta de armazenamento
• Causa 4: o pool de nós habilitado para FIPS é usado

Causa 1: o compartilhamento de arquivos não existe

Para marcar se o compartilhamento de arquivos existir, siga estas etapas:

1. Pesquisa Contas de armazenamento no portal do Azure e acessar sua conta de armazenamento.

   

2. Selecione Compartilhamentos de arquivos em Armazenamento de dados na conta de armazenamento e marcar se o PersistentVolumeClaim associado no arquivo yaml do pod, implantação ou conjunto de estado existir em compartilhamentos de arquivos.

   

Solução: garantir que o compartilhamento de arquivos exista

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

Causa 2: 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 ou telnet mencionado na seção Solução de problemas inicial . Se um tempo limite for exibido, marcar o NSG (Grupo de Segurança de Rede) e verifique se o endereço IP da conta de armazenamento não está bloqueado.

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

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

2. Preencha os campos usando os seguintes valores:

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

3. Selecione o botão Verificar e marcar o status de Tráfego.

O status de 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 NSG será mostrado.

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

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

Causa 3: Dispositivo Virtual bloqueia o tráfego entre o AKS e a conta de armazenamento

Se você estiver usando um Virtual Appliance (geralmente um firewall) para controlar o tráfego de saída do cluster AKS (por exemplo, o Virtual Appliance tem uma tabela de rotas aplicada na sub-rede do cluster AKS e a tabela de rotas tem rotas que enviam tráfego para o Virtual Appliance), o Dispositivo Virtual pode bloquear o tráfego entre o cluster 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 derecursos infraestrutura de propriedades>.
2. Acesse o conjunto de dimensionamento de máquinas virtuais (VMSS) ou uma VM em um conjunto de disponibilidade se você estiver usando esse tipo de conjunto de VM.
3. SelecioneSub-redesde rede virtual/sub-rede> e identifique a sub-rede do cluster 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 nc comando ou telnet e execute a operação de montagem novamente.

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

Se a operação de montagem for bem-sucedida, recomendamos consultar sua equipe de rede para garantir que o Dispositivo Virtual 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 (Federal Information Processing Standard), 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 resolve 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 --enable-fips-image parâmetro.

Para resolve 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 pode ser agendado em um nó habilitado para FIPS

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

1. Use o driver CSI do Arquivo do Azure para criar uma StorageClass personalizada que usa o protocolo NFS.

   Consulte o seguinte arquivo YAML como um 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 está definido como Premium_LRS no arquivo YAML porque o SKU Premium é necessário para NFS. Para obter mais informações, 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 um PVC que faça referência ao StorageClass personalizado azurefile-sc-fips.

   Consulte o seguinte arquivo YAML como um 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 monte o Azurefile-pvc-fips do PVC.

   Consulte o seguinte arquivo YAML como um 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

Aqui estão possíveis causas para este erro:

• Causa 1: o segredo do Kubernetes não faz referência ao nome ou chave da conta de armazenamento correto
• Causa 2: A VNET e a sub-rede do AKS não são permitidas para a conta de armazenamento
• 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
• Causa 4: a conta de armazenamento está definida para exigir criptografia que o cliente não dá suporte
• Causa 5: Requisito mínimo de criptografia para uma conta de armazenamento não é atendido

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

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

Se o compartilhamento de arquivos for criado manualmente, o recurso de segredo 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 desmatar o valor real, a operação de montagem falhará com o erro "Permissão negada".

Possíveis causas para incompatibilidade

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

• Se uma operação "Chave rotativa" for executada no nível da conta de armazenamento, as alterações não refletirão no nível de segredo do Kubernetes. Isso levará a uma incompatibilidade entre o valor da chave no nível da conta de armazenamento e o valor no nível de segredo do Kubernetes.

  Se uma operação "Chave rotativa" acontecer, uma operação com o nome "Regenerar Chaves da Conta de Armazenamento" será exibida no log de atividades da conta de armazenamento. Esteja ciente do período de retenção de 90 dias para o log de atividades.

Verificar incompatibilidade

Para verificar a incompatibilidade, siga estas etapas:

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

   

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

   

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

   

   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 serã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 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 echo comando 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
   

   

Solução: ajustar o segredo do Kubernetes e recriar os pods

Se o valor do nome ou da chave da conta de armazenamento no segredo kubernetes não corresponder ao valor em Chaves de acesso na conta de armazenamento, ajuste o segredo kubernetes no nível de 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 base64. Para obter o valor codificado, use o echo comando.

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 kubernetes tiver os valores certos, crie novamente os pods. Caso contrário, esses pods continuarão a usar 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 AKS não forem adicionadas a 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 com falha executando o seguinte comando:

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

   Verifique o nó na saída de comando:

   

2. Vá para o cluster do AKS no portal do Azure, selecione Grupo derecursos infraestrutura de propriedades>, acesse a VMSS associada ao nó e, em seguida, marcar rede virtual/sub-rede para identificar a VNET e a sub-rede.

   

3. Acesse a conta de armazenamento no portal do Azure. Selecione Rede. Se Permitir acesso de for definido como redes selecionadas, marcar se a VNET e a sub-rede do cluster AKS forem adicionadas.

   

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

   

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

   

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

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

Nesse cenário, se o ponto de extremidade privado e o nó 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".

Solução: criar um link de rede virtual para a VNET do cluster do AKS na zona DNS privada

Entre no nó e marcar se o FQDN (nome de domínio totalmente qualificado) for 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 AKS no nível da zona DNS privada ("privatelink.file.core.windows.net"). Observe que um link de rede virtual já é criado automaticamente para a VNET do ponto de extremidade privado da conta de armazenamento.

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

1. Acesse a zona DNS privado e selecione Links > de rede virtualAdicionar.

   

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

   

3. Selecione OK.

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

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

Arquivos do Azure Configurações de Segurança contêm várias opções para controlar as configurações de segurança e criptografia em contas de armazenamento. Restringir 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 somente aos algoritmos de criptografia AES-128-CCM e AES-128-GCM. O perfil de segurança máxima ou um perfil Personalizado que desabilita o AES-128-GCM causará falhas de 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 máximo de compatibilidade ou um perfil Personalizado que habilita o AES-128-GCM. Para obter mais informações, consulte Arquivos do Azure Configurações de segurança.

Causa 5: 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 somente a criptografia AES-256-GCM, que é a segurança máxima (SMB 3.1.1), faça o seguinte:

Linux

Use o script a seguir para marcar se o cliente der suporte ao AES-256-GCM e aplicá-lo somente se o fizer:

cifsConfPath="/etc/modprobe.d/cifs.conf" 
echo "`date` before change ${cifsConfPath}:"
cat ${cifsConfPath}
if !(( grep require_gcm_256 ${cifsConfPath} ))
then
modprobe cifs
echo 1 > /sys/module/cifs/parameters/require_gcm_256
echo "options cifs require_gcm_256=1" > ${cifsConfPath}
echo "`date` after changing ${cifsConfPath}:"
cat ${cifsConfPath}
fi

Windows

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

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

Mais informações

Se você tiver alguns 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.