Aracılığıyla paylaş

Azure dosya paylaşımını bağlarken oluşan hatalar

  • Makale

Bu makalede, Azure dosya paylaşımının bağlanamamasına neden olan hataların olası nedenleri ve çözümleri sağlanmaktadır.

Belirtiler

Azure Kubernetes Service (AKS) ortamında Dağıtım veya StatefulSet gibi bir Kubernetes kaynağı dağıtırsınız. Dağıtım, Azure dosya paylaşımına başvuran bir PersistentVolumeClaim (PVC) takan bir pod oluşturur.

Ancak, pod ContainerCreating durumunda kalır. komutunu çalıştırdığınızda kubectl describe pods , komut çıktısında aşağıdaki hatalardan birini görebilirsiniz ve bu da bağlama işleminin başarısız olmasına neden olur:

Örnek olarak aşağıdaki çıkışa bakın:

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)

Not

  • Depolama hesabına genel erişim sağlanmışsa, çıktıda görüntülenen ana bilgisayar adı storage-account-name.file.core.windows.net> olur<.
  • Depolama hesabı özel bağlantı, uç nokta veya DNS bölgesi ile özel olarak yapılandırılmışsa, konak adı storage-account-name.privatelink.file.core.windows.net> olur<.

Sorun gidermeden önce

Aşağıdaki örnekte gösterildiği gibi çıktıdaki iletiye göre depolama hesabını ve dosya paylaşımını tanımlayın; değerler sonraki sorun giderme adımlarında kullanılacaktır.

"//storage-account-name.file.core.windows.net/<>< pv-fileshare-name>" bağlama

Olası nedenler ve çözümler için aşağıdaki bölümlere bakın.

Bağlama hatası(2): Böyle bir dosya veya dizin yok

Bu hata AKS kümesi ile depolama hesabı arasında bağlantı olmadığını gösterir.

İlk sorun giderme

Azure Dosya, SMB protokolüne (bağlantı noktası 445) dayanır. 445 numaralı bağlantı noktasının ve/veya depolama hesabının IP adresinin engellenmediğinden emin olun.

Depolama hesabının IP adresini denetlemek için , veya hostgibi nslookupdigbir Etki Alanı Adı Sistemi (DNS) komutu çalıştırın. Örneğin:

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

AKS kümesi ile depolama hesabı arasında bağlantı olup olmadığını denetlemek için düğüme veya poda girin ve aşağıdaki nc veya telnet komutu çalıştırın:

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

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

Bağlama hatasının olası nedenleri(2)

Not

  • Neden 1, 2 ve 4, genel ve özel depolama hesabı senaryoları için geçerlidir.
  • Neden 3 yalnızca genel senaryo için geçerlidir.

Neden 1: Dosya paylaşımı yok

Dosya paylaşımının mevcut olup olmadığını denetlemek için şu adımları izleyin:

  1. Azure portal Depolama hesaplarını Arama ve depolama hesabınıza erişin.

    Azure portal depolama hesapları listesinin ekran görüntüsü.

  2. Depolama hesabında Veri depolama'nın altında Dosya paylaşımları'nı seçin ve pod, dağıtım veya statefulset'in yaml dosyasındaki ilişkili PersistentVolumeClaim öğesinin Dosya paylaşımlarında mevcut olup olmadığını denetleyin.

    Depolama hesabında dosya paylaşımlarını seçme işleminin ekran görüntüsü.

Çözüm: Dosya paylaşımının mevcut olduğundan emin olun

Bu sorunu çözmek için PV/PVC ile ilişkili dosya paylaşımının mevcut olduğundan emin olun.

Neden 2: Ağ Güvenlik Grubu AKS ile depolama hesabı arasındaki trafiği engelliyor

İlk sorun giderme bölümünde belirtilen veya telnet komutunun çıkışını nc denetleyin. Zaman aşımı görüntülenirse Ağ Güvenlik Grubu'na (NSG) bakın ve depolama hesabının IP adresinin engellenmediğinden emin olun.

NSG'nin depolama hesabının IP adresini engellenip engellemediğini denetlemek için şu adımları izleyin:

  1. Azure portal Ağ İzleyicisi gidin ve NSG tanılama'yı seçin.

  2. Aşağıdaki değerleri kullanarak alanları doldurun:

    • Protokol: Herhangi biri
    • Yön: Giden
    • Kaynak türü: IPv4 adresi/CIDR
    • IPv4 adresi/CIDR: AKS düğümüyle ilişkili bir örneğin IP adresi
    • Hedef IP adresi: Depolama hesabının IP adresi
    • Hedef bağlantı noktası: 445

  3. Denetle düğmesini seçin ve Trafik durumunu denetleyin.

