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.
  • 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).

Disk Ephemeral OS

Secara default, Azure secara otomatis mereplikasi disk sistem operasi untuk komputer virtual ke penyimpanan Azure 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:

  • Ultra Disk
  • SSD Premium
  • 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 yang didukung oleh akun penyimpanan Azure ke pod. 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 menyuntikkan data ke dalam sebuah Pod untuk digunakan oleh kontainer.

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 dengan menggunakan API Kubernetes.
  2. Tentukan pod atau penyebaran Anda serta minta Rahasia tertentu.
    • Rahasia hanya disediakan untuk simpul dengan pod terjadwal yang membutuhkannya.
    • Rahasia disimpan dalam tmpfs, tidak ditulis ke disk.
  3. Saat Anda menghapus pod terakhir pada sebuah simpul yang membutuhkan Rahasia, Rahasia 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.
    • Konfigurasi Peta 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 PersistentVolume:

Seperti disebutkan di bagian Volume, pilihan Disk atau Files sering kali ditentukan oleh kebutuhan untuk akses bersamaan ke data atau tingkat performa.

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

Administrator kluster dapat secara statis membuat PersistentVolume, atau volume 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. Penyediaan dinamis menggunakan StorageClass untuk mengidentifikasi jenis penyimpanan Azure 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 dan Standard, Anda dapat membuat StorageClass.

StorageClass juga menentukan reclaimPolicy. Saat Anda menghapus volume persisten, reclaimPolicy mengontrol perilaku sumber daya penyimpanan Azure yang mendasar. Sumber daya penyimpanan yang mendasarinya dapat dihapus atau disimpan untuk digunakan pada Pod yang akan datang.

Untuk kluster yang menggunakan driver Container Storage Interface (CSI), StorageClasses tambahan berikut dibuat:

Kelas penyimpanan Deskripsi
managed-csi Menggunakan penyimpanan redundan lokal (LRS) Azure StandardSSD untuk membuat Disk Terkelola. Kebijakan klaim ulang memastikan bahwa Azure Disk yang mendasar dihapus saat volume persisten yang menggunakannya dihapus. Kelas penyimpanan juga mengonfigurasi volume persisten agar dapat diperluas, Anda hanya perlu mengedit klaim volume persisten dengan ukuran baru.
managed-csi-premium Menggunakan penyimpanan redundan lokal Azure Premium (LRS) untuk membuat Disk Terkelola. Kebijakan klaim kembali memastikan bahwa Azure Disk yang mendasar dihapus saat volume persisten yang menggunakannya dihapus. Demikian pula, kelas penyimpanan ini memungkinkan volume persisten diperluas.
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 mendasar dihapus saat volume persisten yang menggunakannya 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 mendasar dihapus saat volume persisten yang menggunakannya dihapus.

Kecuali Anda menentukan StorageClass untuk volume persisten, StorageClass 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.

Anda dapat membuat StorageClass untuk kebutuhan lain menggunakan kubectl. Contoh berikut menggunakan Disk Terkelola Premium dan menentukan bahwa Azure Disk yang mendasarinya 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

PersistentVolumeClaim meminta penyimpanan StorageClass, mode akses, dan ukuran tertentu. API server Kubernetes dapat menyediakan sumber daya penyimpanan Azure yang mendasarinya secara dinamis jika tidak ada sumber daya yang dapat memenuhi klaim berdasarkan StorageClass 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, PersistentVolume terikat pada PersistentVolumeClaim. Volume persisten adalah 1:1 dipetakan ke klaim.

Contoh berikut, manifes YAML menunjukkan klaim volume persisten yang menggunakan StorageClass premium-terkelola dan meminta Disk 5Gi berukuran:

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.
  • VolumeMount 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: