Opsi penyimpanan untuk aplikasi di Azure Kubernetes Service (AKS)

Aplikasi yang berjalan di Azure Kubernetes Service (AKS) mungkin perlu menyimpan dan mengambil data. Meskipun beberapa beban kerja aplikasi dapat menggunakan penyimpanan lokal dan cepat pada node yang tidak diperlukan dan dikosongkan, yang lain memerlukan penyimpanan yang bertahan pada volume data yang lebih teratur dalam platform Azure.

Beberapa pod mungkin perlu:

• Membagi volume data yang sama.
• Menghubungkan kembali volume data jika Pod dijadwalkan ulang pada node yang berbeda.

Anda mungkin juga perlu mengumpulkan dan menyimpan data sensitif atau informasi konfigurasi aplikasi ke dalam pod.

Artikel ini memperkenalkan konsep inti yang menyediakan penyimpanan untuk aplikasi Anda di AKS:

• Volume
• Volume Persisten
• Kelas penyimpanan
• Permintaan Persistent Volume

Ukuran disk OS default di AKS

Disk OS sementara

Jika Anda memilih SKU komputer virtual (VM) yang mendukung disk OS Sementara tetapi tidak menentukan ukuran disk OS, AKS secara default menyediakan disk OS Sementara dengan ukuran yang diskalakan sesuai dengan total penyimpanan sementara SKU VM selama temp setidaknya 128 GiB. Misalnya, Standard_D8ds_v5 SKU dengan ukuran disk sementara 300 GiB menerima disk OS Sementara 300 GiB secara default jika parameter disk tidak ditentukan.

Jika Anda ingin menggunakan penyimpanan sementara SKU VM, Anda perlu menentukan ukuran disk OS selama penyebaran; jika tidak, penyimpanan tersebut akan digunakan secara otomatis.

Penting

Ukuran disk OS Sementara default hanya digunakan pada kluster atau kumpulan simpul baru di mana disk OS Sementara didukung dan ukuran disk OS default tidak ditentukan. Ukuran disk OS default dapat memengaruhi performa atau biaya kluster Anda. Anda tidak dapat mengubah ukuran disk OS setelah pembuatan kluster atau kumpulan simpul. Ukuran Ephemeral default ini memengaruhi kluster atau kumpulan simpul yang dibuat pada Maret 2025 atau yang lebih baru.

Disk OS terkelola

Saat Anda membuat kluster baru atau menambahkan kumpulan simpul baru ke kluster yang ada, angka untuk vCPU menentukan ukuran disk OS secara default. Jumlah vCPU didasarkan pada SKU VM. Tabel berikut mencantumkan ukuran disk OS default untuk setiap SKU VM:

Core SKU VM (vCPU)	Tingkat disk OS default	IOPS yang diprovisikan	Throughput yang disediakan (Mbps)
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2.300	150
64+	P30/1024G	lima ribu	200

Penting

Ukuran disk OS Terkelola default hanya digunakan pada kluster atau kumpulan node baru ketika disk OS Ephemeral tidak didukung dan ukuran disk OS default tidak ditentukan. Ukuran disk OS default dapat memengaruhi performa atau biaya kluster Anda. Anda tidak dapat mengubah ukuran disk OS setelah pembuatan kluster atau kumpulan simpul. Kami merekomendasikan ukuran disk minimum 512 G jika disk OS Ephemeral tidak dapat digunakan. Ukuran terkelola default ini memengaruhi kluster atau kumpulan simpul yang dibuat pada Juli 2022 atau yang lebih baru.

Disk OS Ephemeral di AKS

Secara default, Azure secara otomatis mereplikasi disk sistem operasi untuk komputer virtual ke Azure Storage untuk menghindari kehilangan data saat VM direlokasi ke host lain. Namun, karena kontainer tidak dirancang untuk mempertahankan status lokal, perilaku ini menawarkan nilai terbatas sambil memberikan beberapa kelemahan. Kelemahan ini termasuk, tetapi tidak terbatas pada, provisi simpul yang lebih lambat dan latensi baca/tulis yang lebih tinggi.

Sebaliknya, disk OS Efemer hanya disimpan di mesin host, persis seperti disk sementara. Dengan konfigurasi ini, Anda mendapatkan latensi baca/tulis yang lebih rendah dengan penskalaan simpul dan peningkatan kluster yang lebih cepat. Oleh karena itu, kami sangat menyarankan untuk menggunakan disk OS Sementara jika memungkinkan.

