Storage dinamico

Questo argomento spiega come utilizzare volumi persistenti e classi di storage per implementare lo storage dinamico per i cluster del carico di lavoro di Tanzu Kubernetes Grid (TKG).

Panoramica: PersistentVolume, PersistentVolumeClaim e StorageClass

All'interno di un cluster Kubernetes, gli oggetti PersistentVolume (PV) forniscono storage condiviso per i pod del cluster che non sono interessati dai cicli di vita dei pod. Il provisioning dello storage viene eseguito nel PV tramite un oggetto PersistentVolumeClaim (PVC), che definisce quanto e come il pod accede allo storage sottostante. Per ulteriori informazioni, vedere Volumi persistenti nella documentazione di Kubernetes.

Gli amministratori del cluster possono definire oggetti StorageClass che consentono agli utenti del cluster di creare dinamicamente oggetti PVC e PV con tipi di storage e regole diversi. Tanzu Kubernetes Grid fornisce inoltre oggetti StorageClass predefiniti che consentono agli utenti di eseguire il provisioning dello storage persistente in un ambiente chiavi in mano.

Gli oggetti StorageClass includono un campo provisioner che identifica il plug-in del servizio interno o esterno che esegue il provisioning dei PV e un campo parameters che associa la classe di storage Kubernetes alle opzioni di storage definite a livello dell'infrastruttura, ad esempio i criteri di storage della macchina virtuale in vSphere. Per ulteriori informazioni, vedere Classi di storage nella documentazione di Kubernetes.

Tipi di risorsa supportati

Tanzu Kubernetes Grid supporta oggetti StorageClass per diversi tipi di storage con provisioning eseguito dai plug-in interni ("in-tree") o esterni ("out-of-tree") di Kubernetes.

Tipi di storage

  • vSphere Cloud Native Storage (CNS)
  • Amazon EBS
  • Azure Disk
  • Azure File
  • iSCSI
  • NFS
Nota

vSphere CSI non supporta la DRS di storage e supporta Storage vMotion con le condizioni descritte in Funzionalità di vSphere supportata dal plug-in vSphere Container Storage nella documentazione di vSphere CSI.

vSphere supporta CSI Storage vMotion a determinate condizioni, consultare il documento CSI per ulteriori dettagli.

Vedere Classi di storage predefinite per le classi di storage predefinite di vSphere CNS, Amazon EBS e Azure Disk.

Provisioning esterno

In TKG v2.4, tutte le classi di storage predefinite utilizzano il provisioning di storage esterno ("out-of-tree"), non il provisioning "in-tree".

  • Le classi di storage non sono in dotazione con Kubernetes core.
  • I valori provisioner dell'oggetto StorageClass non sono preceduti da kubernetes.io.
  • I provisioner seguono lo standard CSI (Container Storage Interface) per lo storage esterno.
  • I cluster del carico di lavoro con classi di storage predefinite distribuite dalle versioni precedenti di TKG possono avere il provisioning dello storage nella struttura. Vedere Creazione di volumi persistenti con classi di storage.

Classi di storage predefinite

Tanzu Kubernetes Grid fornisce oggetti StorageClass predefiniti che consentono agli utenti del cluster del carico di lavoro di eseguire il provisioning dello storage persistente nella propria infrastruttura in un ambiente chiavi in mano, senza bisogno di oggetti StorageClass creati da un amministratore del cluster.

La variabile ENABLE_DEFAULT_STORAGE_CLASS è impostata su true per impostazione predefinita nel file di configurazione del cluster passato all'opzione --file di tanzu cluster create in modo da abilitare la classe di storage predefinita per un cluster del carico di lavoro.

Importante

Non modificare le definizioni delle classi di storage predefinite. Per personalizzare una classe di storage, creare una nuova definizione di StorageClass con il nome name anziché modificare l'oggetto predefinito creato da TKG.

Le definizioni della classi di storage predefinite di Tanzu Kubernetes Grid sono:

vSphere CNS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: csi.vsphere.vmware.com
parameters:
  storagePolicyName: optional

Vedere i parametri della classe di storage vSphere CSI nella documentazione di Kubernetes.

