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ı

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	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	Kategori 5000	200

Önemli

Varsayılan 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. Bu varsayılan disk boyutlandırması, Temmuz 2022 veya sonrasında 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 birlikte daha düşük okuma/yazma gecikme süresi elde edersiniz.

Not

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

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. Açıkça belirtmezseniz, bu yapılandırma varsayılan olarak yönetilen diskler olur. 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 diskleri olur. Kısa ömürlü bir işletim sistemi diski isterseniz doğrulama hatası alırsınız.

• 60 GiB işletim sistemi diski olan aynı Standard_E2bds_v5 VM boyutunu isterseniz, bu yapılandırma varsayılan olarak kısa ömürlü işletim sistemi diskleri olur. İ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.

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 Diski

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ı

Sunucu İleti 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 Azure Dosyalar 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 Files

• Ultra Depolama Alanı
• Premium Depolama
• Standart Depolama

Azure Blob Storage

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:

emptyDir

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. Pod silindikten sonra birim silinir. Bu birim genellikle temel alınan yerel düğüm disk depolama alanını kullanır, ancak yalnızca düğümün belleğinde de bulunabilir.

gizli dizi

Gizli dizi birimlerini kullanarak parolalar gibi hassas verileri podlara ekleyebilirsiniz.

1. Kubernetes API'sini kullanarak bir gizli dizi oluşturun.
2. Podunuzu veya dağıtımınızı tanımlayın ve belirli bir gizli dizi isteyin.
   • 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 dizi gerektiren bir düğümdeki son podu sildiğinizde, gizli dizi düğümün tmpfs'lerinden 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ı birimler

Pod yaşam döngüsünün bir parçası olarak tanımlanan ve oluşturulan birimler yalnızca siz pod 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 veri hizmetlerini kullanabilirsiniz:

• Azure Disk
• Azure Dosyaları
• Azure Container Storage (önizleme).

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 kullanılamayan bir depolama alanı isterse Kubernetes temel alınan Azure Disk veya Dosya depolama alanını oluşturabilir ve 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.

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. Temel alınan kaynak silinebilir veya gelecekteki bir pod ile kullanılmak üzere tutulabilir.

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 kazanma ilkesi, kullanılan kalıcı birim silindiğinde temel alınan Azure Disk'in silinmesini yeniden 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 kazanma ilkesi, kullanılan kalıcı birim silindiğinde temel alınan 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 kazanma ilkesi, kullanılan kalıcı birim silindiğinde temel alınan 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. Birimlerin kalıcı birimler talep ederken ihtiyacınız olan uygun depolama alanını kullandığından emin olun.

Önemli

Kubernetes sürüm 1.21'den başlayarak AKS varsayılan olarak yalnızca 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, Azure yönetilen disklerinizin seçtiğiniz bölgedeki birden çok Azure kullanılabilirlik alanı arasında zaman uyumlu çoğaltmasını 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ı mutabık tutar 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 verileri okuması ve yazması için birim bağlaması.

Aşağıdaki örnek YAML bildirimi, /mnt/azure'da bir birimi bağlamak için önceki kalıcı birim talebin 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 birimi bir Windows kapsayıcısında bağlamak için sürücü harfini ve yolunu 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'de depolama ve yedeklemeler için en iyi yöntemler ve AKS Depolama Konuları.

CSI sürücülerinin nasıl kullanılacağını görmek için aşağıdaki nasıl yapılır makalelerine 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