Persistent Volume

Dokumen ini menjelaskan kondisi terkini dari PersistentVolumes pada Kubernetes. Disarankan telah memiliki familiaritas dengan volume.

Pengenalan

Mengelola penyimpanan adalah hal yang berbeda dengan mengelola komputasi. Sub-sistem PersistentVolume (PV) menyediakan API untuk para pengguna dan administrator yang mengabstraksi detail-detail tentang bagaimana penyimpanan disediakan dari bagaimana penyimpanan dikonsumsi. Untuk melakukan ini, kami mengenalkan dua sumber daya API baru: PersistentVolume (PV) dan PersistentVolumeClaim (PVC).

Sebuah PersistentVolume (PV) adalah suatu bagian dari penyimpanan pada klaster yang telah disediakan oleh seorang administrator. PV merupakan sebuah sumber daya pada klaster sama halnya dengan node yang juga merupakan sumber daya klaster. PV adalah volume plugin seperti Volumes, tetapi memiliki siklus hidup yang independen dari pod individual yang menggunakan PV tersebut. Objek API ini menangkap detail-detail implementasi dari penyimpanan, seperti NFS, iSCSI, atau sistem penyimpanan yang spesifik pada penyedia layanan cloud.

Sebuah PersistentVolumeClaim (PVC) merupakan permintaan penyimpanan oleh pengguna. PVC mirip dengan sebuah pod. Pod mengonsumsi sumber daya node dan PVC mengonsumsi sumber daya PV. Pods dapat meminta taraf-taraf spesifik dari sumber daya (CPU dan Memory). Klaim dapat meminta ukuran dan mode akses yang spesifik (seperti, dapat dipasang sekali sebagai read/write atau lain kali sebagai read-only).

Meskipun PersistentVolumeClaims mengizinkan pengguna untuk mengkonsumsi sumber daya penyimpanan abstrak, pada umumnya para pengguna membutuhkan PersistentVolumes dengan properti yang bermacam-macam, seperti performa, untuk mengatasi masalah yang berbeda. Para administrator klaster harus dapat menawarkan berbagai macam PersistentVolumes yang berbeda tidak hanya pada ukuran dan mode akses, tanpa memaparkan detail-detail bagaimana cara volume tersebut diimplementasikan kepada para pengguna. Untuk mengatasi hal ini maka dibutuhkan sumber daya StorageClass.

Silakan lihat panduan mendetail dengan contoh-contoh yang sudah berjalan.

Siklus hidup dari sebuah volume dan klaim

PV adalah sumber daya dalam sebuah klaster. PVC adalah permintaan terhadap sumber daya tersebut dan juga berperan sebagai pemeriksaan klaim dari sumber daya yang diminta. Interaksi antara PV dan PVC mengikuti siklus hidup berikut ini:

Penyediaan

Ada dua cara untuk menyediakan PV: secara statis atau dinamis.

Statis

Seorang administrator klaster membuat beberapa PV. PV yang telah dibuat membawa detail-detail dari penyimpanan yang sesungguhnya tersedia untuk digunakan oleh pengguna klaster. PV tersebut ada pada Kubernetes API dan siap untuk digunakan.

Dinamis

Ketika tidak ada PV statis yang dibuat oleh administrator yang sesuai dengan PersistentVolumeClaim (PVC) yang dibuat oleh pengguna, klaster akan mencoba untuk menyediakan volume khusus sesuai permintaan PVC. Penyediaan dinamis ini berbasis StorageClass: artinya PVC harus meminta sebuah storage class dan storage class tersebut harus sudah dibuat dan dikonfigurasi oleh administrator agar penyediaan dinamis bisa terjadi. Klaim yang meminta PV dengan storage class "" secara efektif telah menonaktifkan penyediaan dinamis.

Untuk mengaktifkan penyediaan storage dinamis berdasarkan storage class, administrator klaster harus mengaktifkan admission controller DefaultStorageClass pada API server. Hal ini dapat dilakukan, dengan cara memastikan DefaultStorageClass ada di antara urutan daftar value yang dibatasi koma untuk flag --enable-admission-plugins pada komponen API server. Untuk informasi lebih lanjut mengenai flag perintah pada API server, silakan cek dokumentasi, kube-apiserver.

