Aprovisionamento de discos persistentes regionais e volumes de alta disponibilidade equilibrados do Hyperdisk

Esta página explica como ativar o aprovisionamento dinâmico de volumes de alta disponibilidade equilibrados do Hyperdisk e discos persistentes regionais e como aprovisioná-los manualmente no Google Kubernetes Engine (GKE). Para ver as compatibilidades de tipos de máquinas, consulte os artigos Limitações do disco regional e Suporte de séries de máquinas para o Hyperdisk. Geralmente, deve usar volumes Hyperdisk Balanced de alta disponibilidade para séries de máquinas de 3.ª geração ou mais recentes e discos persistentes regionais em séries de máquinas de 2.ª geração ou mais antigas. Para mais informações sobre a geração de séries de máquinas, consulte o artigo Terminologia do Compute Engine.

Para criar soluções completas para aplicações de alta disponibilidade com discos persistentes regionais, consulte o artigo Aumente a disponibilidade de apps com estado com o operador de HA com estado. Esta funcionalidade não suporta volumes de alta disponibilidade equilibrados do Hyperdisk.

Hiperdisco equilibrado de alta disponibilidade

Este exemplo mostra como os volumes de alta disponibilidade equilibrados do Hyperdisk podem ser aprovisionados dinamicamente conforme necessário ou aprovisionados manualmente com antecedência pelo administrador do cluster.

