SeaTunnel Zeta 引擎 Kubernetes 运维实战指南状态巡检、Worker 扩缩容、滚动更新与故障排查【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel本指南面向已通过 StatefulSet 将 SeaTunnel Zeta 引擎部署到 Kubernetes 的运维与开发人员系统讲解集群日常运维的完整操作闭环从状态检查、REST API 访问到 Worker 扩缩容、滚动更新与 PodDisruptionBudget 配置再到常见故障的定位思路。读完本文你将掌握一套可直接落地到生产环境的 Kubernetes 运维动作清单并能结合仓库内配置与源码快速定位 Pod 无法入群、Worker 不就绪、槽位不足、Checkpoint 写失败等问题。运维前提先理解 Zeta 集群的部署形态本指南描述的运维操作建立在分离集群模式Separated Cluster Mode之上Master 与 Worker 各自以 StatefulSet 运行Master 负责作业调度、REST API、作业提交与 IMap 状态存储Worker 提供任务执行槽位Slot且不参与选举、不存储 IMap 数据。生产环境推荐该模式完整的手写清单与拓扑说明见 Kubernetes 部署总览 与 分离集群模式配置细节见 Kubernetes 配置。在开始任何运维动作之前请先确认两个关键事实Hazelcast 成员发现端口是 5801Master 与 Worker 通过无头服务Headless Serviceseatunnel-cluster互相发现Hazelcast 监听 5801 端口Master 的 REST API 监听 8080 端口。这可以在 config/hazelcast-master.yaml 与 config/hazelcast-worker.yaml 中看到port.auto-increment: false、port: 5801/5802。REST API 由seatunnel.yaml控制config/seatunnel.yaml 中seatunnel.engine.http段配置了enable-http: true、port: 8080这是后续所有 curl 操作的前提。一、集群状态检查1.1 三条基础巡检命令kubectl get pods -l appseatunnel kubectl get statefulset kubectl get svc第一条按appseatunnel标签列出全部 Master/Worker Pod用于确认 Pod 的Running与Ready状态第二条查看seatunnel-master、seatunnel-worker两个 StatefulSet 的READY副本数与当前replicas是判断扩缩容是否生效的直接依据第三条检查seatunnel-cluster无头服务Hazelcast 发现用与seatunnel-masterClusterIPREST API 用是否正常存在。更细粒度地按角色过滤可以结合部署清单中component: master/component: worker标签kubectl get pods -l appseatunnel,componentmaster kubectl get pods -l appseatunnel,componentworker1.2 查看 Master / Worker 日志Zeta 集群的启动、成员加入、作业调度与心跳信息都输出到进程日志# 查看 Master 日志 kubectl logs -f seatunnel-master-0 # 查看 Worker 日志 kubectl logs -f seatunnel-worker-0-f用于持续跟踪tail -f 语义去掉-f则只输出当前已有日志。当节点无法入群或 Worker 不就绪时这两条命令是首要的排查入口。生产建议默认日志路径为/opt/seatunnel/logsKubernetes 下应保留控制台输出以便日志采集器sidecar / DaemonSet / 集群监控栈收集若使用log4j2.properties落盘滚动日志需保证日志路径、文件名与采集规则一致并限制保留时间与单文件大小避免写满 Pod 本地磁盘。详见 Kubernetes 配置之日志章节。二、访问 REST API2.1 集群内访问与端口转发REST API 由 Master 提供集群内可直接通过seatunnel-master这个 Service 访问。调试阶段推荐使用端口转发kubectl port-forward svc/seatunnel-master 8080:8080 curl http://127.0.0.1:8080/system-monitoring-information curl http://127.0.0.1:8080/running-jobs这两个端点并非临时约定而是引擎 REST 层明确定义的路径。在 RestConstant.java 中可以看到public static final String REST_URL_RUNNING_JOBS /running-jobs; public static final String REST_URL_SYSTEM_MONITORING_INFORMATION /system-monitoring-information;同文件还定义了大量其他运维可用端点例如/job-info、/finished-jobs、/logs、/loggers运行时调整日志级别、/metrics、/openmetrics、/submit-job、/stop-job等完整的作业提交协议见 REST API V2。也可以直接进入 Master Pod 内部使用本地 curlMASTER_POD$(kubectl get po -n namespace -l app.kubernetes.io/nameseatunnel-master | sed 1d | awk {print $1} | head -n1) kubectl -n namespace exec -it $MASTER_POD -- /bin/bash curl http://127.0.0.1:8080/running-jobs curl http://127.0.0.1:8080/system-monitoring-information2.2 生产环境的暴露方式与安全要求:::caution 警告 生产环境如需将 REST API 暴露到集群外部应通过 Ingress 或 LoadBalancer 按需暴露并必须配套认证、网络策略与访问控制切勿直接将端口转发或 ClusterIP 服务裸露到公网。要点如下认证可通过反向代理层Ingress 网关注入认证或在 config/seatunnel.yaml 中开启 HTTP Basic 认证http.enable-basic-auth、basic-auth-username、basic-auth-password配置项默认注释关闭网络策略使用 NetworkPolicy 限制仅允许作业提交客户端网段访问 8080最小暴露面seatunnel-cluster无头服务的 5801 端口仅用于集群内部成员发现不应暴露到集群外。 :::三、Worker 扩容Scale UpWorker 槽位Slot是集群的调度资源扩容 Worker 即增加可用槽位kubectl scale statefulset seatunnel-worker --replicas4执行后确认 Worker 就绪kubectl get pods -l appseatunnel,componentworker扩容的实操要点大作业提交前先扩容提交大规模作业前先确保 Worker 副本数与槽位足够否则作业会因槽位不足长时间等待调度。这与 config/seatunnel.yaml 中的slot-service.dynamic-slot以及调度策略job-schedule-strategy直接相关StatefulSet 是推荐形态Worker 必须使用 StatefulSet 而非 Deployment。如果使用 Deployment滚动更新、驱逐或重新调度可能同时终止多个 Worker Pod导致可用槽位骤降引发调度、故障转移或集群稳定性问题详见 Kubernetes 部署总览槽位与资源联合规划slot-num需与 Worker 的 CPU、内存以及作业并行度一起规划。生产环境推荐静态槽位dynamic-slot: false、显式slot-num配置示例见 Kubernetes 配置之槽位章节。四、Worker 缩容Scale Down缩容比扩容危险因为可能中断正在该 Worker 上执行的任务。缩容前必须逐项确认运行中的作业不依赖将被移除的 Worker该 Worker 上没有正在执行的任务分片剩余 Worker 的槽位足够承载当前与后续作业结合slot-num与各作业并行度估算Checkpoint 已成功完成缩容前先确认最近一次 checkpoint 状态正常避免状态丢失。:::caution 警告不要一次性缩容多个 Worker。应逐个递减副本数并在每次缩容后观察作业状态与集群健康确认无任务失败、无槽位告警后再进行下一次缩容。# 正确做法逐个缩容并观察 kubectl scale statefulset seatunnel-worker --replicas3 kubectl get pods -l appseatunnel,componentworker # 确认稳定后 kubectl scale statefulset seatunnel-worker --replicas2:::若缩容前有作业运行在目标 Worker 上应先将作业停止或迁移使用 REST API 的 stop-job / 重新提交后再缩容具体作业协议见 REST API V2。五、滚动更新Rolling Updates当镜像或配置发生变化时StatefulSet 会按顺序逐个更新 Podmaster-0 → master-1 → …这是 Kubernetes 的有序滚动语义。官方推荐实践配置preStop钩子调用优雅停机脚本在容器被终止前先调用/opt/seatunnel/bin/stop-seatunnel-cluster.sh并等待SeaTunnelServer进程退出让节点优雅离群而非被强制杀死。完整探针与生命周期片段startupProbe / readinessProbe / livenessProbe / preStop见 分离集群模式之健康检查章节设置足够长的terminationGracePeriodSeconds分离集群模式示例中设为120为优雅停机留出时间窗口降低对运行中作业的影响更新前检查 Master 副本数与 Worker 槽位容量确保更新过程中始终有可用 Master避免选举不稳定与足够槽位避免作业因槽位骤降而调度失败高峰期避免同时更新 Master 与 WorkersubPath挂载的 ConfigMap 不会自动热更新如果配置文件通过subPath挂载分离集群模式示例即如此见 分离集群模式ConfigMap 内容变更不会自动传播进运行中的容器。需要手动执行滚动重启kubectl rollout restart statefulset/seatunnel-master、statefulset/seatunnel-worker或使用 Reloader 等工具在 ConfigMap 变更时自动触发重启。:::caution 警告 如果使用 Reloader 之类的工具自动重启 Pod必须确保它不会在短时间内重启过多 Worker。瞬时重启过多 Worker 会导致可用槽位断崖式下跌造成作业调度失败、故障转移或集群不稳定。 :::六、PodDisruptionBudget自愿中断保护生产环境应为 Master 和 Worker 配置 PodDisruptionBudgetPDB限制节点维护、驱逐等自愿中断voluntary disruption场景下不可用 Pod 的数量。官方给出的标准配置apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: seatunnel-master-pdb spec: minAvailable: 1 selector: matchLabels: app: seatunnel component: master --- apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: seatunnel-worker-pdb spec: maxUnavailable: 1 selector: matchLabels: app: seatunnel component: worker设计说明Master 用minAvailable: 1至少保留 1 个 Master 可用保护选举与 REST API 连续性。注意若配置了 IMapbackup-count: 1需要至少 2 个 Master 副本才能存放 IMap 备份副本单 Master 无法提供高可用详见 分离集群模式Worker 用maxUnavailable: 1一次自愿中断最多允许 1 个 Worker 不可用与不要一次缩容/重启多个 Worker的运维原则一致selector 标签必须与 StatefulSet Pod 模板中的app: seatunnel、component: master|worker完全匹配否则 PDB 不会选中任何 Pod形同虚设。七、常见故障排查Troubleshooting7.1 Pod 无法加入集群按以下顺序逐项核对无头服务是否存在seatunnel-clusterHeadless Service 必须存在且clusterIP: None、publishNotReadyAddresses: trueAPI 发现配置是否与服务一致hazelcast.yaml、hazelcast-master.yaml或hazelcast-worker.yaml中的namespace、service-name、service-port必须与 Service 匹配例如namespace: default、service-name: seatunnel-cluster、service-port: 5801。仓库基线配置见 config/hazelcast-master.yaml 与 config/hazelcast-worker.yamlKubernetes 版本见 分离集群模式RBAC 权限API 发现模式RBAC 集群中使用 API 发现时Pod 必须使用具有get、list、watchPods / Services / Endpoints 权限的 ServiceAccount示例中为seatunnel。RBAC 资源ServiceAccount、Role、RoleBinding需在 StatefulSet 启动前创建并确保serviceAccountName: seatunnel写在 Pod 模板中DNS 发现模式若使用service-dns确认其指向正确命名空间下的seatunnel-cluster无头服务例如seatunnel-cluster.default.svc.cluster.local非 default 命名空间需同步修改端口 5801 是否被 Service 暴露无头服务的ports必须包含名为hazelcast、port: 5801的端口Pod 标签是否匹配 Service selectorService 的selector.app: seatunnel必须能选中 Pod。7.2 Worker Readiness 检查失败Worker 就绪探针失败时按以下顺序排查容器是否正常启动查看kubectl describe pod worker-pod与 Worker 日志kubectl logs seatunnel-worker-n确认无启动异常退出Hazelcast 配置文件是否挂载正确检查/opt/seatunnel/config/hazelcast-worker.yaml或/opt/seatunnel/config/hazelcast.yaml是否通过subPath正确挂载。若整个目录被 ConfigMap 覆盖还必须包含镜像所需全部文件jvm_options、jvm_master_options、jvm_worker_options等详见 Kubernetes 配置之 ConfigMap 章节作业所需的 connector 或自定义插件 jar 是否存在Worker 执行任务需要加载连接器插件缺失会导致任务无法运行甚至 Worker 反复重启。插件加载的三种方式自定义镜像、initContainer 覆盖、PV/对象存储挂载与plugins/、lib/目录的用途边界见 Kubernetes 配置之插件加载章节端口 5801 是否在监听就绪探针readinessProbe默认就是tcpSocket探测 5801 端口端口未监听说明 Hazelcast 未成功启动或配置错误。7.3 可用槽位Slot不足作业因槽位不足而长时间等待调度时检查Worker 副本数是否足够kubectl get statefulset seatunnel-worker查看期望副本与实际就绪副本槽位配置是否符合预期检查seatunnel.yaml中slot-service.dynamic-slot与slot-num。生产推荐静态槽位dynamic-slot: false并显式设置slot-num仓库基线在 config/seatunnel.yaml 中为dynamic-slot: trueKubernetes 生产示例见 Kubernetes 配置之槽位章节Worker 是否处于滚动、驱逐或重启状态kubectl get pods -l appseatunnel,componentworker观察Restarting/Evicted/Terminating状态结合kubectl describe pod查看事件是否一次性终止了过多 Worker Pod这通常是人为操作一次性缩容/滚动或驱逐风暴导致应避免并配合 PDB 限制。7.4 Checkpoint 或 MapStore 写入失败Checkpoint 与 IMap MapStore 都涉及持久化写入按以下顺序排查存储路径是否为共享存储或对象存储多节点集群必须使用共享存储HDFS、NFS/PersistentVolume或对象存储S3、OSS、COS、OBS、TOS 等作为 checkpoint 后端本地磁盘无法跨节点恢复。配置示例见 Kubernetes 配置之 Checkpoint 存储章节Pod 是否有网络访问对象存储/共享存储通常需要集群出网能力检查 Pod 所在节点的网络策略与安全组Secret 或挂载的凭证是否正确凭证必须通过 Kubernetes Secret 以环境变量或挂载文件注入不要把secretKeyRef写进 ConfigMap 文件内容——Kubernetes 不会在 ConfigMap 文件内容中解析secretKeyRefSeaTunnel/Hazelcast 读取到的必须是最终可用值或底层文件系统支持的凭证机制Hadoop credential provider、云厂商凭证链、挂载凭证文件等详见 Kubernetes 配置之凭证章节存储路径是否有读写权限确认每个 Master/Worker Pod 对同一路径都有相同的读/写权限尤其是使用对象存储时所有 Pod 的权限必须一致。7.5 REST API 无法访问seatunnel-masterService 是否存在kubectl get svc seatunnel-masterHTTP 开关是否开启seatunnel.yaml中seatunnel.engine.http.enable-http必须为true仓库基线 config/seatunnel.yaml 默认enable-http: true、port: 8080REST API 端口是否与 Service targetPort 匹配Service 的rest-api端口8080必须与容器实际监听端口一致Ingress / LoadBalancer 转发规则是否正确检查 Ingress host、path、后端 service/port 配置以及 LoadBalancer 的监听端口与目标端口。八、运维动作速查表场景推荐动作关键参考日常巡检kubectl get pods -l appseatunnelkubectl get statefulsetkubectl get svc本文第一节查看节点日志kubectl logs -f seatunnel-master-0/seatunnel-worker-0本文第一节调试 REST APIkubectl port-forward svc/seatunnel-master 8080:8080本文第二节扩容 Workerkubectl scale statefulset seatunnel-worker --replicasN本文第三节缩容 Worker逐个递减先停/迁作业、确认槽位与 checkpoint本文第四节镜像/配置变更preStop 长 terminationGracePeriodSeconds 手动滚动重启或 Reloader本文第五节保护自愿中断MasterminAvailable: 1WorkermaxUnavailable: 1的 PDB本文第六节节点无法入群核对无头服务、发现配置、RBAC、5801 端口、标签本文 7.1槽位不足核对副本数、slot-num、Worker 状态本文 7.3存储写失败核对共享存储/对象存储、网络、凭证、读写权限本文 7.4九、延伸阅读Kubernetes 部署总览三种部署模式与拓扑分离集群模式生产推荐的手写清单Kubernetes 配置ConfigMap/Secret、Hazelcast 发现、槽位、Checkpoint、MapStore、插件加载Helm 快速部署REST API V2 作业提交协议仓库配置文件 config/seatunnel.yaml、config/hazelcast-master.yaml、config/hazelcast-worker.yamlREST 端点定义RestConstant.javaHelm Chart 默认值含 Prometheus 指标注解、探针与扩缩容策略deploy/kubernetes/seatunnel/values.yaml【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考