Memahami Storage Kubernetes dan Praktik CSI Driver EKS

Poin Utama:

Memahami Volume Volatil (Ephemeral Volumes)
Memahami Kubernetes CSI Driver dan EKS Add-on
Memahami PV (Persistent Volume), PVC (Persistent Volume Claim), dan SC (Storage Class)
Memahami Ekspansi Volume PVC Online, Batasan Availability Zone (AZ), dan Kebijakan Reclaim (Reclaim Policy)

Ini adalah direktori GitHub untuk kode yang digunakan dalam praktik di bab ini.
https://github.com/junghoon2/k8s-class/tree/main/aws-ebs-csi

1. Memahami Batasan Volume Volatil (Ephemeral Volumes) pada Kubernetes

Istilah “Ephemeral” merujuk pada sesuatu yang bersifat sementara atau berjangka pendek. Volume volatil terikat langsung dengan siklus hidup (lifecycle) kontainer. Artinya, setiap kali kontainer dibuat atau dimulai ulang (restart), volume tersebut juga ikut diinisialisasi ulang; ketika kontainer dihapus, data pada volume tersebut pun ikut terhapus.

Mari kita pelajari melalui sebuah latihan sederhana.

ephemeral-vol-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: date-pod
  namespace: default
  labels:
    app: date
spec:
  replicas: 1
  selector:
    matchLabels:
      app: date
  template:
    metadata:
      labels:
        app: date
    spec:
      containers:
      - name: date-pod
        image: busybox
        command:
        - "/bin/sh"
        - "-c"
        - "while true; do date >> /pod-out.txt; sleep 5; done"

Terapkan manifes ini:

[(jerry-test:default) pvc]$ k apply -f ephemeral-vol-deploy.yaml
deployment.apps/date-pod created

Periksa data di dalam pod:

[(jerry-test:default) pvc]$ k exec -it date-pod-cd9968dbb-n4gbm -- cat /pod-out.txt
Thu Sep 7 17:29:52 UTC 2023
Thu Sep 7 17:29:57 UTC 2023
Thu Sep 7 17:30:02 UTC 2023

Informasi waktu saat ini tersimpan di dalam file /pod-out.txt.

Sekarang, hapus pod untuk memicunya restart:

[(jerry-test:default) pvc]$ k delete pod date-pod-cd9968dbb-n4gbm
pod "date-pod-cd9968dbb-n4gbm" deleted

[(jerry-test:default) argo-cd-app-of-apps-qa]$ k get pod --selector app=date
NAME                        READY   STATUS    RESTARTS   AGE
date-pod-cd9968dbb-8zlv9    1/1     Running   0          70s

Pod telah dimulai ulang. Karena pod dijalankan melalui resource Deployment, menghapus pod lama (date-pod-cd9968dbb-n4gbm) akan membuatnya hilang dan pod baru (date-pod-cd9968dbb-8zlv9) otomatis dijalankan.

Mari periksa data pada pod baru yang sedang berjalan:

[(jerry-test:default) pvc]$ k exec -it date-pod-cd9968dbb-8zlv9 -- cat /pod-out.txt
Thu Sep 7 17:34:07 UTC 2023
Thu Sep 7 17:34:12 UTC 2023
Thu Sep 7 17:34:17 UTC 2023

Informasi waktu yang tersimpan dari pod sebelumnya (Thu Sep 7 17:29:52 UTC 2023) telah hilang, dan pencatatan baru dimulai sejak pod baru dijalankan (Thu Sep 7 17:34:07 UTC 2023). Artinya, data sebelumnya telah lenyap.

Bagi mereka yang memiliki pengalaman operasional, Anda pasti bisa merasakan betapa mengerikannya insiden “data hilang” ini. ^^)

Aplikasi yang membutuhkan penyimpanan data secara permanen, seperti basis data (database), tidak dapat menggunakan konfigurasi volume volatil bawaan seperti ini. Oleh karena itu, Kubernetes menyediakan sistem storage sebagai resource terpisah.

Pengguna cukup menentukan nama Storage Class yang diinginkan di dalam file YAML PVC. Kemudian, Storage Class akan memprovisikan PV dari kelas tersebut secara dinamis sesuai dengan permintaan pengguna. Mari kita pelajari detailnya melalui praktik langsung.

