Gli StatefulSet rappresentano un insieme di pod con identità univoche e permanenti e
nomi host stabili che GKE gestisce indipendentemente dalla posizione in cui sono
pianificati. Le informazioni sullo stato e altri dati resilienti per qualsiasi pod StatefulSet vengono mantenuti nei volumi persistenti associati a ogni pod nello StatefulSet. I pod StatefulSet possono essere riavviati in qualsiasi momento.
StatefulSet funziona in modo simile in GKE e in Kubernetes. Questo
documento descrive eventuali considerazioni specifiche di GKE. Per scoprire
come funzionano gli StatefulSet, consulta la
documentazione di Kubernetes sugli StatefulSet.
Pianificare il networking per StatefulSet
Gli StatefulSet forniscono spazio di archiviazione permanente sotto forma di PersistentVolume e un'identità di rete univoca (nome host). La tabella seguente include le avvertenze di cui
gli operatori delle applicazioni devono essere a conoscenza quando configurano un StatefulSet:
Avviso relativo al networking
Descrizione
Best practice
Servizi GKE anziché indirizzi IP fissi
Sebbene le repliche
dei pod abbiano un indice ordinale univoco, supportino i volumi per replica e
l'identità di rete (nome host), gli indirizzi IP assegnati a una replica
possono cambiare se GKE riprogramma o espelle un pod.
Per mitigare i problemi di networking, l'architettura deve utilizzare le risorse Service Kubernetes. Per saperne di più, consulta Tipi di servizi Kubernetes.
Servizi headless
Una volta inizializzato, uno StatefulSet viene accoppiato a un servizio headless corrispondente.
Assicurati che `metadata.name` nel
tuo servizio corrisponda al campo serviceName nel tuo StatefulSet. In questo modo, ogni pod dell'applicazione può essere indirizzato a un indirizzo di rete univoco e ben definito. Inoltre, il servizio headless fornisce un record multi-IP per
ogni replica nello StatefulSet, consentendo l'individuazione completa dei peer.
Rilevamento peer
Le applicazioni con stato richiedono un numero minimo (quorum) di
repliche per funzionare con piena disponibilità.
Poiché i pod possono arrestarsi in modo anomalo, essere
ripianificati o rimossi, ogni replica in uno StatefulSet deve essere in grado di abbandonare
e rientrare nel quorum. Le applicazioni che richiedono il peering devono avere la
capacità di rilevare altri peer tramite i servizi headless in Kubernetes.
Controllo di integrità basato su probe di idoneità e probe di attività
La tua applicazione deve avere
probe di idoneità, attività e avvio configurati correttamente, ove applicabile.
La selezione dei timeout per ogni probe dipende dai requisiti della tua
applicazione.
Per i probe di idoneità, segui queste best practice per configurare
l'applicazione in modo che contrassegni l'idoneità quando è pronta a gestire il traffico:
Probe di attività: puoi utilizzare i probe di attività per segnalare se un
container è integro. Ad esempio, una replica del database può utilizzare un probe di attività per
indicare che GKE deve riavviare la replica, ad esempio una condizione di deadlock
Probe di idoneità:puoi utilizzare i probe di idoneità per rimuovere temporaneamente una replica dalla gestione del traffico. Ad esempio, se hai una replica del database
che deve eseguire un backup, puoi utilizzare un probe di idoneità per
interrompere temporaneamente la ricezione delle richieste.
Probe di avvio:puoi utilizzare i probe di avvio per ritardare i controlli di integrità finché non vengono completate le inizializzazioni a esecuzione prolungata. Ad esempio, se hai una replica del database, puoi utilizzare un probe di avvio per attendere l'inizializzazione dei dati archiviati dal disco.
Per scoprire come eseguire il deployment di StatefulSet nel cluster GKE e interagire con loro, consulta la documentazione di Kubernetes sulle nozioni di base di StatefulSet.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-07-22 UTC."],[],[],null,["# About StatefulSets in GKE\n\n[Autopilot](/kubernetes-engine/docs/concepts/autopilot-overview) [Standard](/kubernetes-engine/docs/concepts/choose-cluster-mode)\n\n*** ** * ** ***\n\nThis page describes the use of *StatefulSet* objects in\nGoogle Kubernetes Engine (GKE). You can also learn how to\n[Deploy a stateful application](/kubernetes-engine/docs/how-to/stateful-apps).\n\nAbout StatefulSets\n------------------\n\nStatefulSets represent a set of Pods with unique, persistent identities, and\nstable hostnames that GKE maintains regardless of where they are\nscheduled. The state information and other resilient data for any given\nStatefulSet Pod is maintained in [persistent\nvolumes](/kubernetes-engine/docs/concepts/persistent-volumes) associated with\neach Pod in the StatefulSet. StatefulSet Pods can be restarted at any time.\n\nFor [stateless applications](/kubernetes-engine/docs/how-to/deploying-workloads-overview#stateless_applications), use\n[Deployments](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/).\n\nStatefulSets function similarly in GKE and in Kubernetes. This\ndocument describes any GKE-specific considerations. To learn\nhow StatefulSets work, see the\n[Kubernetes documentation about StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/).\n\n### Plan networking for StatefulSets\n\nStatefulSets provide persistent storage in the form of a PersistentVolume and a\nunique network identity (hostname). The following table includes the caveats that\napplication operators should be aware of when configuring a StatefulSet:\n\nTo read more about probes, see [Configure Liveness, Readiness, and Startup Probes](https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-readiness-probes).\n\n\nWork with StatefulSets\n----------------------\n\nTo learn how to deploy StatefulSets in your GKE cluster and\ninteract with them, see the Kubernetes documentation about\n[StatefulSet basics](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/).\n\nWhat's next\n-----------\n\n- [Learn how to deploy a stateful application](/kubernetes-engine/docs/how-to/stateful-apps)\n- [Learn how to update StatefulSets using rolling updates](https://kubernetes.io/docs/tutorials/stateful-application/basic-stateful-set/#rolling-update)\n- [Learn more about deploying workloads in GKE](/kubernetes-engine/docs/how-to/deploying-workloads-overview)\n- [Read more about StatefulSets in the Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/)\n- [Take a tutorial about upgrading a cluster running a stateful workload](/kubernetes-engine/docs/tutorials/upgrading-stateful-workload)"]]