Azure 파일 공유를 탑재할 수 없음 - Azure

아티클
04/12/2024

이 문서에서는 Azure 파일 공유의 탑재가 실패하는 오류에 대한 가능한 원인 및 솔루션을 제공합니다.

증상

AKS(Azure Kubernetes Service) 환경에서 배포 또는 StatefulSet와 같은 Kubernetes 리소스를 배포합니다. 배포는 Azure 파일 공유를 참조하는 PVC(PersistentVolumeClaim)를 탑재하는 Pod를 만듭니다.

그러나 Pod는 ContainerCreating 상태 유지됩니다. 명령을 실행 kubectl describe pods 하면 명령 출력에 다음 오류 중 하나가 표시되어 탑재 작업이 실패할 수 있습니다.

탑재 오류(2): 이러한 파일 또는 디렉터리가 없음
탑재 오류(13): 사용 권한이 거부됨

예제로 다음 출력을 참조하세요.

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)

참고

스토리지 계정에 공개적으로 액세스할 수 있는 경우 출력에 표시되는 호스트 이름은 storage-account-name.file.core.windows.net>.<
스토리지 계정이 프라이빗 링크, 엔드포인트 또는 DNS 영역으로 비공개로 구성된 경우 호스트 이름은 storage-account-name.privatelink.file.core.windows.net>.<

문제 해결 전

다음 예제와 같이 출력의 메시지에 따라 스토리지 계정 및 파일 공유를 식별합니다. 이 값은 이후 문제 해결 단계에서 사용됩니다.

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

가능한 원인 및 해결 방법은 다음 섹션을 참조하세요.

탑재 오류(2): 이러한 파일 또는 디렉터리가 없음

이 오류는 AKS 클러스터와 스토리지 계정 간에 연결이 없음을 나타냅니다.

초기 문제 해결

Azure File은 SMB 프로토콜(포트 445)을 사용합니다. 포트 445 및/또는 스토리지 계정의 IP 주소가 차단되지 않았는지 확인합니다.

스토리지 계정의 IP 주소를 검사 , 또는 host와 같은 nslookupdigDNS(Domain Name System) 명령을 실행합니다. 예시:

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: NSG는 AKS와 스토리지 계정 간의 트래픽을 차단합니다.
원인 3: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 차단합니다.
원인 4: FIPS 사용 노드 풀 사용

참고

원인 1, 2 및 4는 퍼블릭 및 프라이빗 스토리지 계정 시나리오에 적용됩니다.
원인 3은 공용 시나리오에만 적용됩니다.

원인 1: 파일 공유가 없음

파일 공유가 있는지 검사 하려면 다음 단계를 수행합니다.

Azure Portal 스토리지 계정을 Search 스토리지 계정에 액세스합니다.
스토리지 계정의 데이터 스토리지에서 파일 공유를 선택하고 Pod, 배포 또는 상태 저장 집합의 yaml 파일에 연결된 PersistentVolumeClaim이 파일 공유에 있는 경우 검사.

이 문제를 resolve PV/PVC와 연결된 파일 공유가 있는지 확인합니다.

원인 2: 네트워크 보안 그룹은 AKS와 스토리지 계정 간의 트래픽을 차단합니다.

초기 문제 해결 섹션에 nc 언급된 또는 telnet 명령의 출력을 확인합니다. 시간 제한이 표시되면 NSG(네트워크 보안 그룹)를 검사 스토리지 계정의 IP 주소가 차단되지 않았는지 확인합니다.

NSG가 스토리지 계정의 IP 주소를 차단하는 경우 검사 다음 단계를 수행합니다.

Azure Portal Network Watcher 이동하여 NSG 진단을 선택합니다.
다음 값을 사용하여 필드를 채웁니다.
- 프로토콜: 모든
- 방향: 아웃바운드
- 원본 유형: IPv4 주소/CIDR
- IPv4 주소/CIDR: AKS 노드와 연결된 instance IP 주소입니다.
- 대상 IP 주소: 스토리지 계정의 IP 주소
- 대상 포트: 445
확인 단추를 선택하고 트래픽 상태 검사.

트래픽 상태 허용 또는 거부될 수 있습니다. 거부된 상태 NSG가 AKS 클러스터와 스토리지 계정 간의 트래픽을 차단하고 있음을 의미합니다. 상태 거부되면 NSG 이름이 표시됩니다.

해결 방법: AKS와 스토리지 계정 간의 연결 허용

이 문제를 resolve 하려면 NSG 수준에서 적절하게 변경하여 AKS 클러스터와 포트 445의 스토리지 계정 간의 연결을 허용합니다.

