Usar o controlador CSI do Persistent Disk do Compute Engine

Autopilot Padrão

O Google Kubernetes Engine (GKE) oferece uma forma simples de implementar e gerir automaticamente o controlador da interface de armazenamento de contentores (CSI) do disco persistente do Compute Engine nos seus clusters. O controlador CSI do disco persistente do Compute Engine está sempre ativado nos clusters do Autopilot e não pode ser desativado nem editado. Nos clusters padrão, tem de ativar o controlador CSI do disco persistente do Compute Engine.

A versão do controlador CSI do Persistent Disk do Compute Engine está associada aos números das versões do GKE. Normalmente, a versão do controlador CSI do Persistent Disk do Compute Engine é o controlador mais recente disponível no momento do lançamento da versão do GKE. Os controladores são atualizados automaticamente quando o cluster é atualizado para o patch do GKE mais recente.

Nota: uma vez que o controlador CSI do disco persistente do Compute Engine e alguns dos outros componentes CSI associados são implementados como contentores separados, incorrem na utilização de recursos (CPU, memória e disco de arranque da VM) nos nós do Kubernetes. Normalmente, a utilização da CPU da VM é de dezenas de milicores e a utilização da memória é de dezenas de MB. A utilização do disco de arranque é maioritariamente originada pelos registos do controlador CSI e de outros contentores do sistema na implementação.

Vantagens

A utilização do controlador CSI de disco persistente do Compute Engine oferece as seguintes vantagens:

• Permite a implementação e a gestão automáticas do controlador do disco persistente sem ter de o configurar manualmente.
• Pode usar chaves de encriptação geridas pelo cliente (CMEKs). Estas chaves são usadas para encriptar as chaves de encriptação de dados que encriptam os seus dados. Para saber mais sobre as CMEK no GKE, consulte o artigo Usar CMEK.
• Pode usar cópias instantâneas de volumes com o controlador CSI do Persistent Disk do Compute Engine. Os instantâneos de volume permitem-lhe criar uma cópia do volume num momento específico. Pode usar esta cópia para repor um volume num estado anterior ou aprovisionar um novo volume.
• Pode usar a clonagem de volumes com o controlador CSI do Persistent Disk do Compute Engine em clusters com a versão 1.22 do GKE e posterior. A clonagem de volumes permite-lhe criar um duplicado do seu volume num ponto específico no tempo, aprovisionado com todos os dados do volume de origem.
• As correções de erros e as atualizações de funcionalidades são implementadas independentemente das versões secundárias do Kubernetes. Normalmente, este cronograma de lançamentos resulta numa cadência de lançamentos mais rápida.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.
  Nota: para instalações existentes da CLI gcloud, certifique-se de que define a compute/region propriedade. Se usar principalmente clusters zonais, defina o compute/zone. Ao definir uma localização predefinida, pode evitar erros na CLI gcloud, como os seguintes: One of [--zone, --region] must be supplied: Please specify location. Pode ter de especificar a localização em determinados comandos se a localização do seu cluster for diferente da predefinição que definiu.

Ative o controlador CSI do Persistent Disk do Compute Engine

Para ativar o controlador CSI do Persistent Disk do Compute Engine em clusters Standard existentes, use a CLI Google Cloud ou a Google Cloud consola.

Para ativar o controlador num cluster existente, conclua os seguintes passos:

gcloud

gcloud container clusters update CLUSTER-NAME \
   --update-addons=GcePersistentDiskCsiDriver=ENABLED

Substitua CLUSTER-NAME pelo nome do cluster existente.

Consola

1. Aceda à página Google Kubernetes Engine na Google Cloud consola.

   Aceda ao Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que quer modificar.

3. Em Funcionalidades, junto ao campo Controlador CSI do Persistent Disk do Compute Engine, clique em Editar controlador CSI do Compute Engine.

4. Selecione a caixa de verificação Ativar o controlador CSI do Persistent Disk do Compute Engine.

5. Clique em Guardar alterações.

Depois de ativar o controlador CSI do Persistent Disk do Compute Engine, pode usar o controlador em volumes do Kubernetes com o nome do controlador e do aprovisionador: pd.csi.storage.gke.io.

