Instalar manualmente um driver CSI

Nesta página, explicamos como instalar um driver de armazenamento da interface de armazenamento do contêiner (CSI) em clusters padrão do Google Kubernetes Engine (GKE). Esta página não se aplica aos clusters do Autopilot do GKE, que usam automaticamente o driver CSI do disco permanente do Compute Engine.

Se você estiver usando o driver CSI do disco permanente do Compute Engine no cluster padrão, recomendamos implantar o driver automaticamente para reduzir sua sobrecarga de gerenciamento.

Visão geral

A CSI é uma API aberta padrão que permite ao Kubernetes expor sistemas de armazenamento arbitrários a cargas de trabalho conteinerizadas. Os volumes do Kubernetes são gerenciados por drivers de armazenamento específicos do fornecedor, que foram compilados em binários do Kubernetes historicamente. Anteriormente, não era possível usar um driver de armazenamento que não estava incluído no Kubernetes. A instalação de um driver CSI adiciona compatibilidade com um sistema de armazenamento que não é compatível nativamente com o Kubernetes. Além disso, o CSI permite o uso de recursos de armazenamento modernos, como snapshots e redimensionamento.

Como instalar o driver CSI de um fornecedor

Outros fornecedores de armazenamento desenvolvem os próprios drivers CSI e são responsáveis por fornecer instruções de instalação. Em casos simples, a instalação envolve apenas a implantação de manifestos nos clusters. Veja a lista de drivers CSI na documentação do CSI.

Como verificar a instalação de um driver

Depois de instalar um driver CSI, é possível verificar a instalação executando um dos seguintes comandos, dependendo da versão do GKE do cluster:

1.14+

kubectl get csinodes \
-o jsonpath='{range .items[*]} {.metadata.name}{": "} {range .spec.drivers[*]} {.name}{"\n"} {end}{end}'

1.13.x

kubectl get nodes \
-o jsonpath='{.items[*].metadata.annotations.csi\.volume\.kubernetes\.io\/nodeid}'

Como usar um driver CSI

Para usar um driver CSI:

  1. Crie um StorageClass do Kubernetes que faça referência ao driver no campo provisioner, se um StorageClass não for criado para você como parte da instalação do driver. Alguns drivers CSI implantam um StorageClass quando você os instala.

  2. Para provisionar armazenamento, é possível:

Considerações para StorageClasses apoiadas por um driver CSI

Ao criar um StorageClass, considere o seguinte:

  • A documentação do driver CSI precisa incluir os parâmetros específicos do driver que você provisiona ao StorageClass, incluindo o nome do provisionador.
  • Você precisa nomear o StorageClass de acordo com as propriedades dele, em vez do nome do driver ou appliance específico por trás dele. Nomear o StorageClass de acordo com as propriedades dele permite criar um StorageClasses com o mesmo nome em vários clusters e ambientes e permite que os aplicativos recebam armazenamento com as mesmas propriedades em vários clusters.

Exemplo: StorageClass de referência em um StatefulSet

O exemplo de modelos a seguir mostra como definir um driver CSI em um StorageClass e, em seguida, como referenciar o StorageClass em uma carga de trabalho StatefulSet. O exemplo pressupõe que o driver já foi instalado no cluster.

Veja a seguir um StorageClass simples chamado premium-rwo que usa um driver CSI fictício, csi.example.com, como seu provisionador:

# fast-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: premium-rwo
provisioner: csi.example.com # CSI driver
parameters: # You provide vendor-specific parameters to this specification
  type: example-parameter # Be sure to follow the vendor's instructions
  datastore: my-datastore
reclaimPolicy: Retain
allowVolumeExpansion: true

Você faz referência ao StorageClass na especificação volumeClaimTemplates de um StatefulSet.

Quando você se referir a um StorageClass na especificação volumeClaimTemplates de um StatefulSet, o Kubernetes fornecerá armazenamento estável usando PersistentVolumes. O Kubernetes chama o provisionador definido no StorageClass para criar um novo volume de armazenamento. Nesse caso, o Kubernetes chama o provedor fictício csi.example.com, que chama a API do provedor, para criar um volume. Depois que o volume é provisionado, o Kubernetes cria automaticamente um PersistentVolume para representar o armazenamento.

Veja um StatefulSet simples que faz referência ao StorageClass:

# statefulset.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # This is the specification in which you reference the StorageClass
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 1Gi
      storageClassName: premium-rwo # This field references the existing StorageClass

A seguir