In questa pagina viene spiegato come abilitare il provisioning dinamico delle impostazioni permanenti a livello di regione dischi e come eseguirne manualmente il provisioning in Google Kubernetes Engine (GKE).
Per creare soluzioni end-to-end per applicazioni ad alta disponibilità con dei dischi permanenti a livello di regione, consulta l'articolo Aumentare la disponibilità delle app stateful con l'operatore stateful ad alta disponibilità.
Dischi permanenti a livello di regione
Come per i dischi permanenti a livello di zona, i dischi permanenti a livello di regione possono essere in base alle esigenze o manualmente in anticipo dal cluster ma è consigliato il provisioning dinamico.
Provisioning dinamico
Per abilitare il provisioning dinamico dei dischi permanenti a livello di regione, crea un'istanza
StorageClass
con il parametro replication-type
e specifica la zona
vincoli in allowedTopologies
.
Ad esempio, il seguente file manifest descrive un elemento StorageClass
denominato
regionalpd-storageclass
che utilizza lo standard
e che replica i dati nei dischi permanenti europe-west1-b
europe-west1-c
zone:
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 a livello di regione, 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
tra due zone. Una zona è uguale alla zona in cui è pianificato il pod. La
un'altra zona viene scelta in modo casuale tra quelle disponibili per il cluster.
Se utilizzi un cluster di zona, è necessario impostare allowedTopologies
.
Dopo aver creato StorageClass
, crea un PersistentVolumeClaim
utilizzando il campo storageClassName
per fare riferimento a StorageClass
. Per
Ad esempio, il seguente manifest crea un PersistentVolumeClaim
denominato
regional-pvc
e fa riferimento ai 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 è
eseguito fino a quando non viene creato un pod utilizzando PersistentVolumeClaim
.
Il seguente manifest è un pod di esempio che utilizza lo stato creato in precedenza
PersistentVolumeClaim
:
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
gcloud compute disks create
. L'esempio seguente crea un disco denominato gce-disk-1
replicata 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
Potrai quindi creare un PersistentVolume
che faccia riferimento alla regione
un disco permanente appena creato. Oltre agli oggetti in
Usando dischi permanenti preesistenti come volumi permanenti,
il PersistentVolume
per un disco permanente a livello di regione deve specificare anche un
node-affinity
.
Se utilizzi un'istruzione StorageClass
, dovrebbe essere specificato il driver CSI del disco permanente.
Di seguito è riportato un esempio di manifest StorageClass
che utilizza i valori permanenti standard
i dischi permanenti e che replica i dati nei pod europe-west1-b
e europe-west1-c
zone:
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 file manifest di esempio che crea un elemento PersistentVolume
denominato
pv-demo
e fa riferimento ai 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 dettagli digcloud compute disks create
chiamata, inclusoPROJECT_ID
. - Il campo
claimRef.namespace
deve essere specificato anche se impostato sudefault
.
Denominazione dei dischi permanenti
Kubernetes non è in grado di distinguere tra dischi permanenti a livello di zona e di regione con lo stesso nome. Come soluzione alternativa, assicurati che i dischi permanenti abbiano nomi univoci. Questo problema non si verifica quando utilizzi i dischi permanenti.
Passaggi successivi
- Segui un tutorial per saperne di più Deployment di WordPress su GKE con dischi permanenti e Cloud SQL.