Como usar o driver CSI do disco permanente do Compute Engine

O Google Kubernetes Engine (GKE) fornece uma maneira simples de implantar e gerenciar automaticamente o Driver da interface de armazenamento do contêiner (CSI, na sigla em inglês) do disco permanente do Compute Engine nos clusters.

A versão do driver CSI do disco permanente do Compute Engine está vinculada aos números da versão do GKE. Normalmente, a versão do driver CSI do disco permanente do Compute Engine é o mais recente disponível no momento em que a versão do GKE é lançada. Os drivers são atualizados automaticamente quando o cluster é atualizado para o patch do GKE mais recente.

Vantagens

Usar o driver CSI do disco permanente do Compute Engine em vez do Plug-in de volume gcePersistentDisk (em inglês) em árvore no Kubernetes traz os seguintes benefícios:

  • Os drivers CSI são o futuro da extensão de armazenamento no Kubernetes. O Kubernetes anunciou que os plug-ins de volume em árvore serão removidos do Kubernetes na versão 1.21, embora o provedor gce-pd continue sendo compatível com uma camada de migração transparente. Para mais detalhes, consulte Árvore no Kubernetes para migração de volume CSI para versão Beta (em inglês). Depois que os plug-ins de volume em árvore são removidos, os volumes existentes que usam plug-ins de volume em árvore se comunicam por meio de drivers CSI.
  • Isso permite a implantação e o gerenciamento automáticos do driver de disco permanente sem ter que configurá-lo manualmente ou usar o plug-in de volume em árvore.
  • Isso também fornece recursos adicionais de disco permanente no GKE. Por exemplo:
    • É possível usar chaves de criptografia gerenciadas pelo cliente (CMEKs) com o driver CSI de disco permanente do Compute Engine, mas não o plug-in de volume em árvore. Essas chaves são usadas para criptografar as chaves que criptografam seus dados. Para saber mais sobre a CMEK no GKE, consulte Como usar CMEKs.
    • Use snapshots de volume com o driver CSI de disco permanente do Compute Engine. Eles permitem criar uma cópia do seu volume em um momento específico. Use essa cópia para trazer um volume de volta a um estado anterior ou para provisionar um novo volume.
  • Correções de bugs e atualizações de recursos são lançadas independentemente das versões secundárias do Kubernetes. Essa programação de lançamento geralmente resulta em uma cadência de lançamento mais rápida.

Requisitos

Para usar o driver CSI de disco permanente do Compute Engine, os clusters precisam usar as seguintes versões:

  • Clusters Linux: GKE versão 1.14 ou posterior.
  • Clusters do Windows: GKE versão 1.18 ou posterior.

Para usar o driver CSI do disco permanente do Compute Engine com a Identidade da carga de trabalho, seus clusters precisam usar as seguintes versões:

  • Clusters Linux: GKE versão 1.16 ou posterior.
  • Clusters do Windows: GKE versão 1.20.8-gke.900 ou posterior.

Como ativar o driver CSI do disco permanente do Compute Engine em um novo cluster

Para criar um cluster Standard com uma versão em que o driver CSI do disco permanente do Compute Engine não esteja ativado automaticamente, use a ferramenta de linha de comando gcloud ou o Console do Google Cloud.

Para ativar o driver na criação do cluster, conclua as seguintes etapas:

gcloud

gcloud container clusters create CLUSTER-NAME \
    --addons=GcePersistentDiskCsiDriver \
    --cluster-version=VERSION

Substitua:

  • CLUSTER-NAME: o nome do cluster.
  • VERSION: o número da versão do GKE. Selecione uma versão 1.14 ou superior para usar esse recurso.

Para ver a lista completa de sinalizações, consulte a documentação gcloud container clusters create.

Console

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud:

    Acessar o Google Kubernetes Engine

  2. Clique em Criar.

  3. Na seção Padrão, clique em Configurar.

  4. Configure o cluster como quiser.

  5. No painel de navegação, em Cluster, clique em Recursos.

  6. Marque a caixa de seleção Ativar driver de CSI do disco permanente do Compute Engine.

  7. Clique em Criar.