Pengikatan

Seorang pengguna membuat, atau telah membuat (dalam kasus penyediaan dinamis), sebuah PersistentVolumeClaim (PVC) dengan jumlah penyimpanan spesifik yang diminta dan dengan mode akses tertentu. Sebuah control loop pada master akan melihat adanya PVC baru, mencari PV yang cocok (jika memungkinkan), dan mengikat PVC dengan PV tersebut. Jika sebuah PV disediakan secara dinamis untuk sebuah PVC baru, loop tersebut akan selalu mengikat PV tersebut pada PVC yang baru dibuat itu. Jika tidak, pengguna akan selalu mendapatkan setidaknya apa yang dimintanya, tetapi volume tersebut mungkin lebih dari apa yang diminta sebelumnya. Setelah terikat, ikatan PersistentVolumeClaim (PVC) bersifat eksklusif, terlepas dari bagaimana caranya mereka bisa terikat. Sebuah ikatan PVC ke PV merupakan pemetaan satu ke satu.

Klaim akan berada dalam kondisi tidak terikat tanpa kepastian jika tidak ada volume yang cocok. Klaim akan terikat dengan volume yang cocok ketika ada volume yang cocok. Sebagai contoh, sebuah klaster yang sudah menyediakan banyak PV berukuran 50Gi tidak akan cocok dengan PVC yang meminta 100Gi. PVC hanya akan terikat ketika ada PV 100Gi yang ditambahkan ke klaster.

Penggunaan

Pod menggunakan klaim sebagai volume. Klaster menginspeksi klaim untuk menemukan volume yang terikat dengan klaim tersebut dan memasangkan volume tersebut ke pada pod. Untuk volume yang mendukung banyak mode akses, pengguna yang menentukan mode yang diinginkan ketika menggunakan klaim sebagai volume dalam sebuah pod.

Ketika pengguna memiliki klaim dan klaim tersebut telah terikat, PV yang terikat menjadi hak penggunanya selama yang dibutuhkan. Pengguna menjadwalkan pod dan mengakses PV yang sudah diklaim dengan menambahkan persistentVolumeClaim pada blok volume pada Pod miliknya. Lihat pranala di bawah untuk detail-detail mengenai sintaks.

Object Penyimpanan dalam Perlindungan Penggunaan

Tujuan dari Objek Penyimpanan dalam Perlindungan Penggunan adalah untuk memastikan Persistent Volume Claim (PVC) yang sedang aktif digunakan oleh sebuah pod dan Persistent Volume (PV) yang terikat pada PVC tersebut tidak dihapus dari sistem karena hal ini dapat menyebabkan kehilangan data.

Jika seorang pengguna menghapus PVC yang sedang aktif digunakan oleh sebuah pod, PVC tersebut tidak akan langsung dihapus. Penghapusan PVC akan ditunda sampai PVC tidak lagi aktif digunakan oleh pod manapun, dan juga ketika admin menghapus sebuah PV yang terikat dengan sebuah PVC, PV tersebut tidak akan langsung dihapus. Penghapusan PV akan ditunda sampai PV tidak lagi terikat dengan sebuah PVC.

Kamu dapat melihat PVC yang dilindungi ketika status PVC berisi Terminating dan daftar Finalizers meliputi kubernetes.io/pvc-protection:

kubectl describe pvc hostpath
Name:          hostpath
Namespace:     default
StorageClass:  example-hostpath
Status:        Terminating
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-class=example-hostpath
               volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers:    [kubernetes.io/pvc-protection]
...

Kamu dapat melihat sebuah PV dilindungi ketika status PV berisi Terminating dan daftar Finalizers juga meliputi kubernetes.io/pv-protection:

kubectl describe pv task-pv-volume
Name:            task-pv-volume
Labels:          type=local
Annotations:     <none>
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Available
Claim:
Reclaim Policy:  Delete
Access Modes:    RWO
Capacity:        1Gi
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/data
    HostPathType:
Events:            <none>

Melakukan Reklaim

