Konsep

Edit This Page

StorageClass

Dokumen ini mendeskripsikan konsep StorageClass yang ada pada Kubernetes. Sebelum lanjut membaca, sangat dianjurkan untuk memiliki pengetahuan terhadap volumes dan peristent volume terlebih dahulu.

Pengenalan

Sebuah StorageClass menyediakan cara bagi administrator untuk mendeskripsikan “kelas” dari penyimpanan yang mereka sediakan. Kelas yang berbeda bisa saja memiliki perbedaan dari segi kualitas servis yang disediakan, pemulihan (backup) kebijakan, atau kebijakan lain yang ditentukan oleh administrator kluster. Kubernetes sendiri tidak dipengaruhi oleh kelas apakah yang digunakan pada mekanisme penyimpanan yang digunakan. Mekanisme ini seringkali disebut sebagai “profiles” pada sistem penyimpanan yang lain.

Sumber daya StorageClass

Setiap StorageClass (kelas penyimpanan) memiliki field-field mendasar seperti provisioner, parameters, dan reclaimPolicy, yang digunakan ketika PersistentVolume yang dimiliki oleh kelas tersebut perlu disediakan (di-provision).

Nama yang digunakan oleh suatu StorageClass sifatnya penting, karena ini merupakan cara yang digunakan oleh pengguna untuk meminta penyimpanan dengan kelas tertentu. Administrator dapat menentukan nama dan parameter lain dari suatu kelas ketika membuat suatu objek StorageClass, dan objek yang sudah dibuat tidak dapat diubah lagi definisinya.

Administrator dapat memberikan spesifikasi StorageClass default bagi PVC yang tidak membutuhkan kelas tertentu untuk dapat melakukan mekanisme bind: kamu dapat membaca bagian PersistentVolumeClaim untuk penjelasan lebih lanjut.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
reclaimPolicy: Retain
mountOptions:
  - debug
volumeBindingMode: Immediate

Provisioner

Setiap kelas penyimpanan (storage class) memiliki sebuah provisioner yang menentukan plugin manakah yang digunakan ketika sebuah PV disediakan (di-provision). Field ini haruslah didefinisikan.

Plugin VolumeProvisioner InternalContoh Konfigurasi
AWSElasticBlockStoreAWS EBS
AzureFileAzure File
AzureDiskAzure Disk
CephFS--
CinderOpenStack Cinder
FC--
Flexvolume--
Flocker-
GCEPersistentDiskGCE PD
GlusterfsGlusterfs
iSCSI--
QuobyteQuobyte
NFS--
RBDCeph RBD
VsphereVolumevSphere
PortworxVolumePortworx Volume
ScaleIOScaleIO
StorageOSStorageOS
Local-Local

Kamu tidak dibatasi untuk hanya menggunakan provisioner internal yang disediakan pada list yang tersedia (yang memiliki nama dengan prefix “kubernetes.io” dan didistribusikan bersamaan dengan Kubernetes). Kamu juga dapat menjalankan dan mendefinisikan provisioner eksternal yang merupakan program independen selama program tersebut menerapkan spesifikasi yang didefinisikan oleh Kubernetes. Penulis dari provisioner eksternal Kubernetes memiliki kuasa penuh akan tempat dimana kode sumber yang mereka tulis, bagaimana mekanisme penyediaan (provisioning) dilakukan, serta bagaimana hal tersebut dapat dijalankan, serta plugin volume apakah yang digunakan (termasuk Flex), dkk. Repositori kubernetes-incubator/external-storage menyimpan library yang dibutukan untuk menulis provisioner eksternal yang mengimplementasi spesifikasi serta beberapa provisioner eksternal yang dipelihara oleh komunitas.

Sebagai contoh, NFS tidak menyediakan provisioner internal, tetapi sebuah provisioner eksternal dapat digunakan. Beberapa provisioner eksternal dapat ditemukan di bawah repositori kubernetes-incubator/external-storage. Di sana juga terdapat beberapa kasus dimana vendor penyimpanan 3rd party menyediakan provisioner eksternal yang mereka sediakan sendiri.

Perolehan Kembali untuk Kebijakan (Reclaim Policy)

Persistent Volumes yang secara dinamis dibuat oleh sebuah kelas penyimpanan akan memiliki reclaim policy yang didefinisikan di dalam field reclaimPolicy dari kelas tersebut, yang nilainya dapat diisi dengan Delete atau Retain. Jika tidak terdapat reclaimPolicy yang dispesifikasikan ketika sebuah objek StorageClass dibuat, maka nilai default bagi kelas tersebut adalah Delete.

PersistentVolume yang dibuat secara manual dan diatur dengan menggunakan kelas penyimpanan akan menggunakan reclaim policy apapun yang diberikan pada saat objek tersebut dibuat.

Pilihan Mount

PersistentVolume yang secara dinamis dibuat oleh sebuah kelas penyimpanan akan memiliki pilihan mount yang dapat dispesifikasikan pada field mountOptions dari kelas tersebut.

Jika sebuah plugin volume tidak mendukung pilihan mount yang dispesifikasikan, mekanisme penyediaan (provision) akan digagalkan. Pilihan mount yang akan divalidasi pada kelas penyimpanan maupun PV, maka mount tersebut akan gagal apabila salah satu dari keduanya bersifat invalid.

Mode Volume Binding

Field volumeBindingMode mengontrol kapan mekanisme binding volume dan provisioning dinamis harus dilakukan.

Secara default, ketika mode Immediate yang mengindikasikan terjadinya volume binding dan provisioning dinamis terjadi ketika PersistentVolumeClaim dibuat. Untuk backend penyimpanan yang dibatasi oleh topologi tertentu dan tidak dapat diakses secara global dari semua Node yang ada di kluster, PersistentVolume akan di-bound atau di-provision tanpa perlu memenuhi persyaratan scheduling dari Pod. Hal ini dapat menyebabkan adanya Pod yang tidak mendapatkan mekanisme scheduling.

Seorang administrator kluster dapat mengatasi hal tersebut dengan cara memberikan spesifikasi mode WaitForFirstConsumer yang akan memperlambat mekanisme provisioning dan binding dari sebuah PersistentVolume hingga sebuah Pod yang menggunakan PersistentVolumeClaim dibuat. PersistentVolume akan dipilih atau di-provisioning sesuai dengan topologi yang dispesifikasikan oleh limitasi yang diberikan oleh mekanisme scheduling Pod. Hal ini termasuk, tetapi tidak hanya terbatas pada, persyaratan sumber daya, node selector, afinitas dan anti-afinitas Pod, serta taint dan toleration.

Beberapa plugin di bawah ini mendukung WaitForFirstConsumer dengan provisioning dinamis:

Beberapa plugin di bawah ini mendukung WaitForFirstConsumer dengan binding PersistentVolume yang terlebih dahulu dibuat:

FEATURE STATE: Kubernetes 1.14 beta
Fitur ini berada dalam tingkatan beta, yang artinya:

  • Nama dari versi ini mengandung string beta (misalnya v2beta3).
  • Kode yang ada sudah melalui mekanisme testing yang cukup baik. Menggunakan fitur ini dianggap cukup aman. Fitur ini diekspos secara default.
  • Ketersediaan untuk fitur secara menyeluruh tidak akan dihapus, meskipun begitu detail untuk suatu fitur bisa saja berubah.
  • Skema dan/atau semantik dari suatu obyek mungkin saja berubah tanpa memerhatikan kompatibilitas pada rilis beta selanjutnya. Jika hal ini terjadi, kami akan menyediakan suatu instruksi untuk melakukan migrasi di versi rilis selanjutnya. Hal ini bisa saja terdiri dari penghapusan, pengubahan, ataupun pembuatan obyek API. Proses pengubahan mungkin saja membutuhkan pemikiran yang matang. Dampak proses ini bisa saja menyebabkan downtime aplikasi yang bergantung pada fitur ini.
  • Kami mohon untuk mencoba versi beta yang kami sediakan dan berikan masukan terhadap fitur yang kamu pakai! Apabila fitur tersebut sudah tidak lagi berada di dalam tingkatan beta perubahan yang kami buat terhadap fitur tersebut bisa jadi tidak lagi dapat digunakan

Volume-volume CSI juga didukung dengan adanya provisioning dinamis serta PV yang telah terlebih dahulu dibuat, meskipun demikian, akan lebih baik apabila kamu melihat dokumentasi untuk driver spesifik CSI untuk melihat topologi key yang didukung beserta contoh penggunaannya. Feature gate CSINodeInfo haruslah diaktifkan.

Topologi yang Diizinkan

Ketika sebuah operator kluster memberikan spesifikasi WaitForFirstConsumer pada mode binding volume, mekanisme pembatasan (restriksi) provisioning tidak lagi dibutuhkan pada sebagian besar kasus. Meskipun begitu, apabila hal tersebut masih dibutuhkan, field allowedTopologies dapat dispesifikasikan.

Contoh ini memberikan demonstrasi bagaimana cara membatasi topologi dari volume yang di-provision pada suatu zona spesifik serta harus digunakan sebagai pengganti parameter zone dam zones untuk plugin yang akan digunakan.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: failure-domain.beta.kubernetes.io/zone
    values:
    - us-central1-a
    - us-central1-b

Parameter-Parameter

Kelas-kelas penyimpanan memiliki parameter yang mendeskripsikan volume yang dimiliki oleh kelas penyimpanan tersebut. Parameter yang berbeda bisa saja diterima bergantung pada provisioner. Sebagai contohnya, nilai io1, untuk parameter type, dan parameter iopsPerGB spesifik terhadap EBS. Ketika sebuah parameter diabaikan, beberapa nilai default akan digunakan sebagai gantinya.

AWS EBS

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/aws-ebs
parameters:
  type: io1
  iopsPerGB: "10"
  fsType: ext4
Catatan: Parameter zone dan zones sudah terdeprekasi dan digantikan oleh allowedTopologies

PD GCE

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  replication-type: none

Jika replication-type diubah menjadi none, sebuah PD reguler (zonal) akan di-provisioning.

Jika replication-type diubah menjadi regional-pd, sebuah Persistent Disk Regional (PD Regional) akan di-provisioning. Pada kasus ini, pengguna harus menggunakan zones dan bukan zone untuk menspesifikasikan zona replikasi yang diinginkan. Jika terdapat tepat dua zona yang dispesifikasikan, PD Regional akan di-provisioning pada zona replikasi yang diinginkan. Jika terdapat lebih dari 2 zona yang dispesifikasikan, Kubernetes akan memilih secara acak zona dari zona-zona yang dispesifikasikan. Jika parameter zones tidak diinisialisasi, Kubernetes akan memilih secara acak dari zona yang diatur oleh kluster Kubernetes.

Catatan: Parameter zone dan zones sudah deprecated dan digantikan oleh allowedTopologies

Glusterfs

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/glusterfs
parameters:
  resturl: "http://127.0.0.1:8081"
  clusterid: "630372ccdc720a92c681fb928f27b53f"
  restauthenabled: "true"
  restuser: "admin"
  secretNamespace: "default"
  secretName: "heketi-secret"
  gidMin: "40000"
  gidMax: "50000"
  volumetype: "replicate:3"

Sebagai contoh:

Untuk tipe volume apa saja yang tersedia dan berbagai opsi administrasi yang ada, kamu dapat membaca Petunjuk Administrasi.

Untuk informasi lebih lanjut, kamu dapat membaca Bagaimana Cara Mengatur Heketi.

Ketika PersistentVolume di-provisioning secara dinamis, plugin Gluster secara otomatis akan membuat endpoint serta sebuah servis headless dengan nama gluster-dynamic-<claimname>. Endpoint dinamis dan servis secara otomatis akan dihapus ketika PVC dihapus.

OpenStack Cinder

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gold
provisioner: kubernetes.io/cinder
parameters:
  availability: nova
Catatan:
FEATURE STATE: Kubernetes 1.11 deprecated
Fitur ini deprecated. Untuk informasi lebih lanjut mengenai tingkatan ini, silahkan merujuk pada Kubernetes Deprecation Policy

Provisioner internal OpenStack ini sudah deprecated. Kamu dapat menggunakan provider eksternal penyedia layanan cloud untuk OpenStack.

vSphere

  1. Buatlah sebuah StorageClass dengan menggunakan sebuah format disk yang dispesifikasikan oleh pengguna.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: fast
    provisioner: kubernetes.io/vsphere-volume
    parameters:
      diskformat: zeroedthick

    diskformat: thin, zeroedthick dan eagerzeroedthick. Nilai default: "thin".

  2. Buatlah sebuah StorageClass dengan menggunakan sebuah format disk pada datastore yang dispesifikasikan oleh pengguna.

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: fast
    provisioner: kubernetes.io/vsphere-volume
    parameters:
        diskformat: zeroedthick
        datastore: VSANDatastore

    datastore: Pengguna juga dapat menspesifikasikan datastore pada StorageClass. Volume akan dibuat pada datastore yang dispesifikasikan pada kelas penyimpanan, dalam hal ini adalah VSANDatastore. Field ini bersifat opsional. Jika datastore tidak dispesifikasikan, maka volume akan dibuat dengan menggunakan datastore yang dispesifikasikan pada berkas konfigurasi vSphere yang digunakan untuk menginisialisasi penyedia layanan cloud vSphere.

  3. Manajemen Kebijakan Penyimpanan di dalam Kubernetes

    • Menggunakan kebijakan (policy) yang ada pada vCenter

      Salah satu dari fitur paling penting yang ada pada vSphere untuk manajemen penyimpanan adalah manajemen bebasis policy. Storage Policy Based Management (SPBM) adalah framework yang menyediakan sebuah control plane terpadu pada data service yang meluas dan solusi penyimpanannya yang tersedia. SPBM memungkinkan administrator vSphere menghadapi permasalahan yang mungkin muncul seperti capacity planning, membedakan level servis, dan melakukan manajemen headroom capacity.

      Policy SPBM dapat dispesifikasikan pada StorageClass menggunakan parameter storagePolicyName.

    • Dukungan policy SAN virtual di dalam Kubernetes

      Administrator Vsphere Infrastructure (VI) akan memiliki kemampuan untuk menspesifikasikan Virtual SAN Storage Capabilities khusus selama masa provisioning volume secara dinamis. Persyaratan kapabilitas penyimpanan diubah menjadi sebuah policy Virtual SAN yang nantinya akan dimasukkan ke dalam lapisan Virtual SAN ketika sebuah persitent volume (penyimpanan virtual) dibuat. Penyimpanan virtual kemudian akan didistribusikan pada semua datastore Virtual SAN untuk memenuhi kebutuhan ini.

      Kamu dapat melihat Policy Penyimpanan Berdasarkan Manajemen untuk Provisioning Dinamis Volume untuk detil lebih lanjut mengenai penggunaan policy penyimpanan untuk manajemen persistent volume.

Terdapat beberapa contoh vSphere yang dapat kamu gunakan untuk mencoba manajemen persistent volume di dalam Kubernetes untuk vSpehere.

RBD Ceph

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd
parameters:
  monitors: 10.16.153.105:6789
  adminId: kube
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
  userSecretNamespace: default
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"

Quobyte

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: slow
provisioner: kubernetes.io/quobyte
parameters:
    quobyteAPIServer: "http://138.68.74.142:7860"
    registry: "138.68.74.142:7861"
    adminSecretName: "quobyte-admin-secret"
    adminSecretNamespace: "kube-system"
    user: "root"
    group: "root"
    quobyteConfig: "BASE"
    quobyteTenant: "DEFAULT"

Azure Disk

Kelas Penyimpanan Disk Azure yang Tidak Dikelola

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/azure-disk
parameters:
  skuName: Standard_LRS
  location: eastus
  storageAccount: azure_storage_account_name

Kelas Penyimpanan Disk Azure yang Baru (mulai versi v1.7.2)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/azure-disk
parameters:
  storageaccounttype: Standard_LRS
  kind: Shared

Berkas Azure

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
  skuName: Standard_LRS
  location: eastus
  storageAccount: azure_storage_account_name

Selama provision, sebuah secret dibuat untuk menyimpan credentials. Jika kluster menggunakan konsep RBAC dan Roles Controller, menambahkan kapabilitas create untuk sumber daya secret bagi clusterrole system:controller:persistent-volume-binder.

Volume Portworx

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: portworx-io-priority-high
provisioner: kubernetes.io/portworx-volume
parameters:
  repl: "1"
  snap_interval:   "70"
  io_priority:  "high"

ScaleIO

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: kubernetes.io/scaleio
parameters:
  gateway: https://192.168.99.200:443/api
  system: scaleio
  protectionDomain: pd0
  storagePool: sp1
  storageMode: ThinProvisioned
  secretRef: sio-secret
  readOnly: false
  fsType: xfs

Plugin volume ScaleIO Kubernetes membutuhkan objek Secret yang suda dikonfigurasi sebelumnya. Secret ini harus dibuat dengan tipe kubernetes.io/scaleio dan menggunakan namespace yang sama dengan PVC yang dirujuk, seperti ditunjukkan pada contoh yang ada:

kubectl create secret generic sio-secret --type="kubernetes.io/scaleio" \
--from-literal=username=sioadmin --from-literal=password=d2NABDNjMA== \
--namespace=default

StorageOS

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/storageos
parameters:
  pool: default
  description: Kubernetes volume
  fsType: ext4
  adminSecretNamespace: default
  adminSecretName: storageos-secret

Plugin volume dapat menggunakan objek Secret untuk menspesifikasikan endpoint dan kredensial yang digunakan untuk mengakses API StorageOS. Hal ini hanya akan dibutuhkan apabila terdapat perubahan pada nilai default. Secret ini harus dibuat dengan tipe kubernetes.io/storageos, seperti ditunjukkan pada contoh yang ada:

kubectl create secret generic storageos-secret \
--type="kubernetes.io/storageos" \
--from-literal=apiAddress=tcp://localhost:5705 \
--from-literal=apiUsername=storageos \
--from-literal=apiPassword=storageos \
--namespace=default

Secret yang digunakan untuk melakukan provisioning volume secara dinamis dapat dibuat di namespace apapun dan dirujuk dengan menggunakan parameter adminSecretNamespace. Secret yang digunakan oleh volume yang sedang di-provisioning harus dibuat pada namespace yang sama dengan PVC yang merujuk secret tersebut.

Lokal

FEATURE STATE: Kubernetes v1.14 stable
Cette fonctionnalité est stable, ce qui signifie :

  • Le nom de version est vX où X est un entier.
  • Les versions stables des fonctionnalités seront maintenues pour de nombreuses versions ultérieures.
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

Volume lokal tidak mendukung adanya provisioning secara dinamis, meskipun begitu sebuah StorageClass akan tetap dibuat untuk mencegah terjadinya bind volume sampai scheduling pod dilakukan. Hal ini dispesifikasikan oleh mode binding volume WaitForFirstConsumer.

Memperlambat binding volume mengizinkan scheduler untuk memastikan batasan scheduling semua pod ketika memilih PersistentVolume untuk sebuah PersistentVolumeClaim.

Masukan