K8s StatefulSet生成

Kubernetes StatefulSet & Headless Service YAML ビルダー

コンパニオン Headless Service、永続ボリュームテンプレート(volumeClaimTemplates)、レプリカ数、podManagementPolicy を備えた本番仕様の Kubernetes StatefulSet マニフェストを生成します。

プリセット
StatefulSet・Service 構成設定
序数 >= partition の Pod のみが先行更新されます (カナリア)
ローリングアップデート中に利用不可を許容する Pod 数
:
:
# ============================================================================
# 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
ステートフルレプリカ数OrderedReady
3 ステートフル Pod

パーティション: 0 | 戦略: RollingUpdate

永続ボリューム要求 (PVC)gp3
50Gi / Pod (1 テンプレート)

永続化ポリシー: Retain | fsGroup:: 999

セキュリティ堅牢度セキュリティ等級 A+
100 / 100 本番適合率

ヘルスチェック: 3/3 有効

100% ブラウザ内リアルタイムマニフェスト生成

サーバーへのデータ送信は一切不要。すべてのStatefulSetマニフェスト、Headless Service定義、PVCテンプレートはブラウザのメモリ内で完全に生成されます。

安定したネットワーク識別子と順序制御

順序付き序数識別子、Headless Serviceによる予測可能な安定DNSレコード、OrderedReady起動制御、volumeClaimTemplatesによる永続化を網羅。

本番CISベンチマーク・マルチフォーマット出力

非rootユーザー実行やケーパビリティ破棄などのセキュリティコンテキスト監査、Helmテンプレート、Kustomize構成、kubectl CLIコマンド出力を完備。

技術リファレンス&アーキテクチャガイド

Kubernetes StatefulSet&Headless Service YAML ビルダー — リファレンスガイド

コンパニオン Headless Service、永続ボリュームテンプレート(volumeClaimTemplates)、レプリカ数、podManagementPolicy を備えた本番仕様の Kubernetes StatefulSet マニフェストを生成します。

主要パラメータ&設定項目

spec.serviceNamestring

各Podのオーディナル(インデックス番号)に対するネットワーク識別子およびDNS SRVルーティングを管轄するHeadless Service(clusterIP: None)の名称。

初期値: 必須
spec.replicasinteger

0からN-1まで昇順に順序立てて作成・管理されるステートフルPodの希望レプリカ数。

初期値: 3
spec.podManagementPolicyenum (OrderedReady | Parallel)

Podの起動・停止順序ポリシー。'OrderedReady' は先行PodのReadyを待って順次作成し、'Parallel' は全Podを並行して作成・削除します。

初期値: OrderedReady
spec.volumeClaimTemplatesarray of objects

各オーディナルPodに対して専用の永続ストレージ(PVC)を動的にプロビジョニングするテンプレート配列。

初期値: 必須
spec.updateStrategyobject

自動ローリングアップデートの構成。カナリアテスト用 'partition' 整数値、または手動更新用の 'OnDelete' を指定します。

初期値: RollingUpdate

プロの活用テクニック&推奨設定

StatefulSet は 'cluster

StatefulSet は 'clusterIP: None' の Headless Service との連携が必須です。CoreDNS は '<pod名>.<サービス名>.<namespace>.svc.cluster.local' 形式の安定した A/AAAA および SRV レコードを自動登録し、マスター・レプリカ構成のDBやRaftクラスタの相互通信を実現します。

'spec.updateStrategy.r

'spec.updateStrategy.rollingUpdate.partition' にレプリカ数 - 1 を指定すると、最大インデックスのPod(例: statefulset-2)のみが先行して新バージョンに更新されます。本番データの整合性とクラスタ安定性を検証した後、partition を段階的に0へ引き下げて全体適用します。

PVC の自動削除抑止仕様とデータ消失防止の仕組みを理解する

StatefulSet の縮小(スケールダウン)や削除時、Kubernetes はデータ安全のため volumeClaimTemplates から作られた PVC を自動削除しません。再スケール時には同じオーディナルの PVC が自動再アタッチされます。Kubernetes 1.27+ では persistentVolumeClaimRetentionPolicy によるライフサイクル制御も可能です。

ZooKeeper

ZooKeeper、Kafka、Cassandra などの分散ステートフル基盤ではクォーラム(過半数の合意)が不可欠です。PDB を設定し 'minAvailable: 2' や 'maxUnavailable: 1' を強制することで、ノードの Drain やクラスタ更新による予期せぬスプリットブレインを防止してください。

よくあるトラブルと解決策

Pod が Pending 状態のまま停止し '0/N nodes available: persistentvolumeclaim unbound' が出力される

