Configura l'archiviazione di Distributed Cloud connesso

Questa pagina descrive come configurare l'archiviazione per i cluster connessi a Distributed Cloud, tra cui:

Configurare Distributed Cloud connected per Symcloud Storage

I nodi connessi a Distributed Cloud non espongono direttamente l'archiviazione locale ai workload. Distributed Cloud connected utilizza invece Symcloud Storage di Rakuten, una soluzione di terze parti che funge da livello di astrazione dell'archiviazione locale in esecuzione su ogni nodo connesso a Distributed Cloud e rende disponibile l'archiviazione locale ai workload in esecuzione su tutti i nodi connessi a Distributed Cloud in un cluster.

Container Storage Interface (CSI) è un'API standard aperta supportata da molti dei principali fornitori di spazio di archiviazione che consente a Kubernetes di esporre sistemi di archiviazione arbitrari ai workload containerizzati. In Distributed Cloud connected, Symcloud Storage è la soluzione di archiviazione CSI supportata e gestita. Quando Symcloud Storage è attivato, le StorageClass di Kubernetes StorageClasses vengono configurate automaticamente. Puoi quindi configurare i workload in modo che utilizzino la classe di archiviazione appropriata.

Symcloud Storage viene eseguito il deployment da Google Cloud Marketplace ed è soggetto ai termini ivi indicati. Google fornisce un supporto limitato per l'utilizzo di Symcloud Storage con Distributed Cloud connected e potrebbe coinvolgere il fornitore di terze parti per ricevere assistenza. Gli aggiornamenti software per Symcloud Storage sono inclusi negli aggiornamenti software di Distributed Cloud connected.

Questa release di Distributed Cloud connected viene fornita con e supporta Symcloud Storage 6.0.0-226. Nessun'altra versione di Symcloud Storage è supportata in questa release di Distributed Cloud connected.

Ottenere una licenza Symcloud Storage

Devi ottenere una licenza Symcloud Storage in formato YAML da Google Cloud Marketplace:

Vai a Marketplace

Prerequisiti

Prima di iniziare, completa i seguenti passaggi:

  1. Configura la registrazione e il monitoraggio per il progetto Distributed Cloud connected di destinazione.
  2. Crea il cluster Distributed Cloud connected di destinazione.
  3. Configura la rete Distributed Cloud in modo che i pod nel cluster Distributed Cloud connected di destinazione possano raggiungere il Google Cloud data center.
  4. Collega ogni volume permanente local-block su ogni nodo Distributed Cloud che non vuoi che venga astratto da Symcloud Storage. Se scolleghi un volume permanente local-block collegato, l'installazione di Symcloud Storage cancella i contenuti di quel volume permanente. Per istruzioni, consulta la sezione relativa al collegamento nella documentazione di Kubernetes.

Installare Symcloud Storage su un nodo connesso a Distributed Cloud

Per installare Symcloud Storage su un nodo connesso a Distributed Cloud, completa i seguenti passaggi:

  1. Utilizza il seguente comando per applicare la licenza Symcloud Storage al cluster. Sostituisci LICENSE_FILE con il percorso completo e il nome del file di licenza Symcloud Storage.

    kubectl apply -f LICENSE_FILE -n robin-admin

  2. Utilizza il seguente comando per verificare lo stato del servizio RobinCluster e di tutti i nodi Symcloud Storage:

    kubectl describe robinclusters -n robinio

    Il comando restituisce un output simile al seguente:

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

    Lo stato previsto per il servizio e i nodi è Ready.

Impostare Symcloud Storage come classe di archiviazione predefinita

Utilizza il seguente comando per impostare Symcloud Storage come classe di archiviazione predefinita nel cluster connesso a Distributed Cloud. Sostituisci STORAGE_CLASS con una delle classi Symcloud Storage.

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

Per ulteriori informazioni sull'impostazione della classe di archiviazione predefinita, consulta la sezione relativa alla modifica della StorageClass predefinita nella documentazione di Kubernetes.

