Volume persisten dan penyediaan dinamis

Halaman ini memberikan ringkasan tentang volume persisten dan klaim di Kubernetes, serta penggunaannya dengan Google Kubernetes Engine (GKE). Halaman ini berfokus pada penyimpanan yang didukung oleh persistent disk Compute Engine.

Halaman ini ditujukan untuk spesialis Penyimpanan yang membuat dan mengalokasikan penyimpanan serta mengonfigurasi dan mengelola keamanan, perlindungan, serta akses dan izin data. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.

PersistentVolume

Resource PersistentVolume digunakan untuk mengelola penyimpanan yang tahan lama di cluster. Di GKE, PersistentVolume biasanya didukung oleh persistent disk.

Sebagai gantinya, Anda dapat menggunakan solusi penyimpanan lain seperti NFS. Filestore adalah solusi NFS di Google Cloud. Untuk mempelajari cara menyiapkan instance Filestore sebagai solusi NFS PV untuk cluster GKE, lihat Mengakses instance Filestore dengan driver CSI Filestore di dokumentasi Filestore.

Siklus proses PersistentVolume dikelola oleh Kubernetes. PersistentVolume dapat disediakan secara dinamis; Anda tidak perlu membuat dan menghapus penyimpanan cadangan secara manual.

Resource PersistentVolume adalah resource cluster yang ada secara independen dari Pod. Ini berarti bahwa disk dan data yang ditampilkan oleh PersistentVolume terus ada saat cluster berubah dan saat Pod dihapus dan dibuat ulang. Resource PersistentVolume dapat disediakan secara dinamis melalui PersistentVolumeClaims, atau dapat dibuat secara eksplisit oleh administrator cluster.

Untuk mempelajari resource PersistentVolume lebih lanjut, lihat dokumentasi Persistent Volume Kubernetes dan referensi Persistent Volumes API.

PersistentVolumeClaims

PersistentVolumeClaim adalah permintaan untuk dan klaim atas resource PersistentVolume. Objek PersistentVolumeClaim meminta ukuran, mode akses, dan StorageClass khusus untuk PersistentVolume. Jika PersistentVolume yang memenuhi permintaan ada atau dapat disediakan, PersistentVolumeClaim akan terikat dengan PersistentVolume tersebut.

Pod menggunakan klaim sebagai volume. Cluster memeriksa klaim untuk menemukan volume yang terikat dan memasang volume tersebut untuk Pod.

Portabilitas adalah keuntungan lain dari penggunaan PersistentVolumes dan PersistentVolumeClaims. Anda dapat dengan mudah menggunakan spesifikasi Pod yang sama di berbagai cluster dan lingkungan karena PersistentVolume adalah antarmuka ke penyimpanan pendukung yang sebenarnya.

StorageClasses

Implementasi volume seperti Driver Antarmuka Penyimpanan Container (CSI) persistent disk Compute Engine dikonfigurasi melalui resource StorageClass.

GKE membuat StorageClass default untuk Anda jika menggunakan jenis persistent disk seimbang (ext4). StorageClass default digunakan saat PersistentVolumeClaim tidak menentukan StorageClassName. Anda dapat mengganti StorageClass default yang disediakan dengan milik Anda sendiri. Untuk mendapatkan petunjuk, lihat Mengubah StorageClass default.

Anda dapat membuat resource StorageClass Anda sendiri untuk menjelaskan berbagai kelas penyimpanan. Misalnya, kelas mungkin dipetakan ke level kualitas layanan, atau ke kebijakan pencadangan. Konsep ini terkadang disebut "profil" di sistem penyimpanan lainnya.

Jika menggunakan cluster dengan node pool Windows, Anda harus membuat StorageClass dan menentukan StorageClassName di PersistentVolumeClaim karena fstype default (ext4) tidak didukung dengan Windows. Jika menggunakan persistent disk Compute Engine, Anda harus menggunakan NTFS sebagai jenis penyimpanan file.

Saat menentukan StorageClass, Anda harus mencantumkan penyedia. Di GKE, sebaiknya Anda menggunakan salah satu penyedia berikut:

Menyediakan PersistentVolume secara dinamis

Biasanya, Anda tidak perlu mengonfigurasi objek PersistentVolume secara langsung atau membuat persistent disk Compute Engine. Sebagai gantinya, Anda dapat membuat PersistentVolumeClaim dan Kubernetes secara otomatis menyediakan persistent disk untuk Anda.