Amazon EBS

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: default
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: ebs.csi.aws.com

Vedere i parametri della classe di storage del driver CSI Amazon EBS nella documentazione di AWS.

Azure Disk

apiVersion: storage.k8s.io/v1beta1
kind: StorageClass
metadata:
  name: default
  annotations:
    storageclass.beta.kubernetes.io/is-default-class: "true"
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: disk.csi.azure.com
parameters:
  kind: Managed
  storageaccounttype: Standard_LRS
  cachingmode: ReadOnly
volumeBindingMode: WaitForFirstConsumer

Vedere i parametri della classe di storage del driver CSI Azure Disk nella documentazione di Azure.

Azure File

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azure-file
  labels:
    kubernetes.io/cluster-service: "true"
provisioner: file.csi.azure.com
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict
  - actimeo=30
allowVolumeExpansion: true
parameters:
  skuName: Premium_LRS

Vedere i parametri della classe di storage Azure File nella documentazione di Kubernetes.

Configurazione di CNS e creazione di un criterio di storage (vSphere)

Gli amministratori di vSphere possono configurare vSphere CNS e creare criteri di storage per lo storage a disco virtuale (VMDK), in base alle esigenze degli utenti del cluster Tanzu Kubernetes Grid.

È possibile utilizzare vSAN o VMFS (Virtual Machine File System) locale per lo storage persistente in un cluster Kubernetes, come indicato di seguito:

Storage vSAN:

Per creare un criterio di storage per vSAN storage nel vSphere Client, passare a Home > Criteri e profili (Policies and Profiles) > Criteri di storage della macchina virtuale (VM Storage Policies) e fare clic su Crea (Create) per avviare la procedura guidata Crea criterio di storage della macchina virtuale (Create VM Storage Policy).

Seguire le istruzioni riportate in Creazione di un criterio di storage nella documentazione di vSphere. Assicurarsi di:

  • Nella pagina Struttura dei criteri (Policy structure) in Regole specifiche del datastore (Datastore specific rules), selezionare Abilita regole per storage vSAN (Enable rules for “vSAN” storage).
  • Configurare altri riquadri o accettare i valori predefiniti in base alle esigenze.
  • Registrare il nome del criterio di storage come riferimento come valore storagePolicyName negli oggetti StorageClass.

Storage VMFS locale:

Per creare un criterio di storage per lo storage locale, applicare un tag allo storage e creare un criterio di storage basato sul tag come indicato di seguito:

  1. Dal menu principale di vSphere, selezionare Tag e attributi personalizzati (Tags & Custom Attributes)

  2. Nel riquadro Tag selezionare Categorie (Categories) quindi fare clic su Nuova (New).

  3. Immettere un nome di categoria, ad esempio tkg-storage. Utilizzare le caselle di controllo per associarlo a Datacenter e agli oggetti di storage Cartella (Folder) e Datastore. Fare clic su Crea (Create).

  4. Nella vista Storage principale, selezionare il volume VMFS e nel riquadro Riepilogo (Summary) fare clic su Tag > Assegna (Assign…).

  5. Nel popup Assegna tag (Assign tag), fare clic su Aggiungi tag (Add Tag).

  6. Dal popup Crea tag (Create Tag), assegnare al tag un nome, ad esempio tkg-storage-ds1 e assegnarlo alla Categoria (Category) appena creata. Fare clic su OK.

  7. In Assegna tag (Assign Tag), selezionare il tag e fare clic su Assegna (Assign).

  8. Dal livello principale di vSphere, selezionare Criteri di storage della macchina virtuale (VM Storage Policies) > Crea un criterio di storage (Create a Storage Policy). Viene avviata una configurazione guidata.

  9. Nel riquadro Nome e descrizione (Name and description) immettere un nome per il criterio di storage. Registrare il nome del criterio di storage come riferimento come valore storagePolicyName negli oggetti StorageClass.

  10. Nella pagina Struttura dei criteri (Policy structure) in Regole specifiche del datastore (Datastore specific rules), selezionare Abilita regole di posizionamento basate su tag (Enable tag-based placement rules).

  11. Nel riquadro Posizionamento basato su tag (Tag based placement) fare clic su Aggiungi regola tag (Add Tag Rule) e configurare:

    • Categoria di tag: Seleziona il nome della categoria
    • Opzione di utilizzo (Usage option): Use storage tagged with
    • Tag: Sfogliare e selezionare il nome dell'etichetta
  12. Confermare e configurare altri riquadri o accettare i valori predefiniti in base alle esigenze, quindi fare clic su Rivedi e termina (Review and finish). Selezionare Fine (Finish) per creare il criterio di storage.