Catatan

Saat Anda tidak secara eksplisit meminta disk terkelola Azure untuk OS, AKS menggunakan OS efemeral secara default jika memungkinkan untuk konfigurasi kumpulan simpul tertentu.

Anda dapat menemukan persyaratan ukuran dan rekomendasi untuk disk OS ephemeral dalam dokumentasi Azure VM. Ingatlah pertimbangan berikut saat menggunakan disk OS ephemeral:

Generasi terbaru seri VM tidak memiliki cache khusus, hanya penyimpanan sementara. Misalnya, jika Anda memilih ukuran VM Standard_E2bds_v5 dengan ukuran disk OS default 100 GiB, ia mendukung disk OS sementara, tetapi hanya memiliki 75 GiB penyimpanan sementara. Konfigurasi ini default ke disk OS terkelola jika Anda tidak secara eksplisit menentukannya. Jika Anda meminta disk OS ephemeral, Anda akan menerima kesalahan validasi.

• Jika Anda meminta ukuran VM Standard_E2bds_v5 yang sama dengan disk OS 60 GiB, konfigurasi ini secara default menggunakan disk OS ephemeral. Ukuran 60 GiB yang diminta lebih kecil dari penyimpanan sementara maksimum 75 GiB.
• Jika Anda memilih SKU Standard_E4bds_v5 dengan disk OS 100 GiB, ukuran VM ini mendukung OS sementara dan memiliki 150 GiB penyimpanan sementara. Jika Anda tidak menentukan jenis disk OS, Azure menyediakan disk OS ephemeral ke kumpulan simpul secara default.

VM generasi sebelumnya dan ukuran yang telah dihentikan memiliki ruang cache khusus selain penyimpanan disk sementara. Namun, ruang disk cache digunakan saat mengevaluasi penempatan sementara alih-alih penyimpanan sementara.

Kunci yang dikelola pelanggan

Anda dapat mengelola enkripsi untuk disk OS ephemeral Anda dengan kunci Anda sendiri pada kluster AKS. Untuk informasi selengkapnya, lihat Gunakan Kunci yang Dikelola Pelanggan dengan disk Azure di AKS.

Disk data sementara NVMe

Disk data NVMe Ephemeral menyediakan penyimpanan latensi rendah berkinerja tinggi yang langsung dilampirkan ke host fisik Azure VM Anda. Disk ini sangat ideal untuk beban kerja yang memerlukan penyimpanan sementara yang cepat (penyimpanan yang tidak persisten dan terpasang host yang hilang jika VM dibatalkan alokasinya) untuk pemrosesan data menengah, seperti penembolokan, ruang goresan, atau analitik throughput tinggi.

Disk data NVMe sementara awalnya hanya tersedia pada VM seri L Azure VM, seri E, dan VM GPU. Dengan diperkenalnya generasi Azure VM v6 dan v7, dukungan untuk disk data NVMe ephemeral telah diperluas ke berbagai ukuran VM yang lebih luas, termasuk seri D, seri F, seri H, dan banyak lagi. Disk NVMe memberikan IOPS dan throughput yang lebih tinggi dibandingkan dengan opsi HDD atau SSD tradisional. Namun, data yang disimpan pada disk ini bersifat sementara dan akan hilang jika VM dibatalkan alokasinya atau disebarkan ulang.

Untuk menyederhanakan manajemen dan provisi disk data NVMe ephemeral di AKS, gunakan Azure Container Storage. Azure Container Storage dapat secara otomatis mendeteksi dan mengatur disk data NVMe, memungkinkan Anda membuat dan mengelola volume persisten untuk beban kerja Kubernetes Anda dengan konfigurasi minimal. Pendekatan ini direkomendasikan untuk skenario di mana penyimpanan sementara berkinerja tinggi diperlukan, seperti:

• Lapisan caching berkecepatan tinggi, seperti dataset dan checkpoint untuk pelatihan AI, atau file model yang digunakan untuk inferensi AI
• Database berkinerja tinggi yang dihost sendiri yang menyertakan fitur replikasi dan cadangan bawaan
• Analitik intensif data dan alur pemrosesan yang memerlukan penyimpanan cepat dan sementara
• Ruang penyimpanan sementara untuk pekerjaan batch

Penting

