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: registry.k8s.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: registry.k8s.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: registry.k8s.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: registry.k8s.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: registry.k8s.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: registry.k8s.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: registry.k8s.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: registry.k8s.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 containers[*].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.