Mengonfigurasi penyimpanan yang terhubung dengan Distributed Cloud

Halaman ini menjelaskan cara mengonfigurasi penyimpanan untuk cluster yang terhubung Distributed Cloud, termasuk:

• Rakuten Symcloud Storage
• Skema penyimpanan lokal
• Pemecahan masalah

Mengonfigurasi Distributed Cloud yang terhubung untuk Symcloud Storage

Node yang terhubung ke Distributed Cloud tidak mengekspos penyimpanan lokalnya secara langsung ke workload Anda. Sebagai gantinya, Distributed Cloud terhubung menggunakan Rakuten Symcloud Storage, yang merupakan solusi pihak ketiga yang berfungsi sebagai lapisan abstraksi penyimpanan lokal yang berjalan di setiap node Distributed Cloud terhubung dan membuat penyimpanan lokalnya tersedia untuk beban kerja yang berjalan di semua node Distributed Cloud terhubung dalam cluster.

Container Storage Interface (CSI) adalah API standar terbuka yang didukung oleh banyak vendor penyimpanan utama yang memungkinkan Kubernetes mengekspos sistem penyimpanan arbitrer ke workload dalam container. Di Distributed Cloud connected, Symcloud Storage adalah solusi penyimpanan CSI yang didukung dan dikelola. Saat Symcloud Storage diaktifkan, StorageClasses Kubernetes yang diperlukan akan dikonfigurasi untuk Anda. Kemudian, Anda dapat mengonfigurasi workload untuk menggunakan class penyimpanan yang sesuai.

Symcloud Storage di-deploy dari Google Cloud Marketplace dan tunduk pada persyaratan yang dinyatakan di dalamnya. Google memberikan dukungan terbatas untuk penggunaan Symcloud Storage dengan Distributed Cloud yang terhubung dan dapat menghubungi penyedia pihak ketiga untuk mendapatkan bantuan. Update software untuk Symcloud Storage disertakan dalam update software Distributed Cloud yang terhubung.

Rilis Distributed Cloud terhubung ini dikirimkan dengan dan mendukung Symcloud Storage 6.0.0-226. Tidak ada versi Symcloud Storage lain yang didukung dalam rilis Distributed Cloud yang terhubung ini.

Mendapatkan lisensi Symcloud Storage

Anda harus mendapatkan lisensi Symcloud Storage dalam format YAML dari Google Cloud Marketplace:

Buka Marketplace

Prasyarat

Sebelum memulai, selesaikan langkah-langkah berikut:

1. Konfigurasi logging dan pemantauan untuk project yang terhubung ke Distributed Cloud target.
2. Buat cluster target Distributed Cloud terhubung. Anda dapat memantau progres penyediaan.
3. Konfigurasi jaringan Distributed Cloud Anda sehingga Pod di cluster terhubung Distributed Cloud target dapat menjangkau pusat data Google Cloud .
4. Solusi penyimpanan yang ditetapkan software (SDS) seperti Symcloud Storage menargetkan perangkat blok mentah local-block yang tidak terikat. Distributed Cloud connected mengharapkan solusi SDS diinstal saat pembuatan cluster jika perangkat local-block yang tidak terikat tersedia.

Menginstal Symcloud Storage di node yang terhubung ke Distributed Cloud

Untuk menginstal Symcloud Storage di node yang terhubung ke Distributed Cloud, selesaikan langkah-langkah berikut:

1. Gunakan perintah berikut untuk menerapkan lisensi Symcloud Storage ke cluster Anda. Ganti LICENSE_FILE dengan jalur dan nama lengkap file lisensi Symcloud Storage.

   kubectl apply -f LICENSE_FILE -n robin-admin
   

2. Gunakan perintah berikut untuk memverifikasi status layanan RobinCluster dan semua node Symcloud Storage:

   kubectl describe robinclusters -n robinio
   

   Perintah ini menampilkan output yang mirip dengan berikut ini:

   [...]
   Status:
   [...]
   Phase:              Ready
   robin_node_status:
   [...]
    Status:           Ready
   [...]
    Status:           Ready
   [...]
    Status:           Ready
   [...]
   

   Status yang diharapkan untuk layanan dan node adalah Ready.

Menetapkan Symcloud Storage sebagai kelas penyimpanan default

Gunakan perintah berikut untuk menetapkan Symcloud Storage sebagai class penyimpanan default di cluster yang terhubung Distributed Cloud Anda. Ganti STORAGE_CLASS dengan salah satu kelas Symcloud Storage.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