Disk data NVMe sementara tidak cocok untuk menyimpan data penting atau persisten. Pastikan aplikasi Anda dapat mentolerir kehilangan data dan data penting tersebut disimpan pada volume persisten yang didukung oleh Azure Disk, Azure Files, atau opsi penyimpanan tahan lama lainnya.

Untuk informasi selengkapnya tentang menggunakan Azure Container Storage dengan disk data NVMe ephemeral, lihat Menggunakan Azure Container Storage dengan AKS.

Volume

Kubernetes biasanya memperlakukan masing-masing pod sebagai sumber daya sementara dan dapat dibuang. Aplikasi memiliki pendekatan yang berbeda yang tersedia bagi mereka untuk menggunakan dan menyimpan data. Sebuah volume merupakan cara untuk menyimpan, mengambil, dan mempertahankan data di seluruh pod dan melalui siklus hidup aplikasi.

Volume tradisional dibuat sebagai sumber daya Kubernetes yang didukung oleh Azure Storage. Anda dapat membuat volume data secara manual untuk ditetapkan ke pod secara langsung atau membiarkan Kubernetes membuatnya secara otomatis. Volume data dapat menggunakan: Azure Disk, Azure Files, Azure NetApp Files, atau Azure Blobs.

Catatan

Bergantung pada SKU VM yang Anda gunakan, driver Azure Disk CSI mungkin memiliki batas volume per simpul. Untuk beberapa VM performa tinggi (misalnya, 16 core), batasnya adalah 64 volume per simpul. Untuk mengidentifikasi batas per SKU VM, tinjau kolom Maksimal Disk Data untuk setiap SKU VM yang ditawarkan. Untuk daftar SKU VM yang ditawarkan dan batas kapasitas terperinci yang sesuai, lihat Ukuran komputer virtual tujuan umum.

Untuk membantu menentukan kecocokan terbaik untuk beban kerja Anda antara Azure Files dan Azure NetApp Files, tinjau informasi yang disediakan dalam artikel Azure Files dan perbandingan Azure NetApp Files.

Disk Azure

Gunakan Azure Disk untuk membuat sumber daya Kubernetes DataDisk . Jenis disk meliputi:

• SSD premium (direkomendasikan untuk sebagian besar beban kerja)
• Ultra Disks
• SSD Standar
• HDD Standar

Petunjuk / Saran

Untuk sebagian besar beban kerja produksi dan pengembangan, gunakan SSD Premium.

Karena Disk Azure dimontekan sebagai ReadWriteOnce, maka disk hanya tersedia untuk satu simpul. Untuk volume penyimpanan yang dapat diakses oleh pod pada beberapa simpul secara bersamaan, gunakan Azure Files.

Azure Files

Gunakan Azure Files untuk memasang share Server Message Block (SMB) versi 3.1.1 atau Network File System (NFS) versi 4.1. Azure Files memungkinkan Anda berbagi data di beberapa simpul dan pod dan dapat menggunakan:

• Penyimpanan Azure Premium didukung oleh SSD berperforma tinggi
• Penyimpanan Azure Standar, didukung oleh HDD reguler

Azure NetApp Files

Gunakan Azure NetApp Files untuk menyediakan volume NFS atau SMB berkinerja tinggi untuk beban kerja AKS. Pilih dari lima tingkat layanan berdasarkan throughput dan persyaratan performa beban kerja Anda:

• Elastic Storage (pratinjau)
• Penyimpanan Fleksibel
• Standard Storage
• Penyimpanan Premium
• Penyimpanan Ultra

Azure Blob Storage

Gunakan Azure Blob Storage untuk membuat kontainer penyimpanan blob dan memasangnya menggunakan protokol NFS v3.0 atau BlobFuse.

Jenis volume

Volume Kubernetes mewakili lebih dari sekadar disk tradisional untuk menyimpan dan mengambil informasi. Volume Kubernetes juga dapat digunakan sebagai cara untuk memasukkan data ke dalam pod untuk digunakan oleh kontainernya.

Jenis volume umum dalam Kubernetes meliputi:

emptyDir

Umumnya digunakan sebagai ruang sementara untuk sebuah Pod. Semua kontainer dalam sebuah Pod dapat mengakses data pada volume. Data yang ditulis pada tipe volume ini hanya bertahan selama umurnya pod. Jika Anda menghapus pod, volume akan dihapus. Volume ini biasanya menggunakan penyimpanan disk simpul lokal yang mendasarinya, meskipun volume ini juga hanya ada di memori simpul.

