K8s StatefulSet Generator

Kubernetes StatefulSet & Headless Service YAML Builder

Erstellen Sie produktionsreife Kubernetes StatefulSet-Manifeste mit Headless Service, persistenten volumeClaimTemplates, Replikaten und podManagementPolicy.

Voreinstellungen
StatefulSet- & Service-Konfiguration
Pods mit Ordinal >= Partition werden zuerst aktualisiert (Canary)
Anzahl der während des Rollouts nicht verfügbaren Pods
:
:
# ============================================================================
# Kubernetes StatefulSet: postgres-ha
# Generated via ToolsAA - 100% Client-Side Stateful Workload Builder
# Headless Network Domain: postgres-ha-headless.database.svc.cluster.local
# Pod Stable FQDN: postgres-ha-[0..2].postgres-ha-headless.database.svc.cluster.local
# ============================================================================
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres-ha
  namespace: database
  labels:
    app: "postgres-ha"
    tier: "database"
    app.kubernetes.io/managed-by: toolsaa
  annotations:
    cluster.toolsaa.com/role: "primary-replica"
spec:
  serviceName: "postgres-ha-headless"
  replicas: 3
  podManagementPolicy: OrderedReady
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      partition: 0
      maxUnavailable: 1
  revisionHistoryLimit: 10
  minReadySeconds: 10
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Retain
    whenScaled: Retain
  selector:
    matchLabels:
      app: "postgres-ha"
  template:
    metadata:
      labels:
        app: "postgres-ha"
        tier: "database"
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9187"
    spec:
      serviceAccountName: postgres-sa
      terminationGracePeriodSeconds: 120
      securityContext:
        runAsNonRoot: true
        runAsUser: 999
        runAsGroup: 999
        fsGroup: 999
        fsGroupChangePolicy: "OnRootMismatch"
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values: ["postgres-ha"]
              topologyKey: "kubernetes.io/hostname"
      nodeSelector:
        node-role.kubernetes.io/database: "true"
      containers:
      - name: postgres
        image: postgres:16-alpine
        imagePullPolicy: IfNotPresent
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
        ports:
        - name: postgresql
          containerPort: 5432
          protocol: TCP
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        - name: POSTGRES_DB
          value: "app_production"
        - name: POSTGRES_USER
          value: "postgres"
        - name: PGDATA
          value: "/var/lib/postgresql/data/pgdata"
        resources:
          requests:
            cpu: "500m"
            memory: "1Gi"
          limits:
            cpu: "2000m"
            memory: "4Gi"
        volumeMounts:
        - name: pgdata
          mountPath: "/var/lib/postgresql/data"
        livenessProbe:
          exec:
            command:
            - "pg_isready"
            - "-U"
            - "postgres"
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
          successThreshold: 1
          failureThreshold: 3
        readinessProbe:
          exec:
            command:
            - "pg_isready"
            - "-U"
            - "postgres"
            - "-h"
            - "127.0.0.1"
          initialDelaySeconds: 15
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 3
        startupProbe:
          exec:
            command:
            - "pg_isready"
            - "-U"
            - "postgres"
          initialDelaySeconds: 10
          periodSeconds: 5
          timeoutSeconds: 3
          successThreshold: 1
          failureThreshold: 15
  volumeClaimTemplates:
  - metadata:
      name: pgdata
      labels:
        app: "postgres-ha"
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: "gp3"
      resources:
        requests:
          storage: 50Gi
Stateful-ReplikateOrderedReady
3 Stateful Pods

Partition: 0 | Strategie: RollingUpdate

PersistentVolumeClaimsgp3
50Gi / Pod (1 Vorlagen)

Aufbewahrung: Retain | fsGroup:: 999

SicherheitseinstufungSicherheitsstufe A+
100 / 100 Produktionsbereitschaft

Probes: 3/3 aktiv

100% Lokale Client-Side Manifest-Generierung

Keine Serverübertragung oder Datenspeicherung. Sämtliche Kubernetes-StatefulSet-Manifeste, Headless-Services und PVC-Vorlagen werden direkt im Browser-Speicher kompiliert.

Geordneter Lifecycle & Headless-DNS-Identität

Gewährleistet eindeutige Ordinal-Identitäten, vorhersagbare DNS-Adressierung via Headless Service, OrderedReady-Lifecycle und persistente VolumeClaimTemplates.

CIS-Hardening & Multi-Format-Export

Erzwingt non-root SecurityContexts, verwirft Linux-Capabilities und liefert produktionsreife Ausgaben für Helm-Templates, Kustomize und kubectl CLI-Befehle.

Technische Referenz & Architektur-Leitfaden

Kubernetes StatefulSet & Headless Service YAML Builder — Referenz-Leitfaden

Erstellen Sie produktionsreife Kubernetes StatefulSet-Manifeste mit Headless Service, persistenten volumeClaimTemplates, Replikaten und podManagementPolicy.

Wichtige Parameter & Steuerelemente

spec.serviceNamestring

Name des zugehörigen Headless Service (clusterIP: None), der die Netzwerkidentität und das DNS-SRV-Routing für die Pod-Ordinalzahlen steuert.

Standard: Erforderlich
spec.replicasinteger

Gewünschte Anzahl der Stateful-Pod-Instanzen (0 bis N-1), die sequenziell in aufsteigender Reihenfolge erstellt werden.

Standard: 3
spec.podManagementPolicyenum (OrderedReady | Parallel)

Lebenszyklus-Reihenfolge. 'OrderedReady' startet Pods nacheinander und wartet auf Readiness; 'Parallel' erstellt oder löscht alle Pods gleichzeitig.

