运行有状态应用

有状态应用（数据库、消息队列）通常需要稳定的网络身份与持久存储。

关键要求

• 稳定身份：Pod 名称可预测
• 持久存储：数据不随 Pod 重建丢失
• 有序启动/停止：避免副本同时重启

常见组合

• StatefulSet + PVC
• Headless Service 提供稳定 DNS
• 定期备份与恢复流程

实践建议

• 先跑单实例，再扩到多实例
• 做好 readinessProbe，避免流量打到未就绪副本

实操要点

• 先做快速盘点：kubectl get nodes、kubectl get pods -A、kubectl get events -A。
• 对比“期望状态”和“实际状态”，kubectl describe 往往能解释漂移或失败原因。
• 名称、Label、Selector 要一致，避免 Service 或控制器找不到 Pod。

快速检查清单

• 资源定义与业务意图一致。
• Namespace、权限、镜像与环境匹配。
• 上线前具备健康探针与可观测日志。

数据与身份的稳定性

有状态应用需要稳定身份与稳定存储。有状态应用 通过持久卷、稳定 DNS 与有序生命周期提供这种稳定性，目标是在自动调度与数据安全之间取得平衡。

复制拓扑与一致性

复制系统需要明确一致性模型。常见的是主从或多副本仲裁。Kubernetes 只负责调度与生命周期，不负责共识。你需要理解数据库的主从切换与客户端发现方式。

存储规划与隔离

每个副本应独立 PVC，除非应用明确支持共享卷。规划容量时要考虑增长空间，并通过反亲和性将副本分散到不同节点，降低单点故障影响。

备份与恢复习惯

持久卷不等于备份。建议结合快照与逻辑备份，并定期演练恢复。对于复制系统，恢复顺序会影响主从角色，要在文档中明确步骤。

升级与故障处理

有状态升级更慢，需要分批推进。准备好 readiness 探针，避免误判可用性。节点故障时卷重新挂载可能耗时，需监控挂载状态并考虑更长恢复窗口。

可观测与调优

关注复制延迟、磁盘延时与使用率。资源限制过紧会导致抖动，requests 要合理留出余量。数据库场景下 IO 延迟往往比 CPU 更关键。

主从路由与客户端策略

写流量应指向主节点，读流量可通过 Service 分发到从节点。需要直连时使用稳定 DNS 名称，并在客户端配置明确的角色路由。

维护与自动化

定期进行压缩、清理与一致性校验，选择低峰窗口执行。使用 Operator 或自动化任务管理备份、升级与故障恢复，降低人工操作风险。

kubectl get pods -n demo
kubectl get pvc -n demo
kubectl describe pod db-0 -n demo

运维清单

检查反亲和、PDB、备份任务是否到位。确认每个副本都有独立卷，并演练故障切换流程。稳定性来自配置与习惯的共同作用。

收个尾：有状态应用最大的成本是“恢复时间”

有状态应用的问题，很多时候不是能不能跑，而是出事后能不能在可接受的时间内恢复。

所以建议你至少把这三件事落地：

• PVC 规划清楚（每个副本独立卷，别共享）
• 备份不是口号，要做过恢复演练
• 升级按批次来，读写路由先确认，再推进

参考链接

• 有状态应用教程
• StatefulSet