rahasia

Anda dapat menggunakan volume rahasia untuk menyuntikkan data sensitif ke dalam pod, seperti kata sandi.

1. Buat rahasia menggunakan API Kubernetes.
2. Tentukan pod atau deployment Anda dan minta secret tertentu.
   • Rahasia hanya diberikan kepada simpul yang memiliki pod terjadwal dan memerlukannya.
   • Rahasia disimpan dalam tmpfs, bukan ditulis ke disk.
3. Saat Anda menghapus pod terakhir pada simpul yang membutuhkan rahasia, rahasia tersebut akan dihapus dari tmpfs simpul.
   • Rahasia disimpan dalam namespace tertentu dan hanya diakses oleh pod dalam namespace yang sama.

configMap

Anda dapat menggunakan configMap untuk menyuntikkan properti pasangan kunci-nilai ke dalam Pod, seperti informasi konfigurasi aplikasi. Tentukan informasi konfigurasi aplikasi sebagai sumber daya Kubernetes, yang dapat dengan mudah diperbarui dan diterapkan ke instans baru pod saat dideploy.

Seperti menggunakan rahasia:

1. Buat ConfigMap menggunakan API Kubernetes.
2. Minta ConfigMap saat Anda menentukan pod atau penyebaran.
   • ConfigMaps disimpan dalam namespace tertentu dan hanya diakses oleh pod pada namespace yang sama.

Volume yang Persisten

Volume-volume yang ditentukan dan dibuat sebagai bagian dari siklus hidup pod hanya ada sampai Anda menghapus pod. Pod sering mengharapkan bahwa penyimpanannya tetap ada jika pod dijadwalkan ulang di host yang berbeda selama peristiwa pemeliharaan, terutama dalam StatefulSets. Volume persisten (PV) adalah sumber daya penyimpanan yang dibuat dan dikelola oleh API Kubernetes yang dapat tetap ada meskipun masa pakai Pod individu telah berakhir.

Anda dapat menggunakan layanan Azure Storage berikut untuk menyediakan volume persisten:

• Disk Azure
• Azure Files
• Penyimpanan Kontainer Azure

Seperti yang disebutkan di bagian Volume, pilihan antara disk Azure dan Azure Files biasanya tergantung pada kebutuhan akan akses bersamaan (Azure Files mendukung beberapa simpul secara bersamaan; Azure Disk hanya mendukung simpul tunggal) atau tingkat performa yang diperlukan.

Administrator kluster dapat secara statis membuat volume persisten, atau volume dapat dibuat secara dinamis oleh server API Kubernetes. Jika pod dijadwalkan dan meminta penyimpanan yang saat ini tidak tersedia, Kubernetes dapat membuat Azure Disk atau File Storage yang mendasari dan melampirkannya ke pod. Provisi dinamis menggunakan kelas penyimpanan untuk mengidentifikasi jenis sumber daya apa yang perlu dibuat.

Penting

Volume persisten tidak dapat dibagikan oleh pod Windows dan Linux karena perbedaan dukungan sistem file antara kedua sistem operasi.

Jika Anda menginginkan solusi yang dikelola sepenuhnya untuk akses tingkat blok ke data, pertimbangkan untuk menggunakan Azure Container Storage. Azure Container Storage terintegrasi dengan Kubernetes, sehingga Anda dapat memprovisikan volume persisten secara dinamis dan otomatis. Penyimpanan dukungan yang didukung tergantung pada versi utama. Azure Container Storage versi 2 mendukung disk NVMe lokal dan Azure Elastic SAN. Versi 1 mendukung Azure Disk, disk sementara (NVMe lokal dan SSD sementara), dan Azure Elastic SAN.

Kelas penyimpanan

Untuk menentukan tingkat penyimpanan yang berbeda, seperti premium atau standar, Anda dapat membuat kelas penyimpanan.

Kelas penyimpanan juga menentukan kebijakan klaim ulang. Saat Anda menghapus volume persisten, kebijakan klaim ulang mengontrol perilaku sumber daya Azure Storage yang mendasar. Sumber daya dasar dapat dihapus atau disimpan untuk digunakan dengan pod di masa mendatang.

Untuk kluster yang menggunakan Azure Container Storage, kelas penyimpanan bergantung pada versi utama dan penyimpanan cadangan. Versi 2 menggunakan local-csi untuk disk NVMe lokal dan azuresan-csi untuk Azure Elastic SAN. Versi 1 membuat kelas penyimpanan bernama acstor-<storage-pool-name> dan kelas penyimpanan internal.