Creazione di una classe di storage personalizzata

Gli amministratori del cluster possono creare una nuova classe di storage nel modo seguente:

  1. In vSphere, selezionare o creare il criterio di storage della macchina virtuale da utilizzare come base per la StorageClass Kubernetes.
  2. Creare un file .yaml di configurazione StorageClass con provisioner, parameters e altre opzioni.
    • In vSphere, associare una classe di storage Kubernetes a un criterio di storage vSphere impostando il relativo parametro storagePolicyName sul nome del criterio di storage vSphere, come stringa tra virgolette.
  3. Passare il file a kubectl create -f.
  4. Verificare la classe di storage eseguendo kubectl describe storageclass <storageclass metadata.name>.

Ad esempio, vedere Abilitazione del provisioning dinamico nella documentazione di Kubernetes.

Per informazioni e risorse su vSphere CSI, vedere la documentazione del plug-in VMware vSphere Storage Container.

Utilizzo di una classe di storage personalizzata in un cluster

Per eseguire il provisioning dello storage persistente per i nodi del cluster che non utilizza una delle Classi di storage predefinite descritte in precedenza, gli utenti del cluster includono una classe di storage personalizzata in una configurazione di pod come indicato di seguito:

  1. Impostare il contesto di kubectl sul cluster. Ad esempio:

    kubectl config use-context my-cluster-admin@my-cluster
    
  2. Selezionare o creare una classe di storage.

    • Selezionare:
      • Per visualizzare un elenco delle classi di storage disponibili, eseguire kubectl get storageclass.
    • Crea
  3. Creare una PVC e il relativo PV:

    1. Creare un file .yaml di configurazione PersistentVolumeClaim con spec.storageClassName impostato sul valore metadata.name dell'oggetto StorageClass. Per un esempio, vedere Abilitazione del provisioning dinamico nella documentazione di Kubernetes.
    2. Passare il file a kubectl create -f.
    3. Eseguire kubectl describe pvc <pvc metadata.name> per verificare il PVC.
    4. Viene creato automaticamente un PV insieme alla PVC. Registrarne il nome, elencato nell'output kubectl describe pvc dopo Successfully provisioned volume.
    5. Eseguire kubectl describe pv <pv unique name> per verificare il PV.
  4. Creare un pod utilizzando il PVC:

    1. Creare un file .yaml di configurazione Pod in cui spec.volumes è impostato in modo da includere la PVC in persistentVolumeClaim.claimName. Per un esempio, vedere Provisioning dinamico di un volume di blocchi con il plug-in vSphere Container Storage nella documentazione del plug-in vSphere Container Storage.
    2. Passare il file a kubectl create -f.
    3. Eseguire kubectl get pod <pod metadata.name> per verificare il pod.

Abilitazione dell'espansione del volume per vSphere CSI (vSphere 7)

Per abilitare l'espansione del volume per vSphere storage CSI utilizzato dai cluster del carico di lavoro, è necessario aggiungere un csi-resizer pod sidecar ai processi CSI del cluster.

La configurazione CSI per i cluster del carico di lavoro è codificata come segreto Kubernetes. Questa procedura aggiunge il processo csi-resizer rivedendo il segreto di configurazione CSI. Aggiunge al segreto una definizione stringData che combina due stringhe di dati di configurazione codificate: una stringa values.yaml contenente i dati di configurazione CSI precedenti del segreto e una nuova stringa overlays.yaml che distribuisce il pod csi-resizer.

Nota

