Usar o controlador CSI do Persistent Disk do Compute Engine

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 Persistent Disk 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 mais recente do GKE.

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 acerca das 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 disco persistente 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 dos lançamentos secundários 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 gcloud components update para obter a versão mais recente.

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 Trusted Cloud consola.

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

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

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 Standard através da CLI Google Cloud ou da Trusted 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.

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

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

Use o controlador CSI de disco persistente 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 aprovisionados 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 de 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

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 passos seguintes:

1. Aceda à página Cloud Logging na Trusted 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 voz.
• Saiba como criar discos persistentes regionais.
• Leia mais sobre o controlador no GitHub.