Untuk kluster yang menggunakan driver Antarmuka Penyimpanan Kontainer (CSI), kelas penyimpanan tambahan berikut dibuat:

Kelas penyimpanan	Deskripsi
managed-csi	Menggunakan penyimpanan redundan lokal (LRS) Azure Standard SSD untuk membuat disk terkelola. Kebijakan klaim ulang memastikan bahwa Disk Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus. Kelas penyimpanan juga mengonfigurasi volume persisten agar dapat diperluas. Anda dapat mengedit klaim volume persisten untuk menentukan ukuran baru. Efektif mulai dengan Kubernetes versi 1.29, di kluster Azure Kubernetes Service (AKS) yang disebarkan di berbagai zona ketersediaan, kelas penyimpanan ini memanfaatkan Azure Standard SSD penyimpanan redundan zona (ZRS) untuk membuat disk terkelola.
managed-csi-premium	Menggunakan penyimpanan redundan lokal (LRS) Azure Premium untuk membuat disk terkelola. Kebijakan pemulihan sekali lagi memastikan bahwa Disk Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus. Demikian pula, kelas penyimpanan ini memungkinkan volume persisten diperluas. Mulai efektif pada Kubernetes versi 1.29, di kluster Azure Kubernetes Service (AKS) yang disebarkan di beberapa zona ketersediaan, kelas penyimpanan ini menggunakan Azure Premium zone-redundant storage (ZRS) untuk membuat disk terkelola.
managed-csi-premium-v2	Menggunakan Azure Premium SSD v2 locally redundant storage (LRS) untuk membuat disk terkelola. Kebijakan pemulihan sekali lagi memastikan bahwa Disk Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus. Kelas penyimpanan ini tersedia dimulai dengan Kubernetes versi 1.35.
azurefile-csi	Menggunakan penyimpanan Azure Standard untuk membuat berbagi file Azure. Kebijakan klaim ulang memastikan bahwa berbagi file Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus.
azurefile-csi-premium	Menggunakan penyimpanan Azure Premium untuk membuat berbagi file Azure. Kebijakan klaim ulang memastikan bahwa berbagi file Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus.
azureblob-nfs-premium	Menggunakan penyimpanan Azure Premium untuk membuat kontainer penyimpanan Azure Blob dan menyambungkan menggunakan protokol NFS v3. Kebijakan klaim ulang memastikan bahwa kontainer penyimpanan Blob Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus.
azureblob-fuse-premium	Menggunakan penyimpanan Azure Premium untuk membuat kontainer penyimpanan Azure Blob dan menyambungkan menggunakan BlobFuse. Kebijakan klaim ulang memastikan bahwa kontainer penyimpanan Blob Azure yang mendasar dihapus saat volume persisten yang digunakan dihapus.

Kecuali Anda menentukan kelas penyimpanan untuk volume persisten, kelas penyimpanan default digunakan. Pastikan volume menggunakan penyimpanan yang sesuai dengan yang Anda perlukan saat meminta volume persisten.

Penting

Dimulai dengan Kubernetes versi 1.21, AKS menggunakan driver CSI secara default, dan migrasi CSI diaktifkan. Meskipun volume persisten in-tree yang ada terus berfungsi, mulai dari versi 1.26, AKS tidak akan lagi mendukung volume yang dibuat menggunakan driver in-tree dan penyimpanan yang disediakan untuk file dan disk.

Kelas default akan sama dengan managed-csi.

Mulai efektif pada Kubernetes versi 1.29, ketika Anda menyebarkan kluster Azure Kubernetes Service (AKS) di beberapa zona ketersediaan, AKS sekarang menggunakan penyimpanan redundan zona (ZRS) untuk membuat disk terkelola dalam kelas penyimpanan bawaan. ZRS memastikan replikasi sinkron disk terkelola Azure Anda di beberapa zona ketersediaan Azure di wilayah yang Anda pilih. Strategi redundansi ini meningkatkan ketahanan aplikasi Anda dan melindungi data Anda dari kegagalan pusat data.

Namun, penting untuk dicatat bahwa penyimpanan zona redundan (ZRS) memiliki biaya yang lebih tinggi dibandingkan dengan penyimpanan redundan lokal (LRS). Jika pengoptimalan biaya adalah prioritas, Anda dapat membuat kelas penyimpanan baru dengan parameter yang skuname diatur ke LRS. Anda kemudian dapat menggunakan kelas penyimpanan baru di Klaim Volume Persisten (PVC).