Untuk mengetahui informasi selengkapnya tentang cara menetapkan kelas penyimpanan default, lihat Mengubah StorageClass default dalam dokumentasi Kubernetes.

Kelas Penyimpanan Symcloud

Bagian ini menjelaskan kelas penyimpanan yang dapat diaktifkan Symcloud Storage di cluster yang terhubung ke Distributed Cloud Anda. Symcloud Storage di Distributed Cloud yang terhubung tidak mendukung robin-rwxkelas penyimpanan maupun volume mode sistem file RWX yang dikonfigurasi kustom. Untuk mengetahui informasi selengkapnya tentang class Symcloud Storage, lihat Menggunakan Robin CNS di Kubernetes.

Kelas penyimpanan robin

Kelas penyimpanan robin adalah kelas penyimpanan Read Write-Once (RWO) dasar. Contoh berikut mengilustrasikan pembuatan instance class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

Peringatan: Menggunakan class penyimpanan replika tunggal ini dapat menyebabkan kehilangan data karena tidak memberikan redundansi jika terjadi kegagalan node. Sebaiknya gunakan class penyimpanan yang menyediakan redundansi dengan minimal tiga replika.

Kelas penyimpanan robin-immediate

Class penyimpanan robin-immediate sama dengan robin, kecuali bahwa volume persisten dibuat segera setelah membuat klaim volume persisten yang sesuai. Contoh berikut mengilustrasikan instansiasi class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

Peringatan: Menggunakan class penyimpanan replika tunggal ini dapat menyebabkan kehilangan data karena tidak memberikan redundansi jika terjadi kegagalan node. Sebaiknya gunakan class penyimpanan yang menyediakan redundansi dengan minimal tiga replika.

Kelas penyimpanan robin-repl-3

robin-repl-3 adalah class penyimpanan RWO dengan tiga replika yang mencakup beberapa node Distributed Cloud. Contoh berikut mengilustrasikan pembuatan instance class:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

Mengonfigurasi volume Penyimpanan Symcloud yang diabstraksi untuk workload

Bagian ini memberikan contoh cara menggunakan class penyimpanan Symcloud untuk mengonfigurasi penyimpanan yang diabstraksi untuk workload yang terhubung ke Distributed Cloud. Untuk mengetahui detail selengkapnya tentang cara mengonfigurasi volume Symcloud Storage, lihat Menggunakan Robin CNS di Kubernetes.

Mengonfigurasi volume RWO ext4 dalam mode sistem file

Contoh berikut mengilustrasikan cara mengonfigurasi klaim volume persisten untuk volume RWO dalam mode sistem file dengan sistem file ext4. Ganti STORAGE_CLASS dengan salah satu kelas Symcloud Storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Mengonfigurasi volume RWO dalam mode blok

Contoh berikut menggambarkan cara mengonfigurasi klaim volume persisten untuk volume RWO dalam mode blok. Ganti STORAGE_CLASS dengan salah satu kelas Symcloud Storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

Mengubah konfigurasi volume yang ada

Contoh berikut mengilustrasikan cara mengubah konfigurasi volume RWO yang dikompresi LZ4 Symcloud Storage yang ada menggunakan anotasi. GantiSTORAGE_CLASS dengan salah satu kelas Symcloud Storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Contoh berikut mengilustrasikan cara mengubah konfigurasi volume RWO Symcloud Storage yang ada dengan sistem file xfs menggunakan anotasi. GantiSTORAGE_CLASS dengan salah satu kelas Symcloud Storage.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Mengonfigurasi klien Symcloud Storage CLI

Symcloud Storage menyediakan klien antarmuka command line (CLI) yang dapat Anda gunakan untuk mengelola konfigurasi Symcloud Storage. Untuk mengonfigurasi klien di cluster yang terhubung Distributed Cloud, selesaikan langkah-langkah berikut:

1. Dapatkan jalur image Symcloud Storage yang digunakan oleh instance layanan RobinCluster yang di-deploy di cluster yang terhubung ke Distributed Cloud Anda dan tetapkan variabel lingkungan Anda sebagai berikut:

   image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
   image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
   ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"
   