Ketika seorang pengguna telah selesai dengan volumenya, ia dapat menghapus objek PVC dari API yang memungkinkan untuk reklamasi dari sumber daya tersebut. Kebijakan reklaim dari sebuah PersistentVolume (PV) menyatakan apa yang dilakukan klaster setelah volume dilepaskan dari klaimnya. Saat ini, volume dapat dipertahankan (Retained), didaur ulang (Recycled), atau dihapus (Deleted).

Retain

Retain merupakan kebijakan reklaim yang mengizinkan reklamasi manual dari sebuah sumber daya. Ketika PersistentVolumeClaim (PVC) dihapus, PersistentVolume (PV) masih akan tetap ada dan volume tersebut dianggap "terlepas" . Tetapi PV tersebut belum tersedia untuk klaim lainnya karena data milik pengklaim sebelumnya masih terdapat pada volume. Seorang administrator dapat mereklaim volume secara manual melalui beberapa langkah.

1. Menghapus PersistentVolume (PV). Aset storage yang terasosiasi dengan infrastruktur eksternal (seperti AWS EBS, GCE PD, Azure Disk, atau Cinder Volume) akan tetap ada setelah PV dihapus.
2. Secara manual membersihkan data pada aset storage terkait.
3. Secara manual menghapus aset storage, atau jika kamu ingin menggunakan aset storage yang sama, buatlah sebuah PersistentVolume baru dengan definisi aset storage tersebut.

Delete

Untuk volume plugin yang mendukung kebijakan reklaim Delete, penghapusan akan menghilangkan kedua objek dari Kubernetes, PersistentVolume (PV) dan juga aset storage yang terasosiasi pada infrastruktur eksternal seperti, AWS EBS, GCE PD, Azure Disk, atau Cinder Volume. Volume yang disediakan secara dinamis mewarisi kebijakan reklaim dari StorageClass miliknya, yang secara bawaan adalah Delete. Administrator harus mengkonfigurasi StorageClass sesuai ekspektasi pengguna, jika tidak maka PV tersebut harus diubah atau ditambal setelah dibuat nanti. Lihat Mengganti Kebijakan Reklaim pada PersistentVolume.

Recycle

