Depolama Yapılandırması

Kubernetes depolama kavramları

Kubernetes, temel alınan sanallaştırma teknoloji yığını (isteğe bağlı) ve donanım üzerinde bir altyapı soyutlama katmanı sağlar. kubernetes 'in, depolama alanının yer aldığı yolu Depolama sınıflar aracılığıyla yapılır. Pod sağladığınızda, her birim için bir depolama sınıfı belirtebilirsiniz. Pod 'ın sağlandığı zamanda depolama sınıfı hazırlayıcı , depolamayı sağlamak için çağrılır ve ardından bu sağlanan depolamada kalıcı bir birim oluşturulur ve ardından Pod kalıcı birime kalıcı bir birim talebi tarafından bağlanır.

Kubernetes, depolama altyapısı sağlayıcılarının Kubernetes 'i genişleten sürücüleri ("Eklentiler" olarak da bilinir) takmaları için bir yol sağlar. Depolama eklentiler, kapsayıcı Depolama arabirim standardına uygun olmalıdır. Bu kesin olmayan bu CSI sürücüleri listesinde bulunabilir. Kullandığınız CSı sürücüsü, bulutta barındırılan, yönetilen bir Kubernetes hizmetinde ya da donanımınız için kullandığınız OEM sağlayıcısından çalıştırdığınız gibi etkenlere bağlı olacaktır.

Şu komutu çalıştırarak Kubernetes kümenizde hangi depolama sınıflarının yapılandırıldığını görüntüleyebilirsiniz:

kubectl get storageclass

Azure Kubernetes Service (AKS) kümesinden alınan örnek çıktı:

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Şu komutu çalıştırarak bir depolama sınıfı hakkında ayrıntılı bilgi edinebilirsiniz:

kubectl describe storageclass/<storage class name>

Örnek:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

Aşağıdaki komutları çalıştırarak, şu anda sağlanan kalıcı birimleri ve kalıcı birim taleplerini görebilirsiniz:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Kalıcı birimleri gösterme örneği:


kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Kalıcı birim taleplerini gösterme örneği:


kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Depolama yapılandırmanızı seçerken göz önünde bulundurmanız gereken etmenler

Doğru depolama sınıfının seçilmesi veri dayanıklılığı ve performansı açısından önemlidir. Yanlış depolama sınıfının seçilmesi, bir donanım arızası durumunda verilerinizi toplam veri kaybı riskiyle elde edebilir veya en iyi performansa neden olabilir.

Genellikle iki tür depolama vardır:

  • Yerel depolama -belirli bir düğümdeki yerel sabit sürücülerde sağlanan depolama alanı. Bu tür bir depolama, performans açısından ideal olabilir, ancak verileri birden çok düğüm arasında çoğaltarak veri yedekliği için özellikle tasarlanmasını gerektirir.
  • Uzak, paylaşılan depolama (örneğin, bir uzak depolama cihazında sağlanan depolama alanı; Örneğin, EBS veya Azure dosyaları gıbı bir San, NAS veya bulut depolama hizmeti). Bu tür bir depolama genellikle otomatik olarak veri artıklığı sağlar, ancak yerel depolama alanı olabilir.

NFS tabanlı depolama sınıfları

NFS sunucusu ve depolama sınıfı hazırlayıcısı yapılandırmasına bağlı olarak, ' yi supplementalGroups veritabanı örnekleri için pod yapılandırmalarında ayarlamanız gerekebilir ve istemci tarafından geçirilen grup kimliklerini kullanmak IÇIN NFS sunucu yapılandırmasını değiştirmeniz gerekebilir (geçirilen kullanıcı kimliğini kullanarak sunucuda grup kimliklerini aramak yerine). Bu durumun olup olmadığını öğrenmek için NFS yöneticinize başvurun.

supplementalGroupsÖzelliği bir dizi değer alır ve Azure Arc veri denetleyicisi dağıtımının bir parçası olarak ayarlanabilir ve Azure Arc veri denetleyicisi tarafından yapılandırılan tüm veritabanı örnekleri tarafından kullanılacaktır.

Bu özelliği ayarlamak için aşağıdaki komutu çalıştırın:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Veri denetleyicisi depolama yapılandırması

Veri Hizmetleri için Azure Arc 'daki bazı hizmetler, hizmetlerin verileri çoğaltabilme yeteneği olmadığından, uzak, paylaşılan depolama alanı kullanacak şekilde yapılandırılmaya bağımlıdır. Bu hizmetler, veri denetleyicisi dizin koleksiyonunda bulunur:

Hizmet Kalıcı birim talepleri
ElasticSearch <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0
InfluxDB <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0
denetleyici SQL örneği <namespace>/logs-controldb, <namespace>/data-controldb
Denetleyici API hizmeti <namespace>/data-controller

Veri denetleyicisinin sağlandığı zamanda, bu kalıcı birimlerin her biri için kullanılacak depolama sınıfı--Storage-Class ' ı geçirerek belirtilir | -SC parametresi, az arcdata dc create ve kullanılan dağıtım şablonu dosyasında control.jsdepolama sınıflarını ayarlayarak. Doğrudan bağlı modda veri denetleyicisi oluşturmak için Azure portal kullanıyorsanız, seçtiğiniz dağıtım şablonu şablonda önceden tanımlanmış depolama sınıfına sahip olur ya da önceden tanımlanmış bir depolama sınıfına sahip olmayan bir şablon seçerseniz, sizden bir tane istenir. Özel bir dağıtım şablonu kullanıyorsanız, depolama sınıfını belirtebilirsiniz.

Kutudan çıkan dağıtım şablonlarının, hedef ortam için uygun bir varsayılan depolama sınıfı belirtilmiş, ancak dağıtım sırasında geçersiz kılınabilir. Dağıtım zamanında veri denetleyicisi yığınlarının depolama sınıfı yapılandırmasını değiştirmek için dağıtım profilini değiştirme hakkında ayrıntılı adımlara bakın.

Depolama sınıfını--Storage-Class ile ayarlarsanız | -SC parametresi depolama sınıfı hem günlük hem de veri depolama sınıfları için kullanılacaktır. Dağıtım şablonu dosyasında depolama sınıflarını ayarlarsanız, Günlükler ve veriler için farklı depolama sınıfları belirtebilirsiniz.

Veri denetleyicisi için bir depolama sınıfı seçerken göz önünde bulundurmanız gereken önemli etmenler:

  • Veri dayanıklılığı sağlamak için uzak, paylaşılan bir depolama sınıfı kullanmanız gerekir ve bu sayede Pod bir pod başlatıldığında bir pod veya düğüm kalıcı birime yeniden bağlanabilir.
  • denetleyici SQL örneği, ölçüm veritabanı ve günlükler db 'ye yazılan veriler genellikle oldukça düşüktür ve gecikme süresine duyarlı değildir, böylece ultra hızlı performans depolaması kritik değildir. Sık sık Grafana ve kibana arabirimlerini kullanan kullanıcılarınız varsa ve çok sayıda veritabanı örneği varsa, kullanıcılarınız daha hızlı depolama alanı üzerinde avantaj sağlayabilir.
  • Her bir veritabanı örneği için Günlükler ve ölçümler toplandığından, gereken depolama kapasitesi, dağıttığınız veritabanı örneklerinin sayısıyla değişkendir. Veriler, temizlenmeden önce iki (2) hafta boyunca günlüklerde ve ölçüm VERITABANıNDA tutulur.
  • Depolama sınıfı dağıtımının değiştirilmesi zordur, belgelenmemiştir ve desteklenmez. Dağıtım zamanında depolama sınıfını doğru seçtiğinizden emin olun.

Not

Depolama sınıfı belirtilmemişse, varsayılan depolama sınıfı kullanılacaktır. Her bir Kubernetes kümesi için yalnızca bir varsayılan depolama sınıfı olabilir. Varsayılan depolama sınıfını değiştirebilirsiniz.

Veritabanı örneği depolama yapılandırması

Her veritabanı örneğinin veri, günlük ve yedek kalıcı birimleri vardır. Bu kalıcı birimler için depolama sınıfları dağıtım zamanında belirlenebilir. Hiçbir depolama sınıfı belirtilmemişse, varsayılan depolama sınıfı kullanılacaktır.

Ya da kullanarak bir örnek oluştururken az sql mi-arc create az postgres arc-server create , depolama sınıflarını ayarlamak için kullanılabilecek dört parametre vardır:

Parametre adı, kısa ad Kullanıldığı yerler
--storage-class-data, -d İşlem günlüğü dosyaları dahil tüm veri dosyaları için depolama sınıfını belirtmek için kullanılır
--storage-class-logs, -g Tüm günlük dosyaları için depolama sınıfını belirtmek için kullanılır
--storage-class-data-logs Veritabanı işlem günlüğü dosyaları için depolama sınıfını belirtmek için kullanılır.
--storage-class-backups Tüm yedekleme dosyaları için depolama sınıfını belirtmek için kullanılır.

aşağıdaki tabloda, veri ve günlükler için kalıcı birimle eşlenen Azure SQL yönetilen örnek kapsayıcısı içindeki yollar listelenmiştir:

Parametre adı, kısa ad MSSQL-mıaa kapsayıcısının içindeki yol Description
--storage-class-data, -d /var/opt MSSQL yüklemesi ve diğer sistem işlemlerine yönelik dizinleri içerir. MSSQL dizini, varsayılan verileri (işlem günlükleri dahil), hata günlüğü & yedekleme dizinlerini içerir
--storage-class-logs, -g /var/log Konsol çıkışını (stderr, STDOUT) ve kapsayıcı içindeki işlemlerin diğer günlük bilgilerini depolayan dizinleri içerir

Aşağıdaki tabloda, veri ve Günlükler için kalıcı birimle eşlenen PostgreSQL örnek kapsayıcısının içindeki yollar listelenmiştir:

Parametre adı, kısa ad Postgres kapsayıcısının içindeki yol Description
--storage-class-data, -d /var/seçenek/PostgreSQL Postgres yüklemesi için veri ve günlük dizinleri içerir
--storage-class-logs, -g /var/log Konsol çıkışını (stderr, STDOUT) ve kapsayıcı içindeki işlemlerin diğer günlük bilgilerini depolayan dizinleri içerir

Her veritabanı örneğinin veri dosyaları, Günlükler ve yedeklemeler için ayrı bir kalıcı birimi olacak. Yani bu dosya türlerinin her biri için g/ç 'nin, toplu hazırlayıcı tarafından depolama sağlama şekli ile ilgili olarak ayrılması anlamına gelir. Her veritabanı örneğinin kendi kalıcı birim talepleri ve kalıcı birimleri vardır.

Belirli bir veritabanı örneğinde birden çok veritabanı varsa, tüm veritabanları aynı kalıcı birim talebi, kalıcı birim ve depolama sınıfını kullanır. Tüm yedeklemeler-hem fark günlüğü yedeklemeleri hem de tam yedeklemeler aynı kalıcı birim talebini ve kalıcı birimi kullanacaktır. Veritabanı örneği için kalıcı birim talepleri aşağıda gösterilmiştir:

Örnek Kalıcı birim talepleri
Azure SQL Yönetilen Örnek <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0
PostgreSQL için Azure veritabanı örneği <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0
Azure PostgreSQL hiper ölçek <namespace>/logs-<instance namme>-<ordinal>, <namespace>/data-<instance namme>-<ordinal> (Sıra sayısı 0 ile w arasında değişir; burada w, çalışan sayısıdır)