2. Buat resource robincli dengan konten berikut:

   kind: Deployment
   apiVersion: apps/v1
   metadata:
    name: robincli
    namespace: default
    labels:
      name: robincli
   spec:
    replicas: 1
    selector:
      matchLabels:
        name: robincli
    template:
      metadata:
        annotations:
          product: robin
        labels:
          name: robincli
      spec:
        containers:
        - name: robincli
          image: ROBIN_CNS_IMAGE
          workingDir: /root
          command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
          resources:
            requests:
              memory: "10Mi"
              cpu: "100m"
   

   Ganti ROBIN_CNS_IMAGE dengan jalur repositori lengkap dan nama image yang Anda peroleh di langkah 1.

3. Terapkan resource robincli ke cluster Distributed Cloud terhubung Anda.

4. Saat penginstalan awal, Symcloud Storage membuat secret default-admin-user di namespace robinio dengan sandi acak. Gunakan perintah berikut untuk mendapatkan kredensial login ini:

   1. Dapatkan nama pengguna:

      kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d
      

   2. Dapatkan sandi:

       
      kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d
      

5. Login ke Pod yang baru dibuat dan jalankan klien:

   kubectl exec -it robincli -- bash
   

Mereferensikan kelas penyimpanan dalam StatefulSet

Contoh berikut menunjukkan cara mereferensikan kelas penyimpanan Symcloud Storage dalam workload StatefulSet.

Contoh ini mengasumsikan bahwa Anda menggunakan class penyimpanan robin-repl-3 yang telah dikonfigurasi sebelumnya, yang menyediakan volume yang direplikasi di tiga node pekerja yang berbeda untuk ketersediaan tinggi.

Saat mengonfigurasi StatefulSet untuk ketersediaan tinggi, sertakan praktik terbaik berikut dalam konfigurasi Anda:

• Layanan Headless: StatefulSet memerlukan Layanan Headless pendamping yang cocok dengan kolom serviceName. Service Headless adalah layanan dengan clusterIP: None. Layanan ini menetapkan nama host DNS yang stabil ke setiap Pod dalam set.
• Anti-afinitas Pod: Jika Anda menggunakan class penyimpanan yang direplikasi seperti robin-repl-3, data Anda akan dicerminkan dengan aman di beberapa worker node. Namun, jika Kubernetes menjadwalkan semua pod aplikasi Anda ke worker node yang sama, pemadaman satu node dapat menghentikan aplikasi Anda. Mengonfigurasi anti-afinitas Pod memastikan Pod Anda didistribusikan di seluruh node pekerja terpisah, yang mencocokkan ketersediaan komputasi dengan redundansi penyimpanan Anda.

Contoh berikut menunjukkan konfigurasi lengkap yang mencakup Headless Service (nginx) dan StatefulSet yang dikonfigurasi dengan anti-afinitas Pod yang mereferensikan class penyimpanan robin-repl-3. Jika persyaratan penyimpanan workload Anda meningkat seiring waktu, Anda dapat mengubah ukuran volume secara dinamis dengan mengedit permintaan penyimpanan di PersistentVolumeClaim.

Catatan: Kelas Symcloud Storage yang telah dikonfigurasi sebelumnya menggunakan volumeBindingMode: WaitForFirstConsumer, yang menunda penyediaan volume hingga Pod dijadwalkan. Akibatnya, PersistentVolumeClaim Anda tetap dalam status Pending, atau waiting for first consumer, hingga penjadwalan Pod selesai. Perilaku ini sudah diperkirakan.

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Reference the storage class in this specification
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed
      storageClassName: robin-repl-3 # References the Symcloud storage class

Batasan Penyimpanan Symcloud

Saat menggunakan Symcloud Storage dengan Distributed Cloud terhubung, Anda hanya dapat mencapai ketersediaan tinggi jika cluster Distributed Cloud terhubung Anda terdiri dari tiga atau lebih node Distributed Cloud terhubung.

Menghapus node yang menggunakan Symcloud Storage dari cluster

Replika volume Symcloud Storage disimpan di node pekerja dalam cluster yang terhubung Distributed Cloud Anda. Jika Anda menghapus node dari cluster, data volume Symcloud Storage yang disimpan di node tersebut tidak akan tersedia. Untuk mencegahnya, Anda harus melakukan salah satu tindakan berikut:

• Jika Anda menghapus seluruh cluster, hapus beban kerja dan volume persisten Symcloud Storage yang sesuai sebelum Anda menghapus cluster itu sendiri.
• Jika Anda menghapus node tertentu dari cluster, Anda harus memigrasikan data beban kerja yang disimpan di node tersebut sebelum menghapus node tersebut dari cluster. Untuk mengetahui petunjuknya, lihat Mengosongkan volume dari disk.

