Menyediakan dan menggunakan block storage mentah yang didukung SSD Lokal


Halaman ini menjelaskan cara menyediakan penyimpanan SSD Lokal di cluster Google Kubernetes Engine (GKE), dan cara mengonfigurasi workload untuk menggunakan data dari block storage mentah yang didukung SSD Lokal yang dilampirkan ke node di cluster Anda.

Dengan menggunakan opsi SSD Lokal ini, Anda dapat lebih leluasa mengontrol penyimpanan dasar dan mem-build cache level node Anda sendiri untuk Pod agar dapat memberikan performa yang lebih baik bagi aplikasi Anda. Anda juga dapat menyesuaikan opsi ini dengan menginstal sistem file di disk SSD Lokal dan menjalankan DaemonSet untuk mengonfigurasi RAID dan memformat disk sesuai kebutuhan.

Untuk mempelajari lebih lanjut dukungan SSD Lokal untuk akses blok mentah di GKE, lihat Tentang SSD lokal.

Sebelum memulai

Sebelum memulai, pastikan Anda telah menjalankan tugas berikut:

  • Aktifkan Google Kubernetes Engine API.
  • Aktifkan Google Kubernetes Engine API
  • Jika ingin menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan gcloud components update.

Membuat cluster atau node pool dengan block storage mentah yang didukung SSD Lokal

Gunakan gcloud CLI dengan opsi --local-nvme-ssd-block untuk membuat cluster dengan block storage mentah yang didukung SSD Lokal.

Perintah gcloud CLI yang Anda jalankan untuk membuat cluster atau node pool tergantung pada generasi seri mesin dari jenis mesin yang Anda gunakan. Misalnya, jenis mesin N1 dan N2 masing-masing termasuk dalam seri mesin generasi pertama dan kedua, sedangkan jenis mesin C3 termasuk dalam seri mesin generasi ketiga.

Membuat cluster dengan SSD Lokal

Generasi ke-1 atau ke-2

Jika menggunakan jenis mesin dari seri mesin generasi pertama atau kedua, Anda harus membuat cluster dengan menentukan opsi --local-nvme-ssd-block count=NUMBER_OF_DISKS. Opsi ini menentukan jumlah Disk SSD lokal yang akan dipasang ke setiap node. Jumlah maksimum bervariasi menurut jenis mesin dan region.

Untuk membuat cluster:

gcloud container clusters create CLUSTER_NAME \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS \
    --machine-type=MACHINE_TYPE \
    --release-channel CHANNEL_NAME

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster.
  • NUMBER_OF_DISKS: jumlah disk SSD Lokal yang akan disediakan di setiap node. Jumlah maksimum disk bervariasi menurut jenis mesin dan region.
  • MACHINE_TYPE: jenis mesin generasi pertama atau kedua yang akan digunakan. Kolom ini wajib ditentukan karena Anda tidak dapat menggunakan SSD Lokal dengan jenis e2-medium default.
  • CHANNEL_NAME: saluran rilis yang menyertakan versi GKE yang lebih baru dari 1.25.3-gke.1800.

Generasi ke-3

Jika Anda menggunakan jenis mesin dari seri mesin generasi ketiga, gunakan opsi --local-nvme-ssd-block, tanpa kolom jumlah, untuk membuat cluster. GKE secara otomatis menyediakan kapasitas SSD Lokal untuk cluster Anda berdasarkan bentuk VM. Jumlah maksimum bervariasi menurut jenis mesin dan region.

gcloud container clusters create CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --cluster-version CLUSTER_VERSION \
    --local-nvme-ssd-block

Ganti kode berikut:

  • CLUSTER_NAME: nama cluster.
  • MACHINE_TYPE: jenis mesin yang akan digunakan dari seri mesin generasi ketiga.
  • CLUSTER_VERSION: versi cluster GKE yang mendukung SSD Lokal pada jenis mesin dari seri mesin generasi ketiga.

Membuat node pool dengan SSD Lokal

Generasi ke-1 atau ke-2

Untuk membuat node pool yang menggunakan disk SSD Lokal untuk akses blok mentah, jalankan perintah berikut:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --local-nvme-ssd-block count=NUMBER_OF_DISKS

Ganti kode berikut:

  • POOL_NAME: nama node pool baru.
  • CLUSTER_NAME: nama cluster.
  • MACHINE_TYPE: jenis mesin generasi pertama atau kedua yang akan digunakan. Kolom ini wajib ditentukan karena SSD Lokal tidak dapat digunakan dengan jenis e2-medium default.
  • NUMBER_OF_DISKS: jumlah disk SSD Lokal yang akan disediakan di setiap node. Jumlah maksimum disk bervariasi menurut jenis mesin dan region.