Classi Symcloud Storage

In questa sezione vengono descritte le classi di archiviazione che Symcloud Storage può abilitare nel cluster connesso a Distributed Cloud. Symcloud Storage su Distributed Cloud connected non supporta la classe di archiviazione robin-rwx né i volumi in modalità file system RWX configurati in modo personalizzato. Per ulteriori informazioni sulle classi Symcloud Storage, consulta la sezione relativa all'utilizzo di Robin CNS in Kubernetes.

Classe di archiviazione robin

La classe di archiviazione robin è una classe di archiviazione di base Read Write-Once (RWO). L'esempio seguente illustra l'istanza della classe:

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

Classe di archiviazione robin-immediate

La classe di archiviazione robin-immediate è uguale a robin, tranne per il fatto che il volume permanente viene creato immediatamente dopo la creazione della richiesta di volume permanente corrispondente. L'esempio seguente illustra l'istanza della classe:

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

Classe di archiviazione robin-repl-3

robin-repl-3 è una classe di archiviazione RWO con tre repliche che si estendono su più nodi Distributed Cloud. L'esempio seguente illustra l'istanza della classe:

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

Configurare i volumi Symcloud Storage astratti per i workload

Questa sezione fornisce esempi di come utilizzare le classi Symcloud Storage per configurare l'archiviazione astratta per i workload connessi a Distributed Cloud. Per ulteriori dettagli sulla configurazione dei volumi Symcloud Storage, consulta la sezione relativa all'utilizzo di Robin CNS in Kubernetes.

Configurare un volume RWO ext4 in modalità file system

L'esempio seguente illustra come configurare una richiesta di volume permanente per un volume RWO in modalità file system con il file system ext4. Sostituisci STORAGE_CLASS con una delle classi Symcloud Storage.

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

Configurare un volume RWO in modalità blocco

L'esempio seguente illustra come configurare una richiesta di volume permanente per un volume RWO in modalità blocco. Sostituisci STORAGE_CLASS con una delle classi Symcloud Storage.

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

Modificare la configurazione di un volume esistente

L'esempio seguente illustra come modificare la configurazione di un volume RWO compresso LZ4 Symcloud Storage esistente utilizzando le annotazioni. Sostituisci STORAGE_CLASS con una delle classi 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

L'esempio seguente illustra come modificare la configurazione di un volume RWO Symcloud Storage esistente con il file system xfs utilizzando le annotazioni. Sostituisci STORAGE_CLASS con una delle classi 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

Configurare il client CLI Symcloud Storage

Symcloud Storage fornisce un client dell'interfaccia a riga di comando (CLI) che puoi utilizzare per gestire la configurazione di Symcloud Storage. Per configurare il client nel cluster connesso a Distributed Cloud, completa i seguenti passaggi:

  1. Ottieni il percorso dell'immagine Symcloud Storage utilizzata dall'istanza del servizio RobinCluster di cui è stato eseguito il deployment nel cluster connesso a Distributed Cloud e imposta le variabili di ambiente come segue:

    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. Crea una risorsa robincli con i seguenti contenuti:

    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"

    Sostituisci ROBIN_CNS_IMAGE con il percorso completo del repository e il nome dell'immagine che hai ottenuto nel passaggio 1.

  3. Applica la risorsa robincli al cluster connesso a Distributed Cloud.

  4. Al momento dell'installazione iniziale, Symcloud Storage genera un secret default-admin-user nello spazio dei nomi robinio con una password casuale. Utilizza i seguenti comandi per ottenere queste credenziali di accesso:

    1. Ottieni il nome utente:

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

    2. Ottieni la password:

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

  5. Accedi al pod appena creato ed esegui il client:

    kubectl exec -it robincli -- bash

Fare riferimento alla classe di archiviazione in uno StatefulSet

L'esempio seguente mostra come fare riferimento a una classe di archiviazione Symcloud in un StatefulSet StatefulSet.

