Questa pagina spiega come abilitare il provisioning dinamico dei volumi Hyperdisk bilanciati ad alta affidabilità e dei dischi permanenti regionali e come eseguirne il provisioning manuale in Google Kubernetes Engine (GKE). Per le compatibilità dei tipo di macchina, consulta Limitazioni per il disco regionale e Supporto delle serie di macchine per Hyperdisk. In genere, devi utilizzare i volumi Hyperdisk bilanciato ad alta affidabilità per le serie di macchine di terza generazione o successive e i dischi permanenti a livello di regione nelle serie di macchine di seconda generazione o precedenti. Per ulteriori informazioni sulla generazione delle serie di macchine, consulta la terminologia di Compute Engine.
Per creare soluzioni end-to-end per applicazioni ad alta disponibilità con dischi permanenti regionali, consulta Aumentare la disponibilità delle app stateful con l'operatore HA stateful. Questa funzionalità non supporta i volumi Hyperdisk bilanciati ad alta affidabilità.
Hyperdisk bilanciato con disponibilità elevata
Questo esempio mostra come i volumi Hyperdisk bilanciato ad alta affidabilità possono essere sottoposti a provisioning dinamico in base alle necessità o a provisioning manuale in anticipo da parte dell'amministratore del cluster.
Provisioning dinamico
Salva il seguente manifest in un file denominato
balanced-ha-storage.yaml
.apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: balanced-ha-storage provisioner: pd.csi.storage.gke.io volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true parameters: type: hyperdisk-balanced-high-availability provisioned-throughput-on-create: "250Mi" provisioned-iops-on-create: "7000" allowedTopologies: - matchLabelExpressions: - key: topology.gke.io/zone values: - ZONE1 - ZONE2
Sostituisci quanto segue:
ZONE1
,ZONE2
: le zone all'interno della regione in cui verrà replicato il volume di cui è stato eseguito il provisioning dinamico.
Crea StorageClass:
kubectl create -f hdb-ha-example-class.yaml
Salva il seguente manifest PersistentVolumeClaim in un file denominato
pvc-example.yaml
:kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ACCESS_MODE storageClassName: balanced-ha-storage resources: requests: storage: 20Gi
Sostituisci quanto segue:
ACCESS_MODE
: Hyperdisk bilanciato ad alta affidabilità supportaReadWriteOnce
,ReadWriteMany
eReadWriteOncePod
. Per le differenze e i casi d'uso di ogni modalità di accesso, consulta Modalità di accesso ai volumi persistenti.- Se scegli di utilizzare
ReadWriteMany
, devi anche aggiungerevolumeMode: Block
aPersistentVolumeClaim
, come nel seguente esempio:
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ReadWriteMany volumeMode: Block storageClassName: balanced-ha-storage resources: requests: storage: 20Gi ```
Applica l'oggetto PersistentVolumeClaim che fa riferimento alla classe di archiviazione che hai creato in precedenza:
kubectl apply -f pvc-example.yaml
Provisioning manuale
Segui la documentazione di Compute Engine per creare manualmente un volume Hyperdisk bilanciato ad alta affidabilità.
Salva il seguente manifest PersistentVolume in un file denominato
pv-example.yaml
. Il manifest fa riferimento al volume Hyperdisk Balanced High Availability che hai appena creato:apiVersion: v1 kind: PersistentVolume metadata: name: pv-demo spec: capacity: storage: 500Gi accessModes: - ACCESS_MODE claimRef: namespace: default name: podpvc csi: driver: pd.csi.storage.gke.io volumeHandle: projects/PROJECT_ID/regions/REGION/disks/gce-disk-1 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: topology.gke.io/zone operator: In values: - ZONE1 - ZONE2
Sostituisci quanto segue:
PROJECT_ID
: l'ID progetto del volume che hai creato.REGION
: la regione del disco che hai creato. Per informazioni aggiornate sulla disponibilità regionale, consulta la documentazione di Compute Engine.ZONE1
,ZONE2
: le zone all'interno della regione in cui viene replicato il volume che hai creato.ACCESS_MODE
: Hyperdisk bilanciato ad alta affidabilità supportaReadWriteOnce
,ReadWriteMany
eReadWriteOncePod
. Per le differenze e i casi d'uso di ogni modalità di accesso, consulta Modalità di accesso ai volumi persistenti.
Crea il Persistent Volume che fa riferimento al volume Hyperdisk bilanciato ad alta affidabilità che hai creato in precedenza:
kubectl apply -f pv-example.yaml
Salva il seguente manifest PersistentVolumeClaim in un file denominato
pvc-example.yaml
:kind: PersistentVolumeClaim apiVersion: v1 metadata: name: podpvc spec: accessModes: - ACCESS_MODE storageClassName: balanced-ha-storage resources: requests: storage: 20Gi
Sostituisci quanto segue:
ACCESS_MODE
: Hyperdisk bilanciato ad alta affidabilità supportaReadWriteOnce
,ReadWriteMany
eReadWriteOncePod
. Deve essere la stessa modalità di accesso specificata in PersistentVolume del passaggio precedente. Per le differenze e i casi d'uso di ogni modalità di accesso, consulta Modalità di accesso ai volumi persistenti.
Applica PersistentVolumeClaim che fa riferimento al PersistentVolume che hai creato in precedenza:
kubectl apply -f pvc-example.yaml
Utilizzo di un volume multi-writer in modalità a blocchi
Per utilizzare un volume in modalità blocco, devi specificare volumeBlock
anziché volumeMounts
nel pod di consumo. Un pod di esempio che utilizza PersistenVolumeClaim
introdotto in precedenza dovrebbe avere il seguente aspetto:
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
volumeDevices:
- mountPath: /dev/my-device
name: mypvc
volumes:
- name: mypvc
persistentVolumeClaim:
claimName: podpvc
readOnly: false
Dischi permanenti a livello di regione
Come per i dischi permanenti a livello di zona, i dischi permanenti a livello di regione possono essere sottoposti a provisioning dinamico in base alle necessità o a provisioning manuale in anticipo da parte dell'amministratore del cluster, anche se è consigliato il provisioning dinamico.
Per utilizzare i dischi permanenti a livello di regione di tipo pd-standard
, imposta l'attributo spec.resources.requests.storage
di PersistentVolumeClaim su un minimo di 200 GiB. Se il tuo caso d'uso richiede un volume inferiore, valuta la possibilità di utilizzare pd-balanced
o pd-ssd
.
Provisioning dinamico
Per abilitare il provisioning dinamico dei dischi permanenti a livello di regione, crea un
StorageClass
con il parametro replication-type
e specifica i vincoli di zona in allowedTopologies
.
Ad esempio, il seguente manifest descrive un StorageClass
denominato
regionalpd-storageclass
che utilizza dischi permanenti standard e che replica i dati nelle zone 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 utilizzi un cluster regionale, puoi lasciare allowedTopologies
non specificato. Se
lo fai, quando crei un pod che utilizza un PersistentVolumeClaim
che utilizza questo StorageClass
, viene eseguito il provisioning di un disco permanente a livello di regione con
due zone. Una zona è la stessa in cui è pianificato il pod. L'altra zona viene scelta in modo casuale tra le zone disponibili per il cluster.
Quando utilizzi un cluster di zona, devi impostare allowedTopologies
.
Una volta creato StorageClass
, crea un oggetto PersistentVolumeClaim
utilizzando il campo storageClassName
per fare riferimento a StorageClass
. Ad esempio, il seguente manifest crea un PersistentVolumeClaim
denominato regional-pvc
e fa riferimento a regionalpd-storageclass
:
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: regional-pvc
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 500Gi
storageClassName: regionalpd-storageclass
Poiché StorageClass
è configurato con
volumeBindingMode: WaitForFirstConsumer
, PersistentVolume
non viene
provisionato finché non viene creato un pod che utilizza PersistentVolumeClaim
.
Il seguente manifest è un pod di esempio che utilizza il PersistentVolumeClaim
creato in precedenza:
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
Provisioning manuale
Innanzitutto, crea un disco permanente a livello di regione utilizzando il
comando gcloud compute disks create
. L'esempio seguente crea un disco denominato gce-disk-1
replicato nelle zone 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
Puoi quindi creare un PersistentVolume
che fa riferimento al disco permanente a livello di regione che hai appena creato. Oltre agli oggetti in
Utilizzo di dischi permanenti preesistenti come PersistentVolume,
PersistentVolume
per un disco permanente a livello di regione deve specificare anche un
node-affinity
.
Se utilizzi un StorageClass
, deve specificare il driver CSI per il disco permanente.
Ecco un esempio di manifest StorageClass
che utilizza dischi permanenti standard e che replica i dati nelle zone 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
Ecco un esempio di manifest che crea un PersistentVolume
denominato
pv-demo
e fa riferimento a 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
Tieni presente quanto segue per l'esempio PersistentVolume
:
- Il campo
volumeHandle
contiene i dettagli della chiamatagcloud compute disks create
, incluso il tuoPROJECT_ID
. - Il campo
claimRef.namespace
deve essere specificato anche quando è impostato sudefault
.
Denominazione dei dischi permanenti
Kubernetes non può distinguere tra Persistent Disk zonali e regionali con lo stesso nome. Come soluzione alternativa, assicurati che i dischi permanenti abbiano nomi univoci. Questo problema non si verifica quando si utilizzano dischi permanenti con provisioning dinamico.
Passaggi successivi
- Segui un tutorial per scoprire di più sul deployment di WordPress su GKE con Persistent Disk e Cloud SQL.