Standard: OrderedReady
spec.volumeClaimTemplatesarray of objects

PersistentVolumeClaim-Vorlagen zur dynamischen Bereitstellung dedizierter persistenter Datenträger für jeden Pod-Index.

Standard: Erforderlich
spec.updateStrategyobject

Automatisierte RollingUpdate-Strategie mit optionalem Canary-'partition'-Parameter oder manuellem 'OnDelete'.

Standard: RollingUpdate

Profi-Tipps & Best Practices

Ein StatefulSet benötigt einen

Ein StatefulSet benötigt einen Headless Service mit 'clusterIP: None'. Kubernetes CoreDNS registriert automatisch stabile A/AAAA- und SRV-Einträge im Format '<pod-name>.<service-name>.<namespace>.svc.cluster.local', unverzichtbar für Master-Replica-Datenbanken und Raft-Cluster.

Setzen Sie

Setzen Sie 'spec.updateStrategy.rollingUpdate.partition' auf Replikate - 1, um neue Container-Images isoliert auf dem Pod mit dem höchsten Index (z. B. statefulset-2) als Canary zu testen, bevor das Update auf den gesamten Cluster ausgerollt wird.

Kubernetes löscht PVCs aus

Kubernetes löscht PVCs aus volumeClaimTemplates beim Herunterskalieren oder Löschen des StatefulSets standardmäßig nicht. Neu gestartete Pods binden dieselben Volumes erneut an. Ab K8s 1.27 ermöglicht 'persistentVolumeClaimRetentionPolicy' eine feingranulare Steuerung.

Zustandsbehaftete Systeme wie

Zustandsbehaftete Systeme wie ZooKeeper, Kafka oder Cassandra benötigen ein stabiles Quorum. Definieren Sie stets ein PodDisruptionBudget mit 'minAvailable: 2' oder 'maxUnavailable: 1', um Node-Drains und Cluster-Wartungen abzusichern.

Häufige Fallstricke & Fehlerbehebung

Pod verharrt im Pending-Status mit 'persistentvolumeclaim unbound'

Prüfen Sie 'kubectl describe pvc <claim-name>'. Stellen Sie sicher, dass die angegebene storageClassName im Cluster existiert, der dynamische CSI-Provisioner aktiv ist und die geforderten accessModes (z. B. ReadWriteOnce) unterstützt werden.

Rolling Update oder Skalierung stoppt bei einem bestimmten Ordinal-Pod

Bei 'OrderedReady' stoppt Kubernetes Updates, wenn der vorherige Pod die readinessProbe nicht besteht. Untersuchen Sie Pod-Ereignisse mit 'kubectl describe pod <name>' und beheben Sie Fehler im Health-Check-Endpunkt der Anwendung.

Peer-Discovery zwischen Pods schlägt mit 'NXDOMAIN' über den Headless-Hostnamen fehl

Prüfen Sie, ob 'spec.serviceName' im StatefulSet exakt mit 'metadata.name' des Headless Service übereinstimmt, ob der Service 'clusterIP: None' aufweist und beide Ressourcen identische Selector-Labels verwenden.

Häufig gestellte Fragen (FAQ)

Was ist der fundamentale Unterschied zwischen einem Kubernetes Deployment und einem StatefulSet?▼

Ein Deployment verwaltet austauschbare, zustandslose Pods mit zufälligen Hash-Namen und gemeinsamem oder flüchtigem Speicher. Ein StatefulSet bietet stabile, vorhersagbare Ordinal-Namen (app-0, app-1), geordnete Start- und Stopp-Reihenfolgen, dedizierten persistenten Speicher pro Pod und feste DNS-Namen über einen Headless Service.

Warum benötigt ein StatefulSet zwingend einen Headless Service ('clusterIP: None')?▼

Standard-Services bündeln Pods hinter einer einzelnen virtuellen ClusterIP und verteilen Anfragen per Load-Balancing. Verteilte Datenbanken müssen jedoch spezifische Instanzen (z. B. Primärknoten oder Replikate) direkt adressieren. Ein Headless Service umgeht die virtuelle IP und stellt direkte DNS-A-Records für jede einzelne Pod-IP bereit.

Was geschieht mit PersistentVolumeClaims (PVCs), wenn ein StatefulSet herunterskaliert oder gelöscht wird?▼

Zum Schutz vor versehentlichem Datenverlust löscht Kubernetes die erstellten PVCs nicht automatisch. Wird das StatefulSet später wieder hochskaliert, binden die neuen Pods automatisch die bestehenden persistenten Datenträger wieder ein. Nicht mehr benötigte PVCs müssen manuell gelöscht werden.

Wann sollte 'podManagementPolicy: Parallel' anstelle von 'OrderedReady' verwendet werden?▼

Nutzen Sie 'Parallel' für zustandsbehaftete Anwendungen, die ihre Cluster-Erkennung und Konsensbildung eigenständig auf Anwendungsebene steuern und keine sequenzielle Initialisierung benötigen, oder wenn schnelle parallele Rollouts und Skalierungen erforderlich sind.

Wie funktioniert der Parameter 'updateStrategy.rollingUpdate.partition'?▼

Der Partition-Parameter definiert einen Ordinal-Schwellenwert. Es werden nur Pods aktualisiert, deren Index größer oder gleich dem Partitionswert ist. Wenn Sie partition auf Replikate minus 1 setzen, erhält nur der letzte Pod das neue Image als Canary-Test. Das Absenken auf 0 rollt die Aktualisierung vollständig aus.

Verwandte Werkzeuge & Dienstprogramme

Alle Werkzeuge →