Trafik durumu İzin Verildi veya Reddedildi olabilir. Reddedildi durumu, NSG'nin AKS kümesi ile depolama hesabı arasındaki trafiği engellediği anlamına gelir. Durum Reddedildi ise NSG adı gösterilir.

Çözüm: AKS ile depolama hesabı arasında bağlantıya izin ver

Bu sorunu çözmek için, AKS kümesi ile 445 numaralı bağlantı noktasındaki depolama hesabı arasındaki bağlantıya izin vermek için NSG düzeyinde değişiklikler yapın.

Neden 3: Sanal Gereç AKS ile depolama hesabı arasındaki trafiği engelliyor

AKS kümesinin giden trafiğini denetlemek için bir Sanal Gereç (genellikle bir güvenlik duvarı) kullanıyorsanız (örneğin, Sanal Gerecin AKS kümesinin alt ayasına uygulanan bir yol tablosu varsa ve yol tablosunda Sanal Gereç'e giden trafik gönderen yollar varsa), Sanal Gereç AKS kümesi ile depolama hesabı arasındaki trafiği engelleyebilir.

Sorunu yalıtmak için, trafiği İnternet'e göndermek üzere depolama hesabının IP adresi için yol tablosuna bir yol ekleyin.

AKS kümesinin trafiğini denetleyen yönlendirme tablosunu onaylamak için şu adımları izleyin:

  1. Azure portal AKS kümesine gidin ve Özellikler>Altyapısı kaynak grubunu seçin.
  2. Bu tür bir VM kümesi türü kullanıyorsanız sanal makine ölçek kümesine (VMSS) veya kullanılabilirlik kümesindeki bir VM'ye erişin.
  3. Sanal ağ/alt ağ>Alt ağlar'ı seçin ve AKS kümesinin alt ağını belirleyin. Sağ tarafta rota tablosunu görürsünüz.

Yolu yol tablosuna eklemek için Yol oluşturma bölümündeki adımları izleyin ve aşağıdaki alanları doldurun:

  • Adres ön eki: <depolama hesabının-public-IP>/32
  • Sonraki atlama türü:İnternet

Bu yol, AKS kümesi ile depolama hesabı arasındaki tüm trafiği genel İnternet üzerinden gönderir.

Yolu ekledikten sonra veya telnet komutunu kullanarak nc bağlantıyı test edin ve bağlama işlemini yeniden gerçekleştirin.

Çözüm: Sanal Gerecin AKS ile depolama hesabı arasında trafiğe izin verdiğinden emin olun

Bağlama işlemi başarılı olursa, Sanal Gerecin AKS kümesi ile 445 numaralı bağlantı noktasındaki depolama hesabı arasında trafiğe izin verebildiğinden emin olmak için ağ ekibinize başvurmanızı öneririz.

Neden 4: FIPS etkin düğüm havuzu kullanılıyor

Federal Bilgi İşleme Standardı (FIPS) özellikli bir düğüm havuzu kullanıyorsanız, FIPS bazı kimlik doğrulama modüllerini devre dışı bırakdığından bağlama işlemi başarısız olur ve bu da CIFS paylaşımının bağlamasını engeller. Bu davranış beklenen bir davranıştır ve AKS'ye özgü değildir.

Sorunu çözmek için aşağıdaki çözümlerden birini kullanın:

Çözüm 1: FIPS olmayan bir düğüm havuzundaki düğümlerde pod zamanlama

FIPS, AKS düğüm havuzlarında varsayılan olarak devre dışıdır ve yalnızca parametresi kullanılarak --enable-fips-image düğüm havuzu oluşturma sırasında etkinleştirilebilir.

Hatayı çözmek için FIPS olmayan bir düğüm havuzundaki düğümlerdeki podları zamanlayabilirsiniz.

Çözüm 2: FIPS özellikli bir düğümde zamanlanabilir bir pod oluşturma

FIPS özellikli bir düğümde zamanlanabilir bir pod oluşturmak için şu adımları izleyin:

  1. NFS protokolü kullanan özel bir StorageClass oluşturmak için Azure Dosya CSI sürücüsünü kullanın.

    Örnek olarak aşağıdaki YAML dosyasına bakın:

    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

    NFS için Premium SKU gerektiğinden, SKU YAML dosyasında Premium_LRS olarak ayarlanır. Daha fazla bilgi için bkz. Dinamik Sağlama.

    Premium SKU nedeniyle dosya paylaşımının minimum boyutu 100 GB'tır. Daha fazla bilgi için bkz. Depolama sınıfı oluşturma.

  2. Özel StorageClass azurefile-sc-fips öğesine başvuran bir PVC oluşturun.

    Örnek olarak aşağıdaki YAML dosyasına bakın:

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

  3. PVC azurefile-pvc-fips'i takan bir pod oluşturun.

    Örnek olarak aşağıdaki YAML dosyasına bakın:

    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

Bağlama hatası(13): İzin reddedildi

Bu hatanın olası nedenleri şunlardır:

Not

  • Neden 1, genel ve özel senaryolar için geçerlidir.
  • Neden 2 yalnızca genel senaryo için geçerlidir.
  • Neden 3 yalnızca özel senaryo için geçerlidir.
  • Neden 4, genel ve özel senaryolar için geçerlidir.
  • Neden 5, genel ve özel senaryolar için geçerlidir.

Neden 1: Kubernetes gizli dizisi doğru depolama hesabı adına veya anahtarına başvurmuyor

Dosya paylaşımı dinamik olarak oluşturulursa, "azure-storage-account-storage-account-name-secret<>" adıyla otomatik olarak bir Kubernetes gizli dizisi kaynağı oluşturulur.

Dosya paylaşımı el ile oluşturulduysa Kubernetes gizli dizisi kaynağı el ile oluşturulmalıdır.

Oluşturma yönteminden bağımsız olarak, depolama hesabı adı veya Kubernetes gizli dizisinde başvuruda bulunılan anahtar gerçek değeri yanlış kullanırsa, bağlama işlemi "İzin reddedildi" hatasıyla başarısız olur.

Uyuşmazlık için olası nedenler

  • Kubernetes gizli dizisi el ile oluşturulursa, oluşturma sırasında bir yazım hatası oluşabilir.

  • Depolama hesabı düzeyinde bir "Anahtarı döndürme" işlemi gerçekleştirilirse, değişiklikler Kubernetes gizli dizisi düzeyinde yansıtılmaz. Bu, depolama hesabı düzeyindeki anahtar değeri ile Kubernetes gizli dizi düzeyindeki değer arasında uyuşmazlığa yol açar.

    "Anahtarı döndürme" işlemi gerçekleşirse, depolama hesabının Etkinlik günlüğünde "Depolama Hesabı Anahtarlarını Yeniden Oluştur" adlı bir işlem görüntülenir. Etkinlik günlüğü için 90 günlük saklama süresine dikkat edin.

Uyumsuzluğu doğrulama

Uyuşmazlığı doğrulamak için şu adımları izleyin:

  1. Arama ve Azure portal depolama hesabına erişin. Erişim anahtarları> Depolama hesabındaanahtarları göster'i seçin. Depolama hesabı adını ve ilişkili anahtarları görürsünüz.

    Depolama hesabı adı ve anahtarlarının ekran görüntüsü.

  2. AKS kümesine gidin, Yapılandırma>Gizli Dizileri'ni seçin ve ilişkili gizli diziyi arayıp erişin.

    Depolama hesabı arama ve seçme işleminin ekran görüntüsü.

  3. Göster'i (göz simgesi) seçin ve depolama hesabı adı ile ilişkili anahtarın değerlerini 1. Adım'daki değerlerle karşılaştırın.

    Gizli dizideki depolama hesabı adını ve anahtarını gösteren ekran görüntüsü.

    Göster'i seçmeden önce depolama hesabı adı ve ilişkili anahtarın değerleri base64 dizeleri olarak kodlanır. Göster'i seçtikten sonra değerlerin kodu çözülecektir.

Azure portal AKS kümesine erişiminiz yoksa kubectl düzeyinde 2. Adımı gerçekleştirin:

  1. Kubernetes gizli dizisinin YAML dosyasını alın ve ardından çıkıştan depolama hesabı adı ve anahtarı değerlerini almak için aşağıdaki komutu çalıştırın:

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

  2. echo Depolama hesabı adı ve anahtarı değerlerinin kodunu çözmek ve bunları depolama hesabı düzeyindeki değerlerle karşılaştırmak için komutunu kullanın.

    Depolama hesabı adının kodunu çözme örneği aşağıda verilmiştir:

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

    Depolama hesabı adının kodunu çözen komutun ekran görüntüsü.

Çözüm: Kubernetes gizli dizisini ayarlama ve podları yeniden oluşturma

Kubernetes gizli dizisindeki depolama hesabı adı veya anahtarının değeri depolama hesabındaki Access anahtarlarındaki değerle eşleşmiyorsa, aşağıdaki komutu çalıştırarak Kubernetes gizli dizisini Kubernetes gizli dizisi düzeyinde ayarlayın:

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

Depolama hesabı adının veya Kubernetes gizli dizi yapılandırmasına eklenen anahtarın değeri base64 kodlu bir değer olmalıdır. Kodlanmış değeri almak için komutunu kullanın echo .

Depolama hesabı adını kodlamak için bir örnek aşağıda verilmiştir:

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

Daha fazla bilgi için bkz . Kubectl kullanarak Gizli Dizileri Yönetme.

Kubernetes gizli dizisi azure-storage-account-<storage-account-name>-secret doğru değerlere sahip olduktan sonra podları yeniden oluşturun. Aksi takdirde, bu podlar artık geçerli olmayan eski değerleri kullanmaya devam eder.

Neden 2: DEPOLAMA hesabı için AKS'nin VNET'ine ve alt a bilgisayarına izin verilmiyor

Depolama hesabının ağı seçili ağlarla sınırlıysa ancak AKS kümesinin sanal ağı ve alt ağı seçili ağlara eklenmiyorsa, bağlama işlemi "İzin reddedildi" hatasıyla başarısız olur.

Çözüm: Depolama hesabı için AKS'nin VNET'ine ve alt a bilgisayarına izin ver

  1. Aşağıdaki komutu çalıştırarak hatalı podu barındıran düğümü tanımlayın:

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

    Komut çıkışından düğümü denetleyin:

    Düğüm ve çıkış kimliğine sahip komutun ekran görüntüsü.

  2. Azure portal AKS kümesine gidin, Özellikler>Altyapısı kaynak grubunu seçin, düğümle ilişkili VMSS'ye erişin ve sanal ağı ve alt ağı tanımlamak için Sanal ağ/alt ağ'ı denetleyin.

    Sanal ağ/alt ağ değerinin ekran görüntüsü.

  3. Azure portal depolama hesabına erişin. Ağ'ı seçin. Erişime izin ver seçeneği Seçili ağlar olarak ayarlandıysa, AKS kümesinin VNET ve alt ağının eklenip eklenmediğini denetleyin.

    Seçili boş ağlar listesinin ekran görüntüsü.

    AKS kümesinin sanal ağı ve alt ağı eklenmiyorsa Var olan sanal ağı ekle'yi seçin. Ağ ekle sayfasında AKS kümesinin sanal ağını ve alt ağını yazın veKaydetEkle'yi> seçin.

    Depolama hesabına ağ ekleme ekran görüntüsü.

    Değişikliklerin etkili olması birkaç dakika sürebilir. VNET ve alt ağ eklendikten sonra pod durumunun ContainerCreating'denÇalışıyor olarak değişip değişmediğini denetleyin.

    Geçerli pod durumunu gösteren komut çıktısının ekran görüntüsü.

Neden 3: Bağlantı özel bağlantı üzerinden yapılır, ancak düğümler ve özel uç nokta farklı VNET'lerdedir

AKS kümesi ve depolama hesabı özel bağlantı üzerinden bağlandığında, onaylı bir özel uç nokta bağlantısı kullanılır.

Özel uç nokta bağlantısının ekran görüntüsü.

Bu senaryoda, özel uç nokta ve AKS düğümü aynı sanal ağdaysa bir Azure dosya paylaşımı bağlayabilirsiniz.

Özel uç nokta ve AKS kümeniz farklı VNET'lerdeyse bağlama işlemi "İzin reddedildi" hatasıyla başarısız olur.

Düğümün içine girin ve tam etki alanı adının (FQDN) genel veya özel bir IP adresi aracılığıyla çözümlenip çözümlenmediğini denetleyin. Bunu yapmak için aşağıdaki komutu çalıştırın:

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

FQDN bir genel IP adresi aracılığıyla çözümlenirse (aşağıdaki ekran görüntüsüne bakın), özel DNS bölgesi ("privatelink.file.core.windows.net") düzeyinde AKS kümesinin sanal ağı için bir sanal ağ bağlantısı oluşturun. Depolama hesabının özel uç noktasının sanal ağı için otomatik olarak bir sanal ağ bağlantısı oluşturulduğunu unutmayın.

FQDN'nin genel IP adresiyle çözümlendiğini gösteren ekran görüntüsü.

Sanal ağ bağlantısını oluşturmak için şu adımları izleyin:

  1. Özel DNS bölgesine erişin ve Sanal ağ bağlantıları>Ekle'yi seçin.

    Depolama hesabına eklenen sanal ağ bağlantısını gösteren ekran görüntüsü.

  2. Alanları doldurun ve Sanal ağlar için AKS kümesinin sanal ağını seçin. AKS kümesinin VNET'ini tanımlama hakkında bilgi için Bkz. Çözüm: DEPOLAMA hesabı için AKS'nin VNET'ine ve alt a bilgisayarına izin verme .

    Sanal ağ bağlantısının nasıl ekleneceğini gösteren ekran görüntüsü.

  3. Tamam'ı seçin.

Sanal ağ bağlantısı eklendikten sonra, FQDN özel bir IP adresi aracılığıyla çözümlenmelidir ve bağlama işlemi başarılı olmalıdır. Örnek için aşağıdaki ekran görüntüsüne bakın:

Özel ip adresinin çözümlenmiş olduğunu gösteren ekran görüntüsü.

Neden 4: Depolama hesabı, istemcinin desteklemediği şifreleme gerektirecek şekilde ayarlandı

Azure Dosyalar Güvenlik Ayarları, depolama hesaplarında güvenlik ve şifreleme ayarlarını denetlemeye yönelik çeşitli seçenekler içerir. İzin verilen yöntemlerin ve algoritmaların kısıtlanması istemcilerin bağlanmasını engelleyebilir.

1.25'ten önceki AKS sürümleri Linux 5.4 çekirdeğini kullanan ve yalnızca AES-128-CCM ve AES-128-GCM şifreleme algoritmalarını destekleyen Ubuntu 18.04 LTS'yi temel alır. En yüksek güvenlik profili veya AES-128-GCM'yi devre dışı bırakabilen özel profil, paylaşım eşleme hatalarına neden olur.

AKS 1.25 ve sonraki sürümleri Linux 5.15 çekirdeğini kullanan ve AES-256-GCM desteğine sahip olan Ubuntu 22.04'ü temel alır.

Çözüm: AES-128-GCM şifreleme algoritmasının kullanılmasına izin ver

En yüksek uyumluluk profilini veya AES-128-GCM'yi etkinleştiren bir Özel profil kullanarak AES-128-GCM algoritmasını etkinleştirin. Daha fazla bilgi için bkz. Azure Dosyalar Güvenlik Ayarları.

Neden 5: Depolama hesabı için en düşük şifreleme gereksinimi karşılanmadı

Çözüm: Tüm depolama hesapları için AES-128-GCM şifreleme algoritmasını etkinleştirme

Bir dosya paylaşımını başarıyla bağlamak veya bu paylaşıma erişmek için AES-128-GCM şifreleme algoritması tüm depolama hesapları için etkinleştirilmelidir.

Yalnızca en yüksek güvenlik (SMB 3.1.1) olan AES-256-GCM şifrelemesini kullanmak istiyorsanız aşağıdakileri yapın:

Linux

İstemcinin AES-256-GCM'yi destekleyip desteklemediğini denetlemek ve yalnızca destekliyorsa zorlamak için aşağıdaki betiği kullanın:

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

SMB istemcisi tarafından kullanılan şifreleme şifrelemelerini ve kullanıcı onayı olmadan tercih edilen şifreleme türünü belirtmek için Set-SmbClientConfiguration PowerShell komutunu kullanın:

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

Not

parametresi, EncryptionCiphers x64 tabanlı sistemler için Windows Server sürüm 21H2 için 2022-06 Toplu Güncelleştirmesi (KB5014665) ve Windows 11, sürüm 22H2 (KB5014668) için Toplu Güncelleştirme ile başlayarak kullanılabilir.

Daha fazla bilgi

Başka bağlama hatalarıyla karşılaşırsanız bkz. Linux'ta Azure Dosyalar sorunlarını giderme.

Yardım için bize ulaşın

Sorularınız veya yardıma ihtiyacınız varsa bir destek isteği oluşturun veya Azure topluluk desteği isteyin. Ürün geri bildirimini Azure geri bildirim topluluğuna da gönderebilirsiniz.