Depois de ativar o driver CSI do disco permanente do Compute Engine, será possível usar o driver nos volumes do Kubernetes usando o nome do provisionador e do driver: pd.csi.storage.gke.io.

Como ativar o driver CSI do disco permanente do Compute Engine em um cluster existente

Para ativar o driver CSI de disco permanente do Compute Engine em clusters Standard existentes, use a ferramenta de linha de comando gcloud ou o Console do Google Cloud.

Para ativar o driver em um cluster existente, conclua as etapas a seguir:

gcloud

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

substitua CLUSTER-NAME pelo nome do cluster atual.

Console

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

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

  3. Em Recursos, ao lado do campo Driver CSI do disco permanente do Compute Engine, clique em Editar driver CSI do Compute Engine.

  4. Marque a caixa de seleção Ativar driver de CSI do Persistent Disk do Compute Engine.

  5. Clique em Save Changes.

Como desativar o driver CSI do disco permanente do Compute Engine

É possível desativar o driver CSI do disco permanente do Compute Engine para clusters padrão usando a ferramenta de linha de comando gcloud ou o Console do Google Cloud.

Para desativar o driver em um cluster Standard existente, siga estas etapas:

gcloud

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

substitua CLUSTER-NAME pelo nome do cluster atual.

Console

  1. Acesse a página do Google Kubernetes Engine no Console do Cloud.

    Acessar o Google Kubernetes Engine

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

  3. Em Recursos, ao lado do campo Driver CSI do disco permanente do Compute Engine, clique em Editar driver CSI do Compute Engine.

  4. Desmarque a caixa de seleção Ativar driver de CSI do disco permanente do Compute Engine.

  5. Clique em Save Changes.

Como usar o driver CSI do disco permanente do Compute Engine para clusters do Linux

As seções a seguir descrevem o processo típico de uso de um volume do Kubernetes compatível com um driver CSI no GKE. Essas seções são específicas para clusters que usam o Linux.

Criar um StorageClass

Depois que você ativa o driver CSI do disco permanente do Compute Engine, o GKE instala automaticamente os seguintes StorageClasses:

  • standard-rwo, usando o disco permanente balanceado
  • premium-rwo, usando o disco permanente SSD

Algumas versões mais antigas do cluster de 1.17 e anteriores podem ter o StorageClass singlewriter-standard ou standard-singlewriter, que usa o disco permanente padrão.

Para clusters do Autopilot, o StorageClass padrão é standard-rwo, que usa o driver CSI de disco permanente do Compute Engine. Para clusters Standard, o StorageClass padrão usa o plug-in de volume gcePersistentDisk na árvore do Kubernetes.

Encontre o nome do StorageClasses instalado executando o seguinte comando:

kubectl get sc

Também é possível instalar um StorageClass diferente que usa o driver CSI de disco permanente do Compute Engine adicionando pd.csi.storage.gke.io no campo do provisionador.

Por exemplo, é possível criar um StorageClass usando o seguinte arquivo chamado pd-example-class.yaml:

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

Qualquer tipo de disco permanente pode ser especificado no parâmetro type (por exemplo, pd-ssd, pd-standard ou pd-balanced).

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

kubectl create -f pd-example-class.yaml

Criar um PersistentVolumeClaim

É possível criar um PersistentVolumeClaim que faz referência ao StorageClass do driver CSI do disco permanente do Compute Engine.

O arquivo a seguir, chamado 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

No StorageClass pré-instalado (standard-rwo), volumeBindingMode é definido como WaitForFirstConsumer. Quando volumeBindingMode for definido como WaitForFirstConsumer, o PersistentVolume não será provisionado até que um pod referenciando PersistentVolumeClaim seja programado. Se, no StorageClass, volumeBindingMode estiver definido como Immediate (ou se estiver omitido), um PersistentVolume baseado em disco permanente será provisionado depois que o PersistentVolumeClaim for criado.

Criar um pod que consuma o volume