Desative o controlador CSI do Persistent Disk do Compute Engine

Pode desativar o controlador CSI do Persistent Disk do Compute Engine para clusters padrão através da CLI Google Cloud ou da Google Cloud consola.

Se desativar o controlador, os Pods que usam atualmente PersistentVolumes pertencentes ao controlador não são terminados. Todos os novos pods que tentarem usar esses PersistentVolumes também não são iniciados.

Nota: à medida que o tipo de volume gcePersistentDisk é migrado para o controlador CSI de disco persistente do Compute Engine na versão 1.22 e posteriores, se desativar o controlador CSI de disco persistente, o tipo de volume gcePersistentDisk também deixa de funcionar.

Aviso: existe um problema conhecido no GKE 1.21 e anteriores se estiver a usar o controlador de disco persistente na árvore e quiser eliminar discos regionais. Um disco regional do Compute Engine pode ter fugas quando o respetivo recurso PersistentVolume é eliminado. Este problema pode ser detetado quando a chamada da API para eliminar o disco regional falha e devolve um código de erro diferente de NotFound. Para mais informações, consulte este problema do GitHub.

Para desativar o controlador num cluster padrão existente, conclua os seguintes passos:

gcloud

gcloud container clusters update CLUSTER-NAME \
    --update-addons=GcePersistentDiskCsiDriver=DISABLED

Substitua CLUSTER-NAME pelo nome do cluster existente.

Consola

1. Aceda à página Google Kubernetes Engine na Google Cloud consola.

   Aceda ao Google Kubernetes Engine

2. Na lista de clusters, clique no nome do cluster que quer modificar.

3. Em Funcionalidades, junto ao campo Controlador CSI do Persistent Disk do Compute Engine, clique em Editar controlador CSI do Compute Engine.

4. Desmarque a caixa de verificação Ativar o controlador CSI do Persistent Disk do Compute Engine.

5. Clique em Guardar alterações.

Use o controlador CSI do Persistent Disk do Compute Engine para clusters Linux

As secções seguintes descrevem o processo típico de utilização de um volume do Kubernetes suportado por um controlador CSI no GKE. Estas secções são específicas dos clusters que usam o Linux.

Crie uma StorageClass

Depois de ativar o controlador CSI do Persistent Disk do Compute Engine, o GKE instala automaticamente as seguintes StorageClasses:

• standard-rwo, usando um disco persistente equilibrado
• premium-rwo, usando um disco persistente SSD

Para clusters do Autopilot, a StorageClass predefinida é standard-rwo, que usa o controlador CSI de disco persistente do Compute Engine. Para clusters padrão, a StorageClass predefinida usa o plug-in de volume gcePersistentDisk integrado do Kubernetes.

Pode encontrar o nome das StorageClasses instaladas executando o seguinte comando:

kubectl get sc

Também pode instalar uma StorageClass diferente que use o controlador CSI de disco persistente do Compute Engine adicionando pd.csi.storage.gke.io no campo do aprovisionador.

Por exemplo, pode criar uma StorageClass através do seguinte ficheiro, denominado pd-example-class.yaml.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced

Pode especificar os seguintes tipos de discos persistentes no parâmetro type:

• pd-balanced
• pd-ssd
• pd-standard
• pd-extreme (suportado na versão 1.26 e posterior do GKE)

Se usar pd-standard ou pd-extreme, consulte o artigo Tipos de máquinas não suportados para ver restrições de utilização adicionais.

Quando usa a opção pd-extreme, também tem de adicionar o campo provisioned-iops-on-create ao seu manifesto. Este campo tem de ser definido com o mesmo valor que o valor de IOPS aprovisionado que especificou quando criou o disco persistente.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-extreme
  provisioned-iops-on-create:'10000'

Depois de criar o ficheiro pd-example-class.yaml, execute o seguinte comando:

kubectl create -f pd-example-class.yaml

Crie um PersistentVolumeClaim

Pode criar um PersistentVolumeClaim que faça referência à StorageClass do controlador CSI do Persistent Disk do Compute Engine.

O seguinte ficheiro, denominado pvc-example.yaml, usa a classe de armazenamento pré-instalada standard-rwo:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 6Gi