2. Praktik Storage di Lingkungan EKS

Sekarang, mari kita pelajari cara mengonfigurasi sistem storage Kubernetes di lingkungan EKS melalui latihan praktik.

Untuk menggunakan PV, PVC, dan Storage Class, diperlukan persiapan terlebih dahulu. Pada native Kubernetes di lingkungan on-premise, konfigurasi sistem storage tambahan harus dilakukan secara terpisah dari instalasi dasar Kubernetes. Untuk tujuan ini, administrator Kubernetes memilih dan menginstal layanan storage yang sesuai dengan lingkungan masing-masing, seperti Longhorn, OpenEBS, Ceph, dan lainnya.

Sebaliknya, layanan Managed Kubernetes (seperti EKS, AKS, GKE) telah menyediakan lingkungan storage saat instalasi default. EKS juga menyediakan lingkungan Storage Class gp2 secara default sehingga storage dapat langsung digunakan seperti di bawah ini:

[(jerry-test:default) pvc]$ k get sc
NAME            PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
gp2 (default)   kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  16d

Dengan menggunakan perintah k get sc (storage class) seperti di atas, kita dapat melihat Storage Class bawaan gp2. Pengguna dapat langsung menggunakannya tanpa konfigurasi tambahan. Ini merupakan salah satu keunggulan layanan Managed Kubernetes, di mana berbagai resource bawaan penyedia cloud telah terintegrasi sejak awal.

Namun, storage tipe gp2 bawaan memiliki performa dan efisiensi biaya yang lebih rendah dibandingkan tipe gp3. Oleh karena itu, disarankan untuk tidak menggunakan storage tipe gp2 bawaan, melainkan beralih menggunakan storage tipe gp3 (silakan rujuk perbandingan gp2 vs gp3).

Untuk menggunakan tipe storage gp3, EKS menggunakan driver CSI (Container Storage Interface). CSI Driver adalah antarmuka standar antara Kubernetes dan sistem storage eksternal. CSI memisahkan sistem manajemen storage dari komponen Core Kubernetes, sehingga memungkinkan berbagai vendor storage untuk mengembangkan fungsionalitas tambahan (seperti snapshot) secara bebas tanpa terikat batasan komponen inti Kubernetes. Banyak vendor storage memanfaatkan kemampuan CSI ini untuk merilis fitur-fitur lanjutan.

2.1. Instalasi IRSA dan CSI Driver

Driver CSI menggunakan layanan AWS EBS (Elastic Block Store) yang berada di luar EKS. Karena mengontrol resource di luar Kubernetes, konfigurasi IRSA (IAM Roles for Service Accounts) tetap diperlukan. Sama seperti pada bab sebelumnya, kita menginstal IRSA untuk CSI menggunakan modul Terraform (merujuk pada repositori GitHub penulis):

module "ebs_csi_irsa_role" {
  source = "terraform-aws-modules/iam/aws//modules/iam-role-for-service-accounts-eks"

  role_name             = "ebs-csi-jerry-test"
  attach_ebs_csi_policy = true

  oidc_providers = {
    ex = {
      provider_arn               = module.eks.oidc_provider_arn
      namespace_service_accounts = ["kube-system:ebs-csi-controller-sa"]
    }
  }

  tags = local.tags
}

role_name: Tentukan nama peran yang unik dan dapat dibedakan.

Buat file Terraform seperti di atas dan terapkan modul IRSA untuk CSI:

$ (⎈ |switch-singapore-test:kube-system) tf init
$ (⎈ |switch-singapore-test:kube-system) tf plan -out planfile
$ (⎈ |switch-singapore-test:kube-system) tf apply planfile

Setelah penerapan selesai, Anda dapat memverifikasi EBS CSI Role di AWS Management Console.

(Catatan: Jika Role Name sama, peran tersebut tidak dapat digunakan untuk klaster EKS yang berbeda. Jika Anda mengoperasikan beberapa EKS, terapkan Role Name yang berbeda untuk masing-masing klaster).

Selanjutnya, buat Add-on untuk Driver CSI menggunakan Role tersebut. EKS Add-on adalah komponen tambahan yang diinstal pada EKS untuk memperluas dan meningkatkan kemampuan klaster Kubernetes. Komponen ini menyederhanakan atau mengotomatiskan berbagai fitur yang lazim dibutuhkan dalam operasional klaster.

