Questa pagina spiega come creare e gestire carichi di lavoro stateful all'interno di un cluster Kubernetes isolato da internet di Google Distributed Cloud (GDC). I carichi di lavoro stateful ti consentono di scalare il deployment dell'applicazione con spazio di archiviazione permanente. Lo spazio di archiviazione permanente fornisce alla tua applicazione identità coerenti e nomi host stabili, indipendentemente da dove vengono pianificati i carichi di lavoro.
Questa pagina è rivolta agli sviluppatori del gruppo di operatori di applicazioni, che sono responsabili della creazione dei carichi di lavoro delle applicazioni per la propria organizzazione. Per saperne di più, consulta la documentazione sulle audience per GDC air-gapped.
Prima di iniziare
Per eseguire comandi su un cluster Kubernetes, assicurati di disporre delle seguenti risorse:
Individua il nome del cluster Kubernetes o chiedi all'amministratore della piattaforma qual è il nome del cluster.
Accedi e genera il file kubeconfig per il cluster Kubernetes se non ne hai uno.
Utilizza il percorso kubeconfig del cluster Kubernetes per sostituire
KUBERNETES_CLUSTER_KUBECONFIG
in queste istruzioni.
Per ottenere le autorizzazioni necessarie per creare carichi di lavoro stateful, chiedi all'amministratore IAM dell'organizzazione di concederti il ruolo Amministratore spazio dei nomi (namespace-admin
) nello spazio dei nomi del progetto.
Crea una risorsa StatefulSet
Crea un oggetto StatefulSet
scrivendo un manifest StatefulSet
e
eseguendo kubectl apply
per creare la risorsa. Per fornire un modo stabile ai client di inviare richieste ai pod della risorsa StatefulSet
, devi anche creare un oggetto Service
.
Il comando kubectl apply
utilizza i file manifest per creare, aggiornare ed eliminare
le risorse nel cluster Kubernetes. Si tratta di un metodo dichiarativo di configurazione
degli oggetti. Questo metodo conserva le scritture apportate agli oggetti attivi senza unire
le modifiche nei file di configurazione degli oggetti.
Per creare una risorsa StatefulSet
e Service
, esegui:
kubectl --kubeconfig KUBERNETES_CLUSTER_KUBECONFIG -n NAMESPACE \
apply -f - <<EOF
apiVersion: v1
kind: Service
metadata:
name: SERVICE_NAME
labels:
app: APP_NAME
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: APP_NAME
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: STATEFULSET_NAME
spec:
selector:
matchLabels:
app: APP_LABEL_NAME
serviceName: "SERVICE_NAME"
replicas: NUMBER_OF_REPLICAS
template:
metadata:
labels:
app: APP_LABEL_NAME
spec:
terminationGracePeriodSeconds: 10
containers:
- name: CONTAINER_NAME
image: CONTAINER_IMAGE
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: CONTAINER_STORAGE_VOLUME_PATH
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
EOF
Sostituisci quanto segue:
KUBERNETES_CLUSTER_KUBECONFIG
: il file kubeconfig per il cluster in cui stai eseguendo il deployment dei carichi di lavoro dei container.NAMESPACE
: lo spazio dei nomi del progetto in cui eseguire il deployment dei carichi di lavoro dei container.SERVICE_NAME
: il nome dell'oggettoService
. Assicurati che l'oggettoStatefulSet
imposti l'oggettoService
anche nel suoserviceName
.APP_NAME
: il nome dell'applicazione da eseguire all'interno del deployment.APP_LABEL_NAME
: il selettore di etichette che determina a quali pod appartiene l'oggettoStatefulSet
.STATEFULSET_NAME
: il nome dell'oggettoStatefulSet
.NUMBER_OF_REPLICAS
: il numero di oggettiPod
replicati gestiti dal deployment.CONTAINER_NAME
: il nome del container.CONTAINER_IMAGE
: il nome dell'immagine container. Devi includere il percorso del registro dei container e la versione dell'immagine, ad esempioREGISTRY_PATH/nginx:1.23
.CONTAINER_STORAGE_VOLUME_PATH
: il percorso all'interno del container in cui è montato un volume di archiviazione.
Ad esempio, il seguente oggetto StatefulSet
e l'oggetto Service
corrispondente
creano carichi di lavoro dei container stateful:
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: REGISTRY_PATH/nginx:1.23
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi
In questo esempio:
- Viene creato un oggetto
Service
denominatonginx
, indicato dal campometadata: name
. L'oggettoService
ha come target un'app chiamatanginx
, indicata dalabels.app: nginx
eselector.app: nginx
. L'oggettoService
espone la porta 80 e la denominaweb
. Questo oggettoService
controlla il dominio di rete e indirizza il traffico internet all'applicazione containerizzata di cui è stato eseguito il deployment dall'oggettoStatefulSet
. - Viene creato un
StatefulSet
denominatoweb
con tre oggettiPod
replicati, come impostato dal camporeplicas: 3
. - Il modello
Pod
, impostato dalla sezione.spec.template
, indica che i relativi oggettiPod
sono etichettatiapp: nginx
. - La specifica
Pod
, impostata dalla sezione.template.spec
, indica che i pod diStatefulSet
eseguono un container,nginx
, che esegue l'immaginenginx
alla versione1.23
. - La specifica
Pod
utilizza la porta web aperta dall'oggettoService
. - La sezione
.template.spec.volumeMounts
specifica un campomountPath
, che si chiamawww
.mountPath
è il percorso nel container in cui è montato un volume di archiviazione. StatefulSet
esegue il provisioning di tre oggettiPersistentVolumeClaim
denominatiweb-www-0
,web-www-1
eweb-www-2
, con 1 GB di spazio di archiviazione di cui è stato eseguito il provisioning ciascuno.
Una volta creato, il StatefulSet
garantisce che il numero desiderato di oggetti Pod
sia in esecuzione e disponibile in qualsiasi momento. StatefulSet
sostituisce automaticamente gli oggetti Pod
che non funzionano o vengono rimossi dai nodi e associa nuovi oggetti Pod
alle risorse di archiviazione, alle richieste e ai limiti delle risorse e ad altre configurazioni definite nella specifica Pod
dell'oggetto StatefulSet
.
Richiedere l'archiviazione permanente in una risorsa StatefulSet
L'archiviazione permanente può essere sottoposta a provisioning dinamico in modo che i volumi sottostanti
vengano creati on demand. Le applicazioni possono richiedere l'archiviazione permanente con un oggetto
PersistentVolumeClaim
.
In genere, devi creare oggetti PersistentVolumeClaim
oltre a creare l'oggetto Pod
. Tuttavia, gli oggetti StatefulSet
includono un array volumeClaimTemplates
che genera gli oggetti PersistentVolumeClaim
. Ogni replica StatefulSet
ha il proprio oggetto PersistentVolumeClaim
.
Per saperne di più, consulta Configurare l'archiviazione dei container.