Storage

• 1: Volume
• 2: Persistent Volume
• 3: VolumeSnapshot
• 4: Pengklonaan Volume CSI
• 5: StorageClass
• 6: VolumeSnapshotClass
• 7: Penyediaan Volume Dinamis
• 8: Limit Volume yang Spesifik terhadap Node

1 - Volume

Berkas-berkas yang disimpan di disk di dalam Container bersifat tidak permanen (akan terhapus seiring dengan dihapusnya Container/Pod), yang menimbulkan beberapa masalah untuk aplikasi biasa saat berjalan di dalam Container. Pertama, saat sebuah Container mengalami kegagalan, Kubelet akan memulai kembali Container tersebut, tetapi semua berkas di dalamnya akan hilang - Container berjalan dalam kondisi yang bersih. Kedua, saat menjalankan banyak Container bersamaan di dalam sebuah Pod, biasanya diperlukan untuk saling berbagi berkas-berkas di antara Container-container tersebut. Kedua masalah tersebut dipecahkan oleh abstraksi Volume pada Kubernetes.

Pengetahuan tentang Pod disarankan.

Latar Belakang

Docker juga memiliki konsep volume, walaupun konsepnya Docker agak lebih fleksibel dan kurang dikelola. Pada Docker, sebuah volume adalah sesederhana sebuah direktori pada disk atau di dalam Container lainnya. Lifetime tidak dikelola dan hingga baru-baru ini hanya ada volume yang didukung disk lokal. Docker sekarang menyediakan driver untuk volume, namun fungsionalitasnya masih sangat terbatas (misalnya hingga Docker 1.7 hanya ada satu driver volume yang diizinkan untuk setiap Container, dan tidak ada cara untuk menyampaikan parameter kepada volume).

Sebaliknya, sebuah Volume Kubernetes memiliki lifetime yang gamblang - sama dengan lifetime Pod yang berisi Volume tersebut. Oleh karena itu, sebuah Volume bertahan lebih lama dari Container-container yang berjalan di dalam Pod tersebut, dan data di Volum tersebut juga dipertahankan melewati diulangnya Container. Tentu saja, saat sebuah Pod berakhir, Volume tersebut juga akan berakhir/terhapus. Dan mungkin lebih penting lagi, Kubernetes mendukung banyak jenis Volume, dan sebuah Pod dapat menggunakan sebanyak apapun Volume secara bersamaan.

Pada intinya, sebuah volume hanyalah sebuah direktori, dan mungkin berisi data, yang dapat diakses oleh Container-container di dalam Pod. Bagaimana direktori tersebut dibuat, medium yang menyokongnya, dan isinya ditentukan oleh jenis volume yang digunakan.

Untuk menggunakan sebuah volume, sebuah Pod memerinci volume-volume yang akan disediakan untuk Pod tersebut (kolom .spec.volumes) dan di mana volume-volume tersebut akan ditambatkan (di-mount) di dalam Container-container di Pod (kolom .spec.containers.volumeMounts).

Sebuah proses di dalam Container memiliki sudut pandang filesystem yang disusun dari image dan volume Dockernya. Docker Image berada pada bagian teratas hierarki filesystem, dan volume manapun yang ditambatkan pada path yang diperinci di dalam Image tersebut. Volume tidak dapat ditambatkan pada volume lain atau memiliki hard link ke volume lain. Setiap Container di dalam Pod harus secara independen memerinci di mana tiap Volume ditambatkan.

Jenis-jenis Volume

Kubernetes mendukung beberapa jenis Volume:

• awsElasticBlockStore
• azureDisk
• azureFile
• cephfs
• cinder
• configMap
• csi
• downwardAPI
• emptyDir
• fc (fibre channel)
• flexVolume
• flocker
• gcePersistentDisk
• gitRepo (deprecated)
• glusterfs
• hostPath
• iscsi
• local
• nfs
• persistentVolumeClaim
• projected
• portworxVolume
• quobyte
• rbd
• scaleIO
• secret
• storageos
• vsphereVolume

Kami menyambut kontribusi tambahan.

awsElasticBlockStore

Sebuah Volume awsElasticBlockStore menambatkan sebuah Volume EBS Amazon Web Services (AWS) ke dalam Pod kamu. Hal ini berarti bahwa sebuah Volume EBS dapat sebelumnya diisi terlebih dahulu dengan data, dan data dapat "dipindahkan" diantara banyak Pod.

Ada beberapa batasan saat menggunakan Volume awsElasticBlockStore:

• Node di mana Pod berjalan haruslah merupakan instance AWS EC2.
• Instance tersebut mesti berada pada region dan availability-zone yang sama dengan volume EBS.
• EBS hanya mendukung penambatan pada satu instance EC2 pada saat yang bersamaan.

Membuat sebuah Volume EBS

Sebelum kamu dapat menggunakan sebuah volume EBS pada sebuah Pod, kamu harus membuatnya pada AWS terlebih dahulu.

aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2

Pastikan availability zone yang kamu masukkan sama dengan availability zone klaster kamu. (Dan pastikan juga ukuran dan jenis EBSnya sesuai dengan penggunaan yang kamu butuhkan!)

Contoh Konfigurasi AWS EBS

apiVersion: v1
kind: Pod
metadata:
  name: test-ebs
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-ebs
      name: test-volume
  volumes:
  - name: test-volume
    # volume EBS ini harus sudah dibuat di AWS
    awsElasticBlockStore:
      volumeID: <volume-id>
      fsType: ext4

Migrasi CSI awsElasticBlocStore

Pada saat fitur migrasi CSI (Container Storage Interface) untuk awsElasticBlockStore diaktifkan, fitur ini akan menterjemahkan semua operasi plugin dari plugin yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI ebs.csi.aws.com. Untuk menggunakan fitur ini, Driver CSI AWS EBS harus dinstal di klaster dan fitur Alpha CSIMigration serta CSIMigrationAWS harus diaktifkan.

azureDisk

Sebuah azureDisk digunakan untuk menambatkan sebuah Data Disk Microsoft Azure ke dalam sebuah Pod.

Selengkapnya dapat ditemukan di sini.

Migrasi CSI azureDisk

Pada saat fitur migrasi CSI untuk azureDisk diaktifkan, fitur ini akan menterjemahkan semua operasi plugin dari plugin yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI disk.csi.azure.com. Untuk menggunakan fitur ini, Driver CSI Azure Disk harus dinstal di klaster dan fitur Alpha CSIMigration serta CSIMigrationAzureDisk harus diaktifkan.

azureFile

Sebuah azureFile digunakan untuk menambatkan sebuah Microsoft Azure File Volume (SMB 2.1 dan 3.0) ke dalam sebuah Pod.

Selengkapnya dapat ditemukan di sini.

Migrasi CSI azureFile

Pada saat fitur migrasi CSI untuk azureFile diaktifkan, fitur ini akan menterjemahkan semua operasi plugin dari plugin yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI file.csi.azure.com. Untuk menggunakan fitur ini, Driver CSI Azure File harus dinstal di klaster dan fitur Alpha CSIMigration serta CSIMigrationAzureFile harus diaktifkan.

cephfs

Sebuah Volume cephfs memungkinkan sebuah volume CephFS yang sudah ada untuk ditambatkan ke dalam Pod kamu. Berbeda dengan emptyDir, yang juga ikut dihapus saat Pod dihapus, isi data di dalam sebuah volume CephFS akan dipertahankan dan Volume tersebut hanya dilepaskan tambatannya (mount-nya). Hal ini berarti bahwa sebuah Volume CephFS dapat sebelumnya diisi terlebih dahulu dengan data, dan data dapat "dipindahkan" diantara banyak Pod.

Selengkapnya, lihat contoh CephFS.

cinder

cinder digunakan untuk menambatkan Volume Cinder ke dalam Pod kamu.

Contoh Konfigurasi Volume Cinder

apiVersion: v1
kind: Pod
metadata:
  name: test-cinder
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-cinder-container
    volumeMounts:
    - mountPath: /test-cinder
      name: test-volume
  volumes:
  - name: test-volume
    # Volume OpenStack ini harus sudah ada sebelumnya.
    cinder:
      volumeID: <volume-id>
      fsType: ext4

Migrasi CSI Cinder

Pada saat fitur migrasi CSI untuk Cinder diaktifkan, fitur ini akan menterjemahkan semua operasi plugin dari plugin yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI cinder.csi.openstack.com. Untuk menggunakan fitur ini, Driver CSI Openstack Cinder harus dinstal di klaster dan fitur Alpha CSIMigration serta CSIMigrationOpenStack harus diaktifkan.

configMap

Sumber daya configMap memungkinkan kamu untuk menyuntikkan data konfigurasi ke dalam Pod. Data yang ditaruh di dalam sebuah objek ConfigMap dapat dirujuk dalam sebuah Volume dengan tipe configMap dan kemudian digunakan oleh aplikasi/container yang berjalan di dalam sebuah Pod.

Saat mereferensikan sebuah objek configMap, kamu tinggal memasukkan nama ConfigMap tersebut ke dalam rincian Volume yang bersangkutan. Kamu juga dapat mengganti path spesifik yang akan digunakan pada ConfigMap. Misalnya, untuk menambatkan ConfigMap log-config pada Pod yang diberi nama configmap-pod, kamu dapat menggunakan YAML ini:

apiVersion: v1
kind: Pod
metadata:
  name: configmap-pod
spec:
  containers:
    - name: test
      image: busybox
      volumeMounts:
        - name: config-vol
          mountPath: /etc/config
  volumes:
    - name: config-vol
      configMap:
        name: log-config
        items:
          - key: log_level
            path: log_level

ConfigMap log-config ditambatkan sebagai sebuah Volume, dan semua isinya yang ditaruh di dalam entri log_level-nya ditambatkan dalam Pod tersebut pada path "/etc/config/log_level". Perlu dicatat bahwa path tersebut berasal dari isian mountPath pada Volume, dan path yang ditunjuk dengan key bernama log_level.

downwardAPI

Sebuah Volume downwardAPI digunakan untuk menyediakan data downward API kepada aplikasi. Volume ini menambatkan sebuah direktori dan menulis data yang diminta pada berkas-berkas teks biasa.

Lihat contoh Volume downwardAPI untuk lebih detilnya.

emptyDir

Sebuah Volume emptyDir pertama kali dibuat saat sebuah Pod dimasukkan ke dalam sebuah Node, dan akan terus ada selama Pod tersebut berjalan di Node tersebut. Sesuai dengan namanya, Volume ini awalnya kosong. Container-container di dalam Pod dapat membaca dan menulis berkas-berkas yang sama di dalam Volume emptyDir, walaupun Volume tersebut dapat ditambatkan pada path yang sama maupun berbeda pada setiap Container. Saat sebuah Pod dihapus dari sebuah Node untuk alasan apapun, data di dalam emptyDir tersebut dihapus untuk selamanya.

Beberapa kegunaan emptyDir adalah sebagai berikut:

• Scratch space, misalnya untuk merge sort menggunakan berkas-berkas di disk
• Checkpointing untuk komputasi panjang yang dipulihkan dari proses yang sebelumnya mengalami kegagalan
• Menyimpan berkas-berkas yang diambil oleh Container aplikasi Content Manager saat sebuah peladen web melayani data tersebut

Secara bawaan, emptyDir ditaruh pada media penyimpanan apapun yang menyokong Node yang bersangkuta - mungkin sebuah disk atau SSD atau penyimpanan berbasis jaringan, tergantung lingkungan Node yang kamu miliki. Tetapi, kamu juga dapat menyetel bagian emptyDir.medium menjadi "Memory" untuk memberitahukan pada Kubernetes untuk menggunakan sebuah tmpfs (filesystem berbasis RAM) sebagai gantinya. tmpfs memang sangan cepat, tetapi kamu harus sadar bahwa ia tidak seperti disk, data di tmpfs akan terhapus saat Node tersebut diulang kembali. Selain itu, berkas apapun yang kamu tulis akan dihitung terhadap limit memory milik Container kamu.

Contoh Pod

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /cache
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}

fc (fibre channel)

Sebuah Volume fc memunginkan sebuah volume fibre channel yang sudah ada untuk ditambatkan ke sebuah Pod. Kamu dapat menentukan satu atau banyak target World Wide Names menggunakan parameter targetWWNs pada konfigurasi Volume kamu. Jika banyak WWN ditentukan, maka targetWWNs mengharapkan bahwa WWN tersebut berasal dari koneksi multi-path.

Lihat Contoh FC untuk lebih detilnya.

flocker

Flocker adalah sebuah proyek open-source yg berfungsi sebagai pengatur volume data Container yang diklasterkan. Flocker menyediakan pengelolaan dan orkestrasi volume yang disokong oleh banyak jenis media penyimpanan.

Sebuah Volume flockere memungkinkan sebuah dataset Flocker untuk ditambatkan ke dalam sebuah Pod. Jika dataset tersebut belum ada di dalam Flocker, maka ia harus dibuat terlebih dahulu dengan menggunakan Flocker CLI atau menggunakan Flocker API. Jika dataset tersebut sudah ada, ia akan ditambatkan kembali oleh Flocker ke Node di mana Pod tersebut dijadwalkan. Hal ini berarti data dapat dioper diantara Pod-pod sesuai dengan kebutuhan.

Lihat Contoh Flocker untuk lebih detil.

gcePersistentDisk

Sebuah volume gcePersistentDisk menambatkan sebuah PersistentDisk Google Compute Engine (GCE) ke dalam Pod kamu. Tidak seperti emptyDir yang ikut dihapus saat Pod dihapus, isi dari sebuah PD dipertahankan dan volume-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah PD dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod.

Ada beberapa batasan saat menggunakan sebuah gcePersistentDisk:

• Node-node di mana Pod-pod berjalan haruslah GCE VM.
• VM tersebut harus berada pada proyek GCE yang sama dan zone yang sama dengan PD tersebut

Sebuah fitur PD yaitu mereka dapat ditambatkan sebagai read-only secara bersamaan oleh beberapa pengguna. Hal ini berarti kamu dapat mengisi data terlebih dahulu dan menyediakan data tersebut secara paralel untuk sebanyak apapun Pod yang kamu butuhkan. Sayangnya, PD hanya dapat ditambatkan kepada satu pengguna saja pada mode read-write - yaitu, tidak boleh ada banyak penulis secara bersamaan.

Menggunakan sebuah PD pada sebuah Pod yang diatur oleh sebuah ReplicationController akan gagal, kecuali jika PD tersebut berada pada mode read-only, atau jumlah replica-nya adalah 0 atau 1.

Membuat sebuah PD

Sebelum kamu dapat menggunakan sebuah PD dengan sebuah Pod, kamu harus membuat PD tersebut terlebih dahulu.

gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk

Contoh Pod

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    # GCE PD ini harus sudah ada.
    gcePersistentDisk:
      pdName: my-data-disk
      fsType: ext4

Regional Persistent Disks

Fitur Regional Persistent Disks memungkinkan pembuatan Persistent Disk yang berada pada beberapa zone pada region yang sama. Untuk menggunakan fitur ini, Volume tersebut harus dibuat sebagai sebuah PersistentVolume; mereferensikan Volume tersebut langsung dari sebuah Pod tidak didukung.

Menyediakan sebuah Regional PD PersistentVolume Secara Manual

Penyediaan secara dinamis mungkin dilakukan dengan sebuah StorageClass untuk GCE PD. Sebelum membuat sebuah PersistentVolume, kamu harus membuat PD-nya:

gcloud beta compute disks create --size=500GB my-data-disk
    --region us-central1
    --replica-zones us-central1-a,us-central1-b

Contoh spesifikasi PersistentVolume:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: test-volume
  labels:
    failure-domain.beta.kubernetes.io/zone: us-central1-a__us-central1-b
spec:
  capacity:
    storage: 400Gi
  accessModes:
  - ReadWriteOnce
  gcePersistentDisk:
    pdName: my-data-disk
    fsType: ext4

Migrasi CSI GCE PD

Pada saat fitur migrasi CSI untuk GCE PD diaktifkan, fitur ini akan menterjemahkan semua operasi plugin dari plugin yang sudah ada di kode inti Kubernetes ke bentuk Driver CSI pd.csi.storage.gke.io. Untuk menggunakan fitur ini, Driver CSI GCE PD harus dinstal di klaster dan fitur Alpha CSIMigration serta CSIMigrationGCE harus diaktifkan.

gitRepo (kedaluwarsa)

Sebuah Volume gitRepo adalah sebuah percontohan yang menunjukkan apa yang dapat dilakukan dengan plugin volume. Ia menambatkan sebuah direktori kosong dan mengklon sebuah repository git ke dalamnya untuk digunakan oleh Pod kamu. Ke depannya, Volume seperti ini dapat dipindahkan ke model yang bahkan lebih terpisah, daripada melakukan ekstensi pada Kubernetes API untuk setiap kasus serupa.

Berikut sebuah contoh Volume gitRepo:

apiVersion: v1
kind: Pod
metadata:
  name: server
spec:
  containers:
  - image: nginx
    name: nginx
    volumeMounts:
    - mountPath: /mypath
      name: git-volume
  volumes:
  - name: git-volume
    gitRepo:
      repository: "git@somewhere:me/my-git-repository.git"
      revision: "22f1d8406d464b0c0874075539c1f2e96c253775"

glusterfs

Sebuah Volume glusterfs memungkinkan sebuah volume Glusterfs (sebuah proyek open-source filesystem berbasis jaringan) untuk ditambatkan ke dalam Pod kamu. Tidak seperti emptyDir yang ikut dihapus saat Pod dihapus, isi dari sebuah glusterfs dipertahankan dan volume-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah glusterfs dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod. GlusterFS dapat ditambatkan kepada beberapa penulis secara bersamaan.

Lihat contoh GlusterFS untuk lebih detil.

hostPath

Sebuah Volume hostPath menambatkan sebuah berkas atau direktori dari filesystem Node di mana Pod kamu berjalan ke dalam Pod kamu. Hal ini bukanlah sesuatu yang dibutuhkan oleh sebagian besar Pod kamu, tetapi hal ini menawarkan sebuah mekanisme pintu darurat untuk beberapa aplikasi.

Contohnya, beberapa kegunaan hostPath adalah sebagai berikut:

• Menjalankan sebuah Container yang membutuhkan akses terhadap sistem dalaman Docker; misalnya menggunakan hostPath dari /var/lib/docker
• Menjalankan cAdvisor di dalam sebuah Container; menggunakan hostPath dari /sys
• Memungkinkan sebuah Pod untuk merinci apakah hostPath harus sudah ada sebelum dijalankannya Pod, apakah ia harus dibuat, dan sebagai apa ia harus dibuat.

Sebagai tambahan pada path yang dibutuhkan, pengguna dapat secara opsional merinci type untuk sebuah hostPath.

Nilai yang didukung untuk kolom type adalah:`

Berhati-hatilah saat menggunakan tipe volume ini, karena:

• Pod-pod dengan konfigurasi identik (misalnya dibuat dari podTemplate) mungkin berperilaku berbeda pada Node-node yang berbeda oleh karena berkas-berkas yang berbeda pada Node-node tersebut.
• Saat Kubernetes menambahkan penjadwalan yang sadar terhadap sumber-daya klaster, sesuai yang telah direncanakan, ia tidak dapat melakukan perhitungan terhadap sumber daya yang digunakan oleh sebuah hostPath
• Berkas-berkas atau direktori-direktori yang dibuat pada host-host bersangkutan hanya dapat ditulis oleh root. Kamu butuh antara menjalankan proses aplikasi kamu sebagai root pada sebuah privileged Container atau mengubah permission berkas kamu pada host tersebut agar dapat menulis pada Volume hostPath

Contoh Pod

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # Lokasi direktori pada host
      path: /data
      # kolom ini bersifat opsional
      type: Directory

iscsi

Sebuah Volume iscsi memungkinkan sebuah volume iSCSI (SCSI over IP) yang sudah ada untuk ditambatkan ke dalam Pod kamu. Tidak seperti emptyDir yang ikut dihapus saat Pod dihapus, isi dari sebuah iscsi dipertahankan dan volume-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah iscsi dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod.

Salah satu fitur iSCSI yaitu mereka dapat ditambatkan sebagai read-only secara bersamaan oleh beberapa pengguna. Hal ini berarti kamu dapat mengisi data terlebih dahulu dan menyediakan data tersebut secara paralel untuk sebanyak apapun Pod yang kamu butuhkan. Sayangnya, iSCSI hanya dapat ditambatkan kepada satu pengguna saja pada mode read-write - yaitu, tidak boleh ada banyak penulis secara bersamaan.

Lihat contoh iSCSI untuk lebih detil.

local

Sebuah Volume local merepresentasikan sebuah media penyimpanan lokal yang ditambatkan, seperti disk, partisi, atau direktori.

Volume local hanya dapat digunakan sebagai PersistentVolume yang dibuat secara statis. Dynamic provisioning belum didukung untuk Volume local.

Dibandingkan dengan Volume hostPath, Volume local dapat digunakan secara durable dan portabel tanpa harus menjadwalkan Pod ke Node secara manual, dikarenakan sistem mengetahui pembatasan yang berlaku terhadap Volume pada Node tersebut, dengan cara melihat node affinity pada PersistentVolume-nya.

Tetapi, Volume local masih bergantung pada ketersediaan Node yang bersangkutan, dan tidak semua aplikasi cocok menggunakannya. Jika sebuah Node tiba-tiba gagal, maka Volume local pada Node tersebut menjadi tidak dapat diakses juga, dan Pod yang menggunakannya tidak dapat dijalankan. Aplikasi yang menggunakan Volumelocal harus dapat mentoleransi hal ini dan juga potensi kehilangan data, tergantung pada karakteristik ketahanan disk yang digunakan.

Berikut sebuah contoh spesifikasi PersistentVolume menggunakan sebuah Volume local dan nodeAffinity:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 100Gi
  # kolom volumeMode membutuhkan diaktifkannya feature gate Alpha
  volumeMode: Filesystem
  accessModes:
  - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - example-node

Kolom nodeAffinity ada PersistentVolue dibutuhkan saat menggunakan Volume local. Ia memungkinkan Kubernetes Scheduler untuk menjadwalkan Pod-pod dengan tepat menggunakan Volume local pada Node yang tepat.

Kolom volumeMode pada PersistentVolume sekarang dapat disetel menjadi "Block" (menggantikan nilai bawaan "Filesystem") untuk membuka Volume local tersebut sebagai media penyimpanan blok mentah. Hal ini membutuhkan diaktifkannya Alpha feature gate BlockVolume.

Saat menggunakan Volume local, disarankan untuk membuat sebuah StorageClass dengan volumeBindingMode yang disetel menjadi WaitForFirstConsumer. Lihatcontohnya. Menunda pengikatan Volume memastikan bahwa keputusan pengikatan PersistentVolumeClaim juga akan dievaluasi terhadap batasan-batasan Node yang berlaku pada Pod, seperti kebutuhan sumber daya Node, nodeSelector, podAffinity, dan podAntiAffinity.

Sebuah penyedia statis eksternal dapat berjalan secara terpisah untuk memperbaik pengaturan siklus hidup Volume local. Perlu dicatat bahwa penyedia ini belum mendukung dynamic provisioning. Untuk contoh bagaimana menjalankan penyedia Volume local eksternal, lihat petunjuk penggunaannya.

nfs

Sebuah Volume nfs memungkinkan sebuah NFS (Network File System) yang sudah ada untuk ditambatkan ke dalam Pod kamu. Tidak seperti emptyDir yang ikut dihapus saat Pod dihapus, isi dari sebuah nfs dipertahankan dan volume-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah nfs dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod. NFS juga dapat ditambatkan oleh beberapa penulis secara sekaligus.

Lihat contoh NFS untuk lebih lanjut.

persistentVolumeClaim

Sebuah Volume persistentVolumeClaim digunakan untuk menambatkan sebuah PersistentVolume ke dalam sebuag Pod. PersistentVolume adalah sebuah cara bagi pengguna untuk "mengklaim" penyimpanan yang durable (seperti sebuah GCE PD atau sebuah volume iSCSI) tanpa mengetahui detil lingkungan cloud yang bersangkutan.

Lihat contoh PersistentVolumes untuk lebih lanjut.

projected

Sebuah Volume projected memetakan beberapa sumber Volume yang sudah ada ke dalam direktori yang sama.

Saat ini, tipe-tipe sumber Volume berikut dapat diproyeksikan:

• secret
• downwardAPI
• configMap
• serviceAccountToken

Semua sumber harus berada pada namespace yang sama dengan Pod yang menggunakannya. Untuk lebih lanjut, lihat dokumen desain Volume.

Proyeksi serviceAccountToken adalah fitur yang diperkenalkan pada Kubernetes 1.11 dan dipromosikan menjadi Beta pada 1.12. Untuk mengaktifkan fitur inipada 1.11, kamu harus menyetel feature gate TokenRequestProjection secara eksplisit menjadi True.

Contoh Pod dengan sebuah Secret, Downward API, dan ConfigMap.

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - downwardAPI:
          items:
            - path: "labels"
              fieldRef:
                fieldPath: metadata.labels
            - path: "cpu_limit"
              resourceFieldRef:
                containerName: container-test
                resource: limits.cpu
      - configMap:
          name: myconfigmap
          items:
            - key: config
              path: my-group/my-config

Contoh Pod dengan banyak Secret dengan mode permission bukan bawaan

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: all-in-one
      mountPath: "/projected-volume"
      readOnly: true
  volumes:
  - name: all-in-one
    projected:
      sources:
      - secret:
          name: mysecret
          items:
            - key: username
              path: my-group/my-username
      - secret:
          name: mysecret2
          items:
            - key: password
              path: my-group/my-password
              mode: 511

Setiap sumber Volume projected terdaftar pada spesifikasi di kolom sources. Parameter-parameter tersebut hampir sama persis dengan dua pengecualian berikut:

• Untuk Secret, kolom secretName telah diganti menjadi name agar konsisten dengan penamaan ConfigMap.
• Kolom defaultMode hanya dapat dispesifikasikan pada tingkat projected dan tidak untuk setiap sumber Volume. Tetapi, seperti yang ditunjukkan di atas, kamu dapat secara eksplisit menyetel mode untuk setiap proyeksi.

Saat fitur TokenRequestProjection diaktifkan, kamu dapat menyuntikkan token untuk ServiceAccount yang bersangkutan ke dalam Pod pada path yang diinginkan. Berikut contohnya:

apiVersion: v1
kind: Pod
metadata:
  name: sa-token-test
spec:
  containers:
  - name: container-test
    image: busybox
    volumeMounts:
    - name: token-vol
      mountPath: "/service-account"
      readOnly: true
  volumes:
  - name: token-vol
    projected:
      sources:
      - serviceAccountToken:
          audience: api
          expirationSeconds: 3600
          path: token

Contoh Pod tersebut memiliki Volume projected yang berisi token ServiceAccount yang disuntikkan. Token ini dapat digunakan oleh Container dalam Pod untuk mengakses Kubernetes API Server misalnya. Kolom audience berisi audiensi token yang dituju. Sebuah penerima token tersebut harus mengidentifikasikan dirinya dengan tanda pengenal yang dispesifikasikan pada audience token tersebut, atau jika tidak, harus menolak token tersebut. Kolom ini bersifat opsional dan secara bawaan akan berisi tanda pengenal API Server.

Kolom expirationSeconds adalah masa berlaku yang diinginkan untuk token ServiceAccount tersebut. Secara bawaan, nilainya adalah 1 jam dan harus paling singkat bernilai 10 menit (600 detik). Seorang administrator juga dapat membatasi nilai maksimumnya dengan menyetel opsi --service-account-max-token-expiration pada API Server. Kolom path menunjukkan relative path untuk menambatkan Volume projected tersebut.

portworxVolume

Sebuah portworxVolume adalah sebuah penyimpanan blok elastis yang berjalan secara hyperconverged dengan Kubernetes. Portworx mengambil sidik jari media penyimpanan pada sebuah server, mengklasifikasikannya berdasarkan kemampuannya, dan mengagregasikan kapasitasnya di banyak server. Portworx berjalan secara in-guest pada mesin virtual atau pada Node Linux bare metal.

Sebuah portworxVolume dapat dibuat secara dinamis melalui Kubernetes, atau ia juga dapat disediakan terlebih dahulu dan dirujuk dari dalam Pod Kubernetes. Berikut contoh sebuah Pod yang mereferensikan PortworxVolume yang telah disediakan terlebih dahulu:

apiVersion: v1
kind: Pod
metadata:
  name: test-portworx-volume-pod
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /mnt
      name: pxvol
  volumes:
  - name: pxvol
    # Volume Portworx ini harus sudah tersedia.
    portworxVolume:
      volumeID: "pxvol"
      fsType: "<fs-type>"

Lihat di sini untuk lebih lanjut.

quobyte

Sebuah Volume quobyte memungkinkan sebuah volume Quobyte yang sudah tersedia untuk ditambatkan ke dalam Pod kamu.

Quobyte mendukung Container Storage Interface. CSI adalah plugin yang direkomendasikan untuk menggunakan Volume Quobyte di dalam Kubernetes. Ada petunjuk dan contoh untuk menggunakan Quobyte menggunakan CSI pada proyek GitHub Quobyte.j

rbd

Sebuah Volume rbd memungkinkan sebuah volume Rados Block Device ditambatkan ke dalam Pod kamu. Tidak seperti emptyDir yang ikut dihapus saat Pod dihapus, isi dari sebuah rbd dipertahankan dan volume-nya hanya dilepaskan tambatannya. Hal ini berarti sebuah rbd dapat diisi terlebih dahulu dengan data, dan data tersebut dapat "dioper" diantara Pod-pod.

Sebuah fitur RBD yaitu mereka dapat ditambatkan sebagai read-only secara bersamaan oleh beberapa pengguna. Hal ini berarti kamu dapat mengisi data terlebih dahulu dan menyediakan data tersebut secara paralel untuk sebanyak apapun Pod yang kamu butuhkan. Sayangnya, RBD hanya dapat ditambatkan kepada satu pengguna saja pada mode read-write - yaitu, tidak boleh ada banyak penulis secara bersamaan.

Lihat contoh RBD untuk lebih lanjut.

scaleIO

ScaleIO adalah platform penyimpanan berbasis perangkat lunak yang dapat menggunakan perangkat keras yang sudah tersedia untuk membuat klaster-klaster media penyimpanan terhubung jaringan yang scalable. Plugin Volume scaleIO memungkinkan Pod-pod yang di-deploy untuk mengakses Volume-volume ScaleIO yang telah tersedia (atau dapat menyediakan volume-volume untuk PersistentVolumeClaim secara dinamis, lihat Persistent Volume ScaleIO).

Berikut contoh konfigurasi sebuah Pod yang menggunakan ScaleIO:

apiVersion: v1
kind: Pod
metadata:
  name: pod-0
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: pod-0
    volumeMounts:
    - mountPath: /test-pd
      name: vol-0
  volumes:
  - name: vol-0
    scaleIO:
      gateway: https://localhost:443/api
      system: scaleio
      protectionDomain: sd0
      storagePool: sp1
      volumeName: vol-0
      secretRef:
        name: sio-secret
      fsType: xfs

Lihat contoh ScaleIO untuk lebih lanjut.

secret

Sebuah Volume secret digunakan untuk memberikan informasi yang bersifat sensitif, seperti kata sandi, kepada Pod-pod. Kamu dapat menaruh secret dalam Kubernetes API dan menambatkan mereka sebagai berkas-berkas untuk digunakan oleh Pod-pod tanpa harus terikat pada Kubernetes secara langsung. Volume secret didukung oleh tmpfs (filesystem yang didukung oleh RAM) sehingga mereka tidak pernah ditulis pada media penyimpanan yang non-volatile.

Secret dijelaskan lebih lanjut di sini.

storageOS

Sebuah Volume storageos memungkinkan volume StorageOS yang sudah tersedia untuk ditambatkan ke dalam Pod kamu.

StorageOS berjalan sebagai sebuah COntainer di dalam lingkungan Kubernetes kamu, membuat penyimpanan yang lokal atau penyimpanan yang sedang dipasang untuk diakses dari Node manapun di dalam klaster Kubernetes. Data dapat direplikasikan untuk melindungi dari kegagalan Node. Thin provisioning dan kompresi dapat meningkatkan utilisasi dan mengurangi biaya.

Di dalam intinya, StorageOS menyediakan penyimpanan blok kepada Container-container, yang dapat diakses melalui sebuah filesystem.

Container StorageOS membutuhkan Linux 64-bit dan tidak memiliki ketergantungan tambahan apapun. Tersedia pula sebuah lisensi gratis untuk developer.

apiVersion: v1
kind: Pod
metadata:
  labels:
    name: redis
    role: master
  name: test-storageos-redis
spec:
  containers:
    - name: master
      image: kubernetes/redis:v1
      env:
        - name: MASTER
          value: "true"
      ports:
        - containerPort: 6379
      volumeMounts:
        - mountPath: /redis-master-data
          name: redis-data
  volumes:
    - name: redis-data
      storageos:
        # Volume `redis-vol01` harus sudah tersedia di dalam StorageOS pada Namespace `default`
        volumeName: redis-vol01
        fsType: ext4

Untuk lebih lanjut, termasuk Dynamic Provisioning dan Persistent Volume Claim, lihat contoh-contoh StorageOS.

vsphereVolume

Sebuah vsphereVolume digunakan untuk menambatkan sebuah Volume VMDK vSphere ke dalam Pod kamu. Isi dari sebuah volume dipertahankan pada saat tambatannya dilepas. Ia mendukung penyimpanan data VMFS dan VSAN.

Membuat sebuah Volume VMDK

Pilih satu dari beberapa cara berikut untuk membuat sebuah VMDK.

• Create using vmkfstools
• Create using vmware-vdiskmanager

vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk

vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk

Contoh Konfigurasi vSphere VMDK

apiVersion: v1
kind: Pod
metadata:
  name: test-vmdk
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-vmdk
      name: test-volume
  volumes:
  - name: test-volume
    # Volume VMDK ini harus sudah tersedia.
    vsphereVolume:
      volumePath: "[DatastoreName] volumes/myDisk"
      fsType: ext4

Lebih banyak contoh dapat ditemukan di sini.

Menggunakan subPath

Terkadang, diperlukan untuk membagi sebuah Volume untuk banyak kegunaan berbeda pada sebuah Pod. Kolom volumeMounts.subPath dapat digunakan untuk merinci sebuah sub-path di dalam Volume yang dimaksud, menggantikan root path-nya.

Berikut contoh sebuah Pod dengan stack LAMP (Linux Apache Mysql PHP) menggunakan sebuah Volume yang dibagi-bagi. Isi HTML-nya dipetakan ke dalam direktori html-nya, dan database-nya akan disimpan di dalam direktori mysql-nya.

apiVersion: v1
kind: Pod
metadata:
  name: my-lamp-site
spec:
    containers:
    - name: mysql
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: "rootpasswd"
      volumeMounts:
      - mountPath: /var/lib/mysql
        name: site-data
        subPath: mysql
    - name: php
      image: php:7.0-apache
      volumeMounts:
      - mountPath: /var/www/html
        name: site-data
        subPath: html
    volumes:
    - name: site-data
      persistentVolumeClaim:
        claimName: my-lamp-site-data

Menggunakan subPath dengan environment variable yang diekspansi

Gunakan kolom subPathExpr untuk membuat nama-nama direktori subPath dari environment variable Downward API. Sebelum kamu menggunakan fitur ini, kamu harus mengaktifkan feature gate VolumeSubpathEnvExpansion. Kolom subPath dan subPathExpr bersifat mutually exclusive.

Pada contoh ini, sebuah Pod menggunakan subPathExpr untuk membuat sebuah direktori pod1 di dalam Volume hostPath /var/log/pods, menggunakan nama Pod dari Downward API. Direktori host /var/log/pods/pod1 ditambatkan pada /logs di dalam Container-nya.

apiVersion: v1
kind: Pod
metadata:
  name: pod1
spec:
  containers:
  - name: container1
    env:
    - name: POD_NAME
      valueFrom:
        fieldRef:
          apiVersion: v1
          fieldPath: metadata.name
    image: busybox
    command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ]
    volumeMounts:
    - name: workdir1
      mountPath: /logs
      subPathExpr: $(POD_NAME)
  restartPolicy: Never
  volumes:
  - name: workdir1
    hostPath:
      path: /var/log/pods

Sumber-sumber

Media penyimpanan (Disk, SSD, dll.) dari sebuah Volume emptyDir ditentukan oleh medium dari filesystem yang menyimpan direktori root dari Kubelet (biasanya /var/lib/kubelet). Tidak ada batasan berapa banyak ruang yang dapat digunakan oleh Volume emptyDir dan hostPath, dan tidak ada isolasi antara Container-container atau antara Pod-pod.

Ke depannya, kita mengharapkan Volume emptyDir dan hostPath akan dapat meminta jumlah ruangan penyimpanan tertentu dengan mengunakan spesifikasi [resource]resource, dan memilih tipe media penyimpanan yang akan digunakan, untuk klaster yang memiliki beberapa jenis media penyimpanan.

Plugin Volume yang Out-of-Tree

Plugin Volume yang Out-of-tree termasuk Container Storage Interface (CSI) dan Flexvolume. Mereka memungkinkan vendor penyimpanan untuk membuat plugin penyimpanan buatan tanpa perlu menambahkannya pada repository Kubernetes.

Sebelum dikenalkannya CSI dan Flexvolume, semua plugin volume (seperti jenis-jenis volume yang terdaftar di atas) berada pada "in-tree", yang berarti bahwa mereka dibangun, di-link, di-compile, dan didistribusikan bersama-sama dengan kode inti Kubernetes dan mengekstensi inti dari Kubernetes API. Hal ini berarti menambah sistem penyimpanan baru ke dalam Kubernetes (sebuah plugin volume) membutukan penambahan kode tersebut ke dalam repository kode inti Kubernetes.

CSI dan Flexvolume memungkinkan plugin volume untuk dikembangkan secara terpisah dari kode inti Kubernetes, dan diinstal pada klaster Kubernetes sebagai ekstensi.

Bagi vendor-vendor penyimpanan yang ingin membuat sebuah plugin volume yang out-of-tree, lihat FAQ ini.

CSI

Container Storage Interface (CSI) mendefinisikan standar antarmuka untuk sistem orkestrasi (seperti Kubernetes) untuk mengekspos sistem penyimpanan apapun ke dalam beban kerja Container mereka.

Silahkan lihat proposal desain CSI untuk lebih lanjut.

Dukungan untuk CSI dikenalkan sebagai Alpha pada Kubernetes v1.9, dan menjadi Beta pada Kubernetes v1.10, dan menjadi GA pada Kubernetes v1.13.

Saat sebuah driver volume CSI dipasang pada klaster Kubernetes, pengguna dapat menggunakan tipe Volume csi untuk menambatkan volume-volume yang diekspos oleh driver CSI tersebut.

Tipe Volume csi tidak mendukung referensi secara langsung dari Pod dan hanya dapat dirujuk di dalam sebuah Pod melalui sebuah objek PersistentVolumeClaim.

Kolom-kolom berikut tersedia untuk administrator-administrator penyimpanan untuk mengkonfigurasi sebuah Persistent Volume CSI.

• driver: Sebuah nilai string yang merinci nama dari driver volume yang akan digunakan. Nilai ini harus sesuai dengan nilai yang dikembalikan oleh GetPluginInfoResponse dari _driver_CSI seperti yang didefinisikan pada spesifikasi CSI. Ia digunakan oleh Kubernetes untuk mengidentifikasikan driver CSI mana yang akan dipanggil, dan oleh komponen driver CSI untuk mengidentifikasikan objek PersistentVolume mana yang dimiliki oleh driver CSI tersebut.
• volumeHandle: Sebuah nilai string yang secara unik mengidentifikasikan volume tersebut. Nilai ini harus sesuai dengan nilai yang dikembalikan oleh kolom volume.id dari CreateVolumeResponse dari driver CSI seperti yang didefinisikan pada spesifikasi CSI. Nilai tersebut dioper sebagai volume_id pada semua panggilan terhadap driver volume CSI saat mereferensikan volume yang bersangkutan.
• readOnly: Sebuah nilai boolean bersifat opsional yang mengindikasikan jika sebuah volume akan dijadikan sebagai "ControllerPublished" (ditambatkan) sebagai read-only. Nilai bawaannya adalah false. Nilai ini dioper ke driver CSI melalui kolom readonly pada ControllerPublishVolumeRequest.
• fsType: Jika nilai VolumeMode milik PV adalah FileSystem, maka kolom ini dapat digunakan untuk menunjukkan filesystem yang akan digunakan untu menambatkan volume tersebut. Jika volume tersebut belum diformat dan memformat tidak didukung, maka nilai ini akan digunakan untuk memformat volume tersebut. Nilai ini dioper kepada driver CSI melalui kolom VolumeCapability dari ControllerPublishVolumeRequest, NodeStageVolumeRequest, dan NodePublishVolumeRequest.
• volumeAttributes: Sebuah map dari string kepada string yang merinci properti statis dari sebuah volume. Nilai map ini harus sesuai dengan map yang dikembalikan di dalam kolom volume.attributes pada CreateVolumeResponse dari driver CSI seperti yang didefinisikan pada spesifikasi CSI. Map tersebut dioper kepada driver CSI melalui kolom volume_attributes padaControllerPublishVolumeRequest, NodeStageVolumeRequests, dan NodePublishVolumeRequest.
• controllerPublishSecretRef: Sebuah referensi ke objek Secret yang berisi informasi sensitif untuk diberikan pada driver CSI untuk menyelesaikan panggilan ControllerPublishVolume dan ControllerUnpublishVolume. Kolom ini bersifat opsional, dan dapat bernilai kosong jika tidak ada Secret yang dibutuhkan. Jika objek Secret berisi lebih dari satu secret, maka semua secret tersebut akan diberikan.
• nodeStageSecretRef: Sebuah referensi ke objek Secret yang berisi informasi sensitif untuk diberikan pada driver CSI untuk menyelesaikan panggilan NodeStageVolume. Kolom ini bersifat opsional, dan dapat bernilai kosong jika tidak ada Secret yang dibutuhkan. Jika objek Secret berisi lebih dari satu secret, maka semua secret tersebut akan diberikan.
• nodePublishSecretRef: Sebuah referensi ke objek Secret yang berisi informasi sensitif untuk diberikan pada driver CSI untuk menyelesaikan panggilan NodePublishVolume. Kolom ini bersifat opsional, dan dapat bernilai kosong jika tidak ada Secret yang dibutuhkan. Jika objek Secret berisi lebih dari satu secret, maka semua secret tersebut akan diberikan.

Dukungan CSI untuk volume blok raw

Dimulai pada versi 1.11, CSI memperkenalkan dukungak untuk volume blok raw, yang bergantung pada fitur volume blok raw yang dikenalkan pada versi Kubernetes sebelumnya. Fitur ini akan memungkinkan vendor-vendor dengan driver CSI eksternal untuk mengimplementasi dukungan volume blok raw pada beban kerja Kubernetes.

Dukungan untuk volume blok CSI bersifat feature-gate, tapi secara bawaan diaktifkan. Kedua feature-gate yang harus diaktifkan adalah BlockVolume dan CSIBlockVolume.

Pelajari cara menyiapkan PV/PVC dengan dukungan volume blok raw.

Volume CSI Sementara

FItur ini memungkinkan volume CSI untuk dipasang secara langsung pada spesifikasi Pod, menggantikan spesifikasi pada PersistentVolume. Volume yang dirinci melalui cara ini bersifat sementara tidak akan dipertahankan saat Pod diulang kembali.

Contoh:

kind: Pod
apiVersion: v1
metadata:
  name: my-csi-app
spec:
  containers:
    - name: my-frontend
      image: busybox
      volumeMounts:
      - mountPath: "/data"
        name: my-csi-inline-vol
      command: [ "sleep", "1000000" ]
  volumes:
    - name: my-csi-inline-vol
      csi:
        driver: inline.storage.kubernetes.io
        volumeAttributes:
              foo: bar

Fitur ini memerlukan diaktifkannya feature-gate CSIInlineVolume:

--feature-gates=CSIInlineVolume=true

Volume CSI sementara hanya didukung oleh sebagian dari driver-driver CSI. Silahkan lihat daftar driver CSI di sini.

Sumber-sumber untuk developer

Untuk informasi bagaimana mengembangkan sebuah driver CSI, lihat dokumentasi kubernetes-csi.

Migrasi ke driver-driver CSI dari plugin in-tree

Migrating to CSI drivers from in-tree plugins

Fitur CSI Migration, saat diaktifkan, akan mengarahkan operasi-operasi terhadap plugin-plugin in-tree yang sudah ada ke plugin-plugin CSI yang sesuai (yang diharap sudah dipasang dan dikonfigurasi). Fitur ini mengimplementasi logika translasi dan terjemahan yang dibutuhkan untuk mengarahkan ulang operasi-operasi bersangkutan dengan mulus. Hasilnya, operator-operator tidak perlu membuat perubahan konfigurasi apapun pada StorageClass, PV, atau PVC yang sudah ada (mengacu pada plugin in-tree) saat melakukan transisi pada driver CSI yang menggantikan plugin in-tree yang bersangkutan.

Pada keadaan Alpha, operasi-operasi dan fitur-fitur yang didukung termasuk provisioning/delete, attach/detach, mount/unmount, dan mengubah ukuran volume-volume.

Plugin-plugin in-tree yang mendukung CSI Migration dan mempunyai driver CSI yang sesuai yang telah diimplementasikan terdaftar pada bagian "Jenis-jenis Volume" di atas.

Flexvolume

Flexvolume adalah antarmuka plugin out-of-tree yang telah ada sejak Kubernetes versi 1.2 (sebelum CSI). Ia menggunakan model berbasis exec untuk berhubungan dengan driver-driver. Program driver Flexvolume harus dipasan pada volume plugin path yang telah didefinisikan sebelumnya pada setiap Node (dan pada beberapa kasus, di Master).

Pod-pod berinteraksi dengan driver-driver Flexvolume melalui plugin in-tree flexvolume. Untuk lebih lanjut, dapat ditemukan di sini.

Mount Propagation

Mount propagation memungkinkan berbagi volume-volume yang ditambatkan oleh sebuah Container kepada Container-container lain di dalam Pod yang sama, atau bahkan pada Pod lainnya di dalam Node yang sama.

Mount propagation dari sebuah volume diatur oleh kolom mountPropagation di dalam Container.volumeMounts. Nilai-nilainya adalah sebagai berikut:

• None - Tambatan volume ini tidak akan menerima apapun tambatan selanjutnya yang ditambatkan pada volume ini atau apapun sub-direktori yang dimilikinya oleh host. Dengan cara yang sama, tidak ada tambatan yang dibuat oleh Container yang dapat terlihat pada host. Ini adalah mode bawaan.

  Mode ini setara dengan mount propagation private, seperti yang dideskripsikan pada dokumentasi kernel Linux

• HostToContainer - Tambatan volume ini akan menerima semua tambatan selanjutnya yang ditambatkan pada volume ini atau pada apapun sub-direktori yang dimilikinya.

  Dalam kata lain, jika host yang bersangkutan menambatkan apapun di dalam tambatan volume, Container akan melihatnya ditambatkan di sana.

  Secara serupa, jika ada Pod dengan mount propagation Bidirectional terhadap volume yang sama menambatkan apapun ke situ, maka Container dengan mount propagation HostToContainer akan melihatnya.

  Mode ini setara dengan mount propagation rslave, seperti yang dideskripsikan pada dokumentasi kernel Linux

• Bidirectional - Tambatan volume ini memiliki perilaku yang sama dengan tambatan HostToContainer. Sebagai tambahannya, semua tambatan volume yang dibuat oleh Container akan dipropagasi kembali kepada host yang bersangkutan dan ke semua Container dari semua Pod yang menggunakan volume yang sama.

  Contoh kasus umum untuk mode ini adalah Pod dengan sebuah Flexvolume atau driver CSI atau sebuah Pod yang perlu menambatkan sesuatu pada host-nya dengan menggunakan Volume hostPath.

  Mode ini setara dengan mount propagation rshared, seperti yang dideskripsikan pada dokumentasi kernel Linux

Konfigurasi

Sebelum mount propagation dapat bekerja dengan baik pada beberapa instalasi (CoreOS, RedHat/Centos, Ubuntu), mount share harus dikonfigurasi dengan benar pada Docker, seperti yang ditunjukkan di bawah.

Sunting berkas servis systemd Docker kamu. Setel MountFlags sebagai berikut:

MountFlags=shared

Atau, hapus MountFlags=slave jika ada. Kemudian, ulang kembali daemon Docker-nya:

sudo systemctl daemon-reload
sudo systemctl restart docker

Selanjutnya

• Ikuti contoh memasang WordPress dan MySQL dengan Persistent Volume.

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

3 - VolumeSnapshot

Pengenalan

Seperti halnya sumber daya API PersistentVolume dan PersistentVolumeClaim yang digunakan oleh para pengguna dan administrator untuk menyediakan volume, sumber daya API VolumeSnapshotContent dan VolumeSnapshot digunakan mereka untuk membuat snapshot volume.

VolumeSnapshotContent merupakan suatu snapshot yang diambil dari sebuah volume dari dalam klaster yang telah disediakan oleh administrator. Sepert layaknya PersistentVolume, VolumeSnapshotContent juga merupakan bagian dari sumber daya klaster.

VolumeSnapshot merupakan suatu permintaan snapshot dari volume oleh pengguna. Mirip seperti halnya PersistentVolumeClaim.

Walaupun VolumeSnapshot membuat pengguna bisa mengonsumsi abstraksi dari sumber daya penyimpanan, administrator klaster tetap perlu menawarkan berbagai macam tipe VolumeSnapshotContent, tanpa perlu mengekspos pengguna pada detail bagaimana snapshot volume tersebut harus tersediakan. Bagi yang memerlukan hal ini, ada yang namanya sumber daya VolumeSnapshotClass.

Para pengguna tetap perlu mengetahui beberapa hal di bawah ketika menggunakan fitur ini:

• Objek API VolumeSnapshot, VolumeSnapshotContent, dan VolumeSnapshotClass adalah CRD, bukan bagian dari API inti.
• Fitur VolumeSnapshot hanya tersedia untuk CSI driver.
• Sebagai bagian dari proses deploy, tim Kubernetes menyediakan Container sidecar bantuan untuk controller snapshot berrnama external-snapshotter. Container ini melakukan watch pada objek VolumeSnapshot dan memicu operasi CreateSnapshot dan DeleteSnapshot terhadap sebuah endpoint CSI.
• Driver CSI ada yang telah implementasi fitur VolumeSnapshot, ada juga yang belum. Driver CSI yang telah menyediakan dukungan terhadap fitur VolumeSnapshot kemungkinan besar menggunakan external-snapshotter.
• Driver CSI yang mendukung VolumeSnapshot akan secara otomatis melakukan instalasi CRD untuk VolumeSnapshot.

Siklus hidup VolumeSnapshot dan VolumeSnapshotContent

VolumeSnapshotContent merupakan bagian dari sumber daya klaster. VolumeSnapshot merupakan permintaan terhadap sumber daya tersebut. Interaksi antara VolumeSnapshotContent dan VolumeSnapshot mengikuti siklus hidup berikut ini:

Penyediaan VolumeSnapshot

Ada dua cara untuk menyediakan snapshot: secara statis maupun dinamis.

Statis

Seorang administrator klaster membuat beberapa VolumeSnapshotContent, yang masing-masing memiliki detail tentang penyimpanan sebenarnya yang dapat dipergunakan oleh para pengguna. VolumeSnapshotContent tersebut dapat dikonsumsi melalui API Kubernetes.

Dinamis

Ketika VolumeSnapshotContent yang dibuat oleh administrator tidak ada yang sesuai dengan VolumeSnapshot yang dibuat pengguna, klaster bisa saja mencoba untuk menyediakan sebuah VolumeSnapshot secara dinamis, khususnya untuk objek VolumeSnapshot. Proses penyediaan ini berdasarkan VolumeSnapshotClasses: VolumeSnapshot harus meminta sebuah VolumeSnapshotClass dan administrator harus membuat serta mengatur class tersebut supaya penyediaan dinamis bisa terjadi.

Ikatan (Binding)

Seorang pengguna akan membuat (atau telah membuat, dalam kasus penyediaan dinamis) sebuah VolumeSnapshot dengan ukuran penyimpanan yang diminta beserta mode akses tertentu. Suatu loop kontrol melakukan watch terhadap VolumeSnapshot baru, mencari VolumeSnapshotContent yang sesuai (jika memungkinkan), dan mengikat (bind) keduanya. Jika VolumeSnapshotContent secara dinamis disediakan untuk VolumeSnapshot yang baru, loop akan terus mengikat VolumeSnapshotContent dengan VolumeSnapshot. Ketika telah terikat (bound), VolumeSnapshot bind bersifat eksklusif, terlepas dari bagaimana proses bind dilakukan. Ikatan (binding) antara suatu VolumeSnapshot dengan VolumeSnapshotContent bersifat 1:1 mapping.

VolumeSnapshot akan tetap tidak terikat (unbound) tanpa ada batas waktu, jika VolumeSnapshotContent yang sesuai tidak ditemukan. VolumeSnapshot akan menjadi terikat (bound) ketika VolumeSnapshotContent yang sesuai menjadi ada.

PersistentVolumeClaim dengan in-Use Protection

Tujuan dari objek PersistentVolumeClaim dengan fitur in Use Protection adalah memastikan objek API PVC yang masih dalam penggunaan (in-use) tidak akan dihilangkan dari sistem (penghilangan akan menyebabkan hilangnya data).

Jika sebuah PVC sedang digunakan secara aktif oleh proses snapshot yang digunakan sebagai sumbernya (source), artinya PVC sedang dalam penggunaan (in-use). Jika seorang pengguna menghapus suatu objek API PVC saat dalam penggunaan sebagai sumber snapshot, objek PVC tidak akan dihilangkan segera. Namun, penghapusan objek PVC akan ditunda sampai PVCC tidak lagi secara aktif digunakan oleh proses snapshot manapun. Suatu PVC tidak lagi diguunakan sebagai suumber snapshot ketika ReadyToUse dari Status snapshot menjadi true.

Penghapusan

Proses penghapusan akan menghilangkan objek VolumeSnapshot dari API Kubernetes, beserta aset penyimpanan terkait pada infrastruktur eksternal.

VolumeSnapshotContent

Setiap VolumeSnapshotContent memiliki sebuah spec, yang merepresentasikan spesifikasi dari snapshot volume tersebut.

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotContent
metadata:
  name: new-snapshot-content-test
spec:
  snapshotClassName: csi-hostpath-snapclass
  source:
    name: pvc-test
    kind: PersistentVolumeClaim
  volumeSnapshotSource:
    csiVolumeSnapshotSource:
      creationTime:    1535478900692119403
      driver:          csi-hostpath
      restoreSize:     10Gi
      snapshotHandle:  7bdd0de3-aaeb-11e8-9aae-0242ac110002

Class

Suatu VolumeSnapshotContent dapat memiliki suatu class, yang didapat dengan mengatur atribut snapshotClassName dengan nama dari VolumeSnapshotClass. VolumeSnapshotContent dari class tertentu hanya dapat terikat (bound) dengan VolumeSnapshot yang "meminta" class tersebut. VolumeSnapshotContent tanpa snapshotClassName tidak memiliki class dan hanya dapat terikat (bound) dengan VolumeSnapshot yang "meminta" untuk tidak menggunakan class.

VolumeSnapshot

Masing-masing VolumeSnapshot memiliki sebuah spec dan status, yang merepresentasikan spesifikasi dan status dari snapshot volume tersebut.

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshot
metadata:
  name: new-snapshot-test
spec:
  snapshotClassName: csi-hostpath-snapclass
  source:
    name: pvc-test
    kind: PersistentVolumeClaim

Class

Suatu VolumeSnapshot dapat meminta sebuah class tertentu dengan mengatur nama dari VolumeSnapshotClass menggunakan atribut snapshotClassName. Hanya VolumeSnapshotContent dari class yang diminta, memiliki snapshotClassName yang sama dengan VolumeSnapshot, dapat terikat (bound) dengan VolumeSnapshot tersebut.

Penyediaan (Provisioning) Volume dari Snapshot

Kamu dapat menyediakan sebuah volume baru, yang telah terisi dengan data dari suatu snapshot, dengan menggunakan field dataSource pada objek PersistentVolumeClaim.

Untuk detailnya bisa dilihat pada VolumeSnapshot and Mengembalikan Volume dari Snapshot.

4 - Pengklonaan Volume CSI

Introduction

Fitur CSI Volume Cloning menambahkan dukungan untuk merinci PVC yang telah tersedia pada kolom dataSource untuk mengindikasikan bahwa seorang pengguna ingin melakukan pengklonaan terhadap sebuah Volume.

Sebuah klona didefinisikan sebagai sebuah duplikat dari sebuah Volume Kubernetes yang telah tersedia yang dapat digunakan sebagai sebuah Volume standar. Perbedaannya hanyalah pada saat penyediaannya, daripada membuat sebuah Volume kosong yang "baru", peranti penyokongnya membuat sebuah duplikat sama persis dari Volume yang dirinci.

Implementasi dari pengklonaan, dari sudut pandang API Kubernetes, secara sederhana menambahkan kemampuan untuk merinci sebuah PVC yang telah tersedia sebagai sebuah dataSource saat pembuatan PVC. PVC sumber harus tertambat (bound) dan tersedia (tidak sedang digunakan).

Pengguna-pengguna mesti menyadari hal-hal berikut saat menggunakan fitur ini:

• Dukungan pengklonaan (VolumePVCDataSource) hanya tersedia untuk driver-driver CSI.
• Dukungan pengklonaan hanya tersedia untuk penyedia-penyedia dinamis.
• Driver-driver CSI mungkin telah atau belum mengimplementasi fungsi pengklonaan Volume.
• Kamu hanya dapat mengklonakan sebuah PVC saat ia tersedia pada Namespace yang sama dengan PVC tujuan (sumber dan tujuan harus berada pada Namespace yang sama).
• Pengklonaan hanya didukung pada Storage Class yang sama.
  • Volume tujuan harus memiliki Storage Class yang sama dengan sumbernya.
  • Storage Class bawaan dapat digunakan dan storageClassName dihilangkan dari spec

Penyediaan

Klona-klona disediakan sama seperti PVC lainnya dengan pengecualian dengan penambahan sebuah dataSource yang merujuk pada sebuah PVC yang telah tersedia pada Namespace yang sama.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: clone-of-pvc-1
    namespace: myns
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: cloning
  resources:
    requests:
      storage: 5Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: pvc-1

Hasilnya adalah sebuah PVC baru dengan nama clone-of-pvc-1 yang memiliki isi yang sama dengan sumber yang dirinci pvc-1.

Penggunaan

Setelah tersedianya PVC baru tersebut, PVC baru yang diklonakan tersebut digunakan sama seperti PVC lainnya. Juga diharapkan pada titik ini bahwa PVC baru tersebut adalah sebuah objek terpisah yang independen. Ia dapat digunakan, diklonakan, di-snapshot, atau dihapus secara terpisah dan tanpa perlu memikirkan PVC dataSource aslinya. Hal ini juga berarti bahwa sumber tidak terikat sama sekali dengan klona yang baru dibuat tersebut, dan dapat diubah atau dihapus tanpa memengaruhi klona yang baru dibuat tersebut.

5 - 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 klaster. 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.

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 klaster, 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 klaster 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:

• AWSElasticBlockStore
• GCEPersistentDisk
• AzureDisk

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

• Semua hal di atas
• Lokal

Topologi yang Diizinkan

Ketika sebuah operator klaster 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

• type: io1, gp2, sc1, st1. Lihat dokumentasi AWS untuk detail lebih lanjut. Nilai default: gp2.
• zone (deprecated): zona AWS. Jika tidak terdapat nilai zone atau zones yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan penjadwalan round-robin-ed pada semua zona aktif yang ada pada klaster Kubernetes yang memiliki node.
• zones (deprecated): Nilai terpisahkan koma yang merupakan barisan zona pada AWS. Jika tidak terdapat nilai zone atau zones yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan penjadwalan round-robin-ed pada semua zona aktif yang ada pada klaster Kubernetes yang memiliki node.
• iopsPerGB: hanya untuk volume io1. Operasi per detik per GiB. Volume plugin AWS mengalikan nilai ini dengan ukuran volume yang dibutuhkan untuk menghitung IOPS dari volume (nilai maksimum yang didukung adalah 20,000 IOPS baca dokumentasi AWS. Nilai masukan yang diharapkan merupakan string, misalnya "10", bukan 10.
• fsType: fsType yang didukung oleh Kubernetes. Nilai default-nya adalah: "ext4".
• encrypted: menyatakan dimana volume EBS harus dienkripsi atau tidak. Nilai yang valid adalah "true" atau "false" (dalam string bukan boolean i.e. "true", bukan true).
• kmsKeyId: opsional. Merupakan nama dari Amazon Resource Name dari key yang digunakan untuk melakukan enkripsi volume. Jika nilai ini tidak disediakan tetapi nilai dari field encrypted adalah true, sebuah key akan dibuat oleh AWS. Perhatikan dokumentasi AWS untuk mengetahui nilai yang valid bagi ARN.

PD GCE

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

• type: pd-standard atau pd-ssd. Nilai default: pd-standard
• zone (deprecated): zona GCE. Jika tidak terdapat nilai zone atau zones yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan penjadwalan round-robin-ed pada semua zona aktif yang ada pada klaster Kubernetes yang memiliki node.
• zones (deprecated): Nilai terpisahkan koma yang merupakan barisan zona. Jika tidak terdapat nilai zone atau zones yang dispesifikasikan, volume secara generik dijadwalkan dengan menggunakan penjadwalan round-robin-ed pada semua zona aktif yang ada pada klaster Kubernetes yang memiliki node.
• replication-type: none atau regional-pd. Nilai default: 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 klaster Kubernetes.

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"

• resturl: Servis REST Gluster/URL servis Heketi yang digunakan untuk melakukan provisioning volume gluster sesuai dengan kebutuhan. Format secara umum haruslah dalam bentuk IPaddress:Port dan hal ini merupakan parameter wajib untuk provisioner dinamis GlusterFS. Jika servis Heketi diekspos sebagai servis yang dapat melakukan routing pada pengaturan openshift/kubernetes, ini dapat memiliki format yang sesuai dengan http://heketi-storage-project.cloudapps.mystorage.com dimana fqdn yang ada merupakan URL servis Heketi yang dapat di-resolve.

• restauthenabled : Servis REST Gluster menyediakan nilai boolean yang dapat digunakan untuk mengajukan authentication untuk server REST yang ada. Jika nilai yang disediakan adalah "true", dengan kondisi dimana restuser dan restuserkey atau secretNamespace + secretName harus diisi. Opsi ini sudah_deprecated_, mekanisme otentikasi akan diizinkan apabila salah satu dari _field_ restuser, restuserkey, secretName atau secretNamespace diterapkan.

• restuser : Pengguna servis REST Gluster/Heketi yang memiliki akses untuk membuat volume di dalam Trusted Pool Gluster.

• restuserkey : Password pengguna servis REST Gluster/Heketi yang digunakan untuk mekanisme otentikasi server REST. Parameter ini deprecated dan digantikan dengan parameter secretNamespace + secretName.

• secretNamespace, secretName : Identifikasi instans Secret yang mengandung password pengguna yang digunakan untuk berkomunikasi dengan servis REST Gluster. Parameter ini dianggap opsional, password kosong dapat digunakan ketika nilai dari secretNamespace dan secretName tidak dispesifikasikan. Secret yang disediakan haruslah memiliki tipe "kubernetes.io/glusterfs", yang dapat dibuat dengan menggunakan mekanisme dibawah ini:

  kubectl create secret generic heketi-secret \
    --type="kubernetes.io/glusterfs" --from-literal=key='opensesame' \
    --namespace=default
  

  Contoh Secret dapat ditemukan pada berkas berikut glusterfs-provisioning-secret.yaml.

• clusterid: 630372ccdc720a92c681fb928f27b53f merupakan ID dari klaster yang akan digunakan oleh Heketi ketikan melakukan provisioning volume. ID ini juga dapat berupa serangkaian list, misalnya: "8452344e2becec931ece4e33c4674e4e,42982310de6c63381718ccfa6d8cf397". Parameter ini merupakan parameter opsional.

• gidMin, gidMax : Nilai minimum dan maksimum dari GID untuk kelas penyimpanan (storage class). Sebuah nilai unik dari GID di dalam range ( gidMin-gidMax ) ini akan digunakan untuk melakukan provisioning volume secara dinamis. Nilai ini bersifat opsional. Jika tidak dispesifikasikan, volume akan secara default di-provisioning dalam range 2000-2147483647 yang merupakan nilai default dari gidMin dan gidMax.

• volumetype : Tipe volume beserta paremeter-nya dapat diatur dengan menggunakan nilai opsional berikut. Jika tipe dari volume tidak dispesifikasikan, maka provisioner akan memutuskan tipe volume apakah yang akan digunakan.

  Sebagai contoh:

  • Volume replika: volumetype: replicate:3 dimana '3' merupakan jumlah replika.

  • Persebaran (Disperse)/EC volume: volumetype: disperse:4:2 dimana'4' merupakan data dan '2' merupakan jumlah redundansi.

  • Distribusi volume: volumetype: none

  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

• availability: Zona Availability. Jika tidak dispesifikasikan, secara umum volume akan diatur dengan menggunakan algoritma round-robin pada semua zona aktif dimana klaster Kubernetes memiliki sebuah node.

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"

• monitors: Monitor Ceph, merupakan nilai yang dipisahkan oleh koma (csv). Parameter ini dibutuhkan.

• adminId: ID klien Ceph yang dapat digunakan untuk membuat images di dalam pool. Nilai default-nya adalah "admin".

• adminSecretName: Nama Secret untuk adminId. Parameter ini dibutuhkan. Secret yang dibutuhkan haruslah memiliki tipe "kubernetes.io/rbd".

• adminSecretNamespace: Namespace untuk adminSecretName. Nilai default-nya adalah "default".

• pool: Pool Ceph RBD. Nilai default-nya adalah "rbd".

• userId: Klien ID Ceph yang digunakan untuk melakukan pemetaan image RBD. Nilai default-nya sama dengan adminId.

• userSecretName: Nama Secret Ceph untuk userId yang digunakan untuk memetakan image RBD. Secret ini harus berada pada namespace yang sama dengan PVC. Parameter ini dibutuhkan. Secret yang disediakan haruslah memiliki tipe "kubernetes.io/rbd", dibuat dengan cara:

  kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
    --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \
    --namespace=kube-system
  

• userSecretNamespace: Namespace untuk userSecretName.

• fsType: fsType yang didukung oleh kubernetes. Nilai default-nya adalah: "ext4".

• imageFormat: Format image Ceph RBD, nilai yang mungkin adalah "1" atau "2". Nilai default-nya adalah "2".

• imageFeatures: Parameter ini bersifat opsional dan hanya dapat digunakan jika kamu mengganti nilai dari imageFormat ke "2". Saat ini fitur yang didukung hanyalah layering. Nilai default-nya adalah "", dan tidak ada fitur yang diaktifkan.

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"

• quobyteAPIServer: API Server dari Quobyte dalam format "http(s)://api-server:7860"

• registry: Registri Quobyte yang digunakan untuk melakukan mount volume. Kamu dapat menspesifikasikan registri yang kamu inginkan dengan format pasangan <host>:<port> atau jika kamu ingin mendefinisikan beberapa registri sekaligus kamu dapat menempatkan koma diantara setiap pasangan <host>:<port> yang ada, misalnya <host1>:<port>,<host2>:<port>,<host3>:<port>. Host dapat berupa alamat IP atau DNS.

• adminSecretNamespace: Namespace adminSecretName. Nilai default-nya adalah "default".

• adminSecretName: Secret yang mengandung informasi mengenai pengguna Quobyte dan password yang digunakan untuk melakukan otentikasi API server. Secret yang digunakan haruslah memiliki tipe "kubernetes.io/quobyte", yang dibuat dengan mekanisme berikut:

  kubectl create secret generic quobyte-admin-secret \
    --type="kubernetes.io/quobyte" --from-literal=key='opensesame' \
    --namespace=kube-system
  

• user: Melakukan pemetaan terhadap semua akses yang dimiliki pengguna. Nilai default-nya adalah "root".

• group: Melakukan pemetaan terhadap semua group. Nilai default-nya adalah "nfsnobody".

• quobyteConfig: Menggunakan konfigurasi spesifik untuk membuat volume. Kamu dapat membuat sebuah file konfigurasi atau melakukan modifikasi terhadap konfigurasi yang sudah ada dengan menggunakan tatap muka Web atau CLI quobyte. Nilai default-nya adalah "BASE".

• quobyteTenant: Menggunakan ID tenant yang dispesifikasikan untuk membuat/menghapus volume. Tenant Quobyte haruslah sudah berada di dalam Quobyte. Nilai default-nya adalah "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

• skuName: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai default-nya adalah kosong.
• location: Lokasi akun penyimpanan Azure. Nilai default-nya adalah kosong.
• storageAccount: Nama akun penyimpanan Azure. Jika sebuan akun penyimpanan disediakan, akun tersebut haruslah berada pada grup sumber daya yang ada dengan klaster, dan location akan diabaikan. Jika sebuah akun penyimpanan tidak disediakan, sebuah akun penyimpanan baru akan dibuat pada grup sumber daya yang ada dengan klaster.

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: managed

• storageaccounttype: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai default-nya adalah kosong.
• kind: Nilai yang mungkin adalah shared, dedicated, dan managed (default). Ketika kind yang digunakan adalah shared, semua disk yang tidak di-manage akan dibuat pada beberapa akun penyimpanan yang ada pada grup sumber daya yang sama dengan klaster. Ketika kind yang digunakan adalah dedicated, sebuah akun penyimpanan baru akan dibuat pada grup sumber daya yang ada dengan klaster. Ketika kind yang digunakan adalah managed, semua disk yang dikelola akan dibuat pada grup sumber daya yang ada dengan klaster.

• VM premium dapat di-attach baik pada Standard_LRS dan Premium_LRS disks, sementara Standard VM hanya dapat di-attach pada disk Standard_LRS.
• VM yang dikelola hanya dapat meng-attach disk yang dikelola dan VM yang tidak dikelola hanya dapat meng-attach disk yang tidak dikelola.

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

• skuName: Akun penyimpanan Azure yang ada pada tingkatan Sku. Nilai default-nya adalah kosong.
• location: Lokasi akun penyimpanan Azure. Nilai default-nya adalah kosong.
• storageAccount: Nama akun penyimpanan Azure. Nilai default-nya adalah kosong. Jika sebuah penyimpanan tidak memiliki sebuah akun yang disediakan, semua akun penyimpanan yang diasosiasikan dengan grup sumber daya yang ada dan kemudian melakukan pencarian terhadap akun yang sesuai dengan skuName dan location. Jika sebuah akun penyimpanan disediakan, akun tersebut haruslah berada di dalam grup sumber daya yang sama dengan klaster, serta skuName dan location akan diabaikan.

Selama provision, sebuah secret dibuat untuk menyimpan credentials. Jika klaster 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"

• fs: filesystem yang akan digunakan: none/xfs/ext4 (nilai default-nya: ext4).
• block_size: ukuran block dalam Kbytes (nilai default-nya: 32).
• repl: jumlah replika synchronous yang dapat disediakan dalam bentuk faktor replikasi 1..3 (nilai default-nya: 1) Nilai yang diharapkan dalam bentuk String "1" dan bukan 1.
• io_priority: menentukan apakah volume yang dibuat akan dari penyimpanan dengan kualitas tinggi atau rendah dengan urutan prioritas high/medium/low (nilai default-nya: low).
• snap_interval: interval waktu dalam menit yang digunakan untuk melakukan trigger snapshots. Snapshots dibuat secara inkremen berdasarkan perbedaan yang ada dengan snapshot yang dibuat sebelumnya, nilai perbedaan 0 akan menonaktifkan pembuatan snapshot (nilai default-nya: 0). Sebuah string merupakan nilai yang diharapkan "70" dan bukan 70.
• aggregation_level: menspesifikasikan jumlah chunks dimana volume akan didistribusikan, 0 mengindikasikan volume yang non-aggregate (nilai default-nya: 0). Sebuah string merupakan nilai yang diharapkan "0" dan bukan 0.
• ephemeral: menentukan apakah volume harus dihapus setelah di-unmount atau harus tetap ada. Penggunaan emptyDir dapat diubah menjadi true dan penggunaan persistent volumes untuk basisdata seperti Cassandra harus diubah menjadi false, true/false (nilai default-nya: false). Sebuah string merupakan nilai yang diharapkan "true" dan bukan true.

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

• provisioner: atribut yang nilainya merupakan kubernetes.io/scaleio
• gateway: alamat gateway ScaleIO (wajib)
• system: nama sistem ScaleIO (wajib)
• protectionDomain: nama domain proteksi ScaleIO (wajib)
• storagePool: nama pool volume penyimpanan (wajib)
• storageMode: mode provisioning penyimpanan: ThinProvisioned (default) atau ThickProvisioned
• secretRef: penunjuk pada objek Secret yang dikonfigurasi (wajib)
• readOnly: menentukan mode akses terhadap volume yang di-mount (nilai default-nya: false)
• fsType: filesystem yang digunakan untuk volume (nilai default-nya: ext4)

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

• pool: Nama kapasitas distribusi StorageOS yang digunakan untuk melakukan provisioning volume. Pool default akan digunakan apabila nilainya tidak dispesifikasikan.
• description: Deskripsi untuk melakukan assignment volume yang baru dibuat secara dinamis. Semua deskripsi volume akan bernilai sama untuk kelas penyimpanan yang sama, meskipun begitu kelas penyimpanan yang berbeda dapat digunakan untuk membuat deskripsi yang berbeda untuk penggunaan yang berbeda. Nilai default-nya adalah Kubernetes volume.
• fsType: Tipe filesystem default yang digunakan. Perhatikan bahwa aturan yang didefinisikan oleh pengguna di dalam StirageOS dapat meng-override nilai ini. Nilai default-nya adalah ext4.
• adminSecretNamespace: Namespace dimana konfigurasi secret API berada. Hal ini bersifat wajib apabila adminSecretName diaktifkan.
• adminSecretName: Nama secret yang digunakan untuk memperoleh credentials StorageOS API. Jika tidak dispesifikasikan, nilaidefault akan digunakan.

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

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.

6 - VolumeSnapshotClass

Laman ini menjelaskan tentang konsep VolumeSnapshotClass pada Kubernetes. Sebelum melanjutkan, sangat disarankan untuk membaca snapshot volume dan kelas penyimpanan (storage class) terlebih dahulu.

Pengenalan

Seperti halnya StorageClass yang menyediakan cara bagi admin untuk mendefinisikan "kelas" penyimpanan yang mereka tawarkan saat proses penyediaan sebuah volume, VolumeSnapshotClass menyediakan cara untuk mendefinisikan "kelas" penyimpanan saat menyediakan snapshot volume.

Sumber Daya VolumeSnapshotClass

Masing-masing VolumeSnapshotClass terdiri dari field snapshotter dan parameters, yang digunakan saat sebuah VolumeSnapshot yang dimiliki kelas tersebut perlu untuk disediakan secara dinamis.

Nama yang dimiliki suatu objek VolumeSnapshotClass sangatlah penting, karena digunakan oleh pengguna saat meminta sebuah kelas tertentu. Admin dapat mengatur nama dan parameter lainnya dari sebuah kelas saat pertama kali membuat objek VolumeSnapshotClass. Objek tidak dapat diubah setelah dibuat.

Admin dapat mengatur VolumeSnapshotClass default untuk VolumeSnapshot yang tidak memiliki spesifikasi kelas apapun.

apiVersion: snapshot.storage.k8s.io/v1alpha1
kind: VolumeSnapshotClass
metadata:
  name: csi-hostpath-snapclass
snapshotter: csi-hostpath
parameters:

snapshotter

VolumeSnapshotClass memiliki sebuah snapshotter yang menentukan plugin volume CSI apa yang digunakan untuk penyediaan VolumeSnapshot. Field ini wajib diatur.

parameters

VolumeSnapshotClass memiliki parameter-parameter yang menggambarkan snapshot volume di dalam VolumeSnapshotClass. Parameter-parameter yang berbeda diperbolehkan tergantung dari shapshotter.

7 - Penyediaan Volume Dinamis

Penyediaan volume dinamis memungkinkan volume penyimpanan untuk dibuat sesuai permintaan (on-demand). Tanpa adanya penyediaan dinamis (dynamic provisioning), untuk membuat volume penyimpanan baru, admin klaster secara manual harus memanggil penyedia layanan cloud atau layanan penyimpanan, dan kemudian membuat objek PersistentVolume sebagai representasi di Kubernetes. Fitur penyediaan dinamis menghilangkan kebutuhan admin klaster untuk menyediakan penyimpanan sebelumnya (pre-provision). Dengan demikian, penyimpanan akan tersedia secara otomatis ketika diminta oleh pengguna.

Latar Belakang

Penyediaan volume dinamis diimplementasi berdasarkan objek API StorageClass dari grup API storage.k8s.io. Seorang admin klaster dapat mendefinisikan berbagai macam objek StorageClass sesuai kebutuhan, masing-masing menentukan plugin volume (disebut juga provisioner) yang menyediakan sebuah volume beserta kumpulan parameter untuk diteruskan oleh provisioner ketika proses penyediaan.

Seorang klaster admin dapat mendefinisikan dan mengekspos berbagai templat penyimpanan (dari sistem penyimpanan yang sama maupun berbeda) di dalam klaster, masing-masing dengan kumpulan parameter tertentu. Desain ini memastikan bahwa pengguna tidak perlu khawatir betapa rumitnya mekanisme penyediaan penyimpanan, tapi tetap memiliki kemampuan untuk memilih berbagai macam pilihan penyimpanan.

Info lebih lanjut mengenai storage class dapat dilihat di sini.

Mengaktifkan Penyediaan Dinamis (Dynamic Provisioning)

Untuk mengaktifkan penyediaan dinamis, seorang admin klaster perlu untuk terlebih dahulu membuat (pre-create) satu atau beberapa objek StorageClass untuk pengguna. Objek StorageClass mendefinisikan provisioner mana yang seharusnya digunakan dan parameter apa yang seharusnya diberikan pada provisioner tersebut saat penyediaan dinamis dipanggil. Manifestasi berikut ini membuat sebuah StorageClass "slow" yang menyediakan persistent disk standar.

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

Manifestasi berikut ini membuat sebuah StorageClass "fast" yang menyediakan SSD persistent disk.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-ssd

Menggunakan Penyediaan Dinamis

Pengguna dapat melakukan permintaan untuk penyediaan penyimpanan dinamis dengan memasukkan StorageClass di dalam PersistentVolumeClaim. Sebelum Kubernetes v1.6, ini dapat dilakukan melalui anotasi volume.beta.kubernetes.io/storage-class. Hanya saja, anotasi ini sudah usang sejak v1.6. Pengguna sekarang dapat dan seharusnya menggunakan field storageClassName dari objek PersistentVolumeClaim. Nilai dari field ini haruslah sesuai dengan nama StorageClass yang dikonfigurasi oleh admin (lihat bagian di bawah).

Untuk memilih StorageClass "fast", sebagai contoh, pengguna dapat membuat PersistentVolumeClaim seperti ini:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: fast
  resources:
    requests:
      storage: 30Gi

Klaim ini menghasilkan persistent disk SSD yang disediakan secara otomatis. Ketika klaim dihilangkan, volume akan musnah.

Perilaku Default

Penyediaan dinamis dapat diaktifkan pada setiap klaster supaya semua klaim dapat disediakan secara dinamis jika tidak ada StorageClass yang dispesifikasikan. Seorang klaster admin dapat mengaktifkan perilaku ini dengan cara:

• Menandai satu objek StorageClass sebagai default;
• Memastikan bahwa admission controller DefaultStorageClass telah aktif pada API server.

Seorang admin dapat menandai StorageClass yang spesifik sebagai default dengan menambahkan anotasi storageclass.kubernetes.io/is-default-class. Ketika StorageClass default tersebut ada pada klaster dan pengguna membuat PersistentVolumeClaim tanpa menspesifikasikan storageClassName, admission controller DefaultStorageClass secara otomatis menambahkan field storageClassName dengan StorageClass default.

Perhatikan bahwa hanya bisa ada satu default StorageClass pada sebuah klaster, atau PersistentVolumeClaim tanpa menspesifikasikan storageClassName secara eksplisit tidak bisa terbuat.

Kesadaran (Awareness) Topologi

Pada klaster Multi-Zona, Pod dapat tersebar di banyak Zona pada sebuah Region. Penyimpanan dengan backend Zona-Tunggal seharusnya disediakan pada Zona-Zona dimana Pod dijalankan. Hal ini dapat dicapai dengan mengatur Mode Volume Binding.

8 - Limit Volume yang Spesifik terhadap Node

Laman ini menjelaskan soal jumlah volume maksimal yang dapat dihubungkan ke sebuah Node untuk berbagai penyedia layanan cloud.

Penyedia layanan cloud seperti Google, Amazon, dan Microsoft pada umumnya memiliki keterbatasan dalam jumlah volume yang bisa terhubung ke sebuah Node. Keterbatasn ini sangatlah penting untuk diketahui Kubernetes dalam menentukan keputusan. Jika tidak, Pod-pod yang telah dijadwalkan pada sebuah Node akan macet dan menunggu terus-menerus untuk terhubung pada volume.

Limit default pada Kubernetes

Kubernetes scheduler memiliki limit default untuk jumlah volume yang dapat terhubung pada sebuah Node:

Limit custom

Kamu dapat mengganti limit-limit ini dengan mengkonfigurasi nilai dari variabel environment KUBE_MAX_PD_VOLS, lalu menjalankan scheduler.

Berhati-hatilah jika kamu menerapkan limit yang lebih besar dari limit default. Perhatikan dokumentasi penyedia layanan cloud untuk hal ini, dan pastikan Node benar-benar dapat mendukung nilai limit yang kamu inginkan.

Limit ini diterapkan untuk seluruh klaster, jadi akan berdampak pada semua Node.

Limit volume dinamis

Sebagai fitur Alpha, Kubernetes 1.11 memperkenalkan dukungan untuk limit volume yang dinamis berdasarkan tipe Node. Pada Kubernettes 1.12, fitur ini telah mendapat promosi ke Beta dan akan diaktifkan secara default.

Limit volume dinamis mendukung tipe-tipe volume berikut:

• Amazon EBS
• Google Persistent Disk
• Azure Disk
• CSI

Ketika fitur limit volume dinamis diaktifkan, Kubernetes secara otomatis menentukan tipe Node dan menerapkan jumlah volume dengan tepat, berapa yang bisa terhubung Node. Sebagai contoh:

• Pada Google Compute Engine, maskimal 128 jumlah volumes dapat terhubung pada sebuah node, tergantung dari tipe node.

• Untuk Amazon EBS disk pada tipe instans M5,C5,R5,T3 dan Z1D, Kubernetes hanya memperbolehkan 25 volume dapat terhubung pada sebuah Node. Untuk tipe instans lainnya pada Amazon Elastic Compute Cloud (EC2), Kubernetes memperbolehkan 39 jumlah volume dapat terhubung pada sebuah Node.

• Pada Azure, maksimal 64 jumlah disk dapat terhubung pada suatu node, tergantung dari tipe node. Untuk perinciannya bisa dilihat pada Ukuran mesin virtual (VM) di Azure.

• Untuk CSI, driver manapun yang memberitahukan (advertise) limit volume terhubung melalui spek CSI akan memiliki limit tersebut yang disediakan sebagai properti Node dan Scheduler tidak akan menjadwalkan Pod dengan volume pada Node manapun yang sudah penuh kapasitasnya. Untuk penjelasan lebih jauh lihat spek CSI.