Kubernetes 101: Storage

Memfasilitasi persistensi dan pembagian data, komponen Volume merupakan inti dari fungsionalitas Kubernetes.

Perkenalan

Kubernetes, platform orkestrasi container terdepan di industry saat ini, menawarkan sejumlah komponen dan konsep inovatif, salah satu yang paling penting adalah Kubernetes Volume. Memfasilitasi persistensi dan pembagian data, komponen Volume merupakan inti dari fungsionalitas Kubernetes.

Nah, dalam panduan komprehensif ini, ONXP mau membahas aspek teknis rumit dari Kubernetes Volume, termasuk eksplorasi mendetail plus contoh-contoh yang mudah dimengerti.

Memahami Kubernetes Volume

Pada intinya, Kubernetes Volume itu layaknya kotak penyimpanan yang terkait dengan Pod, sehingga Volume ini bisa bikin data tetap tersedia dan memfasilitasi sejumlah data di beberapa container di dalam Pod.

Singkatnya, Kubernetes Volume bukan Cuma sekedar folder yang berisi data biasa. Volume di Kubernetes ini ada sepanjang Pod-nya, ia akan meningkatkan kemampuan container untuk mengolah dan menangani data.

Kubernetes memiliki berbagai jenis Volume, yang masing-masingnya sesuai dengan kebutuhan dan lingkungannya. Misalnya, Volume EmptyDir, yang dibuat saat Pod ditempatkan pada Node, yang ideal untuk ruang sementara atau awal.

Sementara Volume HostPath memberikan akses ke file atau folder di filesystem Node ke Pod-nya. Ini akan sangat berguna untuk menjalankan layanan storage saat pengujian Node tunggal. Selain itu, PersistentVolume (PV) memberikan Solusi yang lebih kuat untuk menyimpan data dalam jangka panjang, yang tetap bertahan melebihi limit masing-masing Pod.

Misalnya, anggap sebuah Pod menghosting aplikasi web dengan dua container: satu untuk melayani antarmuka web, dan satu lagi untuk mengatur data. Untuk data sementara, misalnya data sesi atau cache, kamu bisa menggunakan Volume EmptyDir. Tapi, untuk menyimpan data pengguna, kamu bisa menggunakan PersistentVolume, agar datanya tetap ada di luar life-cycle Pod.

Cara Kerja Volume Kubernetes

Siklus hidup Kubernetes Volume berhubungan dengan Pod terkait. Saat Pod dibuat, Volume-nya otomatis terbuat dan diisi dengan data dari sumber yang ditentukan. Sebaliknya, kalau Pod-nya dihapus, Volume juga akan hilang, kecuali kamu menggunakan PersistentVolume.

Hubungan antara Volume di Kubernetes dan Pod itu sangan mendasar. Saat Pod dideploy, Volume di-mount ke path tertentu di dalam container. Operasi tersebut memunginkan aplikasi pada container bisa diakses dan disimpan dengan lancar.

Contohnya, aplkiasi database yang berjalan di sebuah container membutuhkan akses ke PersistentVolume yang menyimpan file database yang asli. Saat Pod di-deploy, PersistentVolume ini di-mount ke path spesifik yang diharapkan aplikasi database, agar bisa berinteraksi dengan data seolah-olah data itu ada di filesystem lokal.

Tipe Volume

Di Kubernetes, Volume itu adalah direktori, yang mungkin berisi beberapa data, yang bisa diakses oleh container di dalam Pod. Kubernetes mendukung banyak jenis Volume. Satu Pod bisa menggunakan beberapa jenis Volume sekaligus.

Yuk, lihat beberapa jenis Volume Kubernetes yang umum:

1. emptyDir: Sebuah direktori sementara yang berbagi masa hidup dengan Pod.
2. hostPath: Memasang file atau direktori dari filesystem node host ke Pod-mu.
3. awsElasticBlockStore: Memasang volume Amazon Web Services (AWS) EBS ke dalam Pod-mu.
4. gcePersistentDisk: Memasang Google Compute Engine (GCE) Persistent Disk ke dalam Pod-mu.
5. azureDisk / azureFile: Memasang volume Azure Disk atau berbagi Azure File ke dalam Pod-mu.
6. nfs: Memasang berbagi NFS ke dalam Pod-mu.
7. persistentVolumeClaim: Memberikan cara bagi Pod untuk menggunakan Persistent Volumes.
8. configMap, secret, downwardAPI: Jenis-jenis volume khusus yang memberikan Pod informasi tertentu.
9. csi: Jenis volume eksperimental yang memungkinkan pengguna menggunakan penyedia penyimpanan pihak ketiga.

