2. Kubernetes 核心概念回顾:Pod、Deployment、StatefulSet、Service、ConfigMap、Secret
在深入数据库迁移场景之前,必须牢固掌握 Kubernetes 的六大核心原语。这些原语构成了数据库工作负载在容器平台上运行、暴露、配置与持久化的基础。以下逐一回顾其定义、职责与在数据库迁移中的典型角色。
2.1 Pod:最小的调度与运行单元
Pod 是 Kubernetes 中可创建和部署的最小计算单元。一个 Pod 封装一个或多个容器(通常为一个主容器加若干 Sidecar 辅助容器),共享网络栈、存储卷和生命周期。
- 数据库场景:每个数据库实例(如 MySQL、PostgreSQL、MongoDB)通常运行在独立的 Pod 中,以保证资源隔离与故障边界。
- 迁移角色:迁移工具(如 pg_dump、mydumper)也以 Job 或临时 Pod 形式运行,完成数据导出/导入任务。
- 关键属性:Pod IP 是动态的,不能直接作为稳定访问端点。
实践要点:数据库 Pod 应设置资源请求(requests)与限制(limits),避免因节点资源争抢导致 OOMKill 或性能抖动。
2.2 Deployment:无状态工作负载的声明式管理
Deployment 负责管理无状态应用的副本集(ReplicaSet),提供滚动更新、回滚、扩缩容能力。它不保证 Pod 的唯一标识和存储持久性。
| 特性 | Deployment | 数据库迁移适用性 |
|---|---|---|
| Pod 名称 | 随机后缀,每次更新变化 | 不适合需要固定标识的数据库主节点 |
| 存储 | 不内置持久卷模板 | 需手动挂载 PVC,滚动更新可能造成数据不一致 |
| 更新策略 | 滚动更新(默认) | 数据库迁移中仅用于无状态迁移代理或 Sidecar |
| 典型用途 | Web 服务器、API 网关 | 迁移监控面板、数据校验服务 |
迁移陷阱:不要用 Deployment 管理有状态数据库主实例。滚动更新会导致所有 Pod 同时重建,造成数据丢失或脑裂风险。
2.3 StatefulSet:有状态工作负载的基石
StatefulSet 专为有状态应用设计,为每个 Pod 提供稳定的网络标识(ordinal 索引)和独立的持久化存储。Pod 的创建、删除、扩缩容严格按序执行。
- 稳定网络标识:Pod 名称格式为
<statefulset-name>-<ordinal>,如mysql-0、mysql-1。DNS 记录mysql-0.mysql-headless.namespace.svc.cluster.local可被直接解析。 - 独立持久卷:通过
volumeClaimTemplates自动为每个 Pod 创建独立的 PVC,Pod 重建后仍挂载同一卷。 - 有序操作:缩容时从最大 ordinal 开始删除;更新时按逆序逐个进行。
数据库迁移核心价值:StatefulSet 是 Kubernetes 上运行数据库集群(主从复制、分片集群)的标准方式。迁移过程中,源端和目标端数据库都应使用 StatefulSet 部署,以保证数据持久性和拓扑一致性。
2.4 Service:稳定的网络访问抽象
Service 为一组 Pod 提供稳定的虚拟 IP(ClusterIP)和 DNS 名称,实现负载均衡与服务发现。对于数据库迁移,Service 是客户端访问数据库实例的唯一入口。
| Service 类型 | 访问范围 | 数据库迁移用途 |
|---|---|---|
| ClusterIP | 集群内部 | 数据库主从内部通信、迁移工具连接 |
| NodePort | 集群外部(节点 IP + 端口) | 临时调试、跨集群迁移数据中转 |
| LoadBalancer | 外部负载均衡器 | 生产环境数据库读写分离入口 |
| Headless(无 ClusterIP) | DNS 直连 Pod IP | StatefulSet 有状态服务发现,数据库主从拓扑感知 |
迁移最佳实践:数据库主实例使用 Headless Service 暴露,客户端通过
mysql-0.mysql-headless.namespace.svc.cluster.local:3306 直接连接主节点,避免 ClusterIP 负载均衡导致写入分散。
2.5 ConfigMap 与 Secret:配置与敏感信息管理
ConfigMap 用于存储非敏感配置数据(如数据库连接池大小、日志级别),Secret 用于存储敏感信息(如密码、TLS 证书、API 密钥)。两者都可以通过环境变量或卷挂载方式注入到 Pod 中。
- ConfigMap 示例:存储
max_connections、shared_buffers等数据库参数。 - Secret 示例:存储
MYSQL_ROOT_PASSWORD、PGPASSWORD、TLS 证书。 - 迁移场景:源端数据库连接串、目标端认证凭据、迁移工具配置参数均通过 ConfigMap/Secret 注入,避免硬编码。
# ConfigMap 示例:MySQL 迁移配置
apiVersion: v1
kind: ConfigMap
metadata:
name: mysql-migration-config
data:
max_connections: "500"
innodb_buffer_pool_size: "2G"
migration_batch_size: "10000"
---
# Secret 示例:数据库凭据
apiVersion: v1
kind: Secret
metadata:
name: db-credentials
type: Opaque
stringData:
source_dsn: "user:pass@tcp(source-host:3306)/dbname"
target_dsn: "user:pass@tcp(target-host:3306)/dbname"
安全提醒:Secret 默认仅做 Base64 编码,并非加密。生产环境应启用
encryption-at-rest 并配合 RBAC 限制 Secret 访问权限。迁移过程中避免将 Secret 明文输出到日志。
2.6 六大原语在数据库迁移中的协作关系
一次典型的 Kubernetes 数据库迁移流程中,上述原语按以下方式协作:
- StatefulSet 部署源端和目标端数据库实例,保证持久化存储与稳定标识。
- Headless Service 暴露数据库 Pod,客户端通过 DNS 直连主节点。
- ConfigMap 存储迁移参数(批量大小、超时时间、并发线程数)。
- Secret 存储源端/目标端数据库连接凭据与 TLS 证书。
- Job 或临时 Pod(基于 Pod 模板)运行迁移工具,通过 Service DNS 连接数据库。
- Deployment 可选地运行迁移监控面板或数据校验服务,无状态且可水平扩展。
回顾要点:StatefulSet + Headless Service + 独立 PVC 是数据库在 Kubernetes 上运行的“铁三角”。ConfigMap 和 Secret 负责配置与安全,Deployment 仅用于辅助组件。理解这六者的职责边界,是后续设计迁移接口契约的前提。