L'esempio presuppone che tu stia utilizzando la classe di archiviazione robin-repl-3 preconfigurata, che fornisce volumi replicati su tre nodi worker distinti per l'alta affidabilità.

Quando configuri uno StatefulSet per l'alta affidabilità, includi le seguenti best practice nella configurazione:

  • Servizio headless: uno StatefulSet richiede un servizio headless complementare che corrisponda al campo serviceName. Un servizio headless è un servizio con clusterIP: None. Questo servizio assegna nomi host DNS stabili a ogni pod nel set.
  • Anti-affinità tra pod: se utilizzi una classe di archiviazione replicata come robin-repl-3, i tuoi dati vengono rispecchiati in modo sicuro su più nodi worker. Tuttavia, se Kubernetes pianifica tutti i pod dell'applicazione sullo stesso nodo worker, un'interruzione di un singolo nodo può interrompere l'applicazione. La configurazione dell'anti-affinità tra pod garantisce che i pod siano distribuiti su nodi worker separati, in modo che la disponibilità di calcolo corrisponda alla ridondanza dell'archiviazione.

L'esempio seguente mostra una configurazione completa che include il servizio headless (nginx) e uno StatefulSet configurato con l'anti-affinità tra pod che fa riferimento alla classe di archiviazione robin-repl-3. Se i requisiti di archiviazione del workload aumentano nel tempo, puoi ridimensionare dinamicamente il volume modificando la richiesta di archiviazione nella PersistentVolumeClaim.

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

Limitazioni di Symcloud Storage

Quando utilizzi Symcloud Storage con Distributed Cloud connected, puoi ottenere l'alta affidabilità solo se il cluster connesso a Distributed Cloud è composto da tre o più nodi connessi a Distributed Cloud.

Rimuovere i nodi che utilizzano Symcloud Storage da un cluster

Le repliche dei volumi Symcloud Storage vengono archiviate sui nodi worker all'interno del cluster connesso a Distributed Cloud. Se rimuovi un nodo dal cluster, i dati del volume Symcloud Storage archiviati su quel nodo diventano non disponibili. Per evitare questo problema, devi eseguire una delle seguenti operazioni:

  • Se stai eliminando l'intero cluster, rimuovi i workload e i relativi volumi permanenti Symcloud Storage prima di eliminare il cluster stesso.
  • Se stai rimuovendo nodi specifici dal cluster, devi eseguire la migrazione dei dati del workload archiviati su questi nodi prima di rimuoverli dal cluster. Per istruzioni, consulta la sezione relativa all'evacuazione dei volumi da un disco.

Configurare gli schemi di archiviazione locale

Uno schema di archiviazione è un raggruppamento logico di una o più partizioni. Ogni partizione è un'unità di archiviazione logicamente indipendente. Le partizioni vengono create sul cluster in sequenza finché lo spazio su disco fisico non è esaurito. Ogni schema di archiviazione ha un nome univoco che lo identifica.

Per creare un nuovo schema di archiviazione locale per il cluster connesso a Distributed Cloud, devi richiederlo a Google. Una volta testato e creato lo schema nel cluster, puoi applicarlo utilizzando la gcloud CLI.

Non puoi modificare uno schema dopo che è stato applicato a un cluster. Per modificare uno schema esistente, devi richiedere l'eliminazione dello schema esistente a Google e poi richiedere la creazione di un nuovo schema per sostituirlo.

Definire le partizioni per uno schema di archiviazione locale

Prima di poter richiedere uno schema di archiviazione locale, devi prima definire le partizioni per lo schema.

Una partizione ha le seguenti proprietà:

  • Dimensioni. Puoi specificare le dimensioni di una partizione in byte binari o utilizzare tutto lo spazio rimanente sul disco locale.
  • Tipo. Puoi configurare una partizione come volume permanente (PV) di Kubernetes o come volume locale Linux sul disco locale.
  • Modalità. Puoi configurare il volume archiviato nella partizione come volume a blocchi o come volume del file system. Per le partizioni dei volumi permanenti, la classe di archiviazione della partizione è rispettivamente local-block o local-disks. Per le partizioni dei volumi locali, puoi specificare i punti di collegamento e di montaggio per i file system contenuti.