Veritabanı örneği için bir depolama sınıfı seçerken göz önünde bulundurmanız gereken önemli etmenler:

  • Veritabanı örnekleri tek bir pod düzeninde veya birden çok pod düzeninde dağıtılabilir. Tek pod düzenine örnek olarak Azure yönetilen örneği için genel amaçlı fiyatlandırma katmanı SQL örnektir. Birden çok pod düzenine örnek olarak yüksek oranda kullanılabilir iş açısından kritik bir fiyatlandırma katmanı olan Azure SQL örnektir. Tek pod deseniyle dağıtılan veritabanı örneklerinin veri dayanıklılığını sağlamak için uzak, paylaşılan depolama sınıfı kullanmaları gerekir. Böylece, pod veya düğüm geri getirıldığında kalıcı bir birim için yeniden bağlanılabilir. Buna karşılık yüksek oranda kullanılabilir bir Azure SQL yönetilen örneği, verileri bir örnekten diğerine zaman uyumlu veya zaman uyumsuz olarak çoğaltmak için Always On Kullanılabilirlik Grupları kullanır. Özellikle verilerin zaman uyumlu olarak çoğaltılması durumunda verilerin her zaman birden çok kopyası (genellikle üç kopya) vardır. Bu nedenle, veriler ve günlük dosyaları için yerel depolama veya uzak, paylaşılan depolama sınıfları kullanılabilir. Yerel depolama alanı kullanılırsa, verilerin birden çok kopyası olduğu için veriler başarısız bir pod, düğüm veya depolama donanımı durumunda bile korunur. Bu esneklik sayesinde, daha iyi performans için yerel depolamayı kullanmayı seçebilirsiniz.
  • Veritabanı performansı büyük ölçüde, bir depolama cihazında I/O aktarım hızının bir işlevidir. Veritabanınız okumalarda veya yazmalarda yoğunsa, bu tür bir iş yükü için tasarlanmış donanıma sahip bir depolama sınıfı seçmeniz gerekir. Örneğin, veritabanınız çoğunlukla yazma için kullanılıyorsa, RAID 0 ile yerel depolamayı seçebilirsiniz. Veritabanınız çoğunlukla küçük miktarda "sıcak veri" okuması için kullanılıyorsa ancak genel olarak soğuk veri depolama hacmi varsa, katmanlı depolama kapasitesine sahip bir SAN cihazı seçebilirsiniz. Doğru depolama sınıfını seçmek, herhangi bir veritabanı için kullanabileceğiniz depolama türünü seçmekten farklı değildir.
  • Yerel depolama birimi sağlamayı kullanıyorsanız, disk girişlerinde sorun olmasını önlemek için veriler, günlükler ve yedeklemeler için sağlanan yerel birimlerin her biri farklı temel depolama cihazlarına giriş olduğundan emin olun. Ayrıca işletim sistemi ayrı disklere bağlanan bir bir birim üzerinde de olmalıdır. Bu temelde fiziksel donanımda bir veritabanı örneği için takip edilen kılavuzla aynıdır.
  • Verili bir örnekteki tüm veritabanları kalıcı bir birim talebi ve kalıcı birim paylaştığından, meşgul veritabanı örneklerini aynı veritabanı örneğinde birlikte bulundurmama konusundan emin olun. Mümkünse, meşgul veritabanlarını kendi veritabanı örneklerine ayırarak işletim sistemiyle ilgili bir sorundan kaçının. Ayrıca, genel işletim sistemi trafiğini birden çok düğüm arasında dağıtmak için veritabanı örneklerini ayrı düğümlere dağıtmak için düğüm etiketini kullanın. Sanallaştırma kullanıyorsanız, G/Ç trafiğini yalnızca düğüm düzeyinde değil aynı zamanda birleştirilmiş G/Ç etkinliğini de verilen bir fiziksel konakta tüm düğüm VM'leri tarafından gerçekleştirerek dağıtmayı göz önünde bulundurarak emin olun.

Depolama gereksinimlerini tahmin etmek

Durum bilgili veriler içeren her pod en az iki kalıcı birim kullanır: veriler için bir kalıcı birim ve günlükler için başka bir kalıcı birim. Aşağıdaki tabloda tek bir Veri Denetleyicisi, Azure SQL Yönetilen örneği, PostgreSQL için Azure Veritabanı örneği ve Azure PostgreSQL Hiper Ölçek örneği için gereken kalıcı birim sayısı listelenmiştir:

Kaynak Türü Durum durumlu podların sayısı Gerekli kalıcı birim sayısı
Veri Denetleyicisi 4 ( control controldb , , , logsdb metricsdb ) 4 * 2 = 8
Azure SQL Yönetilen Örnek 1 2
PostgreSQL için Azure Veritabanı örneği 1 2
Azure PostgreSQL Hiper Ölçek 1 + W (W = çalışan sayısı) 2 * (1 + W)

Aşağıdaki tabloda örnek dağıtım için gereken toplam kalıcı birim sayısı gösterilmiştir:

Kaynak Türü Örnek sayısı Gerekli kalıcı birim sayısı
Veri Denetleyicisi 1 4 * 2 = 8
Azure SQL Yönetilen Örnek 5 5 * 2 = 10
PostgreSQL için Azure Veritabanı örneği 5 5 * 2 = 10
Azure PostgreSQL Hiper Ölçek 2 (Çalışan sayısı = örnek başına 4) 2 * 2 * (1 + 4) = 20
Toplam Kalıcı birim sayısı 8 + 10 + 10 + 20 = 48