Penyedia Kubernetes Storage

Penyedia Kubernetes Storage mendukung abstraksi Volume, yang berfungsi sebagai backend fisik di mana data disimpan. Ada banyak pilihan pada penyedia ini, mulai dari sistem penyimpanan lokal sampai solusi berbasis cloud, masing-masing dengan keunggulan uniknya.

Misalnya, NFS (Network File System) bisa digunakan untuk penerapan lokal, yang memungkinkan Pod untuk membaca atau menulis data yang disimpan di penyimpanan jaringanmu yang sudah ada.

Untuk solusi berbasis cloud, penyedia seperti Amazon Web Services (awsElasticBlockStore) dan Google Cloud (gcePersistentDisk) memiliki antarmuka penyimpanan unik mereka sendiri.

Intinya, Penyedia Kubernetes Storage bergantung pada infrastruktur dan kebutuhan khususmu. Bisnis yang aplikasinya berjalan di AWS akan mendapatkan manfaat dari penggunaan awsElasticBlockStore, sementara organisasi yang memiliki perangkat keras penyimpanan on-premises yang besar mungkin akan memilih NFS.

Ingat, setiap penyedia memiliki kelebihan, batasan, dan karakteristik performa masing-masing. Jadi, pilihannya harus didasarkan pada evaluasi cermat terhadap kebutuhan aplikasimu, seperti performa I/O, ketahanan data, dan efektivitas biaya.

Container Storage Interface (CSI)

Container Storage Interface adalah standar yang memberikan akses ke sistem penyimpanan file dan blok arbitrer ke beban kerja dalam container. Kubernetes menggunakan CSI agar penyedia storage pihak ketiga bisa mengembangkan solusi tanpa perlu menambahkan basis kode inti Kubernetes.

CSI memungkinkan Kubernetes berkomunikasi dengan berbagai macam backend penyimpanan, jadi kamu bisa menggunakan sistem penyimpanan tradisional atau solusi penyimpanan berbasis perangkat lunak yang lebih baru.

Fitur tersebut menjamin bahwa apapun system penyimpanan yang digunakan – baik itu perangkat keras on-premises seperti NFS atau sistem berbasis awan seperti Amazon S3—aplikasi yang berjalan di Kubernetes bisa mengakses penyimpanan yang mereka butuhkan.

Misalnya, organisasimu ingin menggunakan solusi penyimpanan baru dan yang sangat canggih, yang belum didukung langsung oleh Kubernetes. Dengan adanya CSI, penyedia storage bisa membuat plugin yang memungkinkan Kubernetes berkomunikasi dengan solusi penyimpanan, sehingga integrasi mereka dengan beban kerja Kubernetes kamu jadi lebih lancar.

Storage Classes di Kubernetes

Storage Classes di Kubernetes sangat penting karena ia menyediakan volume dinamis. Storage Classes membantumu menentukan “classes” atau tingkatan penyimpanan yang beragam, ia juga menyediakan volume berdasarkan permintaan pengguna. Yuk, pelajari lebih detail tentang implementasi StorageClasses.

StorageClasses di Kubernetes menyediakan cara bagi administrator untuk mendeskripsikan “kelas” penyimpanan yang mereka tawarkan. Saat membuat PersistentVolumeClaim, pengguna bisa meminta kelas tertentu untuk mendapatkan pencocokan PersistentVolumes.

Jenis-jenis StorageClasses:

1. Default: Digunakan saat kelas penyimpanan tidak ditentukan di PersistentVolumeClaim. Default sangat berguna ketikakamu tidak memerlukan kelas penyimpanan tertentu.
2. Manual: Artinya, kamu membuat PersistentVolume secara manual yang mengarah ke asset penyimpanan fisik. Dengan metode ini, kamu akan lebih bebas mengelola fitur penyimpanan yang mendasarinya, tapi tidak dinamis.
3. Static Provisioning: Metode gabungan di mana kamu membuat PersistentVolume secara manual, sekaligus mengizinkan sistem mengelola PersistentVolumeClaims secara dinamis.
4. Dynamic Provisioning: Menghilangkan kebutuhan cluster administrator untuk pre-provision storage. Ia secara otomatis menyediakan penyimpanan ketika diminta oleh pengguna.

