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:
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.
- Kubernetes API'sini kullanarak gizli dizi oluşturun.
- 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.
- 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:
- Kubernetes API'sini kullanarak bir ConfigMap oluşturun.
- 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 Azure Disk veya Azure Dosyalar kullanabilirsiniz. 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: