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.
Perhatian:
Kamu harus membuat sebuah volume EBS menggunakanawscli
dengan perintah aws ec2 create-volume
atau menggunakan AWS API sebelum kamu dapat menggunakannya.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
Kubernetes v1.14 [alpha]
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
Kubernetes v1.15 [alpha]
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
Kubernetes v1.15 [alpha]
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.
Perhatian:
Kamu harus memiliki server Ceph sendiri dan mengekspor share-nya sebelum kamu dapat menggunakannya.Selengkapnya, lihat contoh CephFS.
cinder
Catatan:
Prasyarat: Kubernetes dengan penyedia layanan cloud OpenStack yang telah dikonfigurasikan. Untuk konfigurasi penyedia layanan cloud, silahkan lihat penyedia layanan cloud openstack.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
Kubernetes v1.14 [alpha]
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
.
Perhatian:
Kamu harus membuat sebuah ConfigMap sebelum kamu dapat menggunakannya.Catatan:
Sebuah Container yang menggunakan sebuah ConfigMap sebagai tambatan Volume subPath tidak akan menerima pembaruan ConfigMap.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.
Catatan:
Sebuah Container yang menggunakan Downward API sebagai tambatan Volume subPath tidak akan menerima pembaruan Downward API.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.
Catatan:
Sebuah Container yang gagal TIDAK AKAN menghapus sebuah Pod dari sebuah Node, sehingga data di dalam sebuahemptyDir
akan aman jika Container di dalam Podnya gagal.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.
Perhatian:
Sebelumnya, kamu harus mengkonfigurasikan FC SAN Zoning untuk mengalokasikan dan melakukan masking terhadap LUN (volume) tersebut terhadap target WWN sehingga Node-node Kubernetes dapat mengakses mereka.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.
Perhatian:
Kamu harus memiliki instalasi Flocker yang sudah berjalan sebelum kamu dapat menggunakannya.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.
Perhatian:
Kamu harus membuat sebuah PD menggunakangcloud
atau GCE API atau GCP UI sebelum kamu dapat menggunakannya.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
Kubernetes v1.10 [beta]
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
Kubernetes v1.14 [alpha]
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)
Peringatan:
Tipe VolumegitRepo
telah kedaluwarsa. Untuk membuat sebuah Container dengan sebuah git repo, tambatkan sebuah EmptyDir ke dalam sebuah InitContainer yang akan mengklon repo tersebut menggunakan git, dan kemudian tambatkan EmptyDir tersebut ke dalam Container Pod tersebut.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.
Perhatian:
Kamu harus mempunyai instalasi GlusterFS terlebih dahulu sebelum dapat kamu gunakan.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:`
Nilai | Perilaku |
---|---|
String kosong (bawaan) adalah untuk kecocokan dengan versi-versi bawah, yang berarti bahwa tidak ada pemeriksaan yang dilakukan sebelum menambatkan Volume hostPath. | |
DirectoryOrCreate | Jika tidak ada yang tersedia pada path yang dirinci, sebuah direktori kosong akan dibuat sesuai kebutuhan, dengan permission yang disetel menjadi 0755, dan mempunyai grup dan kepemilikan yang sama dengan Kubelet. |
Directory | Sebuah direktori harus sudah tersedia pada path yang dirinci |
FileOrCreate | Jika tidak ada yang tersedia pada path yang dirinci, maka sebuah berkas kosong akan dibuat sesuai kebutuhan dengan permission yang disetel menjadi 0644, dan mempunyai grup dan kepemilikan yang sama dengan Kubelet. |
File | Sebuah berkas harus sudah tersedia pada path yang dirinci |
Socket | Sebuah socket UNIX harus sudah tersedia pada path yang dirinci |
CharDevice | Sebuah character device sudah tersedia pada path yang dirinci |
BlockDevice | Sebuah block device harus sudah tersedia pada path yang dirinci |
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 sebagairoot
pada sebuah privileged Container atau mengubah permission berkas kamu pada host tersebut agar dapat menulis pada VolumehostPath
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.
Perhatian:
Kamu harus memiliki peladen iSCSI yang berjalan dengan volume iSCSI yang telah dibuat terlebih dahulu untuk dapat menggunakannya.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
Kubernetes v1.14 [stable]
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.
Catatan:
PersistentVolume lokal membutuhkan pembersihan dan penghapusan secara manual oleh pengguna jika penyedia eksternal tidak digunakan untuk mengatur siklus hidup Volumelokal
tersebut.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.
Perhatian:
Kamu harus memiliki peladen NFS yang berjalan dengan share yang diekspor sebelum kamu dapat menggunakannya.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 menjadiname
agar konsisten dengan penamaan ConfigMap. - Kolom
defaultMode
hanya dapat dispesifikasikan pada tingkatprojected
dan tidak untuk setiap sumber Volume. Tetapi, seperti yang ditunjukkan di atas, kamu dapat secara eksplisit menyetelmode
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.
Catatan:
Sebuah Container yang menggunakan sebuah sumber Volumeprojected
sebagai tambatan Volume subPath tidak akan menerima pembaruan pada sumber Volume 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>"
Perhatian:
Pastikan kamu sudah memiliki PortworxVolume dengan namapxvol
sebelum dapat menggunakannya pada Pod.Lihat di sini untuk lebih lanjut.
quobyte
Sebuah Volume quobyte
memungkinkan sebuah volume Quobyte yang sudah tersedia untuk ditambatkan ke dalam Pod kamu.
Perhatian:
Kamu harus sudah memiliki instalasi Quobyte dengan volume yang sudah disediakan terlebih dahulu untuk dapat menggunakannya.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.
Perhatian:
Kamu harus memiliki instalasi Ceph yang berjalan sebelum kamu dapat menggunakan RBD.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).
Perhatian:
Kamu harus memiliki klaster ScaleIO yang berjalan dengan volume-volume yang sudah dibuat sebelum kamu dapat menggunakannya.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.
Perhatian:
Kamu harus membuat sebuahsecret
di dalam Kubernetes API sebelum kamu dapat menggunakannya.Catatan:
Sebuah Container yang menggunakan sebuah Secret sebagai sebuah Volume subPath tidak akan mendapatkan pembaruan terhadap Secret.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.
Perhatian:
Kamu harus menjalankan Container StorageOS pada setiap Node yang ingin mengakses volume-volume StorageOS atau yang akan berkontribusi pada kapasitas penyimpanan di klaster StorageOS. Untuk petunjuk instalasi, lihat dokumentasi StorageOS.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
Catatan:
Prasyarat: Kubernetes dengan Cloud Provider vSphere yang telah dikonfigurasikan. Untuk konfigurasi cloudprovider, silahkan lihat petunjuk memulai vSphere.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.
Perhatian:
Kamu harus membuat VMDK menggunakan satu dari cara-cara berikut sebelum menggunakannya dengan Pod.Membuat sebuah Volume VMDK
Pilih satu dari beberapa cara berikut untuk membuat sebuah VMDK.
Pertama-tama, ssh ke dalam ESX, kemudian gunakan perintah berikut untuk membuat sebuah VMDK:
vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk
Gunakan perintah berikut untuk membuat sebuah 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
Kubernetes v1.15 [beta]
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.
Catatan:
Dukungan untuk spesifikasi CSI pada versi 0.2 dan 0.3 telah kedaluwarsa pada Kubernetes v1.13 dan akan dihapus pada rilis-rilis di masa depan.Catatan:
Driver-driver CSI mungkin tidak cocok pada semua rilis Kubernetes. Silahkan lihat dokumentasi driver CSI yang bersangkutan untuk petunjuk penggunaan yang didukung untuk setiap rilis Kubernetes, dan untuk melihat matriks kompabilitasnya.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 olehGetPluginInfoResponse
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 kolomvolume.id
dariCreateVolumeResponse
dari driver CSI seperti yang didefinisikan pada spesifikasi CSI. Nilai tersebut dioper sebagaivolume_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 adalahfalse
. Nilai ini dioper ke driver CSI melalui kolomreadonly
padaControllerPublishVolumeRequest
.fsType
: Jika nilaiVolumeMode
milik PV adalahFileSystem
, 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 kolomVolumeCapability
dariControllerPublishVolumeRequest
,NodeStageVolumeRequest
, danNodePublishVolumeRequest
.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 kolomvolume.attributes
padaCreateVolumeResponse
dari driver CSI seperti yang didefinisikan pada spesifikasi CSI. Map tersebut dioper kepada driver CSI melalui kolomvolume_attributes
padaControllerPublishVolumeRequest
,NodeStageVolumeRequests
, danNodePublishVolumeRequest
.controllerPublishSecretRef
: Sebuah referensi ke objek Secret yang berisi informasi sensitif untuk diberikan pada driver CSI untuk menyelesaikan panggilanControllerPublishVolume
danControllerUnpublishVolume
. 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 panggilanNodeStageVolume
. 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 panggilanNodePublishVolume
. 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
Kubernetes v1.14 [beta]
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
Kubernetes v1.15 [alpha]
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
Kubernetes v1.14 [alpha]
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 LinuxHostToContainer
- 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 propagationHostToContainer
akan melihatnya.Mode ini setara dengan mount propagation
rslave
, seperti yang dideskripsikan pada dokumentasi kernel LinuxBidirectional
- Tambatan volume ini memiliki perilaku yang sama dengan tambatanHostToContainer
. 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
Perhatian:
Mount propagationBidirectional
bisa jadi berbahaya. Ia dapat merusak sistem operasi host-nya, sehingga hanya diizinkan pada Container yang privileged. Keterbiasaan dengan perilaku kernel Linux sangat dianjurkan.
Sebagai tambahan, tambatan volume apapun yang dibuat oleh Container-container di dalam Pod-pod harus dihancurkan (dilepaskan tambatannya) oleh Container-container pada saat terminasi.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.