生产级实战：在 K3S 上构建 3 节点分布式 Apache SeaTunnel Zeta 高可用集群

生产级实战在 K3S 上构建 3 节点分布式 Apache SeaTunnel Zeta 高可用集群在上一篇博客中我们成功跑通了基于local模式的 Oracle 到 Oracle 实时 CDC 同步。然而在生产环境中单机运行local模式不仅无法应对高并发的海量数据流还面临单点故障SPOF的风险。为了实现 7x24 小时高可用HA、全自动负载均衡与分布式弹性伸缩我们需要将 SeaTunnel 的Zeta 引擎迁移至容器化集群。本文将基于边缘级轻量化 Kubernetes 集群K3S手把手带你完成3 节点分布式高可用 Zeta 集群的搭建、组网避坑与任务提交实战。一、 3 节点 Zeta 集群在 K3S 中的架构设计在 Kubernetes / K3S 环境下Zeta 引擎节点之间需要通过 P2P 互相通信、发现彼此并维持集群状态。为了保证集群的绝对稳定我们的架构设计如下StatefulSet状态集设置副本数replicas 3。由于 Zeta 节点之间通过内置的 Hazelcast 进行内部成员发现使用 StatefulSet 可以为 Pod 提供固定的网络拓扑标识seatunnel-0,seatunnel-1,seatunnel-2。Headless Service无头服务声明clusterIP: None。用于节点间的 DNS 内部发现通过稳定的内部短域名如seatunnel-0.seatunnel-service实现跨节点组网。驱动封装由于官方公共镜像不含商业版权驱动我们必须将上一章准备好的ojdbc8.jar和orai18n.jar封装到自定义镜像中确保 3 个节点都能正常解析 Oracle 数据。二、 第一步制作包含 Oracle 驱动的自定义镜像在你的 K3S Master 节点或构建机器上将ojdbc8.jar和orai18n.jar放在同一目录下编写DockerfileFROM apache/seatunnel:2.3.8 # 将 Oracle 核心驱动和国际化语言包拷贝至 SeaTunnel 的 lib 目录 COPY ojdbc8.jar /opt/seatunnel/lib/ COPY orai18n.jar /opt/seatunnel/lib/执行打包命令。如果你使用的是 K3S 自带的 Containerd 运行时可以直接导入或者推送到你的私有镜像仓库# 编译镜像dockerbuild-tmy-registry.local/seatunnel:2.3.8-oracle.# 推送至私有仓库确保 K3S 节点都能拉取dockerpush my-registry.local/seatunnel:2.3.8-oracle三、 第二步配置 3 节点静态 TCP-IP 发现Zeta ConfigZeta 引擎默认使用组播Multicast进行集群发现但这在 K3S如 Flannel 默认网络插件中通常是被禁用的。因此我们必须切换为TCP-IP 发现机制并显式指定 3 个 Pod 的内部短域名。核心避坑点请勿在成员列表中填写全限定域名如xxx.default.svc.cluster.local在某些 CNI 网络抖动时长域名解析失败会导致集群分裂脑裂。最稳妥、切实可行的方法是直接使用Pod名.服务名的短域名格式。创建或修改本地的seatunnel.yaml配置文件seatunnel:engine:backup-count:1queue-type:blockingqueueprint-execution-info-interval:10job-history-limit:100checkpoint:interval:15000max-concurrent:1timeout:60000创建或修改本地的hazelcast.yaml配置文件hazelcast:cluster-name:seatunnel-k3s-clusternetwork:join:multicast:enabled:falsetcp-ip:enabled:truemember-list:-seatunnel-0.seatunnel-service-seatunnel-1.seatunnel-service-seatunnel-2.seatunnel-serviceport:auto-increment:falseport:5801# 核心开启网卡匹配让它自动绑定到 K3S 内部的 10.42.x.x Pod IP 段抛弃 localhostinterfaces:enabled:trueinterfaces:-10.42.*.*四、 第三步编写并部署 K3S 资源清单YAML在 K3S 控制端创建一个整合的资源清单文件seatunnel-k3s-3nodes.yaml。该文件包含了配置挂载ConfigMap、网络路由Service以及 3 副本状态集StatefulSetapiVersion:v1kind:ConfigMapmetadata:name:seatunnel-confignamespace:defaultdata:# 1. 你的原生业务配置保持不变seatunnel.yaml:|seatunnel: engine: backup-count: 1 queue-type: blockingqueue print-execution-info-interval: 10 job-history-limit: 100 checkpoint: interval: 15000 max-concurrent: 1 timeout: 60000# 2. 在这里直接增加 hazelcast.yaml 配置强行覆盖镜像内的写死配置hazelcast.yaml:|hazelcast: cluster-name: seatunnel-k3s-cluster network: join: multicast: enabled: false tcp-ip: enabled: true member-list: - seatunnel-0.seatunnel-service - seatunnel-1.seatunnel-service - seatunnel-2.seatunnel-service port: auto-increment: false port: 5801 # 核心开启网卡匹配让它自动绑定到 K3S 内部的 10.42.x.x Pod IP 段抛弃 localhost interfaces: enabled: true interfaces: - 10.42.*.*---apiVersion:v1kind:Servicemetadata:name:seatunnel-servicenamespace:defaultspec:clusterIP:Noneselector:app:seatunnelports:-name:hazelcastport:5801targetPort:5801---apiVersion:apps/v1kind:StatefulSetmetadata:name:seatunnelnamespace:defaultspec:serviceName:seatunnel-servicereplicas:3selector:matchLabels:app:seatunneltemplate:metadata:labels:app:seatunnelspec:containers:-name:seatunnel-engineimage:docker.io/seatunnelimagePullPolicy:Alwaysports:-containerPort:5801name:hazelcast# 命令回归最简单、最原生、最清爽的状态command:[/opt/seatunnel/bin/seatunnel-cluster.sh]resources:requests:cpu:1memory:2Gilimits:cpu:2memory:4Gi# 将 ConfigMap 中的两个文件分别以标准方式挂载复写进去volumeMounts:-name:config-volumemountPath:/opt/seatunnel/config/seatunnel.yamlsubPath:seatunnel.yaml-name:config-volumemountPath:/opt/seatunnel/config/hazelcast.yamlsubPath:hazelcast.yamlvolumes:-name:config-volumeconfigMap:name:seatunnel-config1. 执行部署在 K3S Master 节点执行一键应用命令kubectl apply-fseatunnel-k3s-3nodes.yaml2. 验证 3 节点集群组网状态部署完成后检查 3 个 Pod 是否全部正常启动kubectl get pods-lapp:seatunnel确保seatunnel-0、seatunnel-1、seatunnel-2的状态全部为Running。随后打印任意一个节点的日志来验证分布式组网是否成功kubectl logs seatunnel-0组网成功的标志在日志中如果看到类似下面的输出显示集群内的Members数量为3并且精准包含了 3 个 Pod 的内部通信端口说明 3 节点分布式高可用集群已经成功建立Members { Member:5801 - e291c944-1234-5678-b123-abcdef123456 this Member:5801 - f823da55-8765-4321-a321-abcdef654321 Member:5801 - c456ab77-9012-3456-d789-abcdef789012 }SeaTunnel 运维利器一键巡检 Zeta 分布式集群状态在 Kubernetes/K3S 上容器化部署 Apache SeaTunnel (Zeta) 后集群健康状态、组网情况及 CDC 实时任务需要快速监控。本文将解析一条用于一键巡检 SeaTunnel 分布式集群状态的命令。 核心巡检命令在 K3S 的 Master 节点或控制端运行sudokubectlexec-itseatunnel-0-ndefault --\/opt/seatunnel/bin/seatunnel-cluster.sh\-mseatunnel-0.seatunnel-service:5801\-s\-cnseatunnel-k3s-cluster 命令参数解析sudo kubectl exec -it seatunnel-0 -n default --获取权限并进入指定的 Pod 交互终端。/opt/seatunnel/bin/seatunnel-cluster.sh -m seatunnel-0.seatunnel-service:5801调用 SeaTunnel 集群管理工具通过短域名指定 Master 节点通信端口。-s展示当前集群运行状态的核心参数。-cn seatunnel-k3s-cluster指定集群名称需与hazelcast.yaml配置严格一致。 预期输出与应用场景执行成功后将展示集群存活成员Members、运行中的作业Running Jobs以及算力槽状态Slots Status。建议在集群部署完毕、提交 CDC 实时任务后或容灾演练后执行此命令进行健康体检。五、 第四步向 K3S 分布式集群提交 CDC 同步任务当集群化部署完成后我们不再使用-e local参数。我们将任务直接通过网络提交到 K3S 集群中由 Zeta 引擎自动进行分布式调度和容灾。使用kubectl exec进入seatunnel-0容器执行任务提交。注意这里的--master参数需要指向我们无头服务中的任意节点kubectlexec-itseatunnel-0 -- ./bin/seatunnel.sh\--config./config/oracle_cdc_to_oracle.conf\--masterseatunnel-0.seatunnel-service:5801集群高可用HA容灾测试任务提交后Zeta 引擎会自动将算力分发到各个节点。此时如果你手动删除模拟故障坠毁seatunnel-1节点kubectl delete pod seatunnel-1K3S 会自动拉起一个全新的 Pod而 Zeta 引擎会利用我们在上一章配置的Checkpoint 快照自动在健康的seatunnel-0或seatunnel-2节点上无缝恢复实时流同步真正实现7x24小时不停机的高可用故障容灾。六、 生产级 K3S 运维保命清单容器 OOM Killed 限制Oracle CDC 底层解析 LogMiner 时如果遇到源端并发大事务会非常消耗堆内存。请务必在 StatefulSet 的limits.memory中至少分配 4Gi 以上空间并通过环境变量传入 JVM 参数如-Xmx3g防止容器被 K3S OOM Killer 强行杀死。持久化 Checkpoint 目录默认情况下Zeta 的 Checkpoint 元数据保存在本地 Pod 路径中。如果 3 个 Pod 同时重启实时流的同步进度就会丢失。在真正的生产环境中建议通过 K3S 的PersistentVolumeClaim (PVC)挂载外部的 NFS、Ceph 或 MinIO 对象存储到/opt/seatunnel/checkpoint/路径下确保元数据绝对安全。总结通过在 K3S 上部署 3 节点的 StatefulSet我们成功将 Apache SeaTunnel 从“单机本地玩具”升华为了“企业级容器化高可用集群”。结合上一章我们打通的 Oracle CDC 实时同步配置这套架构已经完全具备了支撑企业核心生产线海量数据流的能力