Mempelajari Panduan Dasar Kubernetes

Konsep

Kubernetes v1.15 dokumentasi sudah tidak dirawat lagi. Versi yang kamu lihat ini hanyalah snapshot statis. Untuk dokumentasi terkini, lihat versi terkini.

Edit This Page

Penyediaan Volume Dinamis

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

Latar Belakang

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

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

Info lebih lanjut mengenai storage class dapat dilihat di sini.

Mengaktifkan Penyediaan Dinamis (Dynamic Provisioning)

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

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

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

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

Menggunakan Penyediaan Dinamis

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

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

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

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

Perilaku Default

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

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

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

Kesadaran (Awareness) Topologi

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

Masukan