Generasi ke-3

Jika Anda menggunakan jenis mesin dari seri mesin generasi ketiga, gunakan opsi --local-nvme-ssd-block, tanpa kolom jumlah, untuk membuat cluster:

gcloud container node-pools create POOL_NAME \
    --cluster=CLUSTER_NAME \
    --machine-type=MACHINE_TYPE \
    --node-version NODE_VERSION \
    --local-nvme-ssd-block

Ganti kode berikut:

  • POOL_NAME: nama node pool baru.
  • CLUSTER_NAME: nama cluster.
  • MACHINE_TYPE: jenis mesin yang akan digunakan dari jenis mesin generasi ketiga.
  • NODE_VERSION: versi node pool GKE yang mendukung SSD Lokal pada jenis mesin dari seri mesin generasi ketiga.

Node di node pool dibuat dengan label cloud.google.com/gke-local-nvme-ssd=true. Anda dapat memverifikasi label dengan menjalankan perintah berikut:

kubectl describe node NODE_NAME

Untuk setiap SSD Lokal yang terpasang ke node pool, OS host membuat link simbolis (symlink) untuk mengakses disk pada folder ordinal, dan symlink dengan ID unik universal (UUID). Misalnya, jika Anda membuat node pool dengan tiga SSD lokal menggunakan opsi --local-nvme-ssd-block, OS host membuat symlink berikut untuk disk:

  • /dev/disk/by-id/google-local-ssd-block0
  • /dev/disk/by-id/google-local-ssd-block1
  • /dev/disk/by-id/google-local-ssd-block2

Dengan demikian, OS host juga membuat symlink berikut dengan UUID untuk disk:

  • /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID1
  • /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID2
  • /dev/disk/by-uuid/google-local-ssds-nvme-block/local-ssd-GENERATED_UUID3

Hal ini memastikan bahwa disk dapat diakses menggunakan ID unik.

Mengakses volume SSD Lokal

Contoh berikut menunjukkan cara mengakses block storage mentah yang didukung SSD Lokal.

PersistentVolume Lokal

Volume SSD lokal dapat dipasang sebagai Pod menggunakan PersistentVolumes.

Anda dapat membuat PersistentVolume dari SSD Lokal dengan membuat PersistentVolume secara manual, atau dengan menjalankan penyedia statis volume lokal.

Keterbatasan PersistentVolume lokal

  • Penskalaan otomatis cluster dan penyediaan dinamis tidak didukung dengan PersistentVolume lokal.

  • Mengupgrade cluster GKE atau memperbaiki node akan menghapus instance Compute Engine, yang juga menghapus semua data di disk SSD Lokal.

  • Jangan aktifkan upgrade otomatis node atau perbaikan otomatis node untuk cluster atau node pool yang menggunakan SSD Lokal untuk data persisten. Anda harus mencadangkan data aplikasi terlebih dahulu, lalu memulihkan data ke cluster atau node pool baru.

  • Objek PersistentVolume Lokal tidak secara otomatis dibersihkan saat node dihapus, diupgrade, diperbaiki, atau diperkecil skalanya. Sebaiknya Anda secara berkala memindai dan menghapus objek PersistentVolume Lokal yang tidak berlaku dan terkait dengan node yang dihapus.

Membuat PersistentVolume secara manual

Anda dapat membuat PersistentVolume secara manual untuk setiap SSD Lokal di setiap node di cluster Anda.

Gunakan kolom nodeAffinity di objek PersistentVolume untuk mereferensikan SSD Lokal di node tertentu. Contoh berikut menunjukkan spesifikasi PersistentVolume untuk SSD Lokal di node yang menjalankan Linux:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: "example-local-pv"
spec:
  capacity:
    storage: 375Gi
  accessModes:
  - "ReadWriteOnce"
  persistentVolumeReclaimPolicy: "Retain"
  storageClassName: "local-storage"
  local:
    path: "/mnt/disks/ssd0"
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: "kubernetes.io/hostname"
          operator: "In"
          values:
          - "gke-test-cluster-default-pool-926ddf80-f166"

Dalam contoh ini, disk SSD Lokal dikonfigurasi secara manual untuk RAID dan diformat, lalu dipasang di /mnt/disks/ssd0 di node gke-test-cluster-default-pool-926ddf80-f166. Kolom nodeAffinity digunakan untuk membantu menetapkan workload ke node dengan SSD Lokal yang dikonfigurasikan secara manual untuk RAID. Jika Anda hanya memiliki satu node di cluster atau jika Anda telah mengonfigurasi RAID untuk semua node, kolom nodeAffinity tidak diperlukan.

