Como provisionar discos permanentes regionais e volumes de alta disponibilidade do Hyperdisk Balanced

Nesta página, explicamos como ativar o provisionamento dinâmico de volumes de alta disponibilidade balanceados do Hyperdisk e discos permanentes regionais e como provisioná-los manualmente no Google Kubernetes Engine (GKE). Para compatibilidades de tipo de máquina, consulte Limitações do disco regional e Suporte a séries de máquinas para o Hyperdisk. Em geral, use volumes de alta disponibilidade do Hyperdisk Balanced para séries de máquinas de terceira geração ou mais recentes e discos permanentes regionais em séries de máquinas de segunda geração ou mais antigas. Para mais informações sobre a geração de séries de máquinas, consulte Terminologia do Compute Engine.

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. Esse recurso não é compatível com volumes do Hyperdisk Balanced High Availability.

Alta disponibilidade do hiperdisco equilibrada

Este exemplo mostra como os volumes do Hyperdisk Balanced High Availability podem ser provisionados dinamicamente conforme necessário ou manualmente com antecedência pelo administrador do cluster.

Provisionamento dinâmico

  1. Salve o manifesto em um arquivo chamado 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:

    • ZONE1, ZONE2: as zonas da região em que o volume provisionado dinamicamente será replicado.

  2. Crie o StorageClass

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

  3. Salve o seguinte manifesto PersistentVolumeClaim em um arquivo chamado pvc-example.yaml:

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

    Substitua:

    • ACCESS_MODE: o Hyperdisk Balanced High Availability é compatível com ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Para conferir as diferenças e os casos de uso de cada modo de acesso, consulte Modos de acesso de volume permanente.
    • Se você escolher usar ReadWriteMany, também precisará adicionar volumeMode: Block ao PersistentVolumeClaim. Essa configuração evita a corrupção de dados que pode acontecer quando vários pods gravam no armazenamento simultaneamente. A configuração volumeMode: Block expõe o disco como um dispositivo de transferência por blocos bruto que ignora o gerenciamento do sistema de arquivos pelo Kubernetes. Confira o seguinte 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 ao StorageClass criado anteriormente:

    kubectl apply -f pvc-example.yaml

Provisionamento manual

  1. Siga a documentação do Compute Engine para criar um volume do Hyperdisk Balanced High Availability manualmente.

  2. Salve o seguinte manifesto PersistentVolume em um arquivo chamado pv-example.yaml. O manifesto faz referência ao volume do Hyperdisk Balanced High Availability que você 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:

    • PROJECT_ID: o ID do projeto do volume que você criou.
    • REGION: a região do disco que você criou. Consulte a documentação do Compute Engine para saber a disponibilidade regional mais recente.
    • ZONE1, ZONE2: as zonas dentro da região em que o volume criado é replicado.
    • ACCESS_MODE: o Hyperdisk Balanced High Availability é compatível com ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Para conferir as diferenças e os casos de uso de cada modo de acesso, consulte Modos de acesso de volume permanente.

  3. Crie o volume permanente que faz referência ao volume do Hyperdisk Balanced High Availability criado anteriormente:

    kubectl apply -f pv-example.yaml

  4. Salve o seguinte manifesto PersistentVolumeClaim em um arquivo chamado pvc-example.yaml:

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

    Substitua:

    • ACCESS_MODE: o Hyperdisk Balanced High Availability é compatível com ReadWriteOnce, ReadWriteMany e ReadWriteOncePod. Precisa ser o mesmo modo de acesso especificado no PersistentVolume da etapa anterior. Para conferir as diferenças e os casos de uso de cada modo de acesso, consulte Modos de acesso de volume permanente.

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

    kubectl apply -f pvc-example.yaml

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

Para usar um volume no modo de bloco, especifique volumeBlock em vez de volumeMounts no pod de consumo. Um exemplo de pod que usa o PersistenVolumeClaim apresentado anteriormente seria assim:

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 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. Para usar discos permanentes regionais do tipo pd-standard, defina o atributo spec.resources.requests.storage do PersistentVolumeClaim como um mínimo de 200 GiB. Se o caso de uso exigir um volume menor, use pd-balanced ou pd-ssd.

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
  # 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 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
      # 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

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
  # 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

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:
  # 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

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