Konfigurasi Penyimpanan

Konsep penyimpanan Kubernetes

Kubernetes menyediakan lapisan abstraksi infrastruktur di atas tumpukan teknologi virtualisasi (opsional) dan perangkat keras yang mendasarinya. Cara Kubernetes mengabstraksi penyimpanan adalah melalui Kelas Penyimpanan . Saat Anda memprovisikan pod, Anda dapat menentukan kelas penyimpanan untuk setiap volume. Pada saat pod diprovisikan, provisioner kelas penyimpanan dipanggil untuk memprovisi penyimpanan, dan kemudian volume persisten dibuat pada penyimpanan yang diprovisi tersebut lalu pod dipasang ke volume persisten oleh klaim volume persisten .

Kubernetes menyediakan cara bagi penyedia infrastruktur penyimpanan untuk memasang driver (juga disebut "Addon") yang memperluas Kubernetes. Addon penyimpanan harus mematuhi standar Antarmuka Penyimpanan Kontainer . Terdapat puluhan addon yang dapat ditemukan dalam daftar driver CSI yang tidak definitif ini. Driver CSI mana yang Anda gunakan akan bergantung pada faktor-faktor seperti apakah Anda menjalankan layanan Kubernetes yang di-hosting di cloud atau penyedia OEM mana yang Anda gunakan untuk perangkat keras Anda.

Anda dapat melihat kelas penyimpanan mana yang dikonfigurasi di kluster Kubernetes dengan menjalankan perintah ini:

kubectl get storageclass

Contoh output dari kluster Azure Kubernetes Service (AKS):

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

Anda bisa mendapatkan detail tentang kelas penyimpanan dengan menjalankan perintah ini:

kubectl describe storageclass/<storage class name>

Contoh:

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>

Anda dapat melihat volume persisten dan klaim volume persisten yang saat ini diprovisikan dengan menjalankan perintah berikut:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Contoh memperlihatkan volume persisten:


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

Contoh menunjukkan klaim volume persisten:


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

Faktor yang perlu dipertimbangkan saat memilih konfigurasi penyimpanan Anda

Memilih kelas penyimpanan yang tepat penting untuk ketahanan dan performa data. Memilih kelas penyimpanan yang salah dapat membahayakan data Anda dari total kehilangan data jika terjadi kegagalan perangkat keras atau dapat mengakibatkan performa yang kurang optimal.

Secara umum terdapat dua jenis penyimpanan:

  • Penyimpanan lokal - penyimpanan yang diprovisikan pada hard drive lokal pada simpul tertentu. Penyimpanan semacam ini dapat ideal dalam hal performa, tetapi memerlukan desain khusus untuk redundansi data dengan mereplikasi data di beberapa simpul.
  • Penyimpanan jarak jauh, bersama - penyimpanan yang disediakan pada beberapa perangkat penyimpanan jarak jauh - misalnya, SAN, NAS, atau layanan penyimpanan cloud seperti EBS atau Azure Files. Jenis penyimpanan ini umumnya menyediakan redundansi data secara otomatis, tetapi tidak secepat penyimpanan lokal.

Kelas penyimpanan berbasis NFS

Bergantung pada konfigurasi server NFS dan penyedia kelas penyimpanan, Anda mungkin perlu menyetel supplementalGroups dalam konfigurasi pod untuk instans basis data, dan Anda mungkin perlu mengubah konfigurasi server NFS untuk menggunakan ID grup yang diteruskan oleh klien (bukan mencari ID grup di server menggunakan ID pengguna yang diteruskan). Konsultasikan dengan admin NFS Anda untuk menentukan apakah ini masalahnya.

Properti supplementalGroups mengambil larik nilai dan dapat ditetapkan sebagai bagian dari penyebaran pengontrol data Azure Arc dan akan digunakan oleh instans database yang dikonfigurasi oleh pengontrol data Azure Arc.

Untuk mengatur properti ini, jalankan perintah berikut:

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

Konfigurasi penyimpanan pengontrol data

Beberapa layanan di Azure Arc untuk layanan data bergantung pada konfigurasi untuk menggunakan penyimpanan bersama dan jarak jauh karena layanan tidak memiliki kemampuan untuk mereplikasi data. Layanan ini ditemukan dalam pengumpulan pod pengontrol data:

Layanan Klaim Volume Persisten
ElasticSearch <namespace>/logs-logsdb-0, <namespace>/data-logsdb-0
InfluxDB <namespace>/logs-metricsdb-0, <namespace>/data-metricsdb-0
Instans SQL Pengontrol <namespace>/logs-controldb, <namespace>/data-controldb
Layanan API Pengontrol <namespace>/data-controller

Pada saat pengontrol data diprovisikan, kelas penyimpanan yang akan digunakan untuk setiap volume persisten ini ditentukan dengan melewati parameter --storage-class | -sc ke perintah az arcdata dc create atau dengan mengatur kelas penyimpanan di file templat penyebaran control.json yang digunakan. Jika Anda menggunakan portal Microsoft Azure untuk membuat pengontrol data dalam mode yang terhubung langsung, templat penyebaran yang Anda pilih akan memiliki kelas penyimpanan yang telah ditentukan di templat. Selain itu, jika Anda memilih templat yang tidak memiliki kelas penyimpanan yang telah ditentukan sebelumnya, maka Anda akan diminta untuk sebuah kelas penyimpanan. Jika Anda menggunakan templat penyebaran kustom, maka Anda dapat menentukan kelas penyimpanan.

Templat penyebaran yang disediakan di luar kotak memiliki kelas penyimpanan default yang ditentukan yang sesuai untuk lingkungan target, tetapi dapat diganti selama penyebaran. Lihat langkah-langkah terperinci untuk membuat templat konfigurasi kustom untuk mengubah konfigurasi kelas penyimpanan untuk pod pengontrol data pada waktu penyebaran.

Jika Anda mengatur kelas penyimpanan menggunakan parameter --storage-class | -sc kelas penyimpanan akan digunakan untuk kelas penyimpanan log dan data. Jika Anda mengatur kelas penyimpanan dalam file templat penyebaran, Anda dapat menentukan kelas penyimpanan yang berbeda untuk log dan data.

Faktor penting yang perlu dipertimbangkan saat memilih kelas penyimpanan untuk pod pengontrol data:

  • Anda harus menggunakan kelas penyimpanan bersama dan jarak jauh untuk memastikan durabilitas data sehingga jika sebuah pod atau simpul mati ketika pod tersebut dihidupkan kembali dapat terhubung lagi ke volume persisten.
  • Data yang ditulis ke instans SQL pengontrol, DB metrik, dan DB log biasanya memiliki volume yang cukup rendah dan tidak sensitif terhadap latensi sehingga penyimpanan performa ultra cepat menjadi tidak penting. Jika Anda memiliki pengguna yang sering menggunakan antarmuka Grafana dan Kibana serta Anda memiliki jumlah instans database yang besar, pengguna Anda mungkin mendapat manfaat dari penyimpanan yang berkinerja lebih cepat.
  • Kapasitas penyimpanan yang diperlukan bervariasi dengan jumlah instans database yang telah Anda sebarkan karena log dan metrik dikumpulkan untuk setiap instans database. Data disimpan dalam log dan DB metrik selama dua (2) minggu sebelum dihapus menyeluruh.
  • Mengubah penyebaran pasca kelas penyimpanan merupakan hal yang sulit, tidak didokumentasikan, dan tidak didukung. Pastikan untuk memilih kelas penyimpanan dengan benar pada waktu penyebaran.

Catatan

Jika tidak ada kelas penyimpanan yang ditentukan, kelas penyimpanan default akan digunakan. Hanya ada satu kelas penyimpanan default per kluster Kubernetes. Anda dapat mengubah kelas penyimpanan default.

Konfigurasi penyimpanan instans database

Setiap instans database memiliki data, log, dan volume persisten cadangan. Kelas penyimpanan untuk volume persisten ini dapat ditentukan pada waktu penyebaran. Jika tidak ada kelas penyimpanan yang ditentukan, kelas penyimpanan default akan digunakan.

Saat membuat instans menggunakan az sql mi-arc create atau az postgres server-arc create, terdapat empat parameter yang dapat digunakan untuk mengatur kelas penyimpanan:

Nama parameter, nama pendek Digunakan untuk
--storage-class-data, -d Kelas penyimpanan untuk semua file data (.mdf, ndf). Jika tidak ditentukan, default ke kelas penyimpanan untuk pengontrol data.
--storage-class-logs, -g Kelas penyimpanan untuk semua file log. Jika tidak ditentukan, default ke kelas penyimpanan untuk pengontrol data.
--storage-class-data-logs Kelas penyimpanan untuk file log transaksi database. Jika tidak ditentukan, default ke kelas penyimpanan untuk pengontrol data.
--storage-class-backups Kelas penyimpanan untuk semua file cadangan. Jika tidak ditentukan, default ke kelas penyimpanan untuk data (--storage-class-data).

Gunakan kelas penyimpanan berkemampuan ReadWriteMany (RWX) untuk pencadangan. Pelajari selengkapnya tentang mode akses.

Peringatan

Jika Anda tidak menentukan kelas penyimpanan untuk cadangan, penyebaran menggunakan kelas penyimpanan yang ditentukan untuk data. Jika kelas penyimpanan ini tidak mampu RWX, pemulihan point-in-time mungkin tidak berfungsi seperti yang diinginkan.

Tabel di bawah ini mencantumkan jalur di dalam kontainer Azure SQL Managed Instance yang dipetakan ke volume persisten untuk data dan log:

Nama parameter, nama pendek Jalur di dalam mssql-miaa kontainer Deskripsi
--storage-class-data, -d /var/opt Berisi direktori untuk penginstalan mssql dan proses sistem lainnya. Direktori mssql berisi data default (termasuk log transaksi), log kesalahan & direktori cadangan
--storage-class-logs, -g /var/log Berisi direktori yang menyimpan output konsol (stderr, stdout), informasi pengelogan lainnya dari proses di dalam kontainer

Tabel di bawah ini mencantumkan jalur di dalam kontainer instans PostgreSQL yang dipetakan ke volume persisten untuk data dan log:

Nama parameter, nama pendek Jalur di dalam kontainer postgres Deskripsi
--storage-class-data, -d /var/opt/postgresql Berisi direktori data dan log untuk penginstalan postgres
--storage-class-logs, -g /var/log Berisi direktori yang menyimpan output konsol (stderr, stdout), informasi pengelogan lainnya dari proses di dalam kontainer

Setiap instans database akan memiliki volume persisten terpisah untuk file data, log, dan cadangan. Ini berarti bahwa akan ada pemisahan I/O untuk setiap jenis file ini tergantung pada bagaimana provisioner volume akan memprovisikan penyimpanan. Setiap instans database memiliki klaim volume persisten dan volume persistennya sendiri.

Jika terdapat beberapa database pada instans database tertentu, semua database akan menggunakan klaim volume persisten, volume persisten, dan kelas penyimpanan yang sama. Semua pencadangan - baik pencadangan log diferensial maupun pencadangan penuh akan menggunakan klaim volume persisten dan volume persisten yang sama. Klaim volume persisten untuk pod instans database ditunjukkan di bawah ini:

Instans Klaim Volume Persisten
Instans Terkelola Azure SQL <namespace>/logs-<instance name>-0, <namespace>/data-<instance name>-0
Instans Azure database for PostgreSQL <namespace>/logs--<instance name>-0, <namespace>/data--<instance name>-0
Azure PostgreSQL <namespace>/logs-<instance name>-<ordinal>, <namespace>/data-<instance name>-0

Faktor penting yang perlu dipertimbangkan saat memilih kelas penyimpanan untuk pod instans database:

  • Dimulai dengan rilis Februari 2022 dari layanan data Azure Arc, Anda perlu menentukan kelas penyimpanan berkemampuan ReadWriteMany (RWX) untuk cadangan. Pelajari selengkapnya tentang mode akses. Jika tidak ada kelas penyimpanan yang ditentukan untuk cadangan, kelas penyimpanan default di kubernetes digunakan dan jika ini tidak mampu RWX, penyebaran instans terkelola Azure SQL mungkin tidak berhasil.
  • Instans database dapat disebarkan dalam pola pod tunggal atau beberapa pola pod. Contoh pola pod tunggal adalah instans terkelola Azure SQL tingkat harga tujuan umum. Contoh dari beberapa pola pod adalah tingkat harga kritis bisnis yang sangat tersedia instans terkelola Azure SQL. Instans database yang disebarkan dengan pola pod tunggal harus menggunakan kelas penyimpanan bersama jarak jauh untuk memastikan durabilitas data dan agar jika pod atau node mati, saat pod dimunculkan kembali, pod tersebut dapat terhubung kembali ke volume yang persisten. Sebaliknya, instans terkelola Azure SQL yang sangat tersedia menggunakan Grup Ketersediaan Always On untuk mereplikasi data dari satu instans ke instans lainnya baik secara sinkron maupun asinkron. Terutama dalam kasus di mana data direplikasi secara sinkron, selalu ada beberapa salinan data - biasanya tiga salinan. Karena itu, dimungkinkan untuk menggunakan penyimpanan lokal atau jarak jauh, kelas penyimpanan bersama untuk data dan file log. Jika menggunakan penyimpanan lokal, data akan tetap tersimpan bahkan dalam kasus pod, node, atau perangkat keras penyimpanan yang gagal karena ada banyak salinan data. Mengingat fleksibilitas ini, Anda dapat memilih untuk menggunakan penyimpanan lokal untuk performa yang lebih baik.
  • Performa database sebagian besar merupakan fungsi throughput I/O dari perangkat penyimpanan tertentu. Jika database Anda melakukan operasi baca dan tulis yang berat, maka Anda harus memilih kelas penyimpanan dengan perangkat keras yang dirancang untuk jenis beban kerja tersebut. Misalnya, jika database Anda sebagian besar digunakan untuk menulis, Anda dapat memilih penyimpanan lokal dengan RAID 0. Jika database Anda sebagian besar digunakan untuk membaca sejumlah kecil "data panas", tetapi ada volume penyimpanan keseluruhan yang besar dari data dingin, Anda dapat memilih perangkat SAN yang mampu melakukan penyimpanan berjenjang. Memilih kelas penyimpanan yang tepat tidak berbeda dengan memilih jenis penyimpanan yang akan Anda gunakan untuk database apa pun.
  • Jika Anda menggunakan provisioner volume penyimpanan lokal, pastikan bahwa volume lokal yang diprovisikan untuk data, log, dan cadangan masing-masing ditempatkan di perangkat penyimpanan dasar yang berbeda untuk menghindari pertikaian pada I/O disk. OS juga harus berada pada volume yang dipasang ke disk terpisah. Ini pada dasarnya merupakan panduan yang sama seperti yang akan diikuti untuk instans database pada perangkat keras fisik.
  • Karena semua database pada instans tertentu berbagi klaim volume persisten dan volume persisten, pastikan untuk tidak menempatkan instans database yang sibuk pada instans database yang sama. Jika memungkinkan, pisahkan database sibuk ke instans database mereka sendiri untuk menghindari pertikaian I/O. Selanjutnya, gunakan penargetan label simpul untuk menempatkan instans database ke simpul terpisah sehingga dapat mendistribusikan keseluruhan lalu lintas I/O di beberapa simpul. Jika Anda menggunakan virtualisasi, pastikan untuk mempertimbangkan mendistribusikan lalu lintas I/O tidak hanya pada tingkat simpul, tetapi juga aktivitas I/O gabungan yang terjadi oleh semua VM simpul pada host fisik tertentu.

Memperkirakan persyaratan penyimpanan

Setiap pod yang berisi data stateful menggunakan setidaknya dua volume persisten - satu volume persisten untuk data dan volume persisten lainnya untuk log. Tabel di bawah ini mencantumkan jumlah volume persisten yang diperlukan untuk satu Pengontrol Data, Azure SQL Managed instance, instans Azure Database for PostgreSQL, dan instans Azure PostgreSQL HyperScale:

Jenis Sumber Daya Jumlah pod stateful Jumlah volume persisten yang diperlukan
Pengontrol Data 4 (control, controldb, logsdb, metricsdb) 4 * 2 = 8
Instans Terkelola Azure SQL 1 2
Azure PostgreSQL 1 2

Tabel di bawah ini memperlihatkan jumlah total volume persisten yang diperlukan untuk penyebaran sampel:

Jenis Sumber Daya Jumlah instans Jumlah volume persisten yang diperlukan
Pengontrol Data 1 4 * 2 = 8
Instans Terkelola Azure SQL 5 5 * 2 = 10
Azure PostgreSQL 5 5 * 2 = 10
Jumlah Total volume persisten 8 + 10 + 10 = 28