Ao usar pods com PersistentVolumes, recomendamos usar um controlador de carga de trabalho (como uma implantação ou StatefulSet). Mesmo que você geralmente não use um pod independente, o exemplo a seguir usa um para simplificar.

O exemplo a seguir consome o volume que você criou na seção anterior:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       - mountPath: /var/lib/www/html
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       claimName: podpvc
       readOnly: false

Como usar o driver CSI do disco permanente do Compute Engine para clusters do Windows

As seções a seguir descrevem o processo típico de uso de um volume do Kubernetes compatível com um driver CSI no GKE. Essas seções são específicas para 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 de nó são 1.18.12-gke.1203, 1.19.6-gke.800 ou posterior.

Criar um StorageClass

A criação de um StorageClass para Windows é muito semelhante ao Linux. Esteja ciente de que o StorageClass instalado por padrão não funcionará no Windows, porque o tipo de sistema de arquivos é diferente. O driver CSI do disco permanente do Compute Engine para Windows requer NTFS como o tipo de sistema de arquivos.

Por exemplo, é possível criar um StorageClass usando o seguinte arquivo chamado pd- windows-class.yaml. Adicione 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

Criar um PersistentVolumeClaim

Depois de criar um StorageClass para Windows, agora é possível criar um PersistentVolumeClaim que faça referência a esse StorageClass:

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

Criar um pod que consuma o volume

O exemplo a seguir consome o volume que você criou na tarefa anterior:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: podpvc-windows
        readOnly: false

Como usar o driver CSI do disco permanente do Compute Engine com tipos de sistema de arquivos não padrão

O tipo padrão de sistema de arquivos para discos permanentes do Compute Engine no GKE é ext4. Também é possível usar o tipo de armazenamento xfs, desde que a imagem de nó seja compatível. Consulte Suporte do driver de armazenamento para ver uma lista de drivers compatíveis por imagem de nó.

No exemplo a seguir, mostramos como usar xfs como o tipo de sistema de arquivos padrão em vez de ext4 com o driver CSI do disco permanente do Compute Engine.

Criar um StorageClass

  1. Salve o seguinte manifesto como um arquivo chamado pd-xfs-class.yaml:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: xfs-class
    provisioner: pd.csi.storage.gke.io
    parameters:
      type: pd-standard
      csi.storage.k8s.io/fstype: xfs
    volumeBindingMode: WaitForFirstConsumer
    
  2. Aplique o manifesto:

    kubectl apply -f pd-xfs-class.yaml
    

Criar um PersistentVolumeClaim

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

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: xfs-pvc
    spec:
      storageClassName: xfs-class
      accessModes:
        - ReadWriteOnce
      resources:
        requests:
          storage: 10Gi
    
  2. Aplique o manifesto:

    kubectl apply -f pd-xfs-pvc.yaml
    

Criar um pod que consuma o volume

  1. Salve 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
        args: ["sleep","3600"]
        volumeMounts:
        - mountPath: /xfs
          name: xfs-volume
      volumes:
      - name: xfs-volume
        persistentVolumeClaim:
          claimName: xfs-pvc
    
  2. Aplique o manifesto:

    kubectl apply -f pd-xfs-pod.yaml
    

Verificar se o volume foi ativado corretamente

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

    kubectl exec -it pd-xfs-pod -- /bin/bash
    
  2. Procure partições xfs:

    df -aTh --type=xfs
    

    A saída será semelhante a:

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

Problemas conhecidos

Devido a uma restrição de 128 caracteres na especificação do ID do nó do CSI e como o GKE gera nomes de instância, a instalação do driver CSI do disco permanente do Compute Engine pode falhar em clusters do GKE novos e existentes, em determinados pools de nós. Para mais informações, veja esse problema do GitHub.

Ele é corrigido nas seguintes versões:

  • 1.16.15-gke.1700 e mais recentes
  • 1.17.9-6300 e posteriores
  • 1.18.6-4801 e posteriores

Se estiver usando um cluster com uma versão anterior, faça upgrade para uma das versões listadas para resolver o problema.

A seguir