Depolama Yapılandırması

Makale
03/16/2023

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 depolamayı soyutlama yöntemi Depolama Sınıfları'dır. Bir pod sağlarken, her birim için bir depolama sınıfı belirtebilirsiniz. Pod sağlandığında, depolama sınıfı sağlama aracı depolamayı sağlamak için çağrılır ve sağlanan depolamada kalıcı bir birim oluşturulur ve pod kalıcı birim talebiyle kalıcı bir birime bağlanır.

Kubernetes, depolama altyapısı sağlayıcılarının Kubernetes'i genişleten sürücüleri ("Eklentiler" olarak da adlandırılır) takması için bir yol sağlar. Depolama eklentilerin Kapsayıcı Depolama Arabirimi standardı. Bu kesin olmayan CSI sürücüleri listesinde bulunabilen onlarca eklenti vardır. Kullandığınız belirli CSI sürücüsü, bulutta barındırılan, yönetilen bir Kubernetes hizmetinde mi yoksa donanımınız için hangi OEM sağlayıcısını kullandığınız gibi faktörlere bağlıdır.

Kubernetes kümenizde yapılandırılan depolama sınıflarını görüntülemek için şu komutu çalıştırın:

kubectl get storageclass

Azure Kubernetes Service (AKS) kümesinden ö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 depolama sınıfıyla ilgili ayrıntıları alabilirsiniz:

kubectl describe storageclass/<storage class name>

Örneğin:

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>

Şu anda sağlanan kalıcı birimleri ve kalıcı birim taleplerini aşağıdaki komutları çalıştırarak 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 dikkate alınması gereken faktörler

Doğru depolama sınıfını seçmek, veri dayanıklılığı ve performansı açısından önemlidir. Yanlış depolama sınıfını seçmek, donanım arızası durumunda verilerinizin toplam veri kaybı riskini alabilir veya en iyi performansın daha düşük olmasına neden olabilir.

Genellikle iki tür depolama alanı vardır:

Yerel depolama - belirli bir düğümdeki yerel sabit sürücülerde sağlanan depolama alanı. Bu tür depolama, performans açısından ideal olabilir, ancak verileri birden çok düğüm arasında çoğaltarak veri yedekliliği için özel olarak tasarlamayı gerektirir.
Uzak, paylaşılan depolama - SAN, NAS veya EBS veya Azure Dosyalar gibi bir bulut depolama hizmeti gibi bir uzak depolama cihazında sağlanan depolama alanı. Bu tür bir depolama genellikle otomatik olarak veri yedekliliği sağlar, ancak yerel depolama alanı kadar hızlı değildir.

NFS tabanlı depolama sınıfları

NFS sunucunuzun ve depolama sınıfı sağlama sağlayıcınızın yapılandırmasına bağlı olarak, veritabanı örnekleri için pod yapılandırmalarında öğesini ayarlamanız supplementalGroups gerekebilir ve NFS sunucu yapılandırmasını istemci tarafından geçirilen grup kimliklerini kullanacak şekilde değiştirmeniz gerekebilir (geçirilen kullanıcı kimliğini kullanarak sunucuda grup kimliklerine bakmanın aksine). Durumun bu olup olmadığını belirlemek için NFS yöneticinize başvurun.

supplementalGroups özelliği, dağıtımda ayarlayabileceğiniz bir değer dizisi alır. Azure Arc veri denetleyicisi bunları oluşturduğu tüm veritabanı örneklerine uygular.

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'taki bazı hizmetler, hizmetlerin verileri çoğaltma özelliği olmadığından uzak, paylaşılan depolama kullanacak şekilde yapılandırılmasına bağlıdır. Bu hizmetler veri denetleyicisi podlarının koleksiyonunda bulunur:

Hizmet	Kalıcı Birim Talepleri
OpenSearch	`<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'si hizmeti	`<namespace>/data-controller`

Veri denetleyicisi sağlandığında, bu kalıcı birimlerin her biri için kullanılacak depolama sınıfı --storage-class | geçirilerek belirtilir komutu için az arcdata dc create -sc parametresi veya kullanılan control.json dağıtım şablonu dosyasında depolama sınıflarını ayarlayarak. Veri denetleyicisini doğrudan bağlı modda oluşturmak için Azure portalını kullanıyorsanız, seçtiğiniz dağıtım şablonunun şablonda önceden tanımlanmış depolama sınıfı vardır veya önceden tanımlanmış depolama sınıfı olmayan bir şablon seçebilirsiniz. Şablonunuz bir depolama sınıfı tanımlamıyorsa portal sizden bir tane ister. Özel dağıtım şablonu kullanıyorsanız depolama sınıfını belirtebilirsiniz.

Kullanıma hazır olarak sağlanan dağıtım şablonları, hedef ortam için uygun olan varsayılan bir depolama sınıfına sahiptir, ancak dağıtım sırasında geçersiz kılınabilir. Dağıtım zamanında veri denetleyicisi podlarının depolama sınıfı yapılandırmasını değiştirmek üzere özel yapılandırma şablonları oluşturmaya yönelik ayrıntılı adımlara bakın.

veya -scparametresini --storage-class kullanarak depolama sınıfını ayarlarsanız, bu depolama sınıfı hem günlük hem de veri depolama sınıfları için kullanılı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 podları için bir depolama sınıfı seçerken dikkate alınması gereken önemli faktörler:

Veri dayanıklılığını sağlamak için uzak, paylaşılan bir depolama sınıfı kullanmanız gerekir; böylece bir pod veya düğüm ölürse pod yeniden açıldığında kalıcı birime yeniden bağlanabilir.
Denetleyici SQL örneğine, ölçüm veritabanına ve günlük veritabanına yazılan veriler genellikle oldukça düşük hacimli olur ve gecikme süresine duyarlı değildir, bu nedenle ultra hızlı performans depolama kritik değildir. Grafana ve Kibana arabirimlerini sık kullanan kullanıcılarınız varsa ve çok sayıda veritabanı örneğiniz varsa, kullanıcılarınız daha hızlı performans gösteren depolama alanından yararlanabilir.
Günlükler ve ölçümler her veritabanı örneği için toplandığından, gerekli 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çümler db'sinde tutulur.
Dağıtım sonrasında depolama sınıfını değiştirmek zordur, belgelenmez ve desteklenmez. Dağıtım zamanında depolama sınıfını doğru seçtiğinizden emin olun.

Dekont

Hiçbir depolama sınıfı belirtilmezse, varsayılan depolama sınıfı kullanılır. Kubernetes kümesi başına 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ğinde veriler, günlükler ve yedekleme kalıcı birimleri vardır. Bu kalıcı birimlerin depolama sınıfları dağıtım zamanında belirtilebilir. Hiçbir depolama sınıfı belirtilmezse varsayılan depolama sınıfı kullanılır.

veya az postgres server-arc createkullanarak az sql mi-arc create bir örnek oluşturduğunuzda, depolama sınıflarını ayarlamak için kullanabileceğiniz dört parametre vardır:

Parametre adı, kısa ad	Kullanıldığı yerler
`--storage-class-data`, `-d`	Tüm veri dosyaları (.mdf, ndf) için Depolama sınıfı. Belirtilmezse, veri denetleyicisi için varsayılan olarak depolama sınıfını kullanır.
`--storage-class-logs`, `-g`	Tüm günlük dosyaları için Depolama sınıfı. Belirtilmezse, veri denetleyicisi için varsayılan olarak depolama sınıfını kullanır.
`--storage-class-data-logs`	Veritabanı işlem günlüğü dosyaları için Depolama sınıfı. Belirtilmezse, veri denetleyicisi için varsayılan olarak depolama sınıfını kullanır.
`--storage-class-backups`	Tüm yedekleme dosyaları için Depolama sınıfı. Belirtilmezse, varsayılan olarak veriler için depolama sınıfını ()`--storage-class-data` kullanır. Yedeklemeler için ReadWriteMany (RWX) özellikli bir depolama sınıfı kullanın. Erişim modları hakkında daha fazla bilgi edinin.

Uyarı

Yedeklemeler için bir depolama sınıfı belirtmezseniz dağıtım, veriler için belirtilen depolama sınıfını kullanır. Bu depolama sınıfı RWX özellikli değilse, belirli bir noktaya geri yükleme istenen şekilde çalışmayabilir.

Aşağıdaki tabloda, veriler ve günlükler için kalıcı birime eşlenen Azure SQL Yönetilen Örneği kapsayıcısının içindeki yollar listelenmiştir:

Parametre adı, kısa ad	Kapsayıcı içindeki `mssql-miaa` yol	Açıklama
`--storage-class-data`, `-d`	/var/opt	mssql yüklemesi ve diğer sistem işlemleri için dizinleri içerir. mssql dizini varsayılan verileri (işlem günlükleri dahil), hata günlüğü ve yedekleme dizinlerini içerir
`--storage-class-logs`, `-g`	/var/log	Konsol çıkışını (stderr, stdout) depolayan dizinleri, kapsayıcı içindeki işlemlerin diğer günlük bilgilerini içerir

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

Parametre adı, kısa ad	Postgres kapsayıcısı içindeki yol	Açıklama
`--storage-class-data`, `-d`	/var/opt/postgresql	Postgres yüklemesi için veri ve günlük dizinlerini içerir
`--storage-class-logs`, `-g`	/var/log	Konsol çıkışını (stderr, stdout) depolayan dizinleri, kapsayıcı içindeki işlemlerin diğer günlük bilgilerini içerir

Her veritabanı örneğinde veri dosyaları, günlükler ve yedeklemeler için ayrı bir kalıcı birim vardır. Bu, birim sağlamanın depolamayı nasıl sağladığına bağlı olarak bu tür dosyaların her biri için G/Ç ayrımı olduğu 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 değişiklik günlüğü yedeklemeleri hem de tam yedeklemeler aynı kalıcı birim talebi ve kalıcı birim kullanır. Veritabanı örneği podları 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	`<namespace>/logs-<instance name>-<ordinal>`, `<namespace>/data-<instance name>-0`

Veritabanı örneği podları için bir depolama sınıfı seçerken dikkate alınması gereken önemli faktörler:

Azure Arc veri hizmetlerinin Şubat 2022 sürümünden itibaren yedeklemeler için ReadWriteMany (RWX) özellikli bir depolama sınıfı belirtmeniz gerekir. Erişim modları hakkında daha fazla bilgi edinin. Yedeklemeler için depolama sınıfı belirtilmezse kubernetes'teki varsayılan depolama sınıfı kullanılır ve bu RWX özellikli değilse Azure SQL yönetilen örneği dağıtımı başarılı olmayabilir.
Veritabanı örnekleri tek bir pod deseninde veya birden çok pod deseninde dağıtılabilir. Tek bir pod düzenine örnek olarak Genel Amaçlı fiyatlandırma katmanı Azure SQL yönetilen örneği gösterilebilir. Birden çok pod düzenine örnek olarak yüksek oranda kullanılabilir İş Açısından Kritik fiyatlandırma katmanı Azure SQL yönetilen örneği gösterilebilir. Tek pod düzeniyle dağıtılan veritabanı örnekleri, veri dayanıklılığını sağlamak için uzak, paylaşılan bir depolama sınıfı kullanmalıdır ve böylece bir pod veya düğüm ölürse pod yeniden açıldığında kalıcı birime yeniden bağlanabilir. 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ını kullanır. Özellikle de 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ını kullanmak mümkündür. Yerel depolama alanı kullanıyorsanız, verilerin birden çok kopyası olduğundan veriler başarısız pod, düğüm veya depolama donanımı durumunda bile korunur. Bu esneklik göz önüne alındığında, daha iyi performans için yerel depolamayı kullanmayı seçebilirsiniz.
Veritabanı performansı büyük ölçüde belirli bir depolama cihazının G/Ç aktarım hızının bir işlevidir. Veritabanınız okuma işlemleri üzerinde ağırsa veya yazma işlemleri 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şlemleri için kullanılıyorsa, RAID 0 ile yerel depolamayı seçebilirsiniz. Veritabanınız çoğunlukla az miktarda "sık erişimli veri" okuması için kullanılıyorsa ancak genel olarak büyük miktarda soğuk veri depolanıyorsa katmanlı depolama yapabilen bir SAN cihazı seçebilirsiniz. Doğru depolama sınıfını seçmek, herhangi bir veritabanı için kullanacağınız depolama türünü seçmekten farklı değildir.
Yerel bir depolama birimi sağlama aracı kullanıyorsanız, disk G/Ç'sinde çakışmayı önlemek için veriler, günlükler ve yedeklemeler için sağlanan yerel birimlerin her birinin farklı temel alınan depolama cihazlarına giriş olduğundan emin olun. İşletim sistemi ayrıca ayrı disklere bağlı bir birimde de olmalıdır. Bu temelde fiziksel donanımdaki bir veritabanı örneği için izlenecek kılavuzla aynıdır.
Belirli bir örnekteki tüm veritabanları kalıcı birim talebi ve kalıcı birim paylaştığından, aynı veritabanı örneğindeki meşgul veritabanı örneklerini birlikte kullanmamaya dikkat edin. Mümkünse, G/Ç çekişmesi önlemek için meşgul veritabanlarını kendi veritabanı örneklerine ayırın. Ayrıca, genel G/Ç trafiğini birden çok düğüme dağıtmak için veritabanı örneklerini ayrı düğümlere almak için düğüm etiketi hedeflemesini kullanın. Sanallaştırma kullanıyorsanız, G/Ç trafiğini yalnızca düğüm düzeyinde değil, aynı zamanda belirli bir fiziksel konak üzerindeki tüm düğüm VM'leri tarafından gerçekleşen birleştirilmiş G/Ç etkinliğini dağıtmayı da göz önünde bulundurun.

Depolama gereksinimlerini tahmin etme

Durum bilgisi olan 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 bilgisi olan pod 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
Azure PostgreSQL	1	2

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

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
Azure PostgreSQL	5	5 * 2 = 10
Toplam Kalıcı birim sayısı		8 + 10 + 10 = 28

Bu hesaplama, Kubernetes kümeniz için depolama alanını depolamayı hazırlayana veya ortama göre planlamak için kullanılabilir. Örneğin, beş (5) düğüme sahip 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 diskinin eklenebileceği ş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ğlama kritik önem taşır. AKS düğümleri için depolama gereksinimleri için düğümlerin nasıl boyutlandırılacağı hakkında daha fazla ayrıntıya buradan ulaşabilirsiniz.

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

Şirket içi ve uç siteler

Microsoft ve OEM, OS ve Kubernetes iş ortaklarının Azure Arc veri hizmetleri için bir doğrulama programı vardır. Bu program, bir sertifikasyon testi araç setinden 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. Test sonuçları kullanılan işletim sistemini, kullanılan Kubernetes dağıtımını, kullanılan HW'yi, kullanılan CSI eklentisini ve kullanılan depolama sınıflarını gösterir. Bu, müşterilerin gereksinimleri için en iyi depolama sınıfını, işletim sistemini, Kubernetes dağıtımını ve donanımı seçmesine yardımcı olur. Bu program ve test sonuçları hakkında daha fazla bilgiyi burada bulabilirsiniz.

Genel bulut, yönetilen Kubernetes hizmetleri

Genel bulut tabanlı, yönetilen Kubernetes hizmetleri için aşağıdaki önerileri sağlayabiliriz:

Genel bulut hizmeti	Öneri
Azure Kubernetes Service (AKS)	Azure Kubernetes Service (AKS) iki tür depolama alanına sahiptir: Azure Dosyalar ve Azure Yönetilen Diskler. Her depolama türünün iki fiyatlandırma/performans katmanı vardır: standart (HDD) ve premium (SSD). Bu nedenle AKS'de sağlanan dört depolama sınıfı (standart katman Azure Dosyalar), `azurefile-premium` (Azure Dosyalar premium katman), `default` (Azure Diskler standart katmanı) ve `managed-premium` (Azure Diskler premium katmanı) şeklindedir `azurefile` . Varsayılan depolama sınıfıdır `default` (Azure Diskler standart katmanı). Dikkate almanız gereken türler ve katmanlar arasında önemli fiyatlandırma farklılıkları vardır. Yüksek performanslı gereksinimlere sahip üretim iş yükleri için, tüm depolama sınıfları için kullanılmasını `managed-premium` öneririz. Geliştirme/test iş yükleri, kavram kanıtı vb. için maliyetin göz önünde bulundurulacağı `azurefile` durumlarda en düşük maliyetli seçenektir. Tüm seçenekler, Azure'daki ağa bağlı depolama cihazları olduğundan uzak, paylaşılan depolama gerektiren durumlar için kullanılabilir. AKS Depolama hakkında daha fazla bilgi edinin.
AWS Elastic Kubernetes Service (EKS)	Amazon Elastic Kubernetes Service,EBS CSI depolama sürücüsünü temel alan bir birincil depolama sınıfına sahiptir. Bu, üretim iş yükleri için önerilir. EKS kümesine eklenebilen yeni bir depolama sürücüsü ( EFS CSI depolama sürücüsü ) vardır, ancak şu anda beta aşamasındadır ve değiştirilebilir. AWS bu depolama sürücüsünün üretim için desteklendiğini belirtse de, hala beta sürümünde olduğundan ve değiştirilebilir olduğundan bunu kullanmanızı önermeyiz. EBS depolama sınıfı varsayılandır ve olarak adlandırılır `gp2`. EKS Depolama hakkında daha fazla bilgi edinin.
Google Kubernetes Engine (GKE)	Google Kubernetes Engine (GKE) adlı `standard`tek bir depolama sınıfına sahiptir. Bu sınıf GCE kalıcı diskleri için kullanılır. Tek olan, aynı zamanda varsayılandır. GKE için doğrudan bağlı SSD'lerle kullanabileceğiniz yerel, statik birim sağlama aracı olsa da, Google tarafından korunmadığından veya desteklenmediğinden bunu kullanmanızı önermeyiz. GKE depolama hakkında daha fazla bilgi edinin.