Depois de criar o manifesto PersistentVolumeClaim, execute o seguinte comando:

kubectl create -f pvc-example.yaml

Na StorageClass pré-instalada (standard-rwo), volumeBindingMode está definido como WaitForFirstConsumer. Quando volumeBindingMode está definido como WaitForFirstConsumer, o PersistentVolume não é aprovisionado até que um Pod que faça referência ao PersistentVolumeClaim seja agendado. Se volumeBindingMode na StorageClass estiver definido como Immediate (ou for omitido), é aprovisionado um PersistentVolume suportado por um disco persistente após a criação do PersistentVolumeClaim.

Crie um pod que consuma o volume

Quando usar pods com volumes persistentes, recomendamos que use um controlador de carga de trabalho (como uma implementação ou um StatefulSet). Embora normalmente não use um Pod autónomo, o exemplo seguinte usa um para simplificar.

O exemplo seguinte consome o volume que criou na secção anterior:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /var/lib/www/html
         # The name of the volume that is being defined in the "volumes" section.
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       # References the PersistentVolumeClaim created earlier.
       claimName: podpvc
       readOnly: false

Use o controlador CSI do Persistent Disk do Compute Engine para clusters Windows

As secções seguintes descrevem o processo típico de utilização de um volume do Kubernetes suportado por um controlador CSI no GKE. Estas secções são específicas dos clusters que usam o Windows.

Certifique-se de que:

• A versão do cluster é 1.19.7-gke.2000, 1.20.2-gke.2000 ou posterior.
• As versões dos nós são 1.18.12-gke.1203, 1.19.6-gke.800 ou posteriores.

Crie uma StorageClass

A criação de uma StorageClass para o Windows é muito semelhante à do Linux. Tenha em atenção que a StorageClass instalada por predefinição não funciona para o Windows porque o tipo de sistema de ficheiros é diferente. O controlador CSI de disco persistente do Compute Engine para Windows requer NTFS como o tipo de sistema de ficheiros.

Por exemplo, pode criar uma StorageClass através do seguinte ficheiro denominado pd- windows-class.yaml. Certifique-se de que adiciona csi.storage.k8s.io/fstype: NTFS à lista de parâmetros:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: NTFS

Crie um PersistentVolumeClaim

Depois de criar uma StorageClass para o Windows, já pode criar um PersistentVolumeClaim que faça referência a essa StorageClass:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-windows
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: pd-sc-windows
  resources:
    requests:
      storage: 6Gi

Crie um pod que consuma o volume

O exemplo seguinte consome o volume que criou na tarefa anterior:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  # Node selector to ensure the Pod runs on a Windows node.
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      # The container image to use.
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      # The path in the container where the volume will be mounted.
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        # References the PersistentVolumeClaim created earlier.
        claimName: podpvc-windows
        readOnly: false

Modifique dinamicamente os IOPS e o débito do Hyperdisk através da VolumeAttributeClass

Pode usar o VolumeAttributesClass com o controlador CSI de disco persistente do Compute Engine para modificar dinamicamente os atributos do disco persistente, incluindo IOPS e débito. Certifique-se de que a versão do cluster do GKE é a 1.34 ou posterior.

Esta secção demonstra como usar VolumeAttributesClass para modificar dinamicamente o desempenho do volume. Cria dois recursos VolumeAttributesClass, silver e gold, para definir diferentes níveis de IOPS e débito. Em seguida, crie um StorageClass, um PersistentVolumeClaim que faça referência ao nível silver e um Pod para consumir o volume. Por último, atualiza o PersistentVolumeClaim para fazer referência ao nível gold, o que faz uma atualização dinâmica às definições de desempenho do volume.

Nota: embora os manifestos StorageClass e Pod para a utilização geral de discos persistentes sejam abordados anteriormente nesta página, o fluxo de trabalho seguinte é necessário para configurar e validar as funcionalidades de desempenho específicas do Google Cloud Hyperdisk.

Crie um VolumeAttributesClass para definir níveis de desempenho

Esta secção define os recursos VolumeAttributesClass com os níveis de exemplo denominados silver e gold.

1. Guarde o seguinte manifesto como vac-classes.yaml:

   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: silver
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "3000"
     throughput: "188Mi"
   ---
   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: gold
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "6000"
     throughput: "345Mi"
   