Richiedere uno schema di archiviazione locale

Per richiedere un nuovo schema di archiviazione locale per il cluster connesso a Distributed Cloud, contatta l'assistenza Google e fornisci le dimensioni, il tipo, la modalità e, facoltativamente, i punti di montaggio e di collegamento per ogni partizione che vuoi creare nello schema.

Quando riceviamo la tua richiesta, eseguiamo una serie di test per garantire la robustezza dello schema, quindi lo creiamo nel cluster connesso a Distributed Cloud.

Schemi di archiviazione locale predefiniti

Distributed Cloud connected viene fornito con i seguenti schemi di archiviazione locale predefiniti:

  • default_control_plane_node. Questo schema definisce le seguenti partizioni:

    • Una partizione del volume locale da 100 GB in modalità file system.
    • Una partizione del volume permanente in modalità blocco che occupa lo spazio libero su disco rimanente.

  • default_worker_node. Questo schema definisce una partizione del volume permanente da 410 GB in modalità blocco.

Applicare uno schema di archiviazione locale a un cluster

Per applicare uno schema di archiviazione locale al cluster connesso a Distributed Cloud, esegui una delle seguenti operazioni:

  • Per applicare uno schema di archiviazione locale ai nodi del piano di controllo del cluster, utilizza il flag --control-plane-node-storage-schema quando crei il cluster. Per saperne di più, consulta Creare un cluster.

  • Per applicare uno schema di archiviazione locale ai nodi worker del cluster, utilizza --node-storage-schema quando crei un pool di nodi per il cluster. Per saperne di più, consulta Creare un node pool.

Distributed Cloud connected crea le partizioni definite nello schema di archiviazione locale dopo la creazione del cluster o del pool di nodi.

Risoluzione dei problemi

Se le PersistentVolumeClaim rimangono in attesa in modo imprevisto o se i workload non riescono a collegare i volumi, esegui i passaggi per la risoluzione dei problemi elencati in questa sezione.

Le PersistentVolumeClaim rimangono in attesa

Se le PersistentVolumeClaim rimangono nello stato Pending, controlla volumeBindingMode della classe di archiviazione. Le classi Symcloud Storage preconfigurate utilizzano volumeBindingMode: WaitForFirstConsumer, che ritarda il provisioning del volume fino alla pianificazione del pod che fa riferimento alla richiesta. Assicurati che il pod del workload sia stato pianificato correttamente.

Se la pianificazione del pod è stata completata, ma la richiesta rimane in attesa o se il collegamento del volume non riesce, verifica l'integrità del piano di controllo Symcloud Storage e dei daemon a livello di nodo.

Verificare l'integrità del piano di controllo

Per verificare che il piano di controllo Symcloud Storage sia integro e pronto per il provisioning dei volumi, esegui il comando kubectl describe per controllare lo stato della RobinCluster risorsa personalizzata:

kubectl describe robinclusters -n robinio

Nell'output comando, verifica che Phase sia Ready.

Verificare l'integrità del daemon di archiviazione

Per verificare che tutti i pod del daemon di archiviazione a livello di nodo siano in esecuzione, esegui il comando kubectl get:

kubectl get pods -n robinio

Nell'output comando, assicurati che tutti i pod siano nello stato Running. Se un workload viene pianificato su un nodo con un pod del daemon di archiviazione non riuscito, il collegamento del volume si blocca indipendentemente dallo stato centrale di RobinCluster.

Contatta l'assistenza

Se lo stato del piano di controllo Symcloud Storage non è Ready o se i pod del daemon di archiviazione non sono nello stato Running, contatta l'assistenza Google. Quando compili un ticket di assistenza, fornisci gli output dei comandi di risoluzione dei problemi che hai eseguito.