ストレージプロビジョナーのステータスを確認し、'kubectl describe pvc <pvc名>' を実行してください。指定された storageClassName がクラスタ内に存在し、アクセスモード(ReadWriteOnce)およびボリューム容量要求が CSI ドライバで動的払い出し可能か検証します。

StatefulSet のローリングアップデートまたはスケールアップが特定Podで停滞する

'OrderedReady' ポリシーでは、先行するPodが readinessProbe に合格して Ready 状態になるまで後続Podの処理が保留されます。'kubectl describe pod <pod名>' でイベントを確認し、ヘルスチェックエンドポイントや初期化スクリプトの異常を修正してください。

Headless Service 経由の Pod 間ピアディスカバリが 'NXDOMAIN' で失敗する

StatefulSet の 'spec.serviceName' がコンパニオン Service の 'metadata.name' と完全一致しているか確認してください。また、Service の spec.clusterIP が 'None' であり、両マニフェストのラベルセレクターが正しく合致しているか検証します。

よくある質問 (FAQ)

Kubernetes Deployment と StatefulSet の根本的な違いは何ですか?▼

Deployment は代替可能でランダムなハッシュ名を持つステートレスな Pod を管理し、共有またはエフェメラルなストレージを使用します。StatefulSet は一意で固定的なインデックス名(app-0, app-1)、厳格な起動・停止順序、Podごとに独立した永続ボリューム、Headless Service による固定 DNS ホスト名を提供します。

なぜ StatefulSet には Headless Service ('clusterIP: None') が必須なのですか?▼

通常の Service は単一の仮想 IP(ClusterIP)を持ち、Ready な Pod へランダムに負荷分散します。しかし、分散データベースなどではプライマリや特定のレプリカノードを直接指定して通信する必要があります。Headless Service は仮想 IP を発行せず、各 Pod の実 IP を直接解決する個別の DNS A レコードを生成します。

StatefulSet をスケールダウンまたは削除すると PVC はどうなりますか?▼

不慮のデータ消失を防ぐため、Kubernetes のデフォルト仕様として PVC は自動削除されずクラスタ内に保持されます。再度スケールアップした際には、同じインデックスを持つ新規 Pod に元の PVC が自動的に再マウントされます。不要になったボリュームは 'kubectl delete pvc' で手動削除する必要があります。

'podManagementPolicy: Parallel' はどのようなユースケースで使用しますか?▼

アプリケーション層自体が独自の分散合意やピア検出機構を持ち、順次起動を必要としないステートフルシステムや、Pod の起動順序を待たずに高速な並列スケール・ローリング更新を実施したい場合に 'Parallel' を採用します。

'updateStrategy.rollingUpdate.partition' パラメータはどのように動作しますか?▼

partition パラメータは更新対象のオーディナル(インデックス)の閾値を指定します。指定値以上のインデックスを持つ Pod のみが更新されます。例えばレプリカ数3で partition: 2 と設定した場合、最後の Pod(app-2)のみが更新され、カナリア検証が可能になります。値を0に更新すると全Podへ順次ローリングされます。

関連するおすすめ開発ツール

すべてのツール →
Nginx Location優先順位テスター & マッチシミュレーター開発ツール

Nginx locationディレクティブのマッチングルール検証ガイド。修飾子優先順位(=、^~、~、~*)のリアルタイムシミュレーション。

ツールを開く→
Cloudflare Headers & Redirects 生成ツール開発ツール

Cloudflare Pagesの _headers および _redirects 構成、セキュリティヘッダーポリシー、エッジリライティングルールの開発者向け構文リファレンス。

ツールを開く→
Vercel.json 設定・アーキテクチャ開発ツール

エッジルーティング、リライト、セキュリティヘッダー、サーバーレス関数、Cron設定を網羅したvercel.jsonの実務開発者向けリファレンス。

ツールを開く→
ESLint Flat Config (eslint.config.mjs) インタラクティブビルダー開発ツール

TypeScript、React、Next.js、Vue、Prettier、カスタムルールに対応した最新のESLint 9+ フラット設定ファイル(eslint.config.mjs / .js)をブラウザ上で安全に生成します。

ツールを開く→
SemVer範囲・バージョン適合性テスター開発ツール

セマンティック バージョニング(SemVer)範囲(キャレット ^、チルダ ~、ハイフン範囲、X-Range、プレリリース)をテストし、パッケージバージョンの適合性をリアルタイムに検証します。

ツールを開く→
Crontab 表現式解析・スケジュール自動生成ツール開発ツール

POSIXおよびVixie cron式の構文解析、バリデーション、次回実行日時の算出を行う開発者向けリファレンス。

ツールを開く→