Mengonfigurasi skema penyimpanan lokal

Skema penyimpanan adalah pengelompokan logis dari satu atau beberapa partisi. Setiap partisi adalah unit penyimpanan yang independen secara logis. Partisi dibuat di cluster Anda secara berurutan hingga ruang disk fisik habis. Setiap skema penyimpanan memiliki nama unik yang mengidentifikasinya.

Untuk membuat skema penyimpanan lokal baru untuk cluster yang terhubung ke Distributed Cloud, Anda harus memintanya dari Google. Setelah menguji skema dan membuatnya di cluster, Anda dapat menerapkannya menggunakan CLI gcloud.

Anda tidak dapat mengubah skema setelah diterapkan ke cluster. Untuk mengubah skema yang ada, Anda harus meminta penghapusan skema yang ada dari Google, lalu meminta pembuatan skema baru untuk menggantikannya.

Menentukan partisi untuk skema penyimpanan lokal

Sebelum dapat meminta skema penyimpanan lokal, Anda harus menentukan partisi untuk skema tersebut terlebih dahulu.

Partisi memiliki properti berikut:

• Ukuran. Anda dapat menentukan ukuran partisi dalam byte biner, atau membuatnya menggunakan semua ruang yang tersisa di disk lokal.
• Jenis. Anda dapat mengonfigurasi partisi sebagai volume persisten (PV) Kubernetes atau volume lokal Linux di disk lokal.
• Mode. Anda dapat mengonfigurasi volume yang disimpan di partisi sebagai volume blok atau volume sistem file. Untuk partisi volume persisten, kelas penyimpanan partisi masing-masing adalah local-block atau local-disks. Untuk partisi volume lokal, Anda dapat menentukan titik pemasangan dan pengikatan untuk sistem file yang disertakan.

Meminta skema penyimpanan lokal

Untuk meminta skema penyimpanan lokal baru untuk cluster yang terhubung ke Distributed Cloud, hubungi Dukungan Google dan berikan ukuran, jenis, mode, dan, secara opsional, titik pemasangan dan pengikatan untuk setiap partisi yang ingin Anda buat dalam skema.

Saat kami menerima permintaan Anda, kami menjalankan serangkaian pengujian untuk memastikan keandalan skema, lalu membuatnya di cluster yang terhubung ke Distributed Cloud Anda.

Skema penyimpanan lokal default

Distributed Cloud Connected dilengkapi dengan skema penyimpanan lokal default berikut:

• default_control_plane_node. Skema ini menentukan partisi berikut:

  • Partisi volume lokal 100 GB dalam mode sistem file.
  • Partisi volume persisten dalam mode blok yang menempati ruang disk kosong yang tersisa.

• default_worker_node. Skema ini menentukan partisi volume persisten 410 GB dalam mode blok.

Menerapkan skema penyimpanan lokal ke cluster

Untuk menerapkan skema penyimpanan lokal ke cluster yang terhubung ke Distributed Cloud, lakukan salah satu hal berikut:

• Untuk menerapkan skema penyimpanan lokal ke node bidang kontrol cluster, gunakan flag --control-plane-node-storage-schema saat membuat cluster. Untuk mengetahui informasi selengkapnya, lihat Membuat cluster.

• Untuk menerapkan skema penyimpanan lokal ke node pekerja cluster, gunakan --node-storage-schema saat membuat node pool untuk cluster. Untuk mengetahui informasi selengkapnya, lihat Membuat node pool.

Distributed Cloud connected membuat partisi yang ditentukan dalam skema penyimpanan lokal Anda setelah berhasil membuat cluster atau node pool.

Volume persisten lokal statis default

Distributed Cloud connected dilengkapi dengan jenis PersistentVolume (PV) lokal statis default yang telah di-pra-penyediaan berikut:

• anthos-system (97GiB): class penyimpanan volume lokal statis yang telah disediakan sebelumnya dalam mode sistem file.
• local-shared (97GiB): class penyimpanan volume lokal statis yang telah disediakan sebelumnya dalam mode sistem file.
• local-disks: class penyimpanan volume lokal statis yang telah disediakan sebelumnya dalam mode sistem file yang tersedia di deployment node tunggal untuk penyimpanan beban kerja pelanggan. Tidak seperti local-shared, PV ini didukung oleh partisi fisik khusus dan tidak di-overcommit secara logis.
• local-block: partisi perangkat blok mentah yang tidak terikat dan dicadangkan untuk penyimpanan workload dan volume Symcloud Storage. Ukuran partisi ini bergantung pada kapasitas penyimpanan hardware yang mendasarinya, yang menggunakan ruang disk yang tersisa setelah mencadangkan ruang untuk partisi sistem. Biasanya, node bidang kontrol mencadangkan 200 GiB (100 GiB partisi sistem dan 100 GiB partisi etcd), sedangkan node pekerja mencadangkan 100 GiB (untuk partisi sistem). Tata letak partisi, offset slice, dan batas perangkat fisik dari perangkat blok mentah ini bersifat tetap dan tidak dapat diubah.