Di sini, kode Terraform instalasi EKS awal telah mencakup coredns, kube-proxy, dan vpc-cni, sehingga fungsi-fungsi tersebut dikelola sebagai add-on:

cluster_addons = {
    coredns = {
      preserve    = true
      most_recent = true

      timeouts = {
        create = "25m"
        delete = "10m"
      }
    }
    kube-proxy = {
      most_recent = true
    }
    vpc-cni = {
      most_recent = true
    }
  }

Driver EBS CSI juga dapat dikelola sebagai Add-on. Kode Terraform untuk resource Add-on adalah sebagai berikut:

eks-addon.tf

variable "aws_account_id" {
  type = string
}

resource "aws_eks_addon" "aws_ebs_csi_driver" {
  cluster_name             = module.eks.cluster_name
  addon_name               = "aws-ebs-csi-driver"
  service_account_role_arn = "arn:aws:iam::${var.aws_account_id}:role/ebs-csi-jerry-test"
  addon_version            = "v1.20.0-eksbuild.1"
  resolve_conflicts        = "OVERWRITE"

  lifecycle {
    ignore_changes = [
      service_account_role_arn
    ]
  }
}

service_account_role_arn: Masukkan Role_Arn dari Driver EBS CSI yang telah ditambahkan sebelumnya. Sesuaikan dengan AWS Account ID Anda masing-masing.
addon_version: Anda dapat menggunakan versi yang sama dengan penulis atau menggunakan versi terbaru yang tersedia saat instalasi dilakukan.

Terapkan resource Terraform:

$ (⎈ |switch-singapore-test:kube-system) tf plan -out planfile
$ (⎈ |switch-singapore-test:kube-system) tf apply planfile

Setelah berhasil diinstal, Anda dapat melihat EBS CSI Driver terdaftar di menu Add-ons pada konsol AWS EKS.

Ketika add-on terpasang, resource Deployment ebs-csi-controller dan DaemonSet ebs-csi-node akan diinstal seperti berikut:

$ (⎈ |switch-singapore-test:kube-system) k get deployments.apps ebs-csi-controller -n kube-system
NAME                 READY   UP-TO-DATE   AVAILABLE   AGE
ebs-csi-controller   2/2     2            2           8h

$ (⎈ |switch-singapore-test:kube-system) k get ds ebs-csi-node -n kube-system
NAME           DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR              AGE
ebs-csi-node   2         2         2       2            2           kubernetes.io/os=linux     8h

DaemonSet adalah pod pengontrol yang otomatis berjalan di seluruh node Kubernetes. Pemanfaatan utamanya mencakup monitoring, pengumpulan log, dan penyediaan storage. Ketika sebuah node ditambahkan ke klaster, pod DaemonSet akan otomatis dijalankan tanpa konfigurasi tambahan, sehingga sangat mempermudah operasional.

Pod EBS CSI Controller bertanggung jawab menerima permintaan pembuatan PV dari klaster, lalu membuat dan melampirkan (attach) volume pada layanan AWS EBS di luar Kubernetes. Jika terjadi kendala pada konfigurasi volume, proses troubleshooting dilakukan dengan memeriksa log pod ebs-csi-controller.

2.2. Pembuatan SC (Storage Class)

Selanjutnya, buat Storage Class (SC) berbasis CSI Driver yang telah disiapkan. SC juga merupakan resource Kubernetes yang didefinisikan melalui file manifes YAML (repositori GitHub penulis):

ebs-default-storageclass.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
allowVolumeExpansion: true
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  type: gp3

metadata.name: ebs-scNama Storage Class. Anda bebas menamakannya, tetapi disarankan menggunakan nama standar ebs-sc. Nama ini nantinya akan dirujuk saat membuat PVC.
metadata.annotations.storageclass.kubernetes.io/is-default-class: "true"Menetapkan Storage Class berbasis CSI Driver ini sebagai Storage Class default menggantikan tipe gp2 bawaan. Jika pembuatan PVC tidak menyertakan nama storage class secara eksplisit, volume akan dibuat menggunakan ebs-sc secara default.
allowVolumeExpansion: trueKebutuhan untuk memperluas kapasitas volume kerap terjadi di lingkungan produksi. Jika Storage Class mendukung allowVolumeExpansion, kapasitas volume dapat diperbesar secara online tanpa perlu menghapus volume yang ada ataupun mereplikasi melalui Snapshot. Storage Class ebs-sc mendukung ekspansi volume secara online.
provisioner: ebs.csi.aws.comMenentukan secara eksplisit bahwa pembuatan volume dilakukan melalui CSI Driver.
parameters.type: gp3Menentukan tipe volume EBS menjadi gp3.