L'espansione del volume online è supportata in vSphere 7.0 a partire dall'aggiornamento 2; vedere Espansione del volume in vSphere with Tanzu.

  1. Accedere al cluster di gestione per il cluster del carico di lavoro che si sta modificando ed eseguire tanzu cluster list se è necessario recuperare il nome del cluster del carico di lavoro.

  2. Recuperare il nome del segreto CSI per il cluster del carico di lavoro utilizzando i selettori etichette vsphere-csi e il nome del cluster:

    $ kubectl get secret \
      -l tkg.tanzu.vmware.com/cluster-name=NAME_OF_WORKLOAD_CLUSTER \
      -l tkg.tanzu.vmware.com/addon-name=vsphere-csi
    my-wc-vsphere-csi-secret
    
  3. Salvare un backup del contenuto del segreto, in formato YAML, in vsphere-csi-secret.yaml:

    kubectl get secret my-wc-vsphere-csi-secret -o yaml > vsphere-csi-secret.yaml
    
  4. Eseguire nuovamente l'output del contenuto corrente del segreto con i valori data.values decodificati base64 in un file YAML normale.

    $ kubectl get secret my-wc-vsphere-csi-secret -o jsonpath={.data.values\\.yaml} | base64 -d
    
    #@data/values
    #@overlay/match-child-defaults missing_ok=True
    ---
    vsphereCSI:
    CSIAttacherImage:
      repository: projects.registry.vmware.com/tkg
      path: csi/csi-attacher
      tag: v3.0.0_vmware.1
      pullPolicy: IfNotPresent
    vsphereCSIControllerImage:
      repository: projects.registry.vmware.com/tkg
      path: csi/vsphere-block-csi-driver
      tag: v2.1.1_vmware.1
      pullPolicy: IfNotPresent
    livenessProbeImage:
      repository: projects.registry.vmware.com/tkg
      path: csi/csi-livenessprobe
      tag: v2.1.1_vmware.1
      pullPolicy: IfNotPresent
    vsphereSyncerImage:
      repository: projects.registry.vmware.com/tkg
      path: csi/volume-metadata-syncer
      tag: v2.1.1_vmware.1
      pullPolicy: IfNotPresent
    CSIProvisionerImage:
      repository: projects.registry.vmware.com/tkg
      path: csi/csi-provisioner
      tag: v2.0.0_vmware.1
      pullPolicy: IfNotPresent
    CSINodeDriverRegistrarImage:
      repository: projects.registry.vmware.com/tkg
      path: csi/csi-node-driver-registrar
      tag: v2.0.1_vmware.1
      pullPolicy: IfNotPresent
    namespace: kube-system
    clusterName: wc-1
    server: 10.170.104.114
    datacenter: /dc0
    publicNetwork: VM Network
    username: <MY-VSPHERE-USERNAME>
    password: <MY-VSPHERE-PASSWORD>
    
    
  5. Aprire vsphere-csi-secret.yaml in un editor ed eseguire le operazioni seguenti per renderlo simile al codice seguente:

    1. Eliminare la definizione esistente per values.yaml, che è una stringa lunga.
    2. Dopo la prima riga, aggiungere una riga che definisca stringData e far rientrare values.yaml in modo da renderlo il primo elemento.
    3. Copiare l'output di data.values del passaggio precedente.
    4. Dopo la terza riga, incollare l'output di data.values e farlo rientrare come valore di values.yaml.
    5. Immediatamente sotto la definizione di values.yaml, aggiungere un'altra definizione stringData per overlays.yaml come illustrato di seguito. Non modificare altre definizioni nel file.
    apiVersion: v1
    stringData:
      values.yaml: |
        #@data/values
        #@overlay/match-child-defaults missing_ok=True
        ---
        vsphereCSI:
          CSIAttacherImage:
            repository: projects.registry.vmware.com/tkg
            path: csi/csi-attacher
            tag: v3.0.0_vmware.1
            pullPolicy: IfNotPresent
          vsphereCSIControllerImage:
            repository: projects.registry.vmware.com/tkg
            path: csi/vsphere-block-csi-driver
            tag: v2.1.1_vmware.1
            pullPolicy: IfNotPresent
          livenessProbeImage:
            repository: projects.registry.vmware.com/tkg
            path: csi/csi-livenessprobe
            tag: v2.1.1_vmware.1
            pullPolicy: IfNotPresent
          vsphereSyncerImage:
            repository: projects.registry.vmware.com/tkg
            path: csi/volume-metadata-syncer
            tag: v2.1.1_vmware.1
            pullPolicy: IfNotPresent
          CSIProvisionerImage:
            repository: projects.registry.vmware.com/tkg
            path: csi/csi-provisioner
            tag: v2.0.0_vmware.1
            pullPolicy: IfNotPresent
          CSINodeDriverRegistrarImage:
            repository: projects.registry.vmware.com/tkg
            path: csi/csi-node-driver-registrar
            tag: v2.0.1_vmware.1
            pullPolicy: IfNotPresent
          namespace: kube-system
          clusterName: wc-1
          server: 10.170.104.114
          datacenter: /dc0
          publicNetwork: VM Network
          username: <MY-VSPHERE-USERNAME>
          password: <MY-VSPHERE-PASSWORD>
      overlays.yaml: |
        #@ load("@ytt:overlay", "overlay")
        #@overlay/match by=overlay.subset({"kind": "Deployment", "metadata": {"name": "vsphere-csi-controller"}})
        ---
        spec:
          template:
            spec:
              containers:
              #@overlay/append
                - name: csi-resizer
                  image: projects.registry.vmware.com/tkg/kubernetes-csi_external-resizer:v1.0.0_vmware.1
                  args:
                    - "--v=4"
                    - "--timeout=300s"
                    - "--csi-address=$(ADDRESS)"
                    - "--leader-election"
                  env:
                    - name: ADDRESS
                      value: /csi/csi.sock
                  volumeMounts:
                    - mountPath: /csi
                      name: socket-dir
    kind: Secret
    ...
    
  6. Eseguire kubectl apply per aggiornare il segreto del cluster con le definizioni modificate e ricreare il pod csi-controller:

    kubectl apply -f vsphere-csi-secret.yaml
    
  7. Per verificare che vsphere-csi-controller e il resizer esterno funzionino nel cluster:

    1. Verificare che vsphere-csi-controller sia in esecuzione nel cluster del carico di lavoro con sei pod integri:

      $ kubectl get pods -n kube-system -l app=vsphere-csi-controller
      NAME                                     READY   STATUS    RESTARTS   AGE
      vsphere-csi-controller-<ID-HASH>   6/6     Running   0          6m49s
      
    2. Controllare i registri del vsphere-csi-controller per verificare che il ridimensionamento esterno sia stato avviato.

      $ kubectl logs vsphere-csi-controller-<ID-HASH> -n kube-system -c csi-resizer
      I0308 23:44:45.035254       1 main.go:79] Version : v1.0.0-0-gb22717d
      I0308 23:44:45.037856       1 connection.go:153] Connecting to unix:///csi/csi.sock
      I0308 23:44:45.038572       1 common.go:111] Probing CSI driver for readiness
      I0308 23:44:45.040579       1 csi_resizer.go:77] CSI driver name: "csi.vsphere.vmware.com"
      W0308 23:44:45.040612       1 metrics.go:142] metrics endpoint will not be started because `metrics-address` was not specified.
      I0308 23:44:45.042184       1 controller.go:117] Register Pod informer for resizer csi.vsphere.vmware.com
      I0308 23:44:45.043182       1 leaderelection.go:243] attempting to acquire leader lease  kube-system/external-resizer-csi-vsphere-vmware-com...
      I0308 23:44:45.073383       1 leaderelection.go:253] successfully acquired lease kube-system/external-resizer-csi-vsphere-vmware-com
      I0308 23:44:45.076028       1 leader_election.go:172] new leader detected, current leader: vsphere-csi-controller-87d7dcf48-jcht2
      I0308 23:44:45.079332       1 leader_election.go:165] became leader, starting
      I0308 23:44:45.079638       1 controller.go:241] Starting external resizer csi.vsphere.vmware.com
      