Aprovisionamento dinâmico

  1. Guarde o seguinte manifesto num ficheiro com o nome balanced-ha-storage.yaml.

    apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: balanced-ha-storage
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
# Allow volume expansion.
allowVolumeExpansion: true
parameters:
  type: hyperdisk-balanced-high-availability
  # Provisioned throughput in MiB/s.
  provisioned-throughput-on-create: "250Mi"
  # Provisioned IOPS (input/output operations per second).
  provisioned-iops-on-create: "7000"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - ZONE1
    - ZONE2

    Substitua o seguinte:

    • ZONE1, ZONE2: as zonas na região onde o volume aprovisionado dinamicamente vai ser replicado.

  2. Crie a StorageClass:

    kubectl create -f hdb-ha-example-class.yaml

  3. Guarde o seguinte manifesto PersistentVolumeClaim num ficheiro com o nome pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ACCESS_MODE
  storageClassName: balanced-ha-storage
  resources:
    requests:
      storage: 20Gi

    Substitua o seguinte:

    • ACCESS_MODE: o Hyperdisk Balanced High Availability suporta ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Para ver as diferenças e os exemplos de utilização de cada modo de acesso, consulte Modos de acesso a volumes persistentes.
    • Se optar por usar ReadWriteMany, também tem de adicionar volumeMode: Block ao PersistentVolumeClaim. Esta definição evita a danificação de dados que pode ocorrer quando vários pods escrevem no armazenamento em simultâneo. A definição volumeMode: Block expõe o disco como um dispositivo de blocos não processados que ignora a gestão do sistema de ficheiros pelo Kubernetes. Segue-se um exemplo:
      kind: PersistentVolumeClaim
  apiVersion: v1
  metadata:
    name: podpvc
  spec:
    accessModes:
    - ReadWriteMany
    volumeMode: Block
    storageClassName: balanced-ha-storage
    resources:
      requests:
        storage: 20Gi
  ```

  4. Aplique o PersistentVolumeClaim que faz referência à StorageClass que criou anteriormente:

    kubectl apply -f pvc-example.yaml

Aprovisionamento manual

  1. Siga a documentação do Compute Engine para criar manualmente um volume de alta disponibilidade equilibrado do Hyperdisk.

  2. Guarde o seguinte manifesto PersistentVolume num ficheiro com o nome pv-example.yaml. O manifesto faz referência ao volume de alta disponibilidade equilibrado do Hyperdisk que acabou de criar:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  capacity:
    storage: 500Gi
  accessModes:
    - ACCESS_MODE
  # ClaimRef links this PersistentVolume to a PersistentVolumeClaim.
  claimRef:
    namespace: default
    name: podpvc
  csi:
    driver: pd.csi.storage.gke.io
    # The unique identifier of the Compute Engine disk resource that backs this volume.
    volumeHandle: projects/PROJECT_ID/regions/REGION/disks/gce-disk-1
  # Node affinity to ensure the Pod is scheduled in a zone where the volume is replicated.
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
            - ZONE1
            - ZONE2

    Substitua o seguinte:

    • PROJECT_ID: o ID do projeto do volume que criou.
    • REGION: a região do disco que criou. Consulte a documentação do Compute Engine para ver a disponibilidade regional mais recente.
    • ZONE1, ZONE2: as zonas na região onde o volume que criou é replicado.
    • ACCESS_MODE: o Hyperdisk Balanced High Availability suporta ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Para ver as diferenças e os exemplos de utilização de cada modo de acesso, consulte Modos de acesso a volumes persistentes.

  3. Crie o volume persistente que faz referência ao volume de alta disponibilidade equilibrado do Hyperdisk que criou anteriormente:

    kubectl apply -f pv-example.yaml

  4. Guarde o seguinte manifesto PersistentVolumeClaim num ficheiro com o nome pvc-example.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ACCESS_MODE
  storageClassName: balanced-ha-storage
  resources:
    requests:
      storage: 20Gi

    Substitua o seguinte:

    • ACCESS_MODE: o Hyperdisk Balanced High Availability suporta ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Tem de ser o mesmo modo de acesso especificado no PersistentVolume do passo anterior. Para ver as diferenças e os exemplos de utilização de cada modo de acesso, consulte Modos de acesso a volumes persistentes.

  5. Aplique o PersistentVolumeClaim que faz referência ao PersistentVolume que criou anteriormente:

    kubectl apply -f pvc-example.yaml

Consumir um volume de vários escritores no modo de blocos

Para usar um volume no modo de bloqueio, tem de especificar volumeBlock em vez de volumeMounts no agrupamento de consumo. Um exemplo de um Pod que usa o PersistenVolumeClaim introduzido anteriormente deve ter o seguinte aspeto:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-server-deployment
  labels:
    app: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        # Use volumeDevices instead of volumeMounts to consume the volume as a raw block device.
        volumeDevices:
        # The "mountPath" field specifies the path where the block device is accessible in the container.
        - mountPath: /dev/my-device
          name: mypvc
      volumes:
      - name: mypvc
        persistentVolumeClaim:
          claimName: podpvc
          readOnly: false

Discos persistentes regionais

Tal como acontece com os discos persistentes zonais, os discos persistentes regionais podem ser aprovisionados dinamicamente conforme necessário ou aprovisionados manualmente com antecedência pelo administrador do cluster, embora o aprovisionamento dinâmico seja recomendado. Para usar discos persistentes regionais do tipo pd-standard, defina o atributo spec.resources.requests.storage do PersistentVolumeClaim para um mínimo de 200 GiB. Se o seu exemplo de utilização exigir um volume mais pequeno, considere usar pd-balanced ou pd-ssd.

Aprovisionamento dinâmico

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

Por exemplo, o manifesto seguinte descreve um StorageClass denominado regionalpd-storageclass que usa discos persistentes 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
  # Specifies that the disk should be a regional persistent disk.
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
# Constrains which zones the regional persistent disk can be provisioned in.
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Se usar um cluster regional, pode deixar allowedTopologies não especificado. Se o fizer, quando criar um Pod que consuma um PersistentVolumeClaim que use este StorageClass, é aprovisionado um disco persistente regional com duas zonas. Uma zona é igual à zona em que o Pod está agendado. A outra zona é escolhida aleatoriamente entre as zonas disponíveis para o cluster.

Quando usar um cluster zonal, allowedTopologies tem de ser definido.

Depois de criar o StorageClass, crie um objeto PersistentVolumeClaim usando o campo storageClassName para fazer referência ao StorageClass. Por exemplo, o manifesto seguinte cria um PersistentVolumeClaim com o nome 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

Uma vez que o StorageClass está configurado com volumeBindingMode: WaitForFirstConsumer, o PersistentVolume não é aprovisionado até ser criado um pod que use o PersistentVolumeClaim.

O manifesto seguinte é um exemplo de um Pod que usa o PersistentVolumeClaim criado anteriormente:

kind: Pod
apiVersion: v1
metadata:
  name: task-pv-pod
spec:
  volumes:
    - name: task-pv-storage
      # This Pod uses the PVC that's associated with the
      # "regionalpd-storageclass" StorageClass.
      persistentVolumeClaim:
        claimName: regional-pvc
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      # The volume is mounted into the container at the "/usr/share/nginx/html" path.
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

Aprovisionamento manual

Primeiro, crie um disco persistente regional com o comando gcloud compute disks create. O exemplo seguinte cria um disco denominado 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, pode criar um PersistentVolume que faça referência ao disco persistente regional que acabou de criar. Além dos objetos em Usar discos persistentes preexistentes como volumes persistentes, o PersistentVolume para um disco persistente regional também deve especificar um node-affinity. Se usar um StorageClass, deve especificar o controlador CSI do disco persistente.

Segue-se um exemplo de um StorageClassmanifesto que usa discos persistentes 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
  # Specifies that the disk should be a regional persistent disk.
  replication-type: regional-pd
volumeBindingMode: WaitForFirstConsumer
# Constrains which zones the regional persistent disk can be provisioned in.
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - europe-west1-b
    - europe-west1-c

Segue-se um exemplo de um manifesto que cria um PersistentVolume denominado pv-demo e faz referência ao regionalpd-storageclass:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-demo
spec:
  # The StorageClass that specifies regional replication.
  storageClassName: "regionalpd-storageclass"
  capacity:
     storage: 500Gi
  accessModes:
     - ReadWriteOnce
  claimRef:
    namespace: default
    name: pv-claim-demo
  csi:
    driver: pd.csi.storage.gke.io
    # The unique identifier for the pre-existing regional disk.
    volumeHandle: projects/PROJECT_ID/regions/europe-west1/disks/gce-disk-1
  # Ensures that Pods are scheduled in zones where the disk is replicated.
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
          - key: topology.gke.io/zone
            operator: In
            values:
               - europe-west1-b
               - europe-west1-c

Tenha em atenção o seguinte para o exemplo PersistentVolume:

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

Atribuir nomes a discos persistentes

O Kubernetes não consegue distinguir entre discos persistentes zonais e regionais com o mesmo nome. Como solução alternativa, certifique-se de que os discos persistentes têm nomes exclusivos. Este problema não ocorre quando usa discos persistentes aprovisionados dinamicamente.

O que se segue?