Como provisionar discos permanentes regionais

Nesta página, explicamos como ativar o provisionamento dinâmico de discos permanentes regionais e como provisioná-los manualmente no Google Kubernetes Engine (GKE).

Para criar soluções completas para aplicativos de alta disponibilidade com discos permanentes regionais, consulte Aumentar a disponibilidade de aplicativos com estado usando o operador de alta disponibilidade com estado.

Discos permanentes regionais

Como acontece com discos permanentes zonais, os discos permanentes regionais podem ser provisionados dinamicamente conforme necessário ou provisionados manualmente com antecedência pelo administrador do cluster, embora o provisionamento dinâmico seja recomendado.

Provisionamento dinâmico

Para ativar o provisionamento dinâmico de discos permanentes regionais, crie um StorageClass com o parâmetro replication-type e especifique restrições de zona em allowedTopologies.

Por exemplo, o seguinte manifesto descreve um StorageClass chamado regionalpd-storageclass que usa discos permanentes padrão e que replica dados para as zonas europe-west1-b e europe-west1-c:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Se estiver usando um cluster regional, não é necessário especificar allowedTopologies. Se você fizer isso, ao criar um pod que consome um PersistentVolumeClaim que usa esse StorageClass, um disco permanente regional será provisionado com duas zonas. Uma zona é mesma zona em que o pod está programado. A outra zona é escolhida aleatoriamente entre as zonas disponíveis para o cluster.

Ao usar um cluster zonal, allowedTopologies precisa ser definido.

Depois que StorageClass for criado, crie um objeto PersistentVolumeClaim usando o campo storageClassName para se referir ao StorageClass. Por exemplo, o seguinte manifesto cria um PersistentVolumeClaim chamado regional-pvc e faz referência ao regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: regional-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 500Gi
  storageClassName: regionalpd-storageclass

Como o StorageClass é configurado com volumeBindingMode: WaitForFirstConsumer, o PersistentVolume não é provisionado até que um pod que use o PersistentVolumeClaim seja criado.

O manifesto a seguir é um exemplo de pod que usa o PersistentVolumeClaim criado anteriormente:

kind: Pod
apiVersion: v1
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: regional-pvc
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Provisionamento manual

Primeiro, crie um disco permanente regional usando o comando gcloud compute disks create. No exemplo a seguir, criamos um disco chamado gce-disk-1 replicado para as zonas europe-west1-b e europe-west1-c:

gcloud compute disks create gce-disk-1 \
   --size 500Gi \
   --region europe-west1 \
   --replica-zones europe-west1-b,europe-west1-c

Em seguida, crie um PersistentVolume que faça referência ao disco permanente regional que você acabou de criar. Além de objetos em Como usar discos permanentes preexistentes como PersistentVolumes, o PersistentVolume de um disco permanente regional também precisa especificar um node-affinity. Se você usar um StorageClass, ele precisa especificar o driver CSI do disco permanente.

Veja um exemplo de um manifesto de StorageClass que usa discos permanentes padrão e que replica dados para as zonas europe-west1-b e europe-west1-c:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: regionalpd-storageclass
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Veja um exemplo de manifesto que cria um PersistentVolume chamado pv-demo e faz referência ao regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  storageClassName: "regionalpd-storageclass"
  capacity:
     storage: 500Gi
  accessModes:
     - ReadWriteOnce
  claimRef:
    namespace: default
    name: pv-claim-demo
  csi:
    driver: pd.csi.storage.gke.io
    volumeHandle: projects/PROJECT_ID/regions/europe-west1/disks/gce-disk-1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
               - europe-west1-b
               - europe-west1-c

Observe o seguinte para o exemplo PersistentVolume:

  • O campo volumeHandle contém detalhes da chamada gcloud compute disks create, incluindo o PROJECT_ID.
  • O campo claimRef.namespace precisa ser especificado mesmo quando estiver definido como default.

Como nomear discos permanentes

No Kubernetes, não há distinção entre discos permanentes regionais e zonais com o mesmo nome. Como solução alternativa, garanta que os discos permanentes tenham nomes exclusivos. Esse problema não ocorre quando você usa discos permanentes provisionados dinamicamente.

A seguir