Anda dapat membuat kelas penyimpanan untuk kebutuhan lain menggunakan kubectl. Contoh berikut menggunakan disk terkelola premium dan menentukan bahwa Disk Azure yang mendasar harus dipertahankan saat Anda menghapus klaim volume persisten:

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

Manifes ini menggunakan disk.csi.azure.com sebagai penyedia CSI Disk Azure dan Premium_ZRS sebagai skuName untuk SSD Premium zona-redundan. Kebijakan Retain klaim ulang mempertahankan disk yang mendasarinya setelah klaim volume persistennya dihapus, dan WaitForFirstConsumer menunda pengikatan dan provisi volume hingga pod yang menggunakan klaim dibuat sehingga disk disediakan sesuai dengan batasan penjadwalan pod.

Catatan

AKS menyesuaikan kelas penyimpanan default dan akan menggantikan setiap perubahan yang Anda buat pada kelas penyimpanan tersebut.

Untuk informasi selengkapnya tentang kelas penyimpanan, lihat StorageClass di Kubernetes.

Klaim volume persisten

Klaim volume persisten (PVC) meminta penyimpanan kelas penyimpanan, mode akses, dan ukuran tertentu. Server API Kubernetes dapat secara dinamis menyediakan sumber daya Azure Storage yang mendasar jika tidak ada sumber daya yang dapat memenuhi klaim berdasarkan kelas penyimpanan yang ditentukan.

Definisi Pod mencakup peningkatan volume setelah volume terhubung ke Pod.

Setelah sumber daya penyimpanan yang tersedia ditetapkan ke pod yang meminta penyimpanan, volume persisten terikat dengan klaim volume persisten. Volume persisten dipetakan ke klaim dalam skema pemetaan 1:1.

Contoh manifes YAML berikut menunjukkan klaim volume persisten yang menggunakan kelas penyimpanan managed-premium-retain dan meminta Disk Azure yang 5 Gi dalam ukuran:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Klaim ini menggunakan ReadWriteOnce mode akses, yang memungkinkan volume dipasang sebagai baca-tulis oleh satu simpul pada satu waktu, dan mengatur storage permintaan ke 5Gi (5 GiB) sebagai ukuran contoh. Sesuaikan storage nilai agar sesuai dengan persyaratan beban kerja Anda.

Saat Anda membuat definisi Pod, Anda juga menentukan:

• Klaim volume persisten untuk meminta penyimpanan yang diinginkan.
• Pemasangan volume agar aplikasi Anda dapat membaca dan menulis data.

Contoh berikut, manifes YAML menunjukkan bagaimana klaim volume persisten sebelumnya dapat digunakan untuk meningkatkan volume pada /mnt/azure:

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

Untuk memasang volume dalam kontainer Windows, tentukan huruf dan jalur drive. Contohnya:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: 'c:\k'
        name: k-dir
...

Langkah berikutnya

Untuk praktik terbaik terkait, lihat Praktik terbaik untuk penyimpanan dan pencadangan dalam AKS dan pertimbangan penyimpanan AKS.

Untuk informasi selengkapnya tentang Azure Container Storage, lihat artikel berikut ini:

• Apa itu Azure Container Storage?
• Menggunakan Azure Container Storage dengan AKS

Untuk informasi selengkapnya tentang menggunakan driver CSI, lihat artikel berikut ini:

• Driver Antarmuka Penyimpanan Kontainer (CSI) untuk penyimpanan Azure Disk, Azure Files, dan Azure Blob di Azure Kubernetes Service
• Menggunakan driver Azure Disk CSI di Azure Kubernetes Service
• Menggunakan driver CSI Azure Files di Azure Kubernetes Service
• Gunakan driver CSI penyimpanan Azure Blob di Azure Kubernetes Service
• Mengonfigurasi Azure NetApp Files dengan Azure Kubernetes Service

Untuk informasi lebih lanjut mengenai konsep pokok Kube dan AKS, lihat artikel berikut:

• Kluster dan beban kerja Kubernetes / AKS
• Identitas Kubernetes / AKS
• Keamanan Kubernetes/AKS
• Jaringan virtual Kubernetes/AKS
• Skala Kubernetes / AKS