2. Aplique o manifesto:

   kubectl apply -f vac-classes.yaml
   

Crie uma StorageClass para o Hyperdisk

Esta secção define um recurso StorageClass para o aprovisionamento de volumes do Hyperdisk.

1. Guarde o seguinte manifesto como hyperdisk-sc.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-example
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
   

2. Aplique o manifesto:

   kubectl apply -f hyperdisk-sc.yaml
   

Crie um PVC com um nível de desempenho inicial

Esta secção cria um PVC e usa o nível inicial denominado silver.

1. Guarde o seguinte manifesto como vac-silver-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: silver
     resources:
       requests:
         storage: 200Gi
   

2. Aplique o manifesto:

   kubectl apply -f vac-silver-pvc.yaml
   

3. Para aprovisionar um volume persistente, crie um pod que consuma o PVC. O StorageClass criado na secção anterior define volumeBindingMode: WaitForFirstConsumer, o que atrasa o aprovisionamento de volume até que um Pod consuma o PVC. Guarde o seguinte manifesto como test-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: test-pvc-pod
   spec:
     containers:
       - name: nginx-container
         image: nginx:latest
         ports:
           - containerPort: 80
         volumeMounts:
           - name: pvc-storage
             mountPath: /usr/share/nginx/html
     volumes:
       - name: pvc-storage
         persistentVolumeClaim:
           claimName: test-pv-claim
   

4. Aplique o manifesto:

   kubectl apply -f test-pod.yaml
   

5. Para verificar as definições de desempenho do disco, consulte o artigo Verifique as definições de desempenho do disco na Google Cloud consola. Os IOPS aprovisionados devem ser 3000 e a capacidade de débito aprovisionada deve ser 188, respetivamente.

Atualize o PVC para usar um nível de desempenho diferente

Esta secção atualiza o PVC para usar o nível gold em vez do nível silver.

1. Guarde o seguinte manifesto como vac-gold-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: gold
     resources:
       requests:
         storage: 200Gi
   

2. Aplique o manifesto:

   kubectl apply -f vac-gold-pvc.yaml
   

3. Para verificar se as definições de desempenho do disco estão atualizadas, consulte o artigo Verifique as definições de desempenho do disco na Google Cloud consola. Os IOPS aprovisionados devem ser 6000 e a capacidade de débito aprovisionada deve ser 345, respetivamente.

Valide as definições de desempenho do disco na Google Cloud consola

Pode verificar se as definições de IOPS e débito são aplicadas ao disco persistente consultando os detalhes do disco na Google Cloud consola.

1. Obtenha o nome do disco:

   PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}')
   DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||')
   echo "Persistent disk name: $DISK_NAME"
   

2. Na Google Cloud consola, aceda à página Discos.

   Aceda a Discos

3. Clique no nome do disco persistente que corresponde ao nome do disco do resultado do passo anterior.

4. Na página Detalhes do disco, na secção Desempenho, veja IOPS aprovisionados e Débito aprovisionado.

Para mais informações, consulte o artigo Veja as definições de desempenho aprovisionadas para o Hyperdisk.

Considerações para a modificação dinâmica

• Volte a aplicar as configurações anteriores: se não for possível associar um PVC a uma classe de atributos de volume devido a um erro, como recursos indisponíveis, pode voltar a aplicar o PVC anterior em segurança.
• Suporte de quotas: o plano de controlo do Kubernetes pode aplicar quotas a PVCs que referenciam um VolumeAttributesClass específico através de scopeSelector em ResourceQuota.

Use o controlador CSI de disco persistente do Compute Engine com tipos de sistemas de ficheiros não predefinidos

O tipo de sistema de ficheiros predefinido para discos persistentes do Compute Engine no GKE é ext4. Também pode usar o xfstipo de armazenamento, desde que a imagem do nó o suporte. Consulte o artigo Suporte de controladores de armazenamento para ver uma lista dos controladores suportados pela imagem do nó.

O exemplo seguinte mostra como usar xfs como o tipo de sistema de ficheiros predefinido em vez de ext4 com o controlador CSI do disco persistente do Compute Engine.

Crie uma StorageClass