Terapkan manifes Storage Class:

$ (⎈ |switch-singapore-test:kube-system) k apply -f ebs-default-storageclass.yaml
storageclass.storage.k8s.io/ebs-sc created

Periksa Storage Class yang baru dibuat:

[(jerry-test:default) aws-ebs-csi]$ k get sc
NAME               PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ebs-sc (default)   ebs.csi.aws.com          Delete          WaitForFirstConsumer   true                   3s
gp2 (default)      kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  19d

Saat ini, kedua storage class memiliki status (default). Kita perlu menghapus status default dari gp2 agar ebs-sc menjadi satu-satunya storage class default:

[(jerry-test:default) aws-ebs-csi]$ kubectl annotate storageclass gp2 storageclass.kubernetes.io/is-default-class-
storageclass.storage.k8s.io/gp2 annotated

[(jerry-test:default) aws-ebs-csi]$ k get sc
NAME               PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ebs-sc (default)   ebs.csi.aws.com          Delete          WaitForFirstConsumer   true                   3m8s
gp2                kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  19d

Kini, ebs-sc telah menjadi storage class default secara tunggal.

2.3. Pembuatan PVC dan Pod

Alur konfigurasi storage adalah: membuat Storage Class terlebih dahulu, menentukan nama Storage Class pada file YAML PVC, lalu menentukan nama PVC pada file YAML Pod.

Pertama, berikut adalah manifes PVC:

ebs-pvc.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ebs-claim
  namespace: default
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: ebs-sc
  resources:
    requests:
      storage: 4Gi

spec.accessModes: ReadWriteOnceEBS Block Storage hanya mendukung operasi baca-tulis (Read/Write) dari satu node (pod) dalam satu waktu. Jika Anda membutuhkan lingkungan di mana beberapa pod dapat membaca dan menulis secara bersamaan, gunakan AWS EFS (Elastic File System) alih-alih EBS. Sistem file EFS mendukung access mode ReadWriteMany.
spec.storageClassName: ebs-scPVC dapat mengalokasikan volume secara dinamis dengan menentukan nama Storage Class. Tanpa Storage Class, administrator harus menentukan dan membuat PV secara manual setiap saat, yang tentu sangat merepotkan. Dengan mendefinisikan Storage Class, kapasitas, dan access mode di manifes PVC, volume akan dibuat secara “dinamis” saat pod dijalankan.
spec.resources.requests.storage: 4GiMenentukan kapasitas volume yang dibutuhkan oleh pod.

Terapkan manifes PVC:

$ (⎈ |switch-singapore-test:default) k apply -f ebs-pvc.yaml
persistentvolumeclaim/ebs-claim created

Periksa status PVC:

$ (⎈ |switch-singapore-test:default) k get pvc
NAME        STATUS    VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ebs-claim   Pending                                      ebs-sc         24s

Status PVC menunjukkan Pending. Hal ini terjadi karena pada konfigurasi Storage Class ebs-sc, parameter volumeBindingMode disetel ke WaitForFirstConsumer. Mode ini menunda pembuatan volume EBS hingga pod yang menggunakan PVC tersebut dijadwalkan ke node tertentu.

$ (⎈ |switch-singapore-test:default) k get sc
NAME               PROVISIONER       RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ebs-sc (default)   ebs.csi.aws.com   Delete          WaitForFirstConsumer   true                   5h10m

Untuk melihat detail kondisi, gunakan perintah describe. Setiap kali terjadi perilaku di luar perkiraan, langkah pertama pada Kubernetes adalah memeriksanya dengan k describe:

$ (⎈ |switch-singapore-test:default) k describe pvc ebs-claim
(Output dihilangkan: menunjukkan status menunggu pod dibuat sebelum provisioning volume dilakukan)

