Volume persisten & penyediaan GKE

Standard

Halaman ini memberikan ringkasan tentang Volume Persisten (PV), Klaim Volume Persisten (PVC), dan Class Penyimpanan di Google Kubernetes Engine (GKE). Bagian ini berfokus pada penyimpanan yang didukung oleh persistent disk Compute Engine.

Anda akan mempelajari cara membuat, mengelola, dan memecahkan masalah penyimpanan persisten secara efektif dalam cluster GKE untuk membantu memastikan keamanan data, ketersediaan tinggi, dan performa optimal.

Halaman ini ditujukan bagi 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 Google Cloud konten, lihat Peran dan tugas pengguna GKE umum.

PersistentVolume

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

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.

Perhatian: Menggunakan setelan [fsGroup] dengan PersistentVolumes besar dapat menyebabkan pemasangan gagal. Untuk mengetahui informasi selengkapnya, lihat Memecahkan masalah Kegagalan pemasangan volume.

Untuk mempelajari resource PersistentVolume lebih lanjut, lihat dokumentasi Persistent Volumes 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 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:

• CSI persistent disk Compute Engine
• Kubernetes Filestore CSI

Catatan: Dukungan untuk penyedia selain yang tercantum tidak tercakup dalam Cloud Customer Care, kecuali untuk Driver CSI SMB untuk Kubernetes open source, yang disediakan berdasarkan upaya terbaik. Dukungan pihak ketiga untuk penyedia lainnya mungkin juga tersedia.

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.

Catatan: Mengubah label topology.kubernetes.io/zone selama masa aktif PersistentVolume dapat menyebabkan kegagalan pemasangan.

Menghapus penyimpanan persisten

Selama penyediaan dinamis, Anda dapat mengontrol apakah penyimpanan persisten Anda dihapus saat PersistentVolumeClaim (PVC) dihapus. Untuk melakukannya, Anda menetapkan kolom reclaimPolicy dalam konfigurasi StorageClass ke Delete atau Retain.

• reclaimPolicy: Delete: Ini adalah kebijakan default. Saat PVC dihapus, objek PersistentVolume (PV) dan disk yang mendasarinya (seperti persistent disk Compute Engine) akan otomatis dihapus. Gunakan kebijakan ini untuk beban kerja sementara atau untuk persyaratan kepatuhan yang mengharuskan data dibersihkan setelah tugas selesai.

• reclaimPolicy: Retain: Jika Anda menyetel kebijakan ini, PV dan disk yang mendasarinya tidak akan dihapus saat Anda menghapus PVC. Status PV berubah menjadi Released. Data dipertahankan, tetapi volume tidak dapat digunakan oleh PVC baru hingga administrator mengklaimnya kembali secara manual.

Mengelola volume yang dipertahankan secara manual

Jika PersistentVolume memiliki status Released, Anda harus memutuskan secara manual tindakan yang akan dilakukan terhadap data dan disk yang mendasarinya.

• Untuk menghapus penyimpanan secara permanen: Anda harus menghapus resource PersistentVolume Kubernetes dan disk Compute Engine yang mendasarinya.

  1. Hapus PersistentVolume: bash kubectl delete pv <your-pv-name>
  2. Temukan nama disk pokok dengan menjelaskan file konfigurasi YAML untuk PV dan mencari volumeHandle atau kolom serupa.
  3. Hapus persistent disk Compute Engine: bash gcloud compute disks delete <your-disk-name> --zone=<your-zone>

• Untuk menggunakan kembali volume: Mengambil kembali volume dengan status Released untuk digunakan oleh PVC lain adalah tugas lanjutan yang melibatkan pembersihan data disk secara manual dan pengeditan objek PersistentVolume agar menjadi Available lagi. Untuk mengetahui informasi selengkapnya tentang prosedur mendetail, lihat dokumentasi resmi Kubernetes tentang Mengambil Kembali PersistentVolume.

Untuk mencegah atau memitigasi kehilangan data, sebaiknya aktifkan Pencadangan untuk GKE dan jadwalkan pencadangan reguler cluster GKE Anda.

Memecahkan masalah penghapusan disk yang tidak terduga

Jika Anda mengamati bahwa disk persisten pokok Anda dihapus saat Anda tidak mengharapkannya, penyebab paling umum adalah kolom reclaimPolicy yang disetel ke Delete dalam konfigurasi StorageClass yang digunakan oleh PersistentVolumeClaim Anda.

Untuk mendiagnosis masalah ini, selesaikan langkah-langkah berikut:

1. Periksa StorageClass PVC Anda: bash kubectl get pvc <your-pvc-name> -o jsonpath='{.spec.storageClassName}'

2. Periksa kolom reclaimPolicy: bash kubectl get sc <your-storageclass-name> -o yaml

3. Menyelaraskan kebijakan dengan niat Anda:

   • Jika kebijakan adalah Delete dan aplikasi Anda memerlukan data untuk dipertahankan, Anda harus mengupdate aplikasi untuk menggunakan konfigurasi StorageClass yang menetapkan kebijakan ke Retain.
   • Jika kebijakan adalah Delete dan aplikasi Anda bersifat sementara atau tunduk pada aturan kepatuhan yang memerlukan pembersihan data, maka konfigurasi sudah benar dan berfungsi sebagaimana mestinya.

Untuk mengetahui informasi selengkapnya, lihat dokumentasi Kubernetes tentang Mengambil Kembali.

Mengelola penyimpanan persisten selama penghapusan cluster

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

Untuk menghapus resource PersistentVolume saat Anda 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.
• ReadWriteOncePod: Volume hanya dapat dipasang sebagai baca-tulis oleh satu Pod.

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.

Catatan: Anda tidak dapat memasang persistent disk dalam mode tulis di beberapa node secara bersamaan. Lihat Deployment versus StatefulSet.

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.

Catatan: Pemasangan persistent disk dari project Google Cloud lain ke Pod di project Google Cloud Anda saat ini tidak didukung.

Deployment versus 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 tidak secara inheren mengenali zona persistent disk yang sudah ada. Untuk memastikan Pod dijadwalkan dengan benar dengan persistent disk yang sudah ada, gunakan metode penempatan zonal 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

• Pelajari StatefulSets, metode yang direkomendasikan untuk men-deploy aplikasi stateful.
• Pelajari cara men-deploy aplikasi stateful menggunakan StatefulSet.
• Pelajari cara menggunakan persistent disk dalam cluster.
• Pelajari cara membuat disk yang dapat dibaca dari beberapa node.
• Pelajari cara membuat persistent disk yang didukung oleh SSD.
• Pelajari cara menyediakan persistent disk regional.