This site will be decommissioned on January 30th 2025. After that date content will be available at techdocs.broadcom.com.

 

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.2, 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.2.0_vmware.1
  pullPolicy: IfNotPresent
livenessProbeImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/csi-livenessprobe
  tag: v2.2.0_vmware.1
  pullPolicy: IfNotPresent
vsphereSyncerImage:
  repository: projects.registry.vmware.com/tkg
  path: csi/volume-metadata-syncer
  tag: v2.2.0_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.2.0_vmware.1
        pullPolicy: IfNotPresent
      livenessProbeImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/csi-livenessprobe
        tag: v2.2.0_vmware.1
        pullPolicy: IfNotPresent
      vsphereSyncerImage:
        repository: projects.registry.vmware.com/tkg
        path: csi/volume-metadata-syncer
        tag: v2.2.0_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 Distribuzione di cluster del carico di lavoro in più zone di disponibilità (Anteprima tecnica vSphere) 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.

    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