Memahami StorageClasses

StorageClass adalah objek Kubernetes yang mendefinisikan sifat penyimpanan yang disediakan secara dinamis untuk PersistentVolume yang menggunakannya. Ia merangkum detail seperti penyedia penyimpanan, parameter khusus untuk penyedia, dan kebijakan klaim ulang untuk PersistentVolume yang disediakan secara dinamis.

StorageClasses itu sangat fleksibel, sehingga administrator bisa menentukan kelas sebanyak yang diperlukan. Fleksibiltas StorageClasses bisa mendukung terciptanya berbagai tingkatan penyimpanan, misalnya 'fast' untuk penyimpanan berbasis SSD, ‘slow’ untuk penyimpanan berbasis HDD yang lebih murah, atau tingkatan berdasarkan persyaratan IOPS atau kebijakan pencadangan.

Menerapkan StorageClasses

Jika kamu mau membuat StorageClass, definisikan dulu dalam YAML manifest, dengan menetapkan detail seperti provisioner, parameter, dan reclaimPolicy.

Lihatlah contoh sederhana saat kita membuat StorageClass untuk penyimpanan persisten disk standar Google Cloud:

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

Contoh ini mendefinisikan StorageClass dengan nama standard. Penyedia diatur ke kubernetes.io/gce-pd yang mengindikasikan bahwa volume disediakan menggunakan penyimpanan disk persisten Google Cloud.

Bidang parameter menetapkan bahwa kita menggunakan disk tipe 'pd-standard', dan reclaimPolicy diatur ke 'Delete', yang berarti volume secara otomatis dihapus saat pengguna selesai menggunakannya.

Parameter volumeBindingMode yang diatur ke WaitForFirstConsumer artinya volume hanya akan tersedia saat Pod menggunakan PVC dijadwalkan ke sebuah node. Mode tersebut penting untuk jenis volume yang tidak tersedia secara universal atau mungkin memiliki batasan pada node mana volume tersebut dapat dilampirkan.

Menggunakan StorageClasses

Begitu StorageClasses dibuat, kamu bisa menggunakannya di PersistentVolumeClaim dengan menyebutkan nama StorageClasses-nya di field storageClassName. Perhatikan contoh di bawah ini:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: standard
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

Dalam contoh ini, kita membuat PersistentVolumeClaim yang menggunakan StorageClass standard yang sudah ditentukan sebelumnya. Klaim ini meminta volume 8Gi yang bisa di-mount dengan hak read-write oleh satu node.

Otomatisasi Penyediaan dengan StorageClass Default

Perlu dicatat, Kubernetes juga memungkinkan kamu menyetel StorageClass default. PersistentVolumeClaim apa pun yang tidak menentukan storageClassName akan secara otomatis menggunakan StorageClass default.

Untuk menyetel StorageClass jadi default, kamu perlu menambahkan anotasi storageclass.kubernetes.io/is-default-class ke objek StorageClass, seperti:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Di sini, StorageClass 'standar' ditetapkan sebagai default, ia otomatis dipilih untuk PVC yang tidak secara eksplisit mendeklarasikan storageClassName.

Dengan adanya StorageClasses, Kubernetes bisa otomatis mengelola penyediaan dan life-cycle PersistentVolume berdasarkan kelas yang sudah ditentukan, sehingga penyimpanan akan lebih fleksibel dan efisien.

Contoh Implementasi Storage Class

---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-storage-class
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer

Mari uraikan manifest ini:

1. apiVersion: storage.k8s.io/v1: Menentukan versi API yang akan digunakan.
2. kind: StorageClass: Mendefinisikan jenis objek Kubernetes yang akan dibuat, dalam hal ini, StorageClass.
3. metadata.name: my-storage-class: Nama StorageClass yang kita buat.
4. provisioner: kubernetes.io/aws-ebs: Provisioner ini bertanggung jawab untuk membuat dan menghapus sumber daya penyimpanan. Dalam hal ini, menggunakan provisioner AWS EBS, jadi kita menggunakan Amazon Web Services' Elastic Block Store.
5. parameters.type: gp2: Parameter khusus AWS, dan ia menentukan jenis volume EBS yang akan dibuat. 'gp2' artinya General Purpose SSD, sejenis penyimpanan EBS.
6. parameters.fsType: ext4: Parameter khusus AWS lainnya, yang menentukan jenis filesystem dari volume EBS yang dibuat. Di sini, sudah diatur untuk menggunakan ext4.
7. reclaimPolicy: Retain: Kebijakan reclaim untuk PersistentVolume yang dibuat secara dinamis. Kebijakan 'Retain' berarti PV tidak akan dihapus saat PVC terkait dihapus.
8. volumeBindingMode: WaitForFirstConsumer: Menunjukkan kapan harus bind dan provision PersistentVolume. Mode 'WaitForFirstConsumer' berarti PV hanya akan di-provision saat sebuah Pod yang menggunakan PVC dijadwalkan. Mode ini penting untuk tipe volume yang mungkin memiliki batasan pada node mana mereka bisa dilampirkan.

Dengan menerapkan manifest ini, Kubernetes membuat StorageClass bernama 'my-storage-class' dengan konfigurasi yang sudah ditentukan. Sekarang, setiap kali ada PersistentVolumeClaim yang menyebutkan storageClassName: my-storage-class, PersistentVolume baru akan secara otomatis dibuat di AWS EBS dengan parameter yang ditentukan dan dilampirkan pada klaim tersebut.

PV dan PVC

Di Kubernetes, PersistentVolume (PV) dan PersistentVolumeClaim (PVC) adalah dua komponen inti dari sistem penyimpanan, yang dirancang untuk membantu orkestrasi penyimpanan. Untuk memahami lebih dalam, kita perlu mempelajari definisinya, cara kerjanya, siklus hidupnya, dan cara aksesnya.

Persistent Volume (PV)

PersistentVolume (PV) adalah bagian penyimpanan yang disediakan oleh administrator di cluster. Ini mencakup keseluruhan cluster dan tidak bergantung pada siklus hidup setiap pod. PV dapat diprovisikan secara statis (disediakan lebih dulu oleh administrator) atau secara dinamis (melalui StorageClasses).

PV bisa didukung oleh berbagai sistem penyimpanan, termasuk Network File System (NFS), iSCSI, penyimpanan berbasis cloud seperti AWS's Elastic Block Store (EBS), Google Cloud Persistent Disk, Azure Disk, dan lain-lain.

Persistent Volume Claims (PVC)

Di sisi lain, PersistentVolumeClaim (PVC) adalah permintaan penyimpanan oleh pengguna. Sama seperti pod yang menyerap sumber daya node seperti CPU dan memory, PVC juga menyerap sumber daya PV.

PVC memungkinkan pengguna untuk menggunakan sumber daya penyimpanan abstrak. Begitu PVC dibuat, bidang kontrol Kubernetes mencari PV yang cocok untuk di-bind ke PVC. Jika PV yang sesuai ditemukan, siklus hidup PVC menjadi terhubung dengan PV.

Bagaimana PV dan PVC Bekerja Sama

Hubungan antara PV dan PVC itu bersifat mengikat, di mana PVC menetapkan spesifikasi penyimpanan, dan jika ada PV yang memenuhi spesifikasi tersebut, PVC akan mengikatnya.

Ketika PVC dihapus, tergantung pada kebijakan reclaim PV, PV-nya bisa tetap disimpan, dihapus, atau didaur ulang (jika didukung oleh penyedia penyimpanan).

Misalnya, seorang pengguna bisa membuat PVC yang meminta penyimpanan sebesar 10 GB. Jika ada PV yang menyediakan penyimpanan sebesar jumlah yang diinginkan, PVC akan tetap terhubung. Jika PV tersebut tidak ada, PVC akan tetap tidak terhubung sampai muncul PV yang sesuai.

Lifecycle

PV dan PVC memiliki siklus hidupnya masing-masing. Siklus hidup PV tidak bergantung pada Pod atau PVC mana pun, sementara PVC muncul saat ia didefinisikan dan mati saat dihapus.

Sebuah PV bisa memiliki kebijakan reclaim yang berbeda: Retain (PV tidak dihapus setelah PVC dihapus), Delete (PV otomatis dihapus ketika PVC dihapus), atau Recycle (tidak digunakan lagi di Kubernetes 1.13).