Jika didukung oleh plugin volume yang berada di baliknya, kebijakan reklaim Recycle melakukan penghapusan dasar (rm -rf /thevolume/*) pada volume dan membuatnya kembali tersedia untuk klaim baru.

Namun, seorang administrator dapat mengkonfigurasi templat recycler pod kustom menggunakan argumen baris perintah controller manager Kubernetes sebagaimana dijelaskan di sini. Templat reycler pod kustom harus memiliki spesifikasi volumes, seperti yang ditunjukkan pada contoh di bawah:

apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler
  namespace: default
spec:
  restartPolicy: Never
  volumes:
  - name: vol
    hostPath:
      path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "k8s.gcr.io/busybox"
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \"$(ls -A /scrub)\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

Namun, alamat yang dispesifikasikan pada templat recycler pod kustom pada bagian volumes diganti dengan alamat pada volume yang akan didaur ulang.

Memperluas Persistent Volumes Claim

Dukungan untuk memperluas PersistentVolumeClaim (PVC) sekarang sudah diaktifkan sejak awal. Kamu dapat memperluas tipe-tipe volume berikut:

• gcePersistentDisk
• awsElasticBlockStore
• Cinder
• glusterfs
• rbd
• Azure File
• Azure Disk
• Portworx
• FlexVolumes
• CSI

Kamu hanya dapat memperluas sebuah PVC jika kolom allowVolumeExpansion dipasang sebagai benar pada storage class miliknya.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gluster-vol-default
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

Untuk meminta volume yang lebih besar pada sebuah PVC, ubah objek PVC dan spesifikasikan ukuran yang lebih besar. Hal ini akan memicu perluasan dari volume yang berada di balik PersistentVolume (PV). Sebuah PersistentVolume (PV) baru tidak akan dibuat untuk memenuhi klaim tersebut. Sebaliknya, volume yang sudah ada akan diatur ulang ukurannya.

Perluasan Volume CSI

Perluasan volume CSI mengharuskan kamu untuk mengaktifkan gerbang fitur ExpandCSIVolumes dan juga membutuhkan driver CSI yang spesifik untuk mendukung perluasan volume. Silakan merujuk pada dokumentasi driver spesifik CSI untuk informasi lebih lanjut.

Mengubah ukuran sebuah volume yang memiliki file system

Kamu hanya dapat mengubah ukuran volume yang memiliki file system jika file system tersebut adalah XFS, Ext3, atau Ext4.

Ketika sebuah volume memiliki file system, file system tersebut hanya akan diubah ukurannya ketika sebuah pod baru dinyalakan menggunakan PersistentVolumeClaim (PVC) dalam mode ReadWrite. Maka dari itu, jika sebuah pod atau deployment menggunakan sebuah volume dan kamu ingin memperluasnya, kamu harus menghapus atau membuat ulang pod tersebut setelah volume selesai diperluas oleh penyedia cloud dalam controller-manager. Kamu dapat melihat status dari operasi pengubahan ukuran dengan menjalankan perintah kubectl describe pvc:

kubectl describe pvc <pvc_name>

Jika PersistentVolumeClaim (PVC) memiliki status FileSystemResizePending, maka berarti aman untuk membuat ulang pod menggunakan PersistentVolumeClaim (PVC) tersebut.

FlexVolumes mengizinkan pengubahan ukuran jika driver diatur dengan kapabilitas RequiresFSResize menjadi "true". FlexVolume dapat diubah ukurannya pada saat pod mengalami restart.

Mengubah ukuran PersistentVolumeClaim (PVC) yang sedang digunakan

Memperluas PVC yang sedang digunakan merupakan fitur alfa. Untuk menggunakannya, aktifkan gerbang fitur ExpandInUsePersistentVolumes. Pada kasus ini, kamu tidak perlu menghapus dan membuat ulang sebuah Pod atau deployment yang menggunakan PVC yang telah ada. PVC manapun yang sedang digunakan secara otomatis menjadi tersedia untuk pod yang menggunakannya segera setelah file system miliknya diperluas. Fitur ini tidak memiliki efek pada PVC yang tidak sedang digunakan oleh Pod atau deployment. Kamu harus membuat sebuah Pod yang menggunakan PVC sebelum perluasan dapat selesai dilakukan.

Memperluas PVC yang sedang digunakan sudah ditambahkan pada rilis 1.13. Untuk mengaktifkan fitur ini gunakan ExpandInUsePersistentVolumes dan gerbang fitur ExpandPersistentVolumes. Gerbang fitur ExpandPersistentVolumes sudah diaktifkan sejak awal. Jika ExpandInUsePersistentVolumes sudah terpasang, FlexVolume dapat diubah ukurannya secara langsung tanpa perlu melakukan restart pada pod.

Tipe-tipe Persistent Volume

Tipe-tipe PersistentVolume (PV) diimplementasikan sebagai plugin. Kubernetes saat ini mendukung plugin berikut:

• GCEPersistentDisk
• AWSElasticBlockStore
• AzureFile
• AzureDisk
• FC (Fibre Channel)
• FlexVolume
• Flocker
• NFS
• iSCSI
• RBD (Ceph Block Device)
• CephFS
• Cinder (OpenStack block storage)
• Glusterfs
• VsphereVolume
• Quobyte Volumes
• HostPath (Hanya untuk pengujian single node -- penyimpanan lokal tidak didukung dan TIDAK AKAN BEKERJA pada klaster multi-node)
• Portworx Volumes
• ScaleIO Volumes
• StorageOS

Persistent Volume

Setiap PV memiliki sebuah spec dan status, yang merupakan spesifikasi dan status dari volume tersebut.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

Kapasitas

Secara umum, sebuah PV akan memiliki kapasitas storage tertentu. Hal ini ditentukan menggunakan atribut capacity pada PV. Lihat Model Sumber Daya Kubernetes untuk memahami satuan yang diharapkan pada atribut capacity.

Saat ini, ukuran storage merupakan satu-satunya sumber daya yang dapat ditentukan atau diminta. Atribut-atribut lainnya di masa depan dapat mencakup IOPS, throughput, dsb.

Mode Volume

Sebelum Kubernetes 1.9, semua volume plugin akan membuat sebuah filesystem pada PersistentVolume (PV). Sekarang, kamu dapat menentukan nilai dari volumeMode menjadi block untuk menggunakan perangkat raw block, atau filesystem untuk menggunakan sebuah filesystem. filesystem menjadi standar yang digunakan jika nilainya dihilangkan. Hal ini merupakan parameter API opsional.

Mode Akses

Sebuah PersistentVolume (PV) dapat dipasangkan pada sebuah host dengan cara apapun yang didukung oleh penyedia sumber daya. Seperti ditunjukkan pada tabel di bawah, para penyedia akan memiliki kapabilitas yang berbeda-beda dan setiap mode akses PV akan ditentukan menjadi mode-mode spesifik yang didukung oleh tiap volume tersebut. Sebagai contoh, NFS dapat mendukung banyak klien read/write, tetapi sebuah NFS PV tertentu mungkin diekspor pada server sebagai read-only. Setiap PV memilik seperangkat mode aksesnya sendiri yang menjelaskan kapabilitas dari PV tersebut.

Beberapa mode akses tersebut antara lain:

• ReadWriteOnce -- volume dapat dipasang sebagai read-write oleh satu node
• ReadOnlyMany -- volume dapat dipasang sebagai read-only oleh banyak node
• ReadWriteMany -- volume dapat dipasang sebagai read-write oleh banyak node

Pada CLI, mode-mode akses tersebut disingkat menjadi:

• RWO - ReadWriteOnce
• ROX - ReadOnlyMany
• RWX - ReadWriteMany

Penting! Sebuah volume hanya dapat dipasang menggunakan satu mode akses dalam satu waktu, meskipun volume tersebut mendukung banyak mode. Sebagai contoh, sebuah GCEPersistentDisk dapat dipasangkan sebagai ReadWriteOnce oleh satu node atau ReadOnlyMany oleh banyak node, tetapi tidak dalam waktu yang bersamaan.

Kelas

Sebuah PV bisa memiliki sebuah kelas, yang dispesifikasi dalam pengaturan atribut storageClassName menjadi nama StorageClass. Sebuah PV dari kelas tertentu hanya dapat terikat dengan PVC yang meminta kelas tersebut. Sebuah PV tanpa storageClassName tidak memiliki kelas dan hanya dapat terikat dengan PVC yang tidak meminta kelas tertentu.

Dahulu, anotasi volume.beta.kubernetes.io/storage-class digunakan sebagai ganti atribut storageClassName. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.

Kebijakan Reklaim

Kebijakan-kebijakan reklaim saat ini antara lain:

• Retain -- reklamasi manual
• Recycle -- penghapusan dasar (rm -rf /thevolume/*)
• Delete -- aset storage terasosiasi seperti AWS EBS, GCE PD, Azure Disk, atau OpenStack Cinder volume akan dihapus

Saat ini, hanya NFS dan HostPath yang mendukung daur ulang. AWS EBS, GCE PD, Azure Disk, dan Cinder Volume mendukung penghapusan.

Opsi Pemasangan

Seorang administrator Kubernetes dapat menspesifikasi opsi pemasangan tambahan untuk ketika sebuah Persistent Volume dipasangkan pada sebuah node.

Tipe-tipe volume yang mendukung opsi pemasangan antara lain:

• AWSElasticBlockStore
• AzureDisk
• AzureFile
• CephFS
• Cinder (OpenStack block storage)
• GCEPersistentDisk
• Glusterfs
• NFS
• Quobyte Volumes
• RBD (Ceph Block Device)
• StorageOS
• VsphereVolume
• iSCSI

Opsi pemasangan tidak divalidasi, sehingga pemasangan akan gagal jika salah satunya tidak valid.

Dahulu, anotasi volume.beta.kubernetes.io/mount-options digunakan sebagai ganti atribut mountOptions. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.

Afinitas Node

Sebuah PV dapat menspesifikasi afinitas node untuk mendefinisikan batasan yang membatasi node mana saja yang dapat mengakses volume tersebut. Pod yang menggunakan sebuah PV hanya akan bisa dijadwalkan ke node yang dipilih oleh afinitas node.

Fase

Sebuah volume akan berada dalam salah satu fase di bawah ini:

• Available -- sumber daya bebas yang belum terikat dengan sebuah klaim
• Bound -- volume sudah terikat dengan sebuah klaim
• Released -- klaim sudah dihapus, tetapi sumber daya masih belum direklaim oleh klaster
• Failed -- volume gagal menjalankan reklamasi otomatis

CLI akan menunjukkan nama dari PVC yang terikat pada PV.

PersistentVolumeClaims

Setiap PVC memiliki spec dan status, yang merupakan spesifikasi dan status dari klaim.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

Mode Akses

Klaim menggunakan penulisan yang sama dengan volume ketika meminta storage dengan mode akses tertentu.

Mode Volume

Klaim menggunakan penulisan yang sama dengan volume untuk mengindikasikan konsumsi dari volume sebagai filesystem ataupun perangkat block.

Sumber daya

Klaim, seperti pod, bisa meminta sumber daya dengan jumlah tertentu. Pada kasus ini, permintaan untuk storage. Model sumber daya yang sama berlaku untuk baik volume maupun klaim.

Selector

Klaim dapat menspesifikasi label selector untuk memilih serangkaian volume lebih jauh. Hanya volume yang cocok labelnya dengan selector yang dapat terikat dengan klaim. Selector dapat terdiri dari dua kolom:

• matchLabels - volume harus memiliki label dengan nilai ini
• matchExpressions - daftar dari persyaratan yang dibuat dengan menentukan kunci, daftar nilai, dan operator yang menghubungkan kunci dengan nilai. Operator yang valid meliputi In, NotIn, Exists, dan DoesNotExist.

Semua persyaratan tersebut, dari matchLabels dan matchExpressions akan dilakukan operasi AND bersama – semuanya harus dipenuhi untuk mendapatkan kecocokan.

Kelas

Sebuah klaim dapat meminta kelas tertentu dengan menspesifikasi nama dari StorageClass menggunakan atribut storageClassName. Hanya PV dari kelas yang diminta, yang memiliki storageClassName yang sama dengan PVC, yang dapat terikat dengan PVC.

PVC tidak harus meminta sebuah kelas. Sebuah PVC dengan storageClassName miliknya bernilai "" akan selalu diinterpretasikan sebagai meminta PV tanpa kelas, jadi PVC hanya bisa terikat ke PV tanpa kelas (tanpa anotasi atau bernilai ""). Sebuah PVC tanpa storageClassName tidaklah sama dan diperlakukan berbeda oleh klaster tergantung apakah admission plugin DefaultStorageClass dinyalakan.

• Jika admission plugin dinyalakan, administrator bisa menspesifikasi StorageClass standar. Seluruh PVC yang tidak memiliki storageClassName dapat terikat hanya ke PVs standar. Menspesifikasikan StorageClass standar dapat dilakukan dengan mengatur anotasi storageclass.kubernetes.io/is-default-class menjadi "true" pada sebuah objek StorageClass. Jika administrator tidak menspesifikasikan standar apapun, klaster menanggapi pembuatan PVC sekan-akan admission plugin dimatikan. Jika ada lebih dari satu setelan standar dispesifikasikan, admission plugin melarang pembuatan seluruh PVC.
• Jika admission plugin dimatikan, tidak ada pilihan menggunakan StorageClass standar. Semua PVC yang tidak memiliki storageClassName hanya dapat diikat ke PV yang tidak memiliki kelas. Pada kasus ini, PVC yang tidak memiliki storageClassName diperlakukan sama seperti PVC yang memiliki storageClassName bernilai "".

Tergantung metode instalasi, sebuah StorageClass dari setelan standar dapat dibuat ke klaster Kubernetes oleh addon manager pada saat instalasi.

Ketika sebuah PVC menspesifikasi sebuah selector selain meminta StorageClass, kebutuhan tersebut akan digabungkan dengan operasi AND bersama: hanya PV dari kelas yang diminta dan dengan label yang diminta yang dapat terikat ke PVC.

Dahulu, anotasi volume.beta.kubernetes.io/storage-class digunakan sebagai ganti atribut storageClassName. Anotasi ini masih dapat bekerja, namun akan dihilangkan sepenuhnya pada rilis Kubernetes mendatang.

Klaim sebagai Volume

Pod mengakses storage dengan menggunakan klaim sebagai volume. Klaim harus berada pada namespace yang sama dengan pod yang menggunakan klaim tersebut. Klaster menemukan klaim pada namespace yang sama dengan pod dan menggunakannya untuk mendapatkan PersistentVolume (PV) yang ada di baliknya. Volume tersebut kemudian dipasangkan ke host dan lalu ke pod.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

Catatan Mengenai Namespace

Ikatan PersistentVolumes bersifat eksklusif, dan karena PersistentVolumeClaims merupakan objek yang berada pada namespace, pemasangan klaim dengan "banyak" mode (ROX, RWX) hanya dimungkinkan jika berada dalam satu namespace yang sama.

Dukungan Volume Raw Block

Volume plugins berikut mendukung volume raw block, termasuk penyediaan dinamis jika mungkin diterapkan.

• AWSElasticBlockStore
• AzureDisk
• FC (Fibre Channel)
• GCEPersistentDisk
• iSCSI
• Local volume
• RBD (Ceph Block Device)
• VsphereVolume (alpha)

Persistent Volume menggunakan Volume Raw Block

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

Persistent Volume Claim meminta Volume Raw Block

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 10Gi

Spesifikasi Pod yang menambahkan alamat Perangkat Raw Block pada kontainer

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc-container
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc

Mengikat Block Volume

Jika seorang pengguna meminta sebuah volume raw block dengan mengindikasikannya menggunakan kolom volumeMode pada spec PersistentVolumeClaim (PVC), aturan pengikatannya sedikit berbeda dibanding rilis-rilis sebelumnya yang tidak memerhatikan mode ini sebagai bagian dari spec. Di bawah merupakan tabel dari kemungkinan kombinasi yang pengguna dan admin dapat spesifikasikan untuk meminta sebuah perangkat raw block. Tabel tersebut mengindikasikan apakah volume akan terikat atau tidak jika dikombinasikan dengan cara tertentu: Matriks pengikatan volume untuk volume yang disediakan secara statis:

Volume Snapshot dan Dukungan Pemulihan Volume dari Snapshot

Fitur volume snapshot ditambahkan hanya untuk mendukung CSI Volume Plugins. Untuk lebih detail, lihat volume snapshots.

Untuk mengaktifkan dukungan pemulihan sebuah volume dari sebuah sumber data volume snapshot, aktifkan gerbang fitur VolumeSnapshotDataSource pada apiserver dan controller-manager.

Membuat Persistent Volume Claim dari Volume Snapshot

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pvc
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: new-snapshot-test
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

Menulis Konfigurasi Portabel

Jika kamu menulis templat konfigurasi atau contoh yang dapat berjalan pada berbagai macam klaster dan membutuhkan persistent storage, kami merekomendasikan agar kamu menggunakan pola berikut:

• Masukkan objek PersistentVolumeClaim (PVC) pada kumpulan config (bersamaan dengan Deployments, ConfigMaps, dsb).
• Jangan memasukkan objek PersistentVolume (PV) pada config, karena pengguna yang menginstantiasi config tersebut kemungkinan tidak memiliki izin untuk membuat PersistentVolume (PV).
• Berikan pengguna opsi untuk menyediakan nama storage class ketika menginstantiasi templat.
  • Jika pengguna menyediakan nama storage class, taruh nilai tersebut pada kolom persistentVolumeClaim.storageClassName. Hal ini akan membuat PVC agar sesuai dengan storage class yang tepat jika klaster memiliki banyak StorageClass yang diaktifkan oleh admin.
  • Jika pengguna tidak menyediakan nama storage class, biarkan kolom persistentVolumeClaim.storageClassName kosong.
    • Hal ini kakan membuat sebuah PV disediakan secara otomatis untuk pengguna dengan StorageClass standar pada klaster. Banyak lingkungan klaster memiliki StorageClass standar yang sudah terpasang, atau administrator dapat membuat StorageClass standar sendiri.
• Dalam pembuatan, perhatikan PVC yang tidak kunjung terikat setelah beberapa lama dan beritahukan hal ini pada pengguna, karena hal ini dapat mengindikasikan klaster tidak memiliki dukungan penyimpanan dinamis (di mana pengguna harus membuat PV yang sesuai) atau klaster tidak memiliki sistem penyimpanan (di mana penggun tidak dapat membuat PVC yang membutuhkan config).