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 tertentu yang Anda gunakan tergantung pada faktor-faktor seperti apakah Anda berjalan di layanan Kubernetes terkelola yang dihosting cloud atau penyedia OEM mana yang Anda gunakan untuk perangkat keras Anda.
Untuk melihat kelas penyimpanan yang dikonfigurasi di kluster Kubernetes, jalankan 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 array nilai yang dapat Anda atur saat penyebaran. Pengontrol data Azure Arc menerapkan ini ke instans database apa pun yang dibuatnya.
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 |
|---|---|
| OpenSearch | <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 Azure untuk membuat pengontrol data dalam mode terhubung langsung, templat penyebaran yang Anda pilih memiliki kelas penyimpanan yang telah ditentukan sebelumnya dalam templat atau Anda dapat memilih templat yang tidak memiliki kelas penyimpanan yang telah ditentukan sebelumnya. Jika templat Anda tidak menentukan kelas penyimpanan, portal akan memintanya. 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 --storage-class parameter atau -sc, kelas penyimpanan tersebut 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 Anda membuat instans menggunakan atau az sql mi-arc createaz postgres server-arc create, ada empat parameter yang dapat Anda gunakan 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 memiliki volume persisten terpisah untuk file data, log, dan cadangan. Ini berarti bahwa ada pemisahan I/O untuk setiap jenis file ini yang tunduk pada bagaimana penyedia volume menyediakan penyimpanan. Setiap instans database memiliki klaim volume persisten dan volume persistennya sendiri.
Jika ada beberapa database pada instans database tertentu, semua database menggunakan klaim volume persisten yang sama, volume persisten, dan kelas penyimpanan. Semua cadangan - baik cadangan log diferensial maupun cadangan penuh 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 penyedia volume penyimpanan lokal, pastikan bahwa volume lokal yang disediakan untuk data, log, dan cadangan masing-masing mendarat di perangkat penyimpanan yang mendasari 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 untuk mendistribusikan lalu lintas I/O tidak hanya pada tingkat node 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 menunjukkan 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 memberikan hasil pengujian yang sebanding dari toolkit pengujian sertifikasi. Pengujian mengevaluasi kompatibilitas fitur, hasil pengujian stres, serta performa dan skalabilitas. Hasil pengujian menunjukkan OS yang digunakan, distribusi Kubernetes yang digunakan, HW yang digunakan, add-on CSI yang digunakan, dan kelas penyimpanan yang digunakan. Ini membantu pelanggan memilih kelas penyimpanan terbaik, OS, distribusi Kubernetes, dan perangkat keras 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). Ada perbedaan harga yang substansial antara jenis dan tingkatan yang harus Anda pertimbangkan. 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) | Google Kubernetes Engine (GKE) hanya memiliki satu kelas penyimpanan yang disebut standard. Kelas ini 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. |