Sekarang, buat pod yang akan mengonsumsi PVC tersebut:

pvc-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: pvc-pod
spec:
  containers:
  - name: pvc-pod
    image: busybox
    command: ["sh", "-c", "while true; do date >> /data/out.txt; sleep 5; done"]
    volumeMounts:
    - name: date-vol
      mountPath: /data
  volumes:
  - name: date-vol
    persistentVolumeClaim:
      claimName: ebs-claim

Strukturnya sederhana dan tidak rumit. Bahkan jika Anda menggunakan berbagai jenis storage yang berbeda, format manifes yang digunakan tetap sama sehingga sangat praktis. Kubernetes mengabstraksikan cara penggunaan storage demi kenyamanan operasional.

Terapkan manifes pod:

$ (⎈ |switch-singapore-test:default) k apply -f pvc-pod.yaml
pod/pvc-pod created

$ (⎈ |switch-singapore-test:default) k get pod pvc-pod
NAME      READY   STATUS    RESTARTS   AGE
pvc-pod   1/1     Running   0          97s

Periksa file data yang ditulis oleh pod:

$ (⎈ |switch-singapore-test:default) k exec -it pvc-pod -- cat /data/out.txt
Wed Jul 19 15:12:10 UTC 2023
Wed Jul 19 15:12:15 UTC 2023
(bagian baris berikutnya dihilangkan)

Sekarang, mari kita hapus pod tersebut untuk menguji persistensi data:

$ (⎈ |switch-singapore-test:default) k delete -f pvc-pod.yaml
pod "pvc-pod" deleted

$ (⎈ |switch-singapore-test:default) k get pod pvc-pod
Error from server (NotFound): pods "pvc-pod" not found

Jalankan kembali pod tersebut:

$ (⎈ |switch-singapore-test:default) k apply -f pvc-pod.yaml
pod/pvc-pod created

Periksa kembali data di dalam pod:

$ (⎈ |switch-singapore-test:default) k exec -it pvc-pod -- cat /data/out.txt
Wed Jul 19 15:12:10 UTC 2023
Wed Jul 19 15:12:15 UTC 2023
(bagian baris berikutnya dihilangkan)

Pada latihan pertama tanpa PVC, data ikut terhapus ketika pod di-restart. Namun saat menggunakan PVC, data sebelumnya tetap utuh dan tidak terhapus. Melalui PVC, data dapat dipertahankan terlepas dari siklus hidup pod (dihapus maupun dibuat ulang).

2.4. Hubungan antara PV, PVC, dan SC

Mari kita periksa hubungan antara resource Storage Class, PVC, dan PV:

$ (⎈ |switch-singapore-test:default) k get pvc
NAME        STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ebs-claim   Bound    pvc-5f4f2824-adb9-452d-969b-f9c127d2eb29   4Gi        RWO            ebs-sc         25m

Status PVC kini berubah menjadi Bound, dan kolom VOLUME telah diasosiasikan dengan PV bernama pvc-5f4f2824-adb9-452d-969b-f9c127d2eb29.

Periksa PV yang dibuat secara otomatis tersebut:

$ (⎈ |switch-singapore-test:default) k get pv pvc-5f4f2824-adb9-452d-969b-f9c127d2eb29
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM               STORAGECLASS   REASON   AGE
pvc-5f4f2824-adb9-452d-969b-f9c127d2eb29   4Gi        RWO            Delete           Bound    default/ebs-claim   ebs-sc                  13m

Developer cukup menentukan nama Storage Class yang diinginkan untuk mengalokasikan volume secara dinamis ke aplikasi. Jika jenis storage perlu diganti, developer cukup mengubah nama PVC tanpa perlu merombak kode aplikasi.

3. Tips Operasional Storage

Untuk memastikan kelancaran operasional sistem storage, mari kita pelajari:

Ekspansi Volume (Volume Expansion)
Batasan Availability Zone (AZ)
Kebijakan Retensi (Reclaim Policy)

1) Ekspansi Volume (Volume Expansion)

Kebutuhan untuk memperluas kapasitas volume kerap muncul saat sistem berjalan di lingkungan produksi. Melakukan backup volume lama lalu memulihkannya (restore) ke volume baru saat kapasitas hampir habis memakan waktu lama dan berisiko kehilangan data.