원인 3: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 차단합니다.

가상 어플라이언스(일반적으로 방화벽)를 사용하여 AKS 클러스터의 아웃바운드 트래픽을 제어하는 경우(예: 가상 어플라이언스에 AKS 클러스터의 서브넷에 적용된 경로 테이블이 있고 경로 테이블에 가상 어플라이언스로 트래픽을 보내는 경로가 있음) 가상 어플라이언스는 AKS 클러스터와 스토리지 계정 간의 트래픽을 차단할 수 있습니다.

문제를 격리하려면 스토리지 계정의 IP 주소에 대한 경로 테이블에 경로를 추가하여 트래픽을 인터넷으로 보냅니다.

AKS 클러스터의 트래픽을 제어하는 경로 테이블을 확인하려면 다음 단계를 수행합니다.

Azure Portal AKS 클러스터로 이동하여 속성>인프라 리소스 그룹을 선택합니다.
이러한 VM 집합 유형을 사용하는 경우 가용성 집합의 VMSS(가상 머신 확장 집합) 또는 VM에 액세스합니다.
가상 네트워크/서브넷서브넷>을 선택하고 AKS 클러스터의 서브넷을 식별합니다. 오른쪽에 경로 테이블이 표시됩니다.

경로 테이블에 경로를 추가하려면 경로 만들기 의 단계를 수행하고 다음 필드를 입력합니다.

주소 접두사: <storage-account's-public-IP>/32
다음 홉 유형:인터넷

이 경로는 공용 인터넷을 통해 AKS 클러스터와 스토리지 계정 간의 모든 트래픽을 보냅니다.

경로를 추가한 후 또는 telnet 명령을 사용하여 nc 연결을 테스트하고 탑재 작업을 다시 수행합니다.

해결 방법: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 허용하는지 확인

탑재 작업이 성공하면 네트워킹 팀에 문의하여 가상 어플라이언스가 포트 445의 AKS 클러스터와 스토리지 계정 간의 트래픽을 허용할 수 있는지 확인하는 것이 좋습니다.

원인 4: FIPS 사용 노드 풀 사용

FIPS(Federal Information Processing Standard) 사용 노드 풀을 사용하는 경우 FIPS가 일부 인증 모듈을 사용하지 않도록 설정하여 CIFS 공유의 탑재를 방지하므로 탑재 작업이 실패합니다. 이 동작은 AKS와 관련이 없는 것으로 예상됩니다.

문제를 resolve 다음 솔루션 중 하나를 사용합니다.

해결 방법 1: FIPS가 아닌 노드 풀의 노드에서 Pod 예약

FIPS는 기본적으로 AKS 노드 풀에서 사용하지 않도록 설정되며 매개 변수를 사용하여 --enable-fips-image 노드 풀을 만드는 동안에만 사용하도록 설정할 수 있습니다.

오류를 resolve 위해 FIPS가 아닌 노드 풀의 노드에서 Pod를 예약할 수 있습니다.

해결 방법 2: FIPS 사용 노드에서 예약할 수 있는 Pod 만들기

FIPS 사용 노드에서 예약할 수 있는 Pod를 만들려면 다음 단계를 수행합니다.

Azure File CSI 드라이버를 사용하여 NFS 프로토콜을 사용하는 사용자 지정 StorageClass를 만듭니다.

예제로 다음 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는 NFS에 프리미엄 SKU가 필요하기 때문에 YAML 파일에서 Premium_LRS 설정됩니다. 자세한 내용은 동적 프로비저닝을 참조하세요.

프리미엄 SKU로 인해 파일 공유의 최소 크기는 100GB입니다. 자세한 내용은 스토리지 클래스 만들기를 참조하세요.

사용자 지정 StorageClass azurefile-sc-fips를 참조하는 PVC를 만듭니다.

예제로 다음 YAML 파일을 참조하세요.

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

PVC azurefile-pvc-fips를 탑재하는 Pod를 만듭니다.

예제로 다음 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: Kubernetes 비밀이 올바른 스토리지 계정 이름 또는 키를 참조하지 않음
원인 2: 스토리지 계정에 AKS의 VNET 및 서브넷이 허용되지 않음
원인 3: 연결은 프라이빗 링크를 통해 수행되지만 노드와 프라이빗 엔드포인트는 서로 다른 VNET에 있습니다.
원인 4: 스토리지 계정이 클라이언트가 지원하지 않는 암호화를 요구하도록 설정됨
원인 5: 스토리지 계정에 대한 최소 암호화 요구 사항이 충족되지 않음

참고