Manifes berikut menjelaskan permintaan untuk disk dengan penyimpanan 30 gibibyte (GiB) yang mode aksesnya memungkinkannya dipasang sebagai baca-tulis oleh satu node. Tindakan ini juga membuat Pod yang menggunakan PersistentVolumeClaim sebagai volume.

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

Saat Anda membuat objek PersistentVolumeClaim ini dengan kubectl apply -f pvc-pod-demo.yaml, Kubernetes secara dinamis membuat objek PersistentVolume yang sesuai.

Karena kelas penyimpanan standard-rwo menggunakan mode binding volume WaitForFirstConsumer, PersistentVolume tidak akan dibuat hingga Pod dijadwalkan untuk menggunakan volume.

Contoh berikut menunjukkan PersistentVolume yang dibuat.

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

Dengan asumsi bahwa Anda belum mengganti kelas penyimpanan standard-rwo, PersistentVolume ini didukung oleh persistent disk Compute Engine yang baru dan kosong.

Menghapus penyimpanan persisten

Secara default, menghapus PersistentVolumeClaim untuk volume yang disediakan secara dinamis seperti persistent disk Compute Engine akan menghapus objek PersistentVolume dan disk cadangan yang sebenarnya. Perilaku ini dikontrol oleh kebijakan klaim kembali di StorageClass dan PersistentVolume, yang dapat ditetapkan ke default Delete, atau Retain. Untuk mempelajari lebih lanjut, lihat dokumentasi Kubernetes tentang Pengambilan Kembali.

Untuk mencegah atau mengurangi kehilangan data saat Anda menghapus penyimpanan persisten, sebaiknya aktifkan Pencadangan untuk GKE dan jadwalkan pencadangan reguler cluster GKE Anda, termasuk workload yang di-deploy dan datanya.

Mengelola penyimpanan persisten selama penghapusan cluster

Saat cluster GKE dihapus, GKE akan mempertahankan resource PersistentVolume dengan kebijakan pengklaiman kembali Delete atau Retain.

Untuk menghapus resource PersistentVolume saat menghapus cluster, Anda dapat menghapus namespace resource PersistentVolumeClaim secara manual, yang akan memicu penghapusan untuk objek PersistentVolume dengan kebijakan Delete. Atau, Anda dapat menghapus resource PersistentVolumeClaim satu per satu. Namun, GKE tidak menunggu hingga aktivitas penghapusan ini selesai sebelum mulai menghapus cluster. Jadi, jika Anda menghapus namespace, lalu langsung menghapus cluster, resource PersistentVolume dengan kebijakan Delete mungkin tidak akan dihapus.

Setelah penghapusan cluster, Anda dapat melihat resource PersistentVolume yang tersisa di konsol Google Cloud.

Untuk melihat resource yang tidak digunakan, seperti resource PersistentVolume yang tidak digunakan, Anda dapat melihat rekomendasi untuk resource yang tidak ada aktivitas.

Mode akses

Resource PersistentVolume mendukung mode akses berikut:

  • ReadWriteOnce: Volume dapat dipasang sebagai baca-tulis oleh satu node.
  • ReadOnlyMany: Volume dapat dipasang hanya-baca oleh banyak node.
  • ReadWriteMany: Volume dapat dipasang sebagai baca-tulis oleh banyak node. Resource PersistentVolume yang didukung oleh persistent disk Compute Engine tidak mendukung mode akses ini.

Menggunakan persistent disk Compute Engine sebagai ReadOnlyMany

ReadWriteOnce adalah kasus penggunaan paling umum untuk persistent disk dan berfungsi sebagai mode akses default untuk sebagian besar aplikasi. Persistent disk Compute Engine juga mendukung mode ReadOnlyMany sehingga banyak aplikasi atau banyak replika aplikasi yang sama dapat menggunakan disk yang sama secara bersamaan. Contoh kasus penggunaan menampilkan konten statis di beberapa replika.

Untuk mendapatkan petunjuk lihat Menggunakan persistent disk dengan beberapa pembaca.

Menggunakan persistent disk yang sudah ada sebagai PersistentVolumes

Resource PersistentVolume yang disediakan secara dinamis kosong saat dibuat. Jika Anda sudah memiliki persistent disk Compute Engine yang diisi dengan data, Anda dapat memperkenalkannya ke cluster dengan membuat resource PersistentVolume yang sesuai secara manual. Persistent disk harus berada di zona yang sama dengan node cluster.