Perhitungan ini dapat digunakan untuk merencanakan penyimpanan untuk kluster Kubernetes Anda berdasarkan pada provisioner penyimpanan atau lingkungan. Misalnya, jika provisioner penyimpanan lokal digunakan untuk kluster Kubernetes dengan lima (5) simpul sehingga untuk penyebaran sampel di atas setiap simpul memerlukan setidaknya penyimpanan untuk 10 volume persisten. Demikian pula, saat memprovisikan kluster Azure Kubernetes Service (AKS) dengan lima (5) simpul, memilih ukuran VM yang sesuai untuk kumpulan simpul sehingga 10 disk data dapat dilampirkan menjadi sangat penting. Rincian lebih lanjut tentang cara mengukur simpul untuk kebutuhan penyimpanan untuk simpul AKS dapat ditemukan di sini.

Memilih kelas penyimpanan yang tepat

Situs lokal dan tepi

Microsoft dan mitranya dari OEM, OS, dan Kube memiliki program validasi untuk layanan data Azure Arc. Program ini akan memberikan pelanggan hasil pengujian yang sebanding dari toolkit pengujian sertifikasi. Pengujian akan mengevaluasi kompatibilitas fitur, hasil pengujian stres, serta performa dan skalabilitas. Masing-masing hasil pengujian ini akan menunjukkan OS yang digunakan, distribusi Kubernetes yang digunakan, HW yang digunakan, addon CSI yang digunakan, dan kelas penyimpanan yang digunakan. Hal ini akan membantu pelanggan memilih kelas penyimpanan, OS, distribusi Kube, dan perangkat keras terbaik untuk kebutuhan mereka. Informasi lebih lanjut tentang program ini dan hasil tes dapat ditemukan di sini.

Cloud publik, layanan Kubernetes terkelola

Untuk layanan Kubernetes terkelola berbasis cloud publik, kami dapat membuat rekomendasi berikut:

Layanan cloud publik Rekomendasi
Azure Kubernetes Service (AKS) Azure Kubernetes Service (AKS) memiliki dua jenis penyimpanan - Azure Files dan Azure Managed Disks. Setiap jenis penyimpanan memiliki dua tingkat harga/performa - standar (HDD) dan premium (SSD). Dengan demikian, empat kelas penyimpanan yang disediakan dalam AKS adalah azurefile (Azure Files tingkat standar), azurefile-premium (Azure Files tingkat premium), default (Azure Disks tingkat standar), dan managed-premium (Azure Disks tingkat premium). Kelas penyimpanan default adalah default (tingkat standar Azure Disks). Terdapat perbedaan harga yang cukup besar antara jenis dan tingkatan yang harus diperhitungkan dalam keputusan Anda. Untuk beban kerja produksi dengan persyaratan berperforma tinggi, kami merekomendasikan untuk menggunakan managed-premium untuk semua kelas penyimpanan. Untuk beban kerja dev/test, bukti konsep, dll. dengan biaya merupakan pertimbangan, maka azurefile adalah pilihan yang paling murah. Keempat opsi tersebut dapat digunakan untuk situasi yang membutuhkan penyimpanan bersama dan jarak jauh karena semuanya adalah perangkat penyimpanan yang terpasang pada jaringan di Azure. Baca selengkapnya tentang Penyimpanan AKS.
Layanan Kubernetes Elastis (EKS) AWS Layanan Kubernetes Elastis Amazon memiliki satu kelas penyimpanan utama - berdasarkan pada driver penyimpanan CSI EBS. Ini direkomendasikan untuk beban kerja produksi. Terdapat driver penyimpanan baru - driver penyimpanan EFS CSI - yang dapat ditambahkan ke kluster EKS, tetapi saat ini dalam tahap beta dan dapat berubah. Meskipun AWS mengatakan bahwa driver penyimpanan ini didukung untuk produksi, kami tidak menyarankan untuk menggunakannya karena masih dalam versi beta dan dapat berubah. Kelas penyimpanan EBS merupakan default dan disebut gp2. Baca selengkapnya tentang Penyimpanan EKS.
Mesin Kubernetes Google (GKE) Mesin Kubernetes Google (GKE) hanya memiliki satu kelas penyimpanan yang disebut standard yang digunakan untuk disk persisten GCE. Menjadi satu-satunya, itu juga merupakan default. Meskipun terdapat provisioner volume statis dan lokal untuk GKE yang dapat Anda gunakan dengan SSD yang terpasang langsung, kami tidak menyarankan menggunakannya karena tidak dikelola atau didukung oleh Google. Baca selengkapnya tentang penyimpanan GKE.