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 部署,以保证数据持久性和拓扑一致性。
StatefulSet vs Deployment 架构对比 Deployment(无状态) Pod-A-7x9k2 IP: 10.1.0.5 Pod-A-3m1n8 IP: 10.1.0.9 Pod-A-8p2q5 IP: 10.1.0.12 Pod-A-1f4d0 IP: 10.1.0.15 Pod 名称随机,IP 动态,无持久卷绑定 滚动更新时全部重建,标识丢失 StatefulSet(有状态) mysql-0 PVC: data-mysql-0 mysql-1 PVC: data-mysql-1 mysql-2 PVC: data-mysql-2 mysql-3 PVC: data-mysql-3 Pod 名称固定(ordinal 索引),PVC 独立持久化 重建后仍挂载原卷,标识不变

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 明文输出到日志。
ConfigMap & Secret 注入 Pod 的两种方式 方式一:环境变量注入 ConfigMap max_connections=500 Secret source_dsn=... Pod 容器 环境变量:MAX_CONNECTIONS=500, SOURCE_DSN=... 方式二:卷挂载注入 ConfigMap my.cnf 配置文件 Secret tls.crt, tls.key Pod 容器 挂载路径:/etc/mysql/conf.d/my.cnf, /etc/certs/

2.6 六大原语在数据库迁移中的协作关系

一次典型的 Kubernetes 数据库迁移流程中,上述原语按以下方式协作:

  1. StatefulSet 部署源端和目标端数据库实例,保证持久化存储与稳定标识。
  2. Headless Service 暴露数据库 Pod,客户端通过 DNS 直连主节点。
  3. ConfigMap 存储迁移参数(批量大小、超时时间、并发线程数)。
  4. Secret 存储源端/目标端数据库连接凭据与 TLS 证书。
  5. Job 或临时 Pod(基于 Pod 模板)运行迁移工具,通过 Service DNS 连接数据库。
  6. Deployment 可选地运行迁移监控面板或数据校验服务,无状态且可水平扩展。
回顾要点:StatefulSet + Headless Service + 独立 PVC 是数据库在 Kubernetes 上运行的“铁三角”。ConfigMap 和 Secret 负责配置与安全,Deployment 仅用于辅助组件。理解这六者的职责边界,是后续设计迁移接口契约的前提。