在Kubernetes上进行云原生分布式数据库的垂直规格变更，本质上是通过声明式API，让数据库工作负载（Pod）的资源配置（CPU/内存）在无需重启或最小化影响的情况下被动态更新。
下图清晰地展示了这一流程的全貌：
flowchart TDA[用户提交变更声明<br>（如修改Deployment YAML）] --> B{K8s API Server接收};B --> C[控制器检测到期望状态变化];C --> D[调度器驱逐旧Pod并<br>为新Pod选择节点];D --> E[在目标节点创建新Pod<br>（含新资源规格）];subgraph F [关键环节：存储卷动态扩容]E --> G[Pod引用PVC请求更多存储];G --> H[关联的StorageClass<br>调用CSI插件];H --> I[底层云存储服务<br>（如AWS EBS）实际扩容];I --> J[节点挂载扩容后文件系统];endF --> K[新Pod进入Running状态<br>并接替服务];K --> L[控制器终止旧Pod<br>完成变更];
上图展示了K8s协调各组件、驱动规格变更的完整闭环。下面我们来拆解其中几个关键环节的细节。
🔧 K8s在流程中的核心作用
-
接收与处理变更声明
当用户修改YAML文件中的resources.requests/limits并提交时，API Server是变更的入口。Controller Manager中的控制器（如Deployment Controller）会持续监听，发现期望状态与实际状态（Pod的资源配置）的差异，随即驱动系统向新状态收敛。 -
调度与驱逐Pod
Scheduler会基于新Pod的资源请求，为其选择一个有足够资源的节点。如果新旧Pod在同一节点且资源不足，或为平衡负载，K8s会触发驱逐，优雅终止旧Pod（发送SIGTERM信号，等待应用自行清理）。 -
存储卷的动态扩容
这是数据库垂直扩缩容中最关键且特殊的一环，主要依赖CSI机制实现：- Pod通过PersistentVolumeClaim声明所需存储。
- 当修改PVC的
storage请求后，PVC控制器会检测到这一变更。 - 控制器通过CSI接口，调用底层云存储服务（如AWS EBS、GCP Persistent Disk）的API，真正扩大磁盘容量。
- 节点上的kubelet与CSI Node Driver协作，完成文件系统的扩展（例如对
ext4或xfs文件系统执行resize2fs操作）。
💡 关键注意事项与实践建议
- 选择正确的更新策略：对于数据库这类有状态应用，务必使用
RollingUpdate（滚动更新） 策略而非Recreate。这可以确保在旧Pod完全终止前，新Pod已就绪，是实现“在线变更、服务不中断”的关键。 - 理解存储扩容的限制：动态扩容通常要求底层StorageClass的
allowVolumeExpansion字段为true，且不是所有存储类型都支持（例如某些本地卷）。此外，文件系统的扩容操作通常只在Pod所在的节点上发生一次。 - 监控与就绪检查：在数据库Pod的模板中，务必定义完善的
readinessProbe（就绪探针） 。这样K8s能准确判断新Pod何时真正准备好接收流量，避免在升级过程中将请求导向尚未完全初始化的Pod，导致请求失败。 - 资源限制的设定：
resources.limits设置不当可能导致Pod被OOM Killer杀死。建议数据库这类重要应用的requests和limits设为相同值，以保证服务质量。
🔄 进阶方案：自动化与混合扩缩容
垂直扩缩容虽直接，但存在单机资源上限。生产环境常采用更弹性的混合策略：
- HPA：基于CPU/内存等指标，自动增减Pod副本数，应对流量波动。适合无状态或计算层可水平扩展的数据库（如TiDB的TiDB-Server组件）。
- VPA：可自动分析Pod历史资源使用情况，建议或自动调整
requests/limits。但注意，VPA在调整时通常也会重建Pod。
你可以将HPA与VPA结合：HPA负责应对突发流量，进行快速水平伸缩；VPA负责根据长期趋势，周期性地、更平缓地优化单个Pod的资源规格，实现成本与性能的平衡。