Lihat contoh cara membuat Persistent Volume yang didukung oleh persistent disk yang sudah ada.

Deployment vs. StatefulSet

Anda dapat menggunakan template PersistentVolumeClaim atau VolumeClaim di pengontrol level yang lebih tinggi seperti Deployment atau StatefulSets.

Deployment dirancang untuk aplikasi stateless sehingga semua replika Deployment memiliki PersistentVolumeClaim yang sama. Karena Pod replika yang dibuat identik satu sama lain, hanya volume dengan mode ReadWriteMany yang dapat berfungsi di setelan ini.

Bahkan Deployment dengan satu replika yang menggunakan volume ReadWriteOnce tidak direkomendasikan. Hal ini karena strategi Deployment default membuat Pod kedua sebelum menghilangkan Pod pertama pada pembuatan ulang. Deployment dapat gagal dalam deadlock karena Pod kedua tidak dapat dimulai karena volume ReadWriteOnce sudah digunakan, dan Pod pertama tidak akan dihapus karena Pod kedua belum dimulai. Sebagai gantinya, gunakan StatefulSet dengan volume ReadWriteOnce.

StatefulSets adalah metode yang direkomendasikan untuk men-deploy aplikasi stateful yang memerlukan volume unik per replika. Dengan menggunakan StatefulSets dengan template PersistentVolumeClaim, Anda dapat memiliki aplikasi yang dapat meningkatkan skala secara otomatis dengan PersistentVolumesClaims unik yang terkait dengan setiap Pod replika.

Persistent disk menurut region

Persistent disk regional adalah resource multi-zona yang mereplikasi data antara dua zona di region yang sama, dan dapat digunakan seperti halnya persistent disk zona. Jika terjadi pemadaman zona atau jika node cluster di satu zona menjadi tidak dapat dijadwalkan, Kubernetes dapat mengalihkan workload menggunakan volume ke zona lainnya. Anda dapat menggunakan persistent disk regional untuk membuat solusi yang sangat tersedia untuk workload stateful di GKE. Anda harus memastikan bahwa zona utama dan failover sudah dikonfigurasi dengan kapasitas resource yang cukup untuk menjalankan workload.

Persistent disk SSD regional adalah opsi untuk aplikasi seperti database yang memerlukan ketersediaan tinggi dan performa tinggi. Untuk mengetahui detail selengkapnya, lihat Memblokir perbandingan performa penyimpanan.

Seperti persistent disk zona, persistent disk regional dapat disediakan secara dinamis sesuai kebutuhan atau disediakan secara manual terlebih dahulu oleh administrator cluster. Untuk mempelajari cara menambahkan persistent disk regional, lihat Menyediakan persistent disk regional.

Zona di persistent disk

Persistent disk zona adalah resource zona dan persistent disk regional merupakan resource multi-zona. Saat Anda menambahkan penyimpanan persisten ke cluster Anda, kecuali jika zona ditentukan, GKE menetapkan disk ke satu zona. GKE memilih zona secara acak. Setelah persistent disk disediakan, setiap Pod yang merujuk ke disk akan dijadwalkan ke zona yang sama dengan persistent disk. Namun, Pod atau Deployment secara inheren tidak mengenali zona persistent disk yang sudah ada. Untuk memastikan Pod dijadwalkan dengan benar dengan persistent disk yang sudah ada, gunakan metode penempatan zona seperti nodeAffinity dalam spesifikasi Pod atau Deployment Anda untuk menargetkan zona yang sesuai.

Mode binding volume WaitForFirstConsumer

Jika Anda menyediakan persistent disk secara dinamis di cluster, sebaiknya setel mode binding volume WaitForFirstConsumer pada StorageClass. Setelan ini menginstruksikan Kubernetes untuk menyediakan persistent disk di zona yang sama dengan yang dijadwalkan untuk Pod. Hal ini mengikuti batasan penjadwalan Pod seperti anti-afinitas dan pemilih node. Anti-afinitas di zona memungkinkan Pod StatefulSet tersebar di seluruh zona bersama disk yang sesuai.

Berikut adalah contoh StorageClass untuk menyediakan persistent disk zona yang menetapkan WaitForFirstConsumer:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

Untuk contoh penggunaan persistent disk regional, lihat Menyediakan persistent disk regional.

Langkah berikutnya