1. 平台工程视角下的PostgreSQL

把 PostgreSQL 放进 Kubernetes，并不是把 docker run postgres 换成一份 YAML 那么简单。PostgreSQL 是一个有状态、强一致、依赖持久化存储与稳定网络标识的系统；而 Kubernetes 最初是为无状态、可随时替换的工作负载设计的。两者结合时，真正需要平台工程解决的，是“如何让数据库在动态调度、节点漂移、存储解绑、版本升级的环境中，仍然保持数据不丢、身份不乱、故障可恢复”。

本节先建立整体认知：PostgreSQL 在 Kubernetes 上的独特挑战是什么，平台工程能提供什么价值，本课程将沿着怎样的路线推进，以及实验环境如何搭建。

一、PostgreSQL 上 Kubernetes 的四个核心挑战

第一是持久化与调度解耦。Pod 可以被驱逐、重建、迁移，但数据目录不能随 Pod 消失。Kubernetes 用 PV/PVC 抽象存储，用 StorageClass 动态供给卷。问题在于：卷通常绑定在某个可用区或节点上，而 Pod 可能被调度到另一个节点，导致“卷挂不上、Pod 起不来”。平台工程必须处理拓扑约束、卷亲和性与节点池规划。

第二是稳定网络标识。无状态服务用 Service 做负载均衡即可，但 PostgreSQL 主从复制、故障切换、客户端连接都需要知道“谁是主、谁是从”。StatefulSet 提供稳定的 Pod 名称与序号（如 pg-0、pg-1、pg-2），配合 Headless Service 给出稳定 DNS 记录，这是构建数据库集群身份体系的基础。

第三是数据一致性与故障切换。PostgreSQL 原生提供流复制、同步/异步提交、时间线（timeline）等机制，但“谁来判断主库失联、谁来提升从库、如何避免脑裂”并不是 PostgreSQL 自己完成的。这需要 Operator 或外部控制器介入，把数据库语义翻译成 Kubernetes 可执行的动作。

第四是生命周期与运维自动化。备份、恢复、扩缩容、小版本升级、大版本升级、参数调优、监控告警，这些在单机上靠 DBA 手工完成的操作，在 Kubernetes 上必须变成声明式、可重复、可审计的流程。否则平台只是把“手工运维”搬到了 YAML 里。

二、平台工程的核心价值

平台工程不是“帮 DBA 写 YAML”，而是把数据库运维中反复出现的判断与操作，沉淀为可复用的能力。具体体现在三个层面。

抽象层：把“部署一套一主两从、开启同步复制、每天凌晨备份、保留 7 天”这样的意图，表达为一个自定义资源（CR）。用户不需要理解 StatefulSet 的 podManagementPolicy，也不需要手写 pg_hba.conf，只需要声明期望状态。

自动化层：控制器持续对比期望状态与实际状态。当主库 Pod 所在节点失联，控制器依据预设策略判断是否提升从库、如何重建旧主、如何更新 Service 端点。这个过程不依赖人工介入，但必须可观测、可干预。

治理层：多团队共享集群时，需要配额、命名空间隔离、镜像来源限制、备份策略强制、版本基线。平台工程把这些约束前置到准入与模板中，避免“每个团队一套野生数据库”。

三、课程整体路线

本课程共 30 章，按“认知—搭建—运行—治理—进阶”推进。前几章建立平台工程视角与实验环境；随后进入 PostgreSQL 在 Kubernetes 上的核心对象：StatefulSet、Headless Service、PVC、ConfigMap 与 Secret 的协作方式；再进入 Operator 模式，理解控制器如何管理主从拓扑与故障切换；之后覆盖备份恢复、监控告警、连接池、参数调优、版本升级、安全加固与多租户治理；最后以故障演练与平台化复盘收束。

路线设计遵循一个原则：每一章都尽量落到可操作的对象、可观察的指标、可判断的结果。例如讲存储，不只看 PVC 是否 Bound，还要看卷所在节点与 Pod 调度节点是否一致；讲复制，不只看 pg_stat_replication 是否有记录，还要看 write_lag、flush_lag、replay_lag 的量级。

四、实验环境搭建

实验环境建议使用一台具备 8 核 CPU、16 GB 内存、80 GB 磁盘的 Linux 主机，或等价的云主机。工具链包括：Docker 或 containerd、kubectl、kind 或 minikube、Helm、psql。为贴近真实场景，推荐用 kind 创建多节点集群，便于观察 Pod 跨节点调度与卷拓扑。

# 示例：用 kind 创建三节点集群（控制面 1 + 工作节点 2）
cat <<'EOF' > kind-pg.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
- role: worker
  labels:
    node-pool: pg
- role: worker
  labels:
    node-pool: pg
EOF

kind create cluster --name pg-lab --config kind-pg.yaml

# 验证节点与存储类
kubectl get nodes -o wide
kubectl get storageclass

kind 默认提供 standard StorageClass，基于 local-path-provisioner，适合实验但不具备跨节点迁移能力。若希望观察卷拓扑约束，可额外安装 Longhorn 或使用云厂商 CSI 驱动。实验阶段先以 local-path 跑通流程，再替换存储类验证差异。

命名空间与基础对象建议一次性建立：

kubectl create namespace pg-lab
kubectl config set-context --current --namespace=pg-lab

# 示例：创建数据库凭据 Secret
kubectl create secret generic pg-credentials \
  --from-literal=POSTGRES_USER=appuser \
  --from-literal=POSTGRES_PASSWORD='S3cure-Lab-Only' \
  --from-literal=POSTGRES_DB=appdb

验证环境是否就绪，可以按以下清单逐项确认：节点 Ready、StorageClass 可用、默认命名空间可创建 Pod、kubectl 能读取 Secret、psql 客户端版本不低于目标 PostgreSQL 主版本。若使用 kind，还需确认 kubectl port-forward 可用，以便从宿主机连接集群内数据库。