Spesifikasi PersistenVolumeClaim yang sesuai terlihat seperti yang berikut ini:

  kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: ssd-local-claim
  spec:
    accessModes:
    - ReadWriteOnce
    storageClassName: local-storage
    resources:
      requests:
        storage: 37Gi

Jika PersistentVolume dihapus, Anda harus menghapus data dari disk secara manual.

Menjalankan penyedia statis volume lokal

Anda dapat membuat PersistentVolume untuk SSD Lokal secara otomatis menggunakan penyedia statis volume lokal. Penyedianya adalah DaemonSet yang mengelola disk SSD Lokal di setiap node, membuat dan menghapus PersistentVolume untuknya, dan membersihkan data di disk SSD Lokal saat PersistentVolume dirilis.

Untuk menjalankan penyedia statis volume lokal:

  1. Gunakan DaemonSet untuk mengonfigurasi RAID dan memformat disk:

    1. Download spesifikasi gke-daemonset-raid-disks.yaml.
    2. Deploy disk RAID DaemonSet. DaemonSet menetapkan array RAID 0 di semua disk SSD Lokal dan memformat perangkat ke sistem file ext4.

      kubectl create -f gke-daemonset-raid-disks.yaml
      
  2. Download spesifikasi gke-nvme-ssd-block-raid.yaml, dan ubah kolom namespace spesifikasi sesuai kebutuhan.

    Spesifikasinya meliputi resource berikut:

    • ServiceAccount untuk penyedia
    • ClusterRole dan ClusterRoleBindings untuk izin ke:
      • Buat dan Hapus objek PersistentVolume
      • Dapatkan objek Node
    • ConfigMap dengan setelan penyedia untuk GKE
    • DaemonSet untuk menjalankan penyedia
  3. Deploy penyedia:

    kubectl create -f gke-nvme-ssd-block-raid.yaml
    

    Setelah berjalan, penyedia membuat objek PersistentVolume untuk perangkat SSD Lokal RAID di cluster.

  4. Simpan manifes PersistentVolumeClaim berikut sebagai provisioner-pvc-example.yaml:

    kind: PersistentVolumeClaim
    apiVersion: v1
    metadata:
      name: PVC_NAME
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 50Gi
      storageClassName: nvme-ssd-block
    

    Ganti PVC_NAME dengan nama PersistentVolumeClaim Anda.

  5. Buat PersistentVolumeClaim:

    kubectl create -f provisioner-pvc-example.yaml
    
  6. Simpan manifes Pod berikut sebagai provisioner-pod-example.yaml:

    apiVersion: v1
    kind: Pod
    metadata:
      name: POD_NAME
    spec:
      containers:
      - name: "shell"
        image: "ubuntu:14.04"
        command: ["/bin/sh", "-c"]
        args: ["echo 'hello world' > /cache/test.txt && sleep 1 && cat /cache/test.txt && sleep 3600"]
        volumeMounts:
        - mountPath: /cache
          name: local-ssd-storage
      volumes:
      - name: local-ssd-storage
        persistentVolumeClaim:
          claimName: PVC_NAME
    

    Ganti POD_NAME dengan nama Pod Anda.

  7. Buat Pod:

    kubectl create -f provisioner-pod-example.yaml
    

Mengaktifkan binding volume tertunda

Untuk penjadwalan yang lebih baik, sebaiknya buat juga StorageClass dengan volumeBindingMode: WaitForFirstConsumer. Tindakan ini menunda binding PersistentVolumeClaim hingga penjadwalan Pod, sehingga SSD Lokal dipilih dari node yang sesuai yang dapat menjalankan Pod. Perilaku penjadwalan yang ditingkatkan ini mempertimbangkan permintaan CPU dan memori Pod, afinitas node, afinitas dan anti-afinitas Pod, dan beberapa permintaan PersistentVolumeClaim, beserta node yang memiliki SSD lokal yang tersedia, saat memilih node untuk Pod yang dapat dijalankan.

Contoh ini menggunakan mode binding volume tertunda:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: "local-nvme"
provisioner: "kubernetes.io/no-provisioner"
volumeBindingMode: "WaitForFirstConsumer"

Untuk membuat StorageClass dengan binding tertunda, simpan manifes YAML ke file lokal dan terapkan ke cluster menggunakan perintah berikut:

kubectl apply -f filename

Pemecahan masalah

Untuk mengetahui petunjuk pemecahan masalah, lihat Memecahkan masalah penyimpanan di GKE.

Langkah berikutnya