Questa pagina spiega come attivare il provisioning dinamico dei dischi permanenti a livello di regione e come eseguirne il provisioning manuale in Google Kubernetes Engine (GKE).
Per creare soluzioni end-to-end per applicazioni ad alta disponibilità con dischi permanenti a livello di area geografica, consulta Aumentare la disponibilità delle app stateful con Stateful HA Operator.
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 esigenze 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 area geografica di tipo pd-standard
, imposta l'attributo spec.resources.requests.storage
di PersistentVolumeClaim su un valore 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 esegue la replica dei 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 regionale con
due zone. Una zona corrisponde alla zona in cui è pianificato il pod. L'altra zona viene scelta in modo casuale tra quelle disponibili per il cluster.
Quando utilizzi un cluster a livello di zona, è necessario 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
, il provisioning di PersistentVolume
non viene eseguito 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 regionale 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 regionale che hai appena creato. Oltre agli oggetti descritti in Utilizzo di dischi permanenti preesistenti come PersistentVolume, il PersistentVolume
per un disco permanente a livello di area geografica deve specificare anche un node-affinity
.
Se utilizzi un StorageClass
, deve essere specificato il driver CSI per il disco permanente.
Ecco un esempio di manifest StorageClass
che utilizza dischi permanenti standard e che esegue la replica dei 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 se è impostato sudefault
.
Assegnare un nome ai dischi permanenti
Kubernetes non è in grado di distinguere i dischi permanenti 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 dischi permanenti e Cloud SQL.