Per ulteriori informazioni sull'espansione dei volumi di storage di vSphere CSI in modalità online o offline, vedere Espansione del volume in vSphere with Tanzu.

Provisioning di volumi sensibile alla topologia (vSphere)

Per i cluster del carico di lavoro creati da un cluster di gestione autonomo, è possibile configurare il provisioning di volume di storage locali sensibile alla topologia. Il provisioning dei volumi sensibile alla topologia consente a Kubernetes di prendere decisioni intelligenti durante il provisioning dinamico dei volumi. Kubernetes riceve l'input dello scheduler riguardo alla posizione ottimale per eseguire il provisioning di un volume per un pod.

Creare una zona di disponibilità (ZD):

  1. Seguire le istruzioni in Esecuzione dei cluster in più zone di disponibilità per creare quanto segue in vSphere:

    1. Aggiungere il gruppo di host e il gruppo di macchine virtuali.
    2. Aggiungere regole per limitare il gruppo di macchine virtuali nel gruppo di host.

      Per eseguire la ZD nel cluster del carico di lavoro, viene utilizzato un gruppo di macchine virtuali e un gruppo di host.

      Nota

      Le regole di limite valgono solo per le configurazioni dei volumi locali. Non è necessario creare regole di limite se si esegue la distribuzione in più zone di disponibilità.

    3. Distribuire le definizioni di risorse personalizzate (CRD) VSphereFailureDomain e VSphereDeploymentZone nel cluster di gestione autonomo.

      La ZD verrà mappata a una VSphereDeploymentZone e quindi a un gruppo di host in vSphere.

  2. Aggiungere una nuova ZD. È possibile aggiungere una nuova ZD utilizzando una configurazione di overlay ytt o utilizzando la CLI di Tanzu.

    ytt
    Di seguito viene mostrata una configurazione dell'overlay ytt in un cluster legacy e in un cluster con classe. Per informazioni su come scaricare e installare ytt, vedere Installazione degli strumenti Carvel.

    Cluster legacy

    #@overlay/match by=overlay.subset({"kind":"MachineDeployment", "metadata":{"name": "${CLUSTER_NAME}-md-0"}})
      ---
      apiVersion: cluster.x-k8s.io/v1beta1
      kind: MachineDeployment
      metadata:
        name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
      spec:
        clusterName: #@ data.values.CLUSTER_NAME
        replicas: #@ data.values.WORKER_MACHINE_COUNT_0
        selector:
          matchLabels: null
        strategy:
          type: #@ verify_and_configure_machine_deployment_rollout_strategy(data.values.WORKER_ROLLOUT_STRATEGY)
        template:
          metadata:
            labels:
              node-pool: #@ "{}-worker-pool".format(data.values.CLUSTER_NAME)
          spec:
            clusterName: #@ data.values.CLUSTER_NAME
            version: #@ data.values.KUBERNETES_VERSION
            bootstrap:
              configRef:
                name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
                apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
                kind: KubeadmConfigTemplate
            infrastructureRef:
              name: #@ "{}-md-0".format(data.values.CLUSTER_NAME)
              apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
              kind: AWSMachineTemplate
            failureDomain: #@ default_az_0
    
    

    Cluster con classe

    workers:
      machineDeployments:
      #@overlay/match by=overlay.index(0)
      - class: tkg-worker
        name: md-0
        replicas: #@ data.values.WORKER_MACHINE_COUNT_0
        #@overlay/match missing_ok=True
        failureDomain: #@ default_az_0
        metadata:
          annotations:
            run.tanzu.vmware.com/resolve-os-image: #@ "ami-region={},os-name={},os-arch={}".format(data.values.AWS_REGION, data.values.OS_NAME, data.values.OS_ARCH)
    
    CLI di Tanzu
    È possibile creare una nuova ZD per supportare il provisioning dello storage locale sensibile alla topologia utilizzando la CLI di Tanzu.

    Cluster legacy

    tanzu cl node-pool set cl-name -f node-pool.yaml
    
    # node-pool.yaml
    name: vsphere-wc-1-manual-node-pool
    replicas: 1
    az: "rack4"
    

    Cluster con classe

    Vedere Impostazione (creazione) in Configurazione dei pool di nodi per i cluster basati su ClusterClass.

check-circle-line exclamation-circle-line close-line
Scroll to top icon