Bu hesaplama, Kubernetes kümenizin depolama alanını depolama alanı sağlamayı veya ortamı temel alarak planlamak için kullanılabilir. Örneğin, beş (5) düğümü olan bir Kubernetes kümesi için yerel depolama sağlama kullanılıyorsa, her düğümün üzerindeki örnek dağıtım için en az 10 kalıcı birim için depolama gerekir. Benzer şekilde, 10 veri Azure Kubernetes Service ekli olacak şekilde düğüm havuzu için uygun bir VM boyutu seçen beş (5) düğüme sahip bir Azure Kubernetes Service (AKS) kümesi sağlarken kritik öneme sahiptir. AKS düğümleri için depolama ihtiyaçlarına göre düğümlerin boyutu hakkında daha fazla ayrıntı burada bulunabilir.

Doğru depolama sınıfını seçme

Şirket içi ve uç siteler

Microsoft ve OEM, işletim sistemi ve Kubernetes iş ortaklarının veri hizmetleri için Azure Arc programı vardır. Bu program, müşterilere bir sertifikasyon testi araç setinde karşılaştırılabilir test sonuçları sağlar. Testler özellik uyumluluğunu, stres testi sonuçlarını ve performans ile ölçeklenebilirliği değerlendirir. Bu test sonuçlarının her biri kullanılan işletim sistemi, kullanılan Kubernetes dağıtımı, kullanılan HW, kullanılan CSI eklenti ve kullanılan depolama sınıflarını belirtecektir. Bu, müşterilerin gereksinimleri için en iyi depolama sınıfını, işletim sistemi, Kubernetes dağıtımını ve donanımı seçmelerine yardımcı olur. Bu program ve test sonuçları hakkında daha fazla bilgi için buraya bakın.

Genel bulut, yönetilen Kubernetes hizmetleri

Genel bulut tabanlı, yönetilen Kubernetes hizmetleri için aşağıdaki önerilerde bulunabilirsiniz:

Genel bulut hizmeti Öneri
Azure Kubernetes Service (AKS) Azure Kubernetes Service (AKS) iki tür depolama alanına sahip: Azure Dosyalar ve Azure Yönetilen Diskler. Her depolama türü iki fiyatlandırma/performans katmanına sahiptir: standart (HDD) ve premium (SSD). Bu nedenle AKS'de sağlanan dört depolama sınıfı azurefile (Azure Dosyalar katmanı), azurefile-premium (Azure Dosyalar premium katmanı), (Azure Diskleri standart katmanı) ve default managed-premium (Azure Diskleri premium katmanı) sınıftır. Varsayılan depolama sınıfıdır default (Azure Diskleri standart katmanı). Türler ve katmanlar arasında önemli fiyatlandırma farkları vardır ve bu farklar sizin kararınıza göre dikkate alınarak dikkate alındır. Yüksek performanslı gereksinimlere sahip üretim iş yükleri için, tüm depolama sınıfları managed-premium için kullanılması önerilir. Geliştirme ve test iş yükleri, kavram kanıtı vb. için maliyetin dikkate alınması gereken nokta, en azurefile düşük maliyetli seçenektir. Seçeneklerin dördü de Azure'da ağa bağlı depolama cihazları olduğu için uzak ve paylaşılan depolama gerektiren durumlar için kullanılabilir. AKS hakkında daha fazla bilgi Depolama.
AWS Elastic Kubernetes Service (EKS) Amazon'un Elastic Kubernetes Service hizmeti EBS CSI depolama sürücüsüne göre bir birincil depolama sınıfına sahip. Bu, üretim iş yükleri için önerilir. EKS kümesine eklen yeni bir depolama sürücüsü (EFS CSI depolama sürücüsü) var, ancak şu anda beta aşamasındadır ve değişebilir. AWS, bu depolama sürücüsünün üretim için desteklenese de, hala beta sürümünde olduğundan ve değişebilir olduğundan bu sürücünün kullanılması önerilmez. EBS depolama sınıfı varsayılandır ve olarak gp2 çağrılır. EKS hakkında daha fazla bilgi Depolama.
Google Kubernetes Altyapısı (GKE) Google Kubernetes Engine (GKE), GCE kalıcı diskleri için kullanılan adlı standard tek bir depolama sınıfına sahip. Tek seçenek bu, aynı zamanda varsayılan değerdir. GKE için doğrudan bağlı SSD'lerle kullanabileceğiniz bir yerel, statik birim sağlama olsa da, Google tarafından korunmayıcı veya destekçisi olarak kullanılması önerilmez. GKE depolama hakkında daha fazla bilgi okuyun.