원인 1은 퍼블릭 및 프라이빗 시나리오에 적용됩니다.
원인 2는 공용 시나리오에만 적용됩니다.
원인 3은 프라이빗 시나리오에만 적용됩니다.
원인 4는 퍼블릭 및 프라이빗 시나리오에 적용됩니다.
원인 5는 퍼블릭 및 프라이빗 시나리오에 적용됩니다.

원인 1: Kubernetes 비밀이 올바른 스토리지 계정 이름 또는 키를 참조하지 않음

파일 공유를 동적으로 만들면 Kubernetes 비밀 리소스가 "azure-storage-account-storage-account-name-secret<>"이라는 이름으로 자동으로 만들어집니다.

파일 공유를 수동으로 만드는 경우 Kubernetes 비밀 리소스를 수동으로 만들어야 합니다.

생성 방법에 관계없이 Kubernetes 비밀에서 참조되는 스토리지 계정 이름 또는 키가 실제 값과 불일치하는 경우 "사용 권한 거부" 오류와 함께 탑재 작업이 실패합니다.

불일치의 가능한 원인

Kubernetes 비밀을 수동으로 만드는 경우 생성 중에 오타가 발생할 수 있습니다.
스토리지 계정 수준에서 "키 회전" 작업을 수행하는 경우 변경 내용은 Kubernetes 비밀 수준에 반영되지 않습니다. 이렇게 하면 스토리지 계정 수준의 키 값과 Kubernetes 비밀 수준의 값이 일치하지 않습니다.

"키 회전" 작업이 발생하면 "스토리지 계정 키 다시 생성"이라는 이름의 작업이 스토리지 계정의 활동 로그에 표시됩니다. 활동 로그의 보존 기간 90일을 알고 있어야 합니다.

불일치 확인

불일치를 확인하려면 다음 단계를 수행합니다.

Azure Portal 스토리지 계정을 Search 액세스합니다. 액세스 키를> 선택하여 스토리지 계정에키 표시를 선택합니다. 스토리지 계정 이름 및 연결된 키가 표시됩니다.
AKS 클러스터로 이동하여 구성>비밀을 선택한 다음, 연결된 비밀을 검색하고 액세스합니다.
표시(눈 아이콘)를 선택하고 스토리지 계정 이름 및 연결된 키의 값을 1단계의 값과 비교합니다.

표시를 선택하기 전에 스토리지 계정 이름 및 연결된 키의 값이 base64 문자열로 인코딩됩니다. 표시를 선택하면 값이 디코딩됩니다.

Azure Portal AKS 클러스터에 액세스할 수 없는 경우 kubectl 수준에서 2단계를 수행합니다.

Kubernetes 비밀의 YAML 파일을 가져와서 다음 명령을 실행하여 출력에서 스토리지 계정 이름 및 키의 값을 가져옵니다.
```
kubectl get secret <secret-name> -n <secret-namespace> -o <yaml-file-name>
```
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의 VNET 및 서브넷이 허용되지 않음

스토리지 계정의 네트워크가 선택한 네트워크로 제한되지만 AKS 클러스터의 VNET 및 서브넷이 선택한 네트워크에 추가되지 않으면 "사용 권한 거부" 오류와 함께 탑재 작업이 실패합니다.

해결 방법: 스토리지 계정에 AKS의 VNET 및 서브넷 허용

다음 명령을 실행하여 결함이 있는 Pod를 호스트하는 노드를 식별합니다.
```
kubectl get pod <pod-name> -n <namespace> -o wide
```
명령 출력에서 노드를 확인합니다.
Azure Portal AKS 클러스터로 이동하여 속성>인프라 리소스 그룹을 선택하고 노드와 연결된 VMSS에 액세스한 다음 가상 네트워크/서브넷을 검사 VNET 및 서브넷을 식별합니다.
Azure Portal 스토리지 계정에 액세스합니다. 네트워킹을 선택합니다. 에서 액세스 허용이 선택한 네트워크로 설정된 경우 AKS 클러스터의 VNET 및 서브넷이 추가되면 검사.

AKS 클러스터의 VNET 및 서브넷이 추가되지 않은 경우 기존 가상 네트워크 추가를 선택합니다. 네트워크 추가 페이지에서 AKS 클러스터의 VNET 및 서브넷을 입력한 다음저장추가>를 선택합니다.

변경 내용이 적용되는 데 몇 분 정도 걸릴 수 있습니다. VNET 및 서브넷이 추가된 후 Pod 상태 ContainerCreating에서 실행 중으로 변경되는지 검사.

원인 3: 연결은 프라이빗 링크를 통해 수행되지만 노드와 프라이빗 엔드포인트는 서로 다른 VNET에 있습니다.

