Auf dieser Seite wird die Verwendung von StatefulSet-Objekten in Google Kubernetes Engine (GKE) beschrieben. Außerdem erfahren Sie, wie Sie eine zustandsorientierte Anwendung bereitstellen.
StatefulSets
StatefulSets stellen einen Satz Pods mit eindeutigen, dauerhaften Identitäten und stabilen Hostnamen dar, die von GKE unabhängig davon verwaltet werden, wo sie geplant sind. Die Zustandsinformationen und andere stabile Daten für einen StatefulSet-Pod werden in nichtflüchtigen Volumes verwaltet, die jedem Pod im StatefulSet zugeordnet sind. StatefulSet-Pods können jederzeit neu gestartet werden.
StatefulSets funktionieren in GKE und in Kubernetes ähnlich. In diesem Dokument werden alle GKE-spezifischen Aspekte beschrieben. Informationen zur Funktionsweise von StatefulSets finden Sie in der Kubernetes-Dokumentation zu StatefulSets.
Netzwerk für StatefulSets planen
StatefulSets bieten nichtflüchtigen Speicher in Form eines PersistentVolume und einer eindeutigen Netzwerkidentität (Hostname). Die folgende Tabelle enthält die Einschränkungen, die Anwendungsoperatoren bei der Konfiguration eines StatefulSets kennen sollten:
Netzwerkeinschränkungen
Beschreibung
Best Practice
GKE-Services anstelle von festen IP-Adressen
Obwohl Pod-Replikate einen eindeutigen Ordinalindex haben, Replikat-Volumes und die Netzwerkidentität (Hostname) unterstützen, können sich die einem Replikat zugewiesenen IP-Adressen ändern, wenn ein Pod von GKE neu geplant oder entfernt wird.
Zum Beheben von Netzwerkproblemen sollte die Architektur Kubernetes-Service-Ressourcen verwenden. Weitere Informationen finden Sie unter Kubernetes-Services.
Monitorlose Dienste
Bei der Initialisierung wird ein StatefulSet mit einem passenden monitorlosen Dienst gekoppelt.
Prüfen Sie, ob `metadata.name` in Ihrem Service mit dem Feld serviceName in Ihrem StatefulSet übereinstimmt. Dadurch kann jeder Pod in Ihrer Anwendung mit einer eindeutigen, klar definierten Netzwerkadresse angegeben werden. Darüber hinaus bietet der monitorlose Dienst für jedes Replikat in Ihrem StatefulSet einen Multi-IP-Eintrag, der eine vollständige Peer-Erkennung ermöglicht.
Peer-Erkennung
Zustandsorientierte Anwendungen erfordern eine Mindestanzahl (Quorum) von Replikaten, um eine vollständige Verfügbarkeit zu bieten.
Da Pods abstürzen, neu geplant oder entfernt werden können, sollte jedes Replikat in einem StatefulSet das Quorum verlassen und sich wieder verbinden können. Anwendungen, die Peering benötigen, sollten in der Lage sein, andere Peers über monitorlose Services in Kubernetes zu erkennen.
Systemdiagnose auf Grundlage von Bereitschaftsprüfungen und Aktivitätsprüfungen
Ihre Anwendung sollte gegebenenfalls auf geeignete Weise Bereitschafts-, Aktivitäts- und Startprüfungen konfigurieren.
Die Auswahl der Zeitlimits für jede Prüfung hängt von den Anforderungen Ihrer Anwendung ab.
Folgen Sie bei Bereitschaftsprüfungen diesen Best Practices, um Ihre Anwendung so zu konfigurieren, dass sie Bereitschaft signalisiert, wenn sie in der Lage ist, Traffic bereitzustellen:
Aktivitätsprüfungen: Mithilfe von Aktivitätsprüfungen können Sie feststellen, ob ein Container fehlerfrei ist. Beispielsweise kann ein Datenbankreplikat eine Aktivitätsprüfung verwenden, um anzugeben, dass GKE das Replikat neu starten soll, z. B. eine Deadlock-Bedingung.
Bereitschaftsprüfungen: Sie können Bereitschaftsprüfungen verwenden, um dafür zu sorgen, dass ein Replikat vorübergehend keinen Traffic bereitstellt. Wenn Sie beispielsweise ein Datenbankreplikat haben, das eine Sicherung durchführen muss, können Sie mit einer Bereitschaftsprüfung dafür sorgen, dass das Replikat vorübergehend keine Anfragen mehr erhält.
Startprüfung: Sie können Startprüfungen verwenden, um Systemdiagnosen zu verzögern, bis lang andauernde Initialisierungen abgeschlossen sind. Wenn Sie beispielsweise ein Datenbankreplikat haben, können Sie mithilfe einer Startprüfung auf die Initialisierung gespeicherter Daten vom Laufwerk warten.
Informationen zum Bereitstellen von StatefulSets in Ihrem GKE-Cluster und zum Interagieren mit ihnen finden Sie in der Kubernetes-Dokumentation unter StatefulSet-Grundlagen.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-01 (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)"]]
