4. Kubernetes 基础回顾：Pod、Service、Deployment、StatefulSet、ConfigMap、Secret 在同步方案中的用途
在构建搜索索引与业务数据库的数据同步方案时，Kubernetes 的核心资源对象各自承担着不可替代的角色。理解这些原语的职责边界与协作方式，是设计高可用、可扩展同步管道的前提。本节从同步方案的视角，逐一回顾 Pod、Service、Deployment、StatefulSet、ConfigMap 和 Secret 的关键用途。
4.1 资源对象与同步职责总览
下表概括了每个 Kubernetes 资源在同步方案中的核心定位与典型使用场景：
| 资源对象 | 同步方案中的核心职责 | 典型使用场景 |
|---|---|---|
| Pod | 运行同步逻辑的最小执行单元 | CDC 监听器、ETL 转换器、索引写入器 |
| Service | 提供稳定的网络端点，实现服务发现与负载均衡 | 暴露同步 API、连接数据库读写分离端点 |
| Deployment | 管理无状态同步组件的声明式更新与扩缩容 | 索引构建 worker、批量数据迁移任务 |
| StatefulSet | 管理有状态同步组件，保障有序部署与稳定标识 | CDC 日志消费组、分片索引写入器 |
| ConfigMap | 解耦同步配置与容器镜像，支持运行时热更新 | 数据库连接串（非敏感）、同步频率、索引映射规则 |
| Secret | 安全存储敏感凭据，避免明文泄露 | 数据库密码、Elasticsearch API Key、TLS 证书 |
4.2 Pod：同步逻辑的原子载体
Pod 是 Kubernetes 中最小的部署单元，也是同步进程的实际运行环境。在数据同步方案中，一个 Pod 通常包含一个主容器（运行同步引擎）和一个或多个边车容器（Sidecar），用于日志收集、指标暴露或健康检查。
- 单容器 Pod：适用于简单的 CDC 监听器，例如 Debezium 连接器或 Canal 客户端，直接监听 Binlog 并推送到消息队列。
- 多容器 Pod：适用于需要日志聚合或代理的场景，例如同步引擎 + Filebeat 边车，将同步日志直接转发到 Elasticsearch。
- Init 容器：在同步主容器启动前执行初始化任务，如检查数据库连通性、预热索引映射缓存。
4.3 Service：稳定的同步网络入口
Service 为同步组件提供稳定的虚拟 IP 和 DNS 名称，屏蔽后端 Pod 的 IP 变化。在同步架构中，Service 主要承担以下角色：
- 内部服务发现：同步 worker 通过 Service 名称访问数据库代理层或消息队列，无需感知后端 Pod 的扩缩容。
- 读写分离端点：为业务数据库和搜索集群分别创建 Service，同步组件通过不同的 Service 端点区分读写流量。
- Headless Service：配合 StatefulSet 使用，为每个有状态同步 Pod 提供唯一的网络标识，适用于分片索引写入场景。
app: sync-worker。同步客户端通过 sync-service.namespace.svc.cluster.local:8080 调用状态查询接口。
4.4 Deployment：无状态同步组件的弹性管理
Deployment 适用于无状态的同步任务，例如批量数据迁移、索引重建、定时全量同步。其核心优势在于声明式更新与水平弹性伸缩。
| Deployment 特性 | 在同步方案中的价值 |
|---|---|
| 滚动更新（RollingUpdate） | 零停机升级同步引擎版本，逐步替换旧 Pod |
| 副本数（Replicas） | 根据同步队列积压量动态调整 worker 数量 |
| 回滚（Rollback） | 新版本同步逻辑出现数据异常时快速恢复 |
| Pod 模板 | 统一管理同步容器的镜像、环境变量、挂载卷 |
4.5 StatefulSet：有状态同步组件的有序保障
StatefulSet 专为有状态应用设计，在同步方案中用于管理需要持久化标识和有序部署的组件。典型场景包括：
- CDC 日志消费组：每个 StatefulSet Pod 负责消费特定分片的 Binlog，Pod 名称（如
cdc-consumer-0、cdc-consumer-1）作为消费者组内的唯一标识。 - 分片索引写入器：每个 Pod 对应 Elasticsearch 的一个分片，通过 Headless Service 的 DNS 记录
index-writer-0.sync-svc实现稳定的分片路由。 - 有序启停：StatefulSet 保证 Pod 按序号顺序启动和终止，避免分片分配冲突或数据竞争。
4.6 ConfigMap 与 Secret：配置与凭据的解耦管理
ConfigMap 和 Secret 将配置信息从容器镜像中剥离，使同步组件可以在不同环境（开发、测试、生产）复用同一镜像。
| 对比维度 | ConfigMap | Secret |
|---|---|---|
| 存储内容 | 非敏感配置：数据库主机、端口、同步频率、索引映射规则 | 敏感凭据：数据库密码、API Key、TLS 私钥 |
| 数据编码 | 明文（UTF-8） | Base64 编码（etcd 中加密存储） |
| 注入方式 | 环境变量、配置文件挂载 | 环境变量、配置文件挂载（内存 tmpfs） |
| 热更新支持 | 支持（挂载文件自动更新，需应用监听） | 支持（挂载文件自动更新，需应用监听） |
| 同步方案典型键值 | sync.interval=30s、index.mapping=product_v2 |
db.password=xxxx、es.api.key=yyyy |
envFrom 或 volumes 同时引用两者。
4.7 资源协作关系图
下图展示了在典型 CDC 同步方案中，Pod、Service、Deployment、StatefulSet、ConfigMap 和 Secret 之间的协作关系：
4.8 有状态同步组件的 StatefulSet 示意
对于需要分片消费或持久化偏移量的同步场景，StatefulSet 提供比 Deployment 更严格的保障。下图展示 StatefulSet 如何管理 CDC 消费者组：
4.9 资源选择决策矩阵
在实际设计同步方案时，可根据以下条件快速选择合适的工作负载类型：
| 同步组件特征 | 推荐资源类型 | 原因 |
|---|---|---|
| 无状态、可并行、支持任意副本扩缩 | Deployment | 滚动更新、回滚、HPA 自动扩缩容 |
| 有状态、需要稳定 Pod 名称和有序启停 | StatefulSet | 分片消费、偏移量持久化、SRV 记录 |
| 需要暴露内部 API 供其他组件调用 | Service（ClusterIP） | 稳定的虚拟 IP 和 DNS 名称 |
| 需要分片级别的直接 Pod 访问 | Service（Headless） | 每个 Pod 独立的 DNS 记录 |
| 非敏感配置，需跨环境复用 | ConfigMap | 明文存储，支持热更新 |
| 敏感凭据，需加密存储 | Secret | Base64 编码，etcd 加密，内存挂载 |