1. Guarde o seguinte manifesto como um ficheiro YAML com o nome pd-xfs-class.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: xfs-class
   provisioner: pd.csi.storage.gke.io
   parameters:
     # The type of Compute Engine persistent disk to provision.
     type: pd-balanced
     # Specify "xfs" as the filesystem type.
     csi.storage.k8s.io/fstype: xfs
   volumeBindingMode: WaitForFirstConsumer
   

2. Aplique o manifesto:

   kubectl apply -f pd-xfs-class.yaml
   

Crie um PersistentVolumeClaim

1. Guarde o seguinte manifesto como pd-xfs-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: xfs-pvc
   spec:
     # References the StorageClass created earlier.
     storageClassName: xfs-class
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         # The amount of storage requested.
         storage: 10Gi
   

2. Aplique o manifesto:

   kubectl apply -f pd-xfs-pvc.yaml
   

Crie um pod que consuma o volume

1. Guarde o seguinte manifesto como pd-xfs-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pd-xfs-pod
   spec:
     containers:
     - name: cloud-sdk
       image: google/cloud-sdk:slim
       # Keep the container running for 1 hour.
       args: ["sleep","3600"]
       volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /xfs
         name: xfs-volume
     # Define the volumes available to the containers in the Pod.
     volumes:
     - name: xfs-volume
       persistentVolumeClaim:
         # References the PersistentVolumeClaim created earlier.
         claimName: xfs-pvc
   

2. Aplique o manifesto:

   kubectl apply -f pd-xfs-pod.yaml
   

Verifique se o volume foi montado corretamente

1. Abra uma sessão de shell no pod:

   kubectl exec -it pd-xfs-pod -- /bin/bash
   

2. Procure partições xfs:

   df -aTh --type=xfs
   

   O resultado deve ser semelhante ao seguinte:

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/sdb       xfs    30G   63M   30G   1% /xfs
   

Veja os registos do controlador CSI do Persistent Disk do Compute Engine

Pode usar o Cloud Logging para ver eventos relacionados com o controlador CSI de disco persistente do Compute Engine. Os registos podem ajudar a resolver problemas.

Para mais informações sobre o Cloud Logging, consulte o artigo Ver os registos do GKE.

Para ver os registos do controlador CSI do disco persistente do Compute Engine, conclua os seguintes passos:

1. Aceda à página Cloud Logging na Google Cloud consola.

   Aceda ao Cloud Logging

2. Para filtrar as entradas do registo de modo a mostrar apenas as entradas relacionadas com o controlador CSI que é executado no seu espaço de nomes, execute a seguinte consulta do Cloud Logging:

    resource.type="k8s_container"
    resource.labels.project_id="PROJECT_ID"
    resource.labels.location="LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.namespace_name="kube-system"
    resource.labels.container_name="gce-pd-driver"
   

   Substitua o seguinte:

   • PROJECT_ID: o nome do seu projeto.
   • LOCATION: a região ou a zona do Compute Engine do cluster.
   • CLUSTER_NAME: o nome do cluster.

Problemas conhecidos

Tipos de máquinas não suportados

Se estiver a usar a família de máquinas da série C3, o tipo de disco persistente pd-standard não é suportado.

Se tentar executar um pod numa máquina e o pod usar um tipo de disco persistente não suportado, é emitida uma mensagem de aviso semelhante à seguinte no pod:

AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.

Se o seu cluster tiver vários conjuntos de nós com diferentes famílias de máquinas, pode usar contaminações de nós e afinidade de nós para limitar onde as cargas de trabalho podem ser agendadas. Por exemplo, pode usar esta abordagem para restringir uma carga de trabalho que usa pd-standard de ser executada numa família de máquinas não suportada.

Se estiver a usar o pd-extreme tipo de disco persistente, tem de garantir que o disco está associado a uma instância de VM com um formato de máquina adequado. Para saber mais, consulte o artigo Suporte de formas de máquinas.

O que se segue?

• Saiba como usar a expansão do volume.
• Saiba como usar as capturas instantâneas de volume.
• Saiba como usar a clonagem de volume.
• Saiba como criar discos persistentes regionais.
• Leia mais sobre o controlador no GitHub.