Bagikan melalui

Opsi penyimpanan untuk aplikasi di Azure Kubernetes Service (AKS)

  • Artikel

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.
  • Memasang ulang 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:

Diagram opsi penyimpanan untuk aplikasi di kluster Azure Kubernetes Services (AKS).

Ukuran disk OS default

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

Inti SKU mesin virtual (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 5000 200

Penting

Ukuran disk OS default hanya digunakan pada kluster atau kumpulan simpul baru saat 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. Ukuran disk default ini memengaruhi kluster atau kumpulan simpul yang dibuat pada Juli 2022 atau yang lebih baru.

Disk Ephemeral OS

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 sementara hanya disimpan di komputer host, sama seperti disk sementara. Dengan konfigurasi ini, Anda mendapatkan latensi baca/tulis yang lebih rendah, bersama dengan penskalaan node dan peningkatan kluster yang lebih cepat.

Catatan

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

Persyaratan ukuran dan rekomendasi untuk disk OS ephemeral tersedia dalam dokumentasi Azure VM. Berikut ini adalah beberapa pertimbangan ukuran umum:

  • Jika Anda memilih untuk menggunakan ukuran VM default AKS Standard_DS2_v2 SKU dengan ukuran disk OS default 100 GiB, ukuran VM default mendukung OS ephemeral, tetapi hanya memiliki ukuran cache 86 GiB. Konfigurasi ini akan default ke disk terkelola jika Anda tidak secara eksplisit menentukannya. Jika Anda meminta OS ephemeral, Anda menerima kesalahan validasi.

  • Jika Anda meminta SKU Standard_DS2_v2 yang sama dengan disk OS 60-GiB, konfigurasi ini akan default ke OS ephemeral. Ukuran 60 GiB yang diminta lebih kecil dari ukuran cache maksimum 86 GiB.

  • Jika Anda memilih SKU Standard_D8s_v3 dengan disk OS 100 GB, ukuran VM ini mendukung OS ephemeral dan memiliki ruang cache 200 GiB. Jika Anda tidak menentukan jenis disk OS, kumpulan simpul akan menerima OS ephemeral secara default.

Generasi terbaru seri VM tidak memiliki cache khusus, tetapi 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 penyimpanan sementara 75 GB. Konfigurasi ini akan default ke disk OS terkelola jika Anda tidak secara eksplisit menentukannya. Jika Anda meminta disk OS ephemeral, Anda menerima kesalahan validasi.

  • Jika Anda meminta ukuran VM Standard_E2bds_v5 yang sama dengan disk OS 60 GiB, konfigurasi ini default ke 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, secara default Azure menyediakan disk OS ephemeral ke kumpulan simpul.

Kunci yang dikelola pelanggan

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

Volume

Kubernetes biasanya memperlakukan masing-masing Pod sebagai sumber daya sementara dan sekali pakai. Aplikasi memiliki pendekatan yang berbeda yang tersedia bagi mereka untuk menggunakan dan menyimpan data. Sebuah volume merupakan cara untuk menyimpan, mengambil, dan meneruskan 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 membuat Kubernetes 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 Disk data maks 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.

Azure Disk

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

  • SSD premium (direkomendasikan untuk sebagian besar beban kerja)
  • Disk ultra
  • SSD Standar
  • HDD Standar

Tip

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

Karena Disk Azure dipasang sebagai ReadWriteOnce, 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 berbagi 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

  • Ultra Storage
  • Penyimpanan Premium
  • Standard Storage

Azure Blob Storage

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

  • Blob blok

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 untuk tipe volume ini hanya bertahan untuk umur 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 penyebaran Anda dan minta rahasia tertentu.
    • Rahasia hanya disediakan untuk simpul dengan pod terjadwal yang membutuhkannya.
    • Rahasia disimpan dalam tmpfs, bukan ditulis ke disk.
  3. Ketika Anda menghapus pod terakhir pada node yang memerlukan rahasia, rahasia akan dihapus dari tmpfs simpul.
    • Rahasia disimpan dalam namespace layanan 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 diperbarui dan diterapkan dengan mudah ke instans baru Pod saat digunakan.

Seperti menggunakan rahasia:

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

Volume Persisten

Volume yang ditentukan dan dibuat sebagai bagian dari siklus hidup Pod hanya ada sampai Anda menghapus Pod. Pod sering mengharapkan penyimpanan mereka tetap ada jika sebuah Pod dijadwalkan ulang pada host yang berbeda selama pemeliharaan, terutama di StatefulSets. Volume persisten (PV) adalah sumber daya penyimpanan yang dibuat dan dikelola oleh API Kubernetes yang dapat ada di luar masa pakai Pod individu.

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

Seperti yang disebutkan di bagian Volume , pilihan Azure Disks atau Azure Files sering ditentukan oleh kebutuhan akan akses bersamaan ke data atau tingkat performa.

Diagram volume persisten dalam kluster Azure Kubernetes Services (AKS).

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 Penyimpanan Azure Disk atau File yang mendasar 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.

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 yang mendasar dapat dihapus atau disimpan untuk digunakan dengan pod di masa mendatang.

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 Azure Disk yang mendasarinya dihapus saat volume persisten yang menggunakannya dihapus. Kelas penyimpanan juga mengonfigurasi volume persisten agar dapat diperluas. Anda dapat mengedit klaim volume persisten untuk menentukan ukuran baru. Efektif dimulai dengan Kubernetes versi 1.29, di kluster Azure Kubernetes Service (AKS) yang disebarkan di beberapa zona ketersediaan, kelas penyimpanan ini menggunakan penyimpanan redundan zona (ZRS) Azure Standard SSD untuk membuat disk terkelola.
managed-csi-premium Menggunakan penyimpanan redundan lokal (LRS) Azure Premium untuk membuat disk terkelola. Kebijakan klaim ulang memastikan bahwa Azure Disk yang mendasarinya dihapus saat volume persisten yang menggunakannya dihapus. Demikian pula, kelas penyimpanan ini memungkinkan volume persisten diperluas. Efektif dimulai dengan Kubernetes versi 1.29, di kluster Azure Kubernetes Service (AKS) yang disebarkan di beberapa zona ketersediaan, kelas penyimpanan ini menggunakan penyimpanan redundan zona Azure Premium (ZRS) untuk membuat disk terkelola.
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 menggunakannya 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 menggunakannya 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 Azure Blob yang mendasari 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 Azure Blob yang mendasari 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 yang Anda perlukan saat meminta volume persisten.

Penting

Dimulai dengan Kubernetes versi 1.21, AKS hanya menggunakan driver CSI secara default dan migrasi CSI diaktifkan. Meskipun volume persisten dalam pohon yang ada terus berfungsi, dimulai dengan 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.

Efektif dimulai dengan 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 Azure Disk yang mendasar harus dipertahankan saat Anda menghapus pod:

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

Catatan

AKS merekonsiliasi kelas penyimpanan default dan akan menimpa 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.

Diagram klaim volume persisten dalam kluster Azure Kubernetes Services (AKS).

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 pemetaan 1:1.

Contoh manifes YAML berikut menunjukkan klaim volume persisten yang menggunakan kelas penyimpanan premium terkelola dan meminta Azure Disk berukuran 5Gi :

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

Saat Anda membuat definisi Pod, Anda juga menentukan:

  • Klaim volume persisten untuk meminta penyimpanan yang diinginkan.
  • Pemasangan volume untuk aplikasi Anda untuk 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 wadah Windows, tentukan huruf dan jalur kandar. 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 Pertimbangan Penyimpanan AKS dan AKS.

Untuk melihat cara menggunakan driver CSI, lihat artikel cara penggunaan berikut ini:

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