AKS 클러스터 및 스토리지 계정이 프라이빗 링크를 통해 연결되면 승인된 프라이빗 엔드포인트 연결이 사용됩니다.

이 시나리오에서 프라이빗 엔드포인트와 AKS 노드가 동일한 VNET에 있는 경우 Azure 파일 공유를 탑재할 수 있습니다.

프라이빗 엔드포인트와 AKS 클러스터가 다른 VNET에 있는 경우 "사용 권한 거부" 오류와 함께 탑재 작업이 실패합니다.

해결 방법: 프라이빗 DNS 영역에서 AKS 클러스터의 VNET에 대한 가상 네트워크 링크 만들기

노드 내부에 들어가서 FQDN(정규화된 도메인 이름)이 공용 또는 개인 IP 주소를 통해 확인되면 검사. 이렇게 하려면 다음 명령을 실행합니다.

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

공용 IP 주소를 통해 FQDN을 확인하는 경우(다음 스크린샷 참조) 프라이빗 DNS 영역("privatelink.file.core.windows.net") 수준에서 AKS 클러스터의 VNET에 대한 가상 네트워크 링크를 만듭니다. 스토리지 계정의 프라이빗 엔드포인트의 VNET에 대한 가상 네트워크 링크가 이미 자동으로 만들어집니다.

가상 네트워크 링크를 만들려면 다음 단계를 수행합니다.

프라이빗 DNS 영역에 액세스하고 가상 네트워크 링크 추가를> 선택합니다.
필드를 입력하고 가상 네트워크에 대한 AKS 클러스터의 VNET을 선택합니다. AKS 클러스터의 VNET을 식별하는 방법은 솔루션: 스토리지 계정에 AKS의 VNET 및 서브넷 허용 섹션을 참조하세요 .
확인을 선택합니다.

가상 네트워크 링크가 추가되면 개인 IP 주소를 통해 FQDN을 확인해야 하며 탑재 작업이 성공해야 합니다. 예제는 다음 스크린샷을 참조하세요.

원인 4: 스토리지 계정이 클라이언트가 지원하지 않는 암호화를 요구하도록 설정됨

Azure Files 보안 설정에는 스토리지 계정의 보안 및 암호화 설정을 제어하기 위한 여러 옵션이 포함되어 있습니다. 허용되는 메서드 및 알고리즘을 제한하면 클라이언트가 연결되지 않도록 할 수 있습니다.

1.25 이전의 AKS 버전은 Linux 5.4 커널을 사용하고 AES-128-CCM 및 AES-128-GCM 암호화 알고리즘만 지원하는 Ubuntu 18.04 LTS를 기반으로 합니다. 최대 보안 프로필 또는 AES-128-GCM을 사용하지 않도록 설정하는 사용자 지정 프로필은 공유 매핑 오류를 발생합니다.

AKS 버전 1.25 이상 버전은 Linux 5.15 커널을 사용하고 AES-256-GCM을 지원하는 Ubuntu 22.04를 기반으로 합니다.

해결 방법: AES-128-GCM 암호화 알고리즘 사용 허용

최대 호환성 프로필 또는 AES-128-GCM을 사용하도록 설정하는 사용자 지정 프로필을 사용하여 AES-128-GCM 알고리즘을 사용하도록 설정합니다. 자세한 내용은 Azure Files 보안 설정을 참조하세요.

원인 5: 스토리지 계정에 대한 최소 암호화 요구 사항이 충족되지 않음

해결 방법: 모든 스토리지 계정에 AES-128-GCM 암호화 알고리즘 사용

파일 공유를 탑재하거나 액세스하려면 모든 스토리지 계정에 대해 AES-128-GCM 암호화 알고리즘을 사용하도록 설정해야 합니다.

최대 보안(SMB 3.1.1)인 AES-256-GCM 암호화만 사용하려면 다음을 수행합니다.

Linux

다음 스크립트를 사용하여 클라이언트가 AES-256-GCM을 지원하는지 검사 다음 스크립트가 있는 경우에만 적용합니다.

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

Set-SmbClientConfiguration PowerShell 명령을 사용하여 SMB 클라이언트에서 사용하는 암호화 암호화와 사용자 확인 없이 기본 설정 암호화 유형을 지정합니다.

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

참고

매개 변수는 EncryptionCiphers x64 기반 시스템(KB5014665)용 Windows Server 버전 21H2용 2022-06 누적 업데이트 및 Windows 11 대한 누적 업데이트 버전 22H2(KB5014668)부터 사용할 수 있습니다.

추가 정보