Untungnya, volume yang dibuat dengan Driver EKS CSI mendukung fitur ekspansi volume secara online tanpa downtime. Dukungan fitur ini dapat dilihat melalui atribut Storage Class:

[(jerry-test:default) ~]$ k get sc
NAME               PROVISIONER               RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
ebs-sc (default)   ebs.csi.aws.com          Delete          WaitForFirstConsumer   true                   2d21h
gp2                kubernetes.io/aws-ebs   Delete          WaitForFirstConsumer   false                  22d

Perhatikan kolom ALLOWVOLUMEEXPANSION. Storage Class ebs-sc bernilai true, sedangkan gp2 bernilai false. Artinya, volume yang dibuat dari ebs-sc dapat diperbesar kapasitasnya secara langsung.

Mari kita perbesar kapasitas volume menggunakan perintah k edit pvc. Anda dapat memanfaatkan k edit atau k patch untuk mengubah atribut resource yang sedang berjalan:

[(jerry-test:default) ~]$ k edit pvc ebs-claim

Ubah nilai storage dari 4Gi menjadi 10Gi:

# (bagian konfigurasi lain dihilangkan)
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi # Ubah dari 4Gi ke 10Gi
  storageClassName: ebs-sc
  volumeMode: Filesystem
  volumeName: pvc-8283283c-a2f3-4a59-bf84-9ac2ffbedbad
# (bagian konfigurasi lain dihilangkan)

Simpan perubahan dan keluar (:wq).

[(jerry-test:default) ~]$ k edit pvc ebs-claim
persistentvolumeclaim/ebs-claim edited

Periksa kembali atribut PVC:

[(jerry-test:default) ~]$ k get pvc
NAME        STATUS   VOLUME                                    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
ebs-claim   Bound    pvc-283283c-a2f3-a59-bf84-ac2ffbedbad     10Gi       RWO            ebs-sc         3h1m

Kapasitas telah bertambah menjadi 10Gi.

Verifikasi kapasitas langsung dari dalam pod:

[(jerry-test:default) ~]$ k exec -it pvc-pod -- sh
sh-4.4# df -h
Filesystem      Size  Used Avail Use% Mounted on
overlay         100G  7.8G   93G   8% /
tmpfs            64M     0   64M   0% /dev
tmpfs           3.9G     0  3.9G   0% /sys/fs/cgroup
/dev/nvme1n1    9.8G   84K  9.7G   1% /data
/dev/nvme0n1p1  100G  7.8G   93G   8% /etc/hosts
(bagian baris berikutnya dihilangkan)

Volume /data kini telah bertambah menjadi ~9.8G. Fitur ini sangat bermanfaat dan praktis digunakan dalam kondisi darurat ketika disk hampir penuh.

2) Batasan Availability Zone (AZ)

Volume AWS EBS adalah resource yang terikat pada Availability Zone (AZ) tertentu. Oleh karena itu, agar pod dapat menggunakan volume EBS tersebut, pod harus dijadwalkan pada node yang berada di Availability Zone yang sama dengan volume terkait.

Terkadang muncul eror di mana pod gagal berjalan karena tidak dapat melampirkan volume EBS yang berada di AZ berbeda. Jika Anda menemui pesan eror bahwa pod gagal me-mount volume EBS, hal pertama yang harus diperiksa adalah kesesuaian Availability Zone antara node dan volume tersebut.

3) Kebijakan Retensi (Reclaim Policy)

Reclaim Policy mengatur perlakuan terhadap volume storage fisik ketika resource PVC dihapus. Terdapat dua kebijakan utama:

Delete: Ketika PVC dihapus, Persistent Volume (PV) dan storage AWS EBS fisik di latar belakang akan ikut terhapus secara otomatis.
Retain: Ketika PVC dihapus, PV dan volume fisik EBS tidak dihapus, melainkan tetap dipertahankan (retained) agar data dapat diselamatkan atau dihubungkan kembali secara manual jika diperlukan.

Secara default, Storage Class menggunakan kebijakan Delete. Namun, jika data yang disimpan sangat penting dan Anda ingin menghindari risiko kehilangan data akibat ketidaksengajaan penghapusan PVC, Anda dapat mengonfigurasi Reclaim Policy menjadi Retain.