Mode Akses

PV dan PVC mendukung mode akses yang berbeda:

ReadWriteOnce: Volume bisa di-mount sebagai read-write oleh satu node.
ReadOnlyMany: Volume bisa di-mount sebagai read-only oleh banyak node.
ReadWriteMany: Volume bisa di-mount sebagai read-write oleh banyak node.

Perhatikan bahwa tidak semua penyedia penyimpanan mendukung semua mode akses. Misalnya, GCE Persistent Disk standar hanya mendukung ReadWriteOnce, sedangkan NFS mendukung ReadWriteMany.

Utilization

Untuk menggunakan PV dan PVC, kamu perlu mendeklarasikannya di konfigurasi pod-mu. Kamu akan mendeklarasikan sebuah PVC, menentukan persyaratan penyimpanan dan mode aksesnya, lalu menggunakan nama PVC tersebut sebagai volume dalam konfigurasi Pod-mu.

Volume tersebut kemudian dilampirkan ke container yang diinginkan dalam Pod-mu, dengan menentukan jalur pemasangannya. Lalu, aplikasi dalam container akan berinteraksi dengan volume seolah-olah itu adalah sistem file lokal, tanpa mengetahui sifat mekanisme penyimpanan yang mendasarinya.

Berikut adalah contoh manifest dasar untuk PersistentVolume (PV):

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: slow
  hostPath:
    path: /data/my-pv

Sekarang, mari kita uraikan:

1. apiVersion: v1: Menentukan versi API yang akan digunakan.
2. kind: PersistentVolume: Mendefinisikan jenis objek Kubernetes yang akan dibuat, dalam hal ini, PersistentVolume.
3. metadata.name: my-pv: Nama PV yang sedang kita buat.
4. spec.capacity.storage: 10Gi: Kapasitas penyimpanan PV. Ini adalah jumlah penyimpanan yang disediakan volume.
5. spec.volumeMode: Filesystem: Mendefinisikan apakah penyimpanan yang digunakan berbasis blok atau berbasis sistem file. Dalam hal ini, berbasis sistem file.
6. spec.accessModes: [ReadWriteOnce]: Mode akses untuk PV. ReadWriteOnce berarti volume bisa di-mount sebagai read-write oleh satu node.
7. spec.persistentVolumeReclaimPolicy: Retain: Kebijakan reclaim PV. Saat PVC dihapus, kebijakan Retain berarti PV tidak akan dihapus.
8. spec.storageClassName: slow: StorageClass yang terkait dengan PV. StorageClass harus dibuat sebelum merujuk di sini.
9. spec.hostPath.path: /data/my-pv: Jalur pada host tempat data akan disimpan. hostPath sebaiknya hanya digunakan untuk pengujian node tunggal, bukan untuk cluster multi-node.

Dan berikut adalah manifest untuk PersistentVolumeClaim (PVC):

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  storageClassName: slow
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Mari kita uraikan:

1. apiVersion: v1: Menentukan versi API yang akan digunakan.
2. kind: PersistentVolumeClaim: Mendefinisikan jenis objek Kubernetes yang akan dibuat, dalam hal ini, sebuah PersistentVolumeClaim.
3. metadata.name: my-pvc: Nama PVC yang kita buat.
4. spec.storageClassName: slow: StorageClass yang diminta di PVC. Sebuah PV dari kelas yang sama akan di-bind ke PVC ini.
5. spec.accessModes: [ReadWriteOnce]: Mode akses untuk PVC. ReadWriteOnce artinya volume bisa di-mount sebagai read-write oleh satu node. PV yang di-bind juga harus mendukung mode ini.
6. spec.resources.requests.storage: 5Gi: Ukuran penyimpanan yang diminta dalam PVC. PV yang di-bind setidaknya harus memiliki penyimpanan sebanyak ini.

Setelah kedua manifes ini diaplikasikan, Kubernetes akan menghubungkan my-pvc ke my-pv karena keduanya memiliki accessModes dan storageClassName yang kompatibel, dan PV memiliki cukup penyimpanan untuk permintaan PVC. Volume yang terhubung bisa digunakan oleh sebuah Pod dengan mengacu my-pvc pada spesifikasinya.