Odoo連携サービスにおけるPostgresのStatefulSet構成まとめ

8月 27, 2026

—

✅ 前提

項目	内容
用途	Odoo連携サービスのデータストア（連携データ保持用）
DB要件	永続データが必要（再起動・ノード障害時も保持）
高可用性	最初は不要。障害時は手動で再起動でOK（Patroniは後から検討）
重要度	Odoo本体のPaaS（Odoo.sh）がメイン。Postgresは「連携補助」の役割なのでまずはシンプルに。

✅ なぜStatefulSetが必要？

理由	内容
データ永続化	Pod削除後もデータが消えないようにするため（PVCをPodに紐付け）
一意なPod名	`postgres-0` のような固定名が必要（接続先の安定性のため）
永続ボリューム管理	Podごとに独立したストレージを確保（削除してもPVCは残る）
起動順序制御	マスター/レプリカ構成を作るときに重要（今回は不要）

✅ Kubernetes構成（シンプル版）

1️⃣ StatefulSet + PVCでPostgresをデプロイ

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 1
  selector:
    matchLabels:
      app: postgres
  template:
    metadata:
      labels:
        app: postgres
    spec:
      containers:
      - name: postgres
        image: postgres:15
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_USER
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: username
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: postgres-secret
              key: password
        volumeMounts:
        - name: data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: ["ReadWriteOnce"]
      resources:
        requests:
          storage: 10Gi

2️⃣ Headless ServiceでPodへのアクセスを安定化

apiVersion: v1
kind: Service
metadata:
name: postgres
spec:
clusterIP: None # Headless Service
selector:
app: postgres
ports:

port: 5432
name: postgres

Pod名でアクセスできる：

postgres-0.postgres.default.svc.cluster.local

✅ 運用のポイント

項目	内容
障害時の対応	ノード障害でPodが落ちた場合、Kubernetesが他ノードでPod再作成（PVCは再利用）。手動で再起動でOK。
データの復旧	PVCが残るため、再作成されたPodは以前のデータを自動的に利用。
スケール	初期は1Podで十分。レプリカは不要（必要なら後からPatroniで構築）。
バックアップ	`pg_dump`, `pg_basebackup` などで定期バックアップを別途取得する。
監視	Prometheus + Exporterで最低限の監視を入れるのが理想（必要になったら追加）。

✅ 後で追加できる強化ポイント

項目	内容	追加するタイミング
フェイルオーバー自動化	Patroni/Stolon	必要になったとき（案件増・要求増）
データバックアップ自動化	CronJobで`pg_dump`	初期段階からでもOK（推奨）
リソース管理	`resources`制御でCPU/メモリ制限	使用量に応じて調整
モニタリング	Postgres Exporter	監視が必要になったら

✅ なぜこれで良いのか（初期フェーズの結論）

目的	結論
最初から複雑なHA構成にする必要は？	❌ ない。Odoo連携部分は「止まったら再実行」で許容可能。
まずは何を作る？	✅ StatefulSet + 1PodのPostgresでシンプルに開始。
重要なのは？	✅ データの永続化（PVC）を確保し、障害時に手動で再起動できる設計にすること。

✅ まとめ

項目	推奨
Odoo本体	Odoo.sh（PaaS）で提供。
外部連携部分（Odoo Community）	K8sにDeployment（ステートレス）。
外部連携DB（Postgres）	K8sにStatefulSet + PVCで構築。HAは不要（障害時は手動再起動）。
障害対応	手動でPod再起動でOK（Patroni等は不要）。
必要に応じて後から強化	Patroni導入、監視導入、バックアップ自動化。