Azure Kubernetes Service'teki (AKS) uygulamalar için depolama seçenekleri

Azure Kubernetes Service'te (AKS) çalışan uygulamaların verileri depolaması ve alması gerekebilir. Bazı uygulama iş yükleri gereksiz ve boşaltılmamış düğümlerde yerel ve hızlı depolama kullanabilirken, diğerleri Azure platformundaki daha düzenli veri hacimlerinde kalıcı depolama alanı gerektirir.

Birden çok pod için gerekenler:

• Aynı veri birimlerini paylaşın.
• Pod farklı bir düğümde yeniden zamanlanmışsa veri birimlerini yeniden bağlayın.

Ayrıca hassas verileri veya uygulama yapılandırma bilgilerini de toplamanız ve podlarda depolamanız gerekebilir.

Bu makalede, AKS'deki uygulamalarınıza depolama sağlayan temel kavramlar açıklanır:

• Birim
• Kalıcı birimler
• Depolama sınıfları
• Kalıcı birim talepleri

Varsayılan işletim sistemi disk boyutlandırması

Kısa ömürlü işletim sistemi diskleri

Kısa ömürlü işletim sistemi disklerini destekleyen ancak işletim sistemi disk boyutu belirtmeyen bir VM SKU'su seçerseniz, varsayılan olarak AKS, geçici değer en az 128GiB olduğu sürece VM SKU'sunun toplam geçici depolama alanına göre ölçeklendirilen bir boyuta sahip kısa ömürlü bir işletim sistemi diski sağlar. Örneğin, geçici disk boyutu 300GiB olan SKU, Standard_D8ds_v5 disk parametreleri belirtilmemişse varsayılan olarak bir 300GiB Kısa Ömürlü işletim sistemi diski alır.

VM SKU'sunun geçici depolama alanını kullanmak istiyorsanız, dağıtım sırasında işletim sistemi disk boyutunu belirtmeniz gerekir, aksi takdirde varsayılan olarak kullanılır.

Önemli

Varsayılan Kısa Ömürlü İşletim Sistemi disk boyutlandırması yalnızca kısa ömürlü işletim sistemi disklerinin desteklendiği ve varsayılan işletim sistemi disk boyutunun belirtilmediğinde yeni kümelerde veya düğüm havuzlarında kullanılır. Varsayılan işletim sistemi disk boyutu kümenizin performansını veya maliyetini etkileyebilir. Küme veya düğüm havuzu oluşturulduktan sonra işletim sistemi disk boyutunu değiştiremezsiniz. Bu varsayılan Kısa Ömürlü boyutlandırma, Mart 2025 veya sonrasında oluşturulan kümeleri veya düğüm havuzlarını etkiler.

Yönetilen işletim sistemi diskleri

Yeni bir küme oluşturduğunuzda veya var olan bir kümeye yeni düğüm havuzu eklediğinizde, işletim sistemi disk boyutunu varsayılan olarak vCPU sayısı belirler. vCPU sayısı VM SKU'sunu temel alır. Aşağıdaki tabloda her VM SKU'su için varsayılan işletim sistemi disk boyutu listelenir:

VM SKU Çekirdekleri (vCPU' lar)	Varsayılan İşletim Sistemi Disk Katmanı	Sağlanan IOPS	Sağlanan Aktarım Hızı (Mb/sn)
1 - 7	P10/128G	beş yüz	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	Yüz elli
64+	P30/1024G	5.000	200

Önemli

Varsayılan Yönetilen işletim sistemi disk boyutlandırması yalnızca kısa ömürlü işletim sistemi diskleri desteklenmediğinde ve varsayılan işletim sistemi disk boyutu belirtilmediğinde yeni kümelerde veya düğüm havuzlarında kullanılır. Varsayılan işletim sistemi disk boyutu kümenizin performansını veya maliyetini etkileyebilir. Küme veya düğüm havuzu oluşturulduktan sonra işletim sistemi disk boyutunu değiştiremezsiniz. Kısa ömürlü işletim sistemi diski kullanılamıyorsa en az 512G disk boyutu önerilir. Bu varsayılan Yönetilen boyutlandırma, Temmuz 2022 veya sonraki sürümlerde oluşturulan kümeleri veya düğüm havuzlarını etkiler.

Kısa Ömürlü İşletim Sistemi diski

Varsayılan olarak Azure, sanal makine başka bir konağa yeniden konumlandırıldığında veri kaybını önlemek için sanal makinenin işletim sistemi diskini otomatik olarak Azure Depolama'ya çoğaltır. Ancak kapsayıcılar yerel durumun kalıcı olması için tasarlanmadığından, bu davranış bazı dezavantajlar sağlarken sınırlı değer sunar. Bu dezavantajlar daha yavaş düğüm sağlama ve daha yüksek okuma/yazma gecikme süresi içerir ancak bunlarla sınırlı değildir.

Buna karşılık Kısa ömürlü işletim sistemi diskleri, tıpkı geçici bir disk gibi yalnızca konak makinede depolanır. Bu yapılandırmayla, daha hızlı düğüm ölçeklendirme ve küme yükseltmeleriyle daha düşük okuma/yazma gecikme süresi elde edersiniz. Bu nedenle, mümkün olduğunda Kısa Ömürlü işletim sistemi disklerinin kullanılmasını kesinlikle öneririz.

Not

AKS, işletim sistemi için Azure yönetilen disklerini açıkça istemediğinizde, belirli bir düğüm havuzu yapılandırması için mümkünse varsayılan olarak kısa ömürlü işletim sistemine geçer.

Kısa ömürlü işletim sistemi diskleri için boyut gereksinimleri ve önerileri Azure VM belgelerinde bulunabilir. Aşağıda genel boyutlandırma ile ilgili dikkat edilmesi gereken bazı noktalar bulunmaktadır:

• Varsayılan işletim sistemi disk boyutu 100 GiB olan SKU'Standard_DS2_v2 AKS varsayılan VM boyutunu kullanmayı seçtiyseniz, varsayılan VM boyutu kısa ömürlü işletim sistemini destekler, ancak yalnızca 86 GiB önbellek boyutuna sahiptir. Bu yapılandırmayı açıkça belirtmezseniz, varsayılan olarak yönetilen disklere geçer. Kısa ömürlü işletim sistemi isteğinde bulunursanız doğrulama hatası alırsınız.

• 60 GiB işletim sistemi diski ile aynı Standard_DS2_v2 SKU'su isterseniz, bu yapılandırma varsayılan olarak kısa ömürlü işletim sistemi olur. İstenen 60 GiB boyutu, en fazla 86 GiB önbellek boyutundan daha küçüktür.

• 100 GB işletim sistemi diski olan Standard_D8s_v3 SKU'yu seçerseniz, bu VM boyutu kısa ömürlü işletim sistemini destekler ve 200 GiB önbellek alanına sahiptir. İşletim sistemi disk türünü belirtmezseniz düğüm havuzu varsayılan olarak kısa ömürlü işletim sistemi alır.

En son nesil VM serisinin ayrılmış bir önbelleği yoktur, yalnızca geçici depolama alanı vardır. Örneğin, varsayılan işletim sistemi disk boyutu 100 GiB olan Standard_E2bds_v5 VM boyutunu seçtiyseniz kısa ömürlü işletim sistemi disklerini destekler, ancak yalnızca 75 GB geçici depolama alanı vardır. Açıkça belirtmezseniz, bu yapılandırma varsayılan olarak yönetilen işletim sistemi disklerini seçer. Kısa ömürlü bir işletim sistemi diski isterseniz doğrulama hatası alırsınız.

• 60 GiB işletim sistemi diski ile aynı Standard_E2bds_v5 VM boyutunu isterseniz, bu yapılandırma varsayılan olarak geçici işletim sistemi disklerini kullanır. İstenen 60 GiB boyutu, 75 GiB'lik maksimum geçici depolamadan daha küçüktür.

• 100 GiB işletim sistemi diski olan Standard_E4bds_v5 SKU'yu seçerseniz, bu VM boyutu kısa ömürlü işletim sistemini destekler ve 150 GiB geçici depolama alanına sahiptir. İşletim sistemi disk türünü belirtmezseniz, Azure varsayılan olarak düğüm havuzuna kısa ömürlü bir işletim sistemi diski sağlar.

Müşteri tarafından yönetilen anahtarlar

Kısa ömürlü işletim sistemi diskiniz için şifrelemeyi aks kümesinde kendi anahtarlarınızla yönetebilirsiniz. Daha fazla bilgi için bkz . AKS üzerinde Azure disk ile Müşteri Tarafından Yönetilen anahtarı kullanma.

Kısa ömürlü NVMe veri diskleri

Kısa ömürlü NVMe veri diskleri, doğrudan Azure VM'nizin fiziksel konağına bağlı yüksek performanslı, düşük gecikme süreli depolama sağlar. Bu diskler önbelleğe alma, karalama alanı veya yüksek aktarım hızı analizi gibi ara veri işleme için hızlı ve geçici depolama gerektiren iş yükleri için idealdir.

Kısa ömürlü NVMe veri diskleri başlangıçta yalnızca Azure VM L serisi, E serisi ve GPU VM'lerinde kullanılabilirdi. Azure VM v6 ve v7 nesillerinin kullanıma sunulmasıyla kısa ömürlü NVMe veri diskleri desteği D serisi, F serisi, H serisi ve daha fazlası dahil olmak üzere çok daha geniş bir VM boyutu yelpazesine genişletildi. NVMe diskleri, geleneksel HDD veya SSD seçeneklerine kıyasla çok daha yüksek IOPS ve aktarım hızı sunar. Ancak, bu disklerde depolanan veriler geçicidir ve VM serbest bırakılırsa veya yeniden dağıtılırsa kaybolur.

AKS'de kısa ömürlü NVMe veri disklerinin yönetimini ve sağlanmasını basitleştirmek için Azure Container Storage'ı kullanın. Azure Container Storage NVMe veri disklerini otomatik olarak algılayabilir ve düzenleyebilir; böylece Kubernetes iş yükleriniz için en az yapılandırmayla kalıcı birimler oluşturup yönetebilirsiniz. Bu yaklaşım, aşağıdakiler gibi yüksek performanslı, geçici depolama gerektiren senaryolar için önerilir:

• Yapay zeka eğitimi için veri kümeleri ve denetim noktaları gibi yüksek hızlı önbelleğe alma katmanları veya yapay zeka çıkarımı için kullanılan model dosyaları
• Yerleşik çoğaltma ve yedekleme özellikleri içeren yüksek performanslı, kendi kendine barındırılan veritabanları
• Hızlı ve geçici depolama gerektiren veri yoğunluklu analiz ve işleme işlem hatları
• Toplu işler için geçici çalışma alanı

Önemli

Kısa ömürlü NVMe veri diskleri kritik veya kalıcı verileri depolamak için uygun değildir. Uygulamanızın veri kaybına dayanadığından ve önemli verilerin Azure Disk, Azure Dosyalar veya diğer dayanıklı depolama seçenekleri tarafından yedeklenen kalıcı birimlerde depolandığından emin olun.

Azure Container Storage'ı kısa ömürlü NVMe veri diskleriyle kullanma hakkında daha fazla bilgi için bkz. AKS ile Azure Container Storage'ı kullanma.

Birimler

Kubernetes genellikle tek tek podları kısa ömürlü, tek kullanımlık kaynaklar olarak kabul eder. Uygulamaların, verileri kullanmak ve kalıcı hale getirmek için kullanabileceği farklı yaklaşımları vardır. Birim, podlar arasında ve uygulama yaşam döngüsü boyunca verileri depolamanın, almanın ve kalıcı hale getirmek için kullanılan bir yolu temsil eder.

Geleneksel birimler, Azure Depolama tarafından yedeklenen Kubernetes kaynakları olarak oluşturulur. Podlara doğrudan atanacak veri birimlerini el ile oluşturabilir veya Kubernetes'in bunları otomatik olarak oluşturmasını sağlayabilirsiniz. Veri birimleri şunları kullanabilir: Azure Disk, Azure Dosyalar, Azure NetApp Files veya Azure Blobları.

Not

Kullandığınız VM SKU'sunun bağlı olarak, Azure Disk CSI sürücüsünün düğüm başına birim sınırı olabilir. Bazı yüksek performanslı VM'ler için (örneğin, 16 çekirdek), düğüm başına sınır 64 birimdir. VM SKU'su başına sınırı belirlemek için, sunulan her VM SKU'su için En fazla veri diski sütununu gözden geçirin. Sunulan VM SKU'larının listesi ve bunların ilgili ayrıntılı kapasite sınırları için bkz . Genel amaçlı sanal makine boyutları.

Azure Dosyalar ile Azure NetApp Files arasında iş yükünüz için en uygun olanın belirlenmesine yardımcı olmak için Azure Dosyalar ve Azure NetApp Files karşılaştırması makalesinde sağlanan bilgileri gözden geçirin.

Azure Disk

Kubernetes DataDisk kaynağı oluşturmak için Azure Disk'i kullanın. Disk türleri şunlardır:

• Premium SSD'ler (çoğu iş yükü için önerilir)
• Ultra diskler
• Standart SSD’ler
• Standart HHD’ler

İpucu

Çoğu üretim ve geliştirme iş yükü için Premium SSD'leri kullanın.

Azure Disk, ReadWriteOnce olarak bağlandığından, yalnızca tek bir düğümde kullanılabilir. Birden çok düğümdeki podlar tarafından aynı anda erişilebilen depolama birimleri için Azure Dosyalar kullanın.

Azure Dosyaları

Azure Dosyalar'ı, Sunucu Mesaj Bloğu (SMB) sürüm 3.1.1 paylaşımını veya Ağ Dosya Sistemi (NFS) sürüm 4.1 paylaşımını bağlamak için kullanın. Azure Dosyalar birden çok düğüm ve pod arasında veri paylaşmanıza olanak sağlar ve bunları kullanabilirsiniz:

• Yüksek performanslı SSD'ler tarafından yedeklenen Azure Premium depolama
• Normal HDD'ler tarafından yedeklenen Azure Standart depolama

Azure NetApp Dosyaları

• Ultra Depolama
• Premium Depolama
• Standart Depolama

Azure Blob Saklama Alanı

Azure Blob Depolama kullanarak bir blob depolama kapsayıcısı oluşturun ve NFS v3.0 protokolunu veya BlobFuse'u kullanarak bağlayın.

• Blok blobları

Birim türleri

Kubernetes birimleri, bilgileri depolamak ve almak için geleneksel bir diskten fazlasını temsil eder. Kubernetes birimleri, kapsayıcıları tarafından kullanılmak üzere bir pod'a veri eklemenin bir yolu olarak da kullanılabilir.

Kubernetes'teki yaygın birim türleri şunlardır:

boşDizin

Genellikle pod için geçici alan olarak kullanılır. Pod içindeki tüm kapsayıcılar birimdeki verilere erişebilir. Bu birim türüne yazılan veriler yalnızca podun kullanım ömrü boyunca kalır. Podu sildiğinizde birim de silinir. Bu birim genellikle yerel düğümün disk depolama alanını kullanır, ancak yalnızca düğümün belleğinde de mevcut olabilir.

gizli

Gizli bellek birimlerini kullanarak parolalar gibi hassas verileri podlara ekleyebilirsiniz.

1. Kubernetes API'sini kullanarak bir gizli oluşturun.
2. Podunuzu veya dağıtımınızı tanımlayın ve belirli bir gizliyi talep edin.
   • Gizli diziler yalnızca bunları gerektiren zamanlanmış bir pod ile düğümlere sağlanır.
   • Gizli dizi, diske yazılmaz, tmpfs içinde depolanır.
3. Gizli anahtar gerektiren bir düğümdeki son podu sildiğinizde, gizli anahtar düğümün tmpfs dosyasından silinir.
   • Gizli diziler belirli bir ad alanında depolanır ve yalnızca aynı ad alanı içindeki podlar tarafından erişilir.

configMap

Uygulama yapılandırma bilgileri gibi anahtar-değer çifti özelliklerini podlara eklemek için configMap'i kullanabilirsiniz. Uygulama yapılandırma bilgilerini kubernetes kaynağı olarak tanımlayın, kolayca güncelleştirilebilir ve dağıtıldıklarında yeni pod örneklerine uygulanır.

Gizli dizi kullanmak gibi:

1. Kubernetes API'sini kullanarak bir ConfigMap oluşturun.
2. Bir pod veya dağıtım tanımlarken ConfigMap'i isteyin.
   • ConfigMap'ler belirli bir ad alanında depolanır ve yalnızca aynı ad alanı içindeki podlar tarafından erişilir.

Kalıcı Hacimler

Pod yaşam döngüsünün bir parçası olarak tanımlanan ve oluşturulan birimler yalnızca podu silene kadar mevcut olur. Podlar genellikle özellikle StatefulSets'te bir bakım olayı sırasında pod farklı bir konakta yeniden zamanlanırsa depolamalarının kalmasını bekler. Kalıcı birim (PV), Kubernetes API'si tarafından oluşturulan ve yönetilen ve tek bir podun kullanım ömründen daha uzun süre var olabilecek bir depolama kaynağıdır.

Kalıcı birimi sağlamak için aşağıdaki Azure Depolama hizmetlerini kullanabilirsiniz:

• Azure Disk
• Azure Dosyaları
• Azure Container Storage

Birimler bölümünde belirtildiği gibi, Azure Diskleri veya Azure Dosyalar seçimi genellikle verilere veya performans katmanına eşzamanlı erişim gereksinimine göre belirlenir.

Küme yöneticisi statik olarak kalıcı bir birim oluşturabilir veya kubernetes API sunucusu tarafından dinamik olarak bir birim oluşturulabilir. Bir pod zamanlanmışsa ve şu anda mevcut olmayan bir depolama alanı talep ederse, Kubernetes, gereksinimlere uygun olarak Azure Disk veya Dosya depolama alanını oluşturabilir ve bunu pod'a ekleyebilir. Dinamik sağlama, oluşturulması gereken kaynak türünü belirlemek için bir depolama sınıfı kullanır.

Önemli

İki işletim sistemi arasındaki dosya sistemi desteği farklılıkları nedeniyle kalıcı birimler Windows ve Linux podları tarafından paylaşılamaz.

Verilere blok düzeyinde erişim için tam olarak yönetilen bir çözüm istiyorsanız, CSI sürücüleri yerine Azure Container Storage'ı kullanmayı göz önünde bulundurun. Azure Container Storage, Kubernetes ile tümleştirilip kalıcı birimlerin dinamik ve otomatik olarak sağlanmasına olanak sağlar. Azure Container Storage, Azure Diskleri, Kısa Ömürlü Diskleri ve Azure Elastik SAN'yı (önizleme) depolama alanı olarak destekleyerek Kubernetes kümelerinde çalışan durum bilgisi olan uygulamalar için esneklik ve ölçeklenebilirlik sunar.

Depolama sınıfları

Premium veya standart gibi farklı depolama katmanları belirtmek için bir depolama sınıfı oluşturabilirsiniz.

Depolama sınıfı bir geri kazanma ilkesi de tanımlar. Kalıcı birimi sildiğinizde geri kazanma ilkesi, temel alınan Azure Depolama kaynağının davranışını denetler. Alt kaynak silinebilir veya gelecekteki bir pod ile kullanılmak üzere tutulabilir.

Azure Container Storage kullanan kümeler için adlı acstor-<storage-pool-name>ek bir depolama sınıfı görürsünüz. Bir iç depolama sınıfı da oluşturulur.

Kapsayıcı Depolama Arabirimi (CSI) sürücülerini kullanan kümeler için aşağıdaki ek depolama sınıfları oluşturulur:

Depolama sınıfı	Açıklama
managed-csi	Yönetilen disk oluşturmak için Azure Standart SSD yerel olarak yedekli depolama (LRS) kullanır. Geri kazanma ilkesi, kullanılan kalıcı birim silindiğinde temel alınan Azure Disk'in silinmesini sağlar. Depolama sınıfı, kalıcı birimleri de genişletilebilir olacak şekilde yapılandırıyor. Yeni boyutu belirtmek için kalıcı birim talebi düzenleyebilirsiniz. Birden çok kullanılabilirlik alanına dağıtılan Azure Kubernetes Service (AKS) kümelerinde Kubernetes sürüm 1.29'dan itibaren geçerli olan bu depolama sınıfı, yönetilen diskler oluşturmak için Azure Standart SSD alanlar arası yedekli depolama (ZRS) kullanır.
managed-csi-premium	Yönetilen disk oluşturmak için Azure Premium yerel olarak yedekli depolama (LRS) kullanır. Geri kazanım politikası, kullanılan kalıcı birim silindiğinde temel Azure Disk'in silinmesini yine sağlar. Benzer şekilde, bu depolama sınıfı kalıcı birimlerin genişletilmesine izin verir. Birden çok kullanılabilirlik alanına dağıtılan Azure Kubernetes Service (AKS) kümelerinde Kubernetes sürüm 1.29'dan itibaren geçerli olan bu depolama sınıfı, yönetilen diskler oluşturmak için Azure Premium alanlar arası yedekli depolama (ZRS) kullanır.
azurefile-csi	Azure dosya paylaşımı oluşturmak için Azure Standart depolamayı kullanır. Geri kazanma ilkesi, kullanılan kalıcı birim silindiğinde temel alınan Azure dosya paylaşımının silinmesini sağlar.
azurefile-csi-premium	Bir Azure dosya paylaşımı oluşturmak için Azure Premium depolamayı kullanır. Geri kazanma ilkesi, kullanılan kalıcı birim silindiğinde temel alınan Azure dosya paylaşımının silinmesini sağlar.
azureblob-nfs-premium	Azure Blob depolama kapsayıcısı oluşturmak ve NFS v3 protokolunu kullanarak bağlanmak için Azure Premium depolamayı kullanır. Geri kazanım ilkesi, kullanılan kalıcı birim silindiğinde temel Azure Blob depolama kapsayıcısının silinmesini sağlar.
azureblob-fuse-premium	Azure Blob depolama kapsayıcısı oluşturmak ve BlobFuse kullanarak bağlanmak için Azure Premium depolamayı kullanır. Geri kazanım ilkesi, kullanılan kalıcı birim silindiğinde temel Azure Blob depolama kapsayıcısının silinmesini sağlar.

Kalıcı birim için bir depolama sınıfı belirtmediğiniz sürece varsayılan depolama sınıfı kullanılır. Kalıcı disk alanı talep ederken, ihtiyacınız olan uygun depolama alanını kullandıklarından emin olun.

Önemli

Kubernetes sürüm 1.21'den başlayarak AKS varsayılan olarak CSI sürücülerini kullanır ve CSI geçişi etkinleştirilir. Mevcut ağaç içi kalıcı birimler 1.26 sürümünden başlayarak çalışmaya devam etse de AKS artık ağaç içi sürücü ve dosyalar ve disk için sağlanan depolama kullanılarak oluşturulan birimleri desteklemeyecektir.

sınıfı ile default aynı managed-csiolacaktır.

Kubernetes sürüm 1.29'dan başlayarak, Azure Kubernetes Service (AKS) kümelerini birden çok kullanılabilirlik alanına dağıttığınızda AKS artık yerleşik depolama sınıflarında yönetilen diskler oluşturmak için alanlar arası yedekli depolama (ZRS) kullanıyor. ZRS, seçtiğiniz bölgedeki birden çok Azure kullanılabilirlik alanı arasında Azure yönetilen disklerinizin eşzamanlı replikasyonunu sağlar. Bu yedeklilik stratejisi, uygulamalarınızın dayanıklılığını artırır ve verilerinizi veri merkezi hatalarına karşı korur.

Ancak, alanlar arası yedekli depolamanın (ZRS) yerel olarak yedekli depolamaya (LRS) kıyasla daha yüksek bir maliyetle geldiğini unutmayın. Maliyet iyileştirme öncelikliyse, parametresi LRS olarak ayarlanmış yeni bir depolama sınıfı skuname oluşturabilirsiniz. Daha sonra Kalıcı Birim Talebinizde (PVC) yeni depolama sınıfını kullanabilirsiniz.

kullanarak kubectldiğer gereksinimler için bir depolama sınıfı oluşturabilirsiniz. Aşağıdaki örnek premium yönetilen diskleri kullanır ve pod'u sildiğinizde temel alınan Azure Disk'in korunması gerektiğini belirtir:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Not

AKS, varsayılan depolama sınıflarını düzenler ve bu depolama sınıflarında yaptığınız değişikliklerin üzerine yazar.

Depolama sınıfları hakkında daha fazla bilgi için bkz Kubernetes'te StorageClass.

Kalıcı birim talepleri

Kalıcı birim talebi (PVC), belirli bir depolama sınıfının, erişim modunun ve boyutunun depolanmasını ister. Kubernetes API sunucusu, tanımlı depolama sınıfına göre talebi karşılayabilen mevcut bir kaynak yoksa temel alınan Azure Depolama kaynağını dinamik olarak sağlayabilir.

Pod tanımı, birim pod'a bağlandıktan sonra birim bağlamasını içerir.

Depolama isteyen poda kullanılabilir bir depolama kaynağı atandıktan sonra, kalıcı birim kalıcı bir birim talebine bağlanır . Kalıcı birimler, 1:1 eşlemesindeki taleplere eşlenir.

Aşağıdaki örnek YAML bildirimi, yönetilen-premium depolama sınıfını kullanan ve boyutu 5Gi olan bir Azure Disk isteyen kalıcı birim talebini gösterir:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Pod tanımı oluşturduğunuzda şunları da belirtirsiniz:

• Kalıcı birim istenen depolamayı istemek için talepte bulunur.
• Uygulamalarınızın veri okuma ve yazma işlemleri için birim montajı.

Aşağıdaki örnek YAML bildirimi, önceki kalıcı birim talebinin /mnt/azure konumunda bir birim bağlamak için nasıl kullanılabileceğini gösterir.

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Bir disk birimini bir Windows kapsayıcısında bağlamak için sürücü harfi ve yolu belirtin. Örneğin:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

Sonraki adımlar

İlişkili en iyi yöntemler için bkz . AKS ve AKS depolamada depolama ve yedeklemeler için en iyi yöntemler.

Azure Container Storage hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Azure Container Storage nedir?
• AKS ile Azure Container Storage kullanma

CSI sürücülerini kullanma hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Azure Kubernetes Service'te Azure Disk, Azure Dosyalar ve Azure Blob depolama için Kapsayıcı Depolama Arabirimi (CSI) sürücüleri
• Azure Kubernetes Service'te Azure Disk CSI sürücüsünü kullanma
• Azure Kubernetes Service'te Azure Dosyalar CSI sürücüsü kullanma
• Azure Kubernetes Service'te Azure Blob depolama CSI sürücüsünü kullanma
• Azure Kubernetes Service ile Azure NetApp Files'ı yapılandırma

Temel Kubernetes ve AKS kavramları hakkında daha fazla bilgi için aşağıdaki makalelere bakın:

• Kubernetes / AKS kümeleri ve iş yükleri
• Kubernetes / AKS kimliği
• Kubernetes / AKS güvenliği
• Kubernetes / AKS sanal ağları
• Kubernetes / AKS ölçeği