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

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

Varsayılan olarak, Vm başka bir konağa yeniden konumlandırıldığında veri kaybını önlemek için Azure, bir sanal makinenin işletim sistemi diskini otomatik olarak Azure depolama alanına ç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 desteklenmeyen 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:

• Ultra Diskler
• Premium SSD’ler
• Standart SSD’ler
• Standart HHD’ler

İpucu

Çoğu üretim ve geliştirme iş yükü için Premium SSD 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 kullanarak Bir Sunucu İleti Bloğu (SMB) sürüm 3.1.1 paylaşımını veya Azure depolama hesabı tarafından yedeklenen Ağ Dosya Sistemi (NFS) sürüm 4.1 paylaşımını podlara bağlayı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 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.
   • Yapılandırma Haritalar 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.

PersistentVolume sağlamak için aşağıdaki Azure Depolama veri hizmetlerini kullanabilirsiniz:

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

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

Küme yöneticisi statik olarak bir PersistentVolume oluşturabilir veya birim Kubernetes API sunucusu tarafından dinamik olarak oluşturulur. Bir pod zamanlanmışsa ve şu anda kullanılamayan depolamayı isterse, Kubernetes temel alınan Azure Disk veya Dosya depolama alanını oluşturabilir ve pod'a ekleyebilir. Dinamik sağlama, oluşturulması gereken Azure depolama türünü belirlemek için bir Depolama Class 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 ve Standart gibi farklı depolama katmanlarını tanımlamak için bir Depolama Class oluşturabilirsiniz.

Depolama Class ayrıca reclaimPolicy'yi de tanımlar. Kalıcı birimi sildiğinizde, reclaimPolicy temel alınan Azure depolama kaynağının davranışını denetler. Temel alınan depolama kaynağı 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 öğeler StorageClasses oluşturulur:

Depolama sınıfı	Açıklama
managed-csi	Yönetilen Disk oluşturmak için Azure StandardSSD 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ı ayrıca kalıcı birimleri genişletilebilir olacak şekilde yapılandırıyor, yalnızca kalıcı birim talebinizi yeni boyutla düzenlemeniz yeterlidir.
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.
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 Class belirtmediğiniz sürece varsayılan Depolama Class 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.

kullanarak kubectldiğer gereksinimler için bir Depolama Class oluşturabilirsiniz. Aşağıdaki örnek Premium Yönetilen Diskler 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 Depolama Class.

Kalıcı birim talepleri

PersistentVolumeClaim belirli bir Depolama Class, erişim modu ve boyutun depolanmasını ister. Kubernetes API sunucusu, tanımlanan Depolama Class temelinde mevcut hiçbir kaynak talebi karşılayamıyorsa 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, PersistentVolume bir PersistentVolumeClaim'e bağlanır . Kalıcı birimler taleplere eşlenmiş 1:1'dir.

Aşağıdaki örnek YAML bildirimi, managed-premium Depolama Class kullanan ve boyutta bir Disk 5Gi isteyen kalıcı bir birim talebi 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 volumeMount.

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 ve AKS'de depolama ve yedeklemeler için en iyi yöntemler Depolama Dikkat Edilmesi Gerekenler.

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