PV local-shared setiap node tidak dapat diakses oleh node lain dalam cluster. Pod yang berjalan di node menulis ke direktori terpisah yang berada di drive disk fisik yang sama di node tersebut. Jika Anda tidak menggunakan Symcloud Storage, perangkat blok mentah local-block yang tidak terikat akan tetap tersedia di setiap node.

PV statis anthos-system dan local-shared secara logis di-overcommit dan didukung oleh sistem file partisi ~105 GB fisik tunggal yang sama yang di-mount di /dev/mapper/shared_lpvs_encrypted pada setiap node. Arsitektur ini menyediakan isolasi tingkat direktori untuk layanan latar belakang sistem yang dikelola Google, seperti logging, pemantauan, dan jaringan, tanpa membuang kapasitas disk fisik. PV sistem ini disediakan secara berlebih hingga kapasitas nominal maksimumnya di awal karena pengubahan ukuran volume lokal statis memerlukan migrasi data dan pembuatan ulang PV dan PVC yang terpengaruh.

Hindari penggunaan local-shared PV untuk workload produksi

Jangan gunakan PV local-shared untuk beban kerja produksi. Karena PV ini berada di drive disk fisik yang sama dengan layanan sistem yang terhubung Distributed Cloud, setiap workload yang Anda deploy untuk menggunakan PV tersebut akan bersaing untuk mendapatkan ruang dengan sistem yang terhubung Distributed Cloud itu sendiri.

Jika ruang kosong di disk drive sistem habis, hal berikut akan terjadi:

• Layanan platform yang dikelola Google dan pod pemantauan mengalami error
• Kubernetes memicu status DiskPressure berat pada node
• Kubernetes menghapus semua pod dari node

Untuk mencegah hal ini, gunakan hanya class penyimpanan yang ditawarkan oleh Symcloud Storage untuk workload produksi.

Pemecahan masalah

Jika PersistentVolumeClaims tetap tertunda secara tidak terduga atau beban kerja gagal melampirkan volume, jalankan langkah-langkah pemecahan masalah yang tercantum di bagian ini.

PersistentVolumeClaims tetap menunggu keputusan

Jika PersistentVolumeClaims Anda tetap dalam status Pending, periksa volumeBindingMode class penyimpanan Anda. Kelas Symcloud Storage yang telah dikonfigurasi sebelumnya menggunakan volumeBindingMode: WaitForFirstConsumer, yang menunda penyediaan volume hingga Pod yang mereferensikan klaim dijadwalkan. Pastikan Pod workload Anda berhasil dijadwalkan.

Jika penjadwalan Pod selesai, tetapi klaim tetap tertunda, atau jika pemasangan volume gagal, verifikasi kondisi bidang kontrol Symcloud Storage dan daemon tingkat node.

Memverifikasi kondisi bidang kontrol

Untuk memverifikasi bahwa bidang kontrol Symcloud Storage dalam kondisi baik dan siap menyediakan volume, jalankan perintah kubectl describe untuk memeriksa status resource kustom RobinCluster:

kubectl describe robinclusters -n robinio

Di output perintah, pastikan Phase adalah Ready.

Memverifikasi kondisi daemon penyimpanan

Untuk memverifikasi bahwa semua Pod daemon penyimpanan tingkat node sedang berjalan, jalankan perintah kubectl get:

kubectl get pods -n robinio

Di output perintah, pastikan semua Pod dalam status Running. Jika beban kerja dijadwalkan pada node dengan Pod daemon penyimpanan yang gagal, pemasangan volume akan terhenti terlepas dari status RobinCluster pusat.

Hubungi dukungan

Jika status bidang kontrol Symcloud Storage bukan Ready atau Pod daemon penyimpanan apa pun tidak dalam status Running, hubungi Dukungan Google. Saat mengajukan tiket dukungan, berikan output perintah pemecahan masalah yang Anda jalankan.