다른 탑재 오류가 발생하는 경우 Linux에서 Azure Files 문제 해결을 참조하세요.

도움을 요청하십시오.

질문이 있거나 도움이 필요한 경우 지원 요청을 생성하거나 Azure 커뮤니티 지원에 문의하세요. Azure 피드백 커뮤니티에 제품 피드백을 제출할 수도 있습니다.

다음을 통해 공유

증상

문제 해결 전

탑재 오류(2): 이러한 파일 또는 디렉터리가 없음

초기 문제 해결

탑재 오류의 가능한 원인(2)

원인 1: 파일 공유가 없음

원인 2: 네트워크 보안 그룹은 AKS와 스토리지 계정 간의 트래픽을 차단합니다.

해결 방법: AKS와 스토리지 계정 간의 연결 허용

원인 3: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 차단합니다.

해결 방법: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 허용하는지 확인

원인 4: FIPS 사용 노드 풀 사용

해결 방법 1: FIPS가 아닌 노드 풀의 노드에서 Pod 예약

해결 방법 2: FIPS 사용 노드에서 예약할 수 있는 Pod 만들기

탑재 오류(13): 사용 권한이 거부됨

원인 1: Kubernetes 비밀이 올바른 스토리지 계정 이름 또는 키를 참조하지 않음

불일치의 가능한 원인

불일치 확인

해결 방법: Kubernetes 비밀을 조정하고 Pod를 다시 만듭니다.

원인 2: 스토리지 계정에 AKS의 VNET 및 서브넷이 허용되지 않음

해결 방법: 스토리지 계정에 AKS의 VNET 및 서브넷 허용

원인 3: 연결은 프라이빗 링크를 통해 수행되지만 노드와 프라이빗 엔드포인트는 서로 다른 VNET에 있습니다.

해결 방법: 프라이빗 DNS 영역에서 AKS 클러스터의 VNET에 대한 가상 네트워크 링크 만들기

원인 4: 스토리지 계정이 클라이언트가 지원하지 않는 암호화를 요구하도록 설정됨

해결 방법: AES-128-GCM 암호화 알고리즘 사용 허용

원인 5: 스토리지 계정에 대한 최소 암호화 요구 사항이 충족되지 않음

해결 방법: 모든 스토리지 계정에 AES-128-GCM 암호화 알고리즘 사용

Linux

Windows

추가 정보

도움을 요청하십시오.

피드백

피드백

추가 리소스

다음을 통해 공유

Azure 파일 공유를 탑재할 때 오류 발생

증상

문제 해결 전

탑재 오류(2): 이러한 파일 또는 디렉터리가 없음

초기 문제 해결

탑재 오류의 가능한 원인(2)

원인 1: 파일 공유가 없음

해결 방법: 파일 공유가 있는지 확인

원인 2: 네트워크 보안 그룹은 AKS와 스토리지 계정 간의 트래픽을 차단합니다.

해결 방법: AKS와 스토리지 계정 간의 연결 허용

원인 3: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 차단합니다.

해결 방법: 가상 어플라이언스가 AKS와 스토리지 계정 간의 트래픽을 허용하는지 확인

원인 4: FIPS 사용 노드 풀 사용

해결 방법 1: FIPS가 아닌 노드 풀의 노드에서 Pod 예약

해결 방법 2: FIPS 사용 노드에서 예약할 수 있는 Pod 만들기

탑재 오류(13): 사용 권한이 거부됨

원인 1: Kubernetes 비밀이 올바른 스토리지 계정 이름 또는 키를 참조하지 않음

불일치의 가능한 원인

불일치 확인

해결 방법: Kubernetes 비밀을 조정하고 Pod를 다시 만듭니다.

원인 2: 스토리지 계정에 AKS의 VNET 및 서브넷이 허용되지 않음

해결 방법: 스토리지 계정에 AKS의 VNET 및 서브넷 허용

원인 3: 연결은 프라이빗 링크를 통해 수행되지만 노드와 프라이빗 엔드포인트는 서로 다른 VNET에 있습니다.

해결 방법: 프라이빗 DNS 영역에서 AKS 클러스터의 VNET에 대한 가상 네트워크 링크 만들기

원인 4: 스토리지 계정이 클라이언트가 지원하지 않는 암호화를 요구하도록 설정됨

해결 방법: AES-128-GCM 암호화 알고리즘 사용 허용

원인 5: 스토리지 계정에 대한 최소 암호화 요구 사항이 충족되지 않음

해결 방법: 모든 스토리지 계정에 AES-128-GCM 암호화 알고리즘 사용

Linux

Windows

추가 정보

도움을 요청하십시오.

피드백

피드백

추가 리소스