SeaTunnel on Kubernetes 配置实战ConfigMap、Hazelcast 集群发现、MapStore 与插件加载全指南【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel本文是 Apache SeaTunnel 在 Kubernetes 上部署的核心配置参考涵盖 ConfigMap/Secret 的挂载规范、基于 Headless Service 的 Hazelcast API/DNS 两种集群发现方式、Master/Worker 分离配置、Slot 调度、Checkpoint 存储与 IMap MapStoreHDFS/S3/OSS持久化以及自定义插件的三种加载方案。读完本文你将能依据 docs/en/getting-started/kubernetes/configuration.md 的原则结合仓库中真实的 config 目录与 Helm Chart 模板独立搭建并调优一套可上生产的 SeaTunnel Kubernetes 集群。SeaTunnel 以 Zeta 引擎为默认分布式运行环境集群成员间的发现与通信依赖 Hazelcast。在 Kubernetes 上部署时除了要正确编排 Pod更关键的是把 SeaTunnel 与 Hazelcast 的配置文件seatunnel.yaml、hazelcast*.yaml、hazelcast-client.yaml以正确的方式注入容器、配置好集群成员发现机制、规划好状态持久化后端与插件加载路径。下面逐一展开。配置注入ConfigMap 与 Secret 的使用边界非敏感配置应存放在 ConfigMap 中并通过subPath逐个挂载到容器内对应的文件路径例如/opt/seatunnel/config/seatunnel.yaml/opt/seatunnel/config/hazelcast-master.yaml仓库中的 Helm Chart 正是这样实现的。查看 deploy/kubernetes/seatunnel/templates/configmap.yaml它会将conf/目录下的全部文件hazelcast-client.yaml、hazelcast-master.yaml、hazelcast-worker.yaml、jvm_client_options、jvm_master_options、jvm_worker_options、log4j2.properties、seatunnel.yaml见 deploy/kubernetes/seatunnel/conf渲染进同一个 ConfigMap而 deploy/kubernetes/seatunnel/templates/deployment-seatunnel-master.yaml 中通过volumeMounts使用mountPath: /opt/seatunnel/config/xxx加subPath: xxx的方式逐个挂载避免把整个config目录整体覆盖。警告不要用一个 ConfigMap 整体挂载/opt/seatunnel/config目录除非该 ConfigMap 同时包含镜像所需的所有文件例如jvm_options、jvm_master_options、jvm_worker_options。整体覆盖目录会丢失镜像内自带的其余配置文件。不要把敏感值直接写进 ConfigMap包括数据库密码、对象存储 access key 与 secret key、Token、私钥以及其他凭据。ConfigMap 的文件内容不会解析 Kubernetes 的secretKeyRef。SeaTunnel、Hazelcast 以及底层文件系统读取到的必须是最终可用的配置值或它们自身支持的凭据机制例如环境变量、Hadoop credential provider、云厂商凭据链credential chain或挂载的凭据文件。敏感值应存放在 Kubernetes Secret 中通过环境变量或挂载文件注入。下面IMap MapStore一节会给出 S3 凭据通过secretKeyRef注入环境变量的完整示例。Hazelcast 集群发现Headless Service 与两种发现模式集群模式下 SeaTunnel 依赖 Hazelcast 发现其他成员。在 Kubernetes 上标准做法是先创建一个 Headless ServiceapiVersion: v1 kind: Service metadata: name: seatunnel-cluster spec: clusterIP: None publishNotReadyAddresses: true ports: - name: hazelcast port: 5801 selector: app: seatunnel仓库中的 deploy/kubernetes/seatunnel/templates/service-headless.yaml 即采用clusterIP: None的 Headless Service并将 5801 端口命名为hazelcast-port。注意两点port: 5801对应 Hazelcast 成员端口与 config/hazelcast.yaml 中port: 5801一致。publishNotReadyAddresses: true允许集群引导阶段 DNS 也能解析到尚未就绪的 Pod。在此基础上可以选择以下两种 Hazelcast Kubernetes 发现模式之一。API Discovery通过 Kubernetes API 解析成员API 发现利用 Kubernetes API从配置的 namespace 与 Service 解析成员。对应的hazelcast.yaml必须使用相同的 namespace、service 名称与端口hazelcast: network: join: kubernetes: enabled: true namespace: default service-name: seatunnel-cluster service-port: 5801若 SeaTunnel 部署在default之外的 namespace需要同步更新namespace。同时更新hazelcast-client.yaml的cluster-members例如seatunnel-cluster.namespace.svc.cluster.local:5801使提交作业的客户端能连到同一 namespace。警告RBAC 前提当使用namespace、service-name、service-port时Hazelcast 在成员引导阶段会查询 Kubernetes API。在启用 RBAC 的集群中SeaTunnel Pod 需要一个绑定到读取部署 namespace 下 Pods、Services、Endpoints权限的 ServiceAccount。必须在启动 StatefulSet 之前创建好 RBAC 资源并在 Pod 模板中设置serviceAccountName: seatunnel。apiVersion: v1 kind: ServiceAccount metadata: name: seatunnel --- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: seatunnel-hazelcast-discovery rules: - apiGroups: [] resources: [pods, services, endpoints] verbs: [get, list, watch] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: seatunnel-hazelcast-discovery subjects: - kind: ServiceAccount name: seatunnel roleRef: apiGroup: rbac.authorization.k8s.io kind: Role name: seatunnel-hazelcast-discovery仓库自带的 Helm Chart 也内置了 ServiceAccount/Role/RoleBinding 模板见 deploy/kubernetes/seatunnel/templates/rbac.yaml并已在 Master Deployment 中配置serviceAccountName见 deploy/kubernetes/seatunnel/templates/deployment-seatunnel-master.yaml。不过 Chart 自带的 Role 仅授予configmaps的读取权限并未包含 API Discovery 所需的 pods/services/endpoints 权限若采用 API 发现模式需要额外补充上述 RBAC 规则。DNS Discovery通过 Kubernetes DNS 解析成员DNS 发现通过 Kubernetes DNS 解析 Headless Service。它不需要 Hazelcast 调用 Kubernetes API因此不需要为成员发现额外创建 Role 或 RoleBinding。当集群只需要通过一个稳定的 Headless Service 发现成员时此模式更简单hazelcast: network: join: kubernetes: enabled: true service-dns: seatunnel-cluster.default.svc.cluster.local service-dns-timeout: 10注意若 SeaTunnel 部署在default之外的 namespace需要把service-dns与hazelcast-client.yaml的cluster-members同步更新到同一 namespace。同时保持 Headless Service 上的publishNotReadyAddresses: true以便集群引导期间 DNS 发现也能解析到 Pod。与代码库对齐的 Hazelcast properties 基线SeaTunnel 服务端设置来自seatunnel.yaml中的seatunnel.engine集群成员发现来自hazelcast.yaml、hazelcast-master.yaml或hazelcast-worker.yaml。以下是官方文档推荐作为基线的 Hazelcastproperties它们与当前 SeaTunnel 默认的 Hazelcast 配置保持一致可直接对照 config/hazelcast.yaml 与 config/hazelcast-master.yamlproperties: hazelcast.invocation.max.retry.count: 20 hazelcast.tcp.join.port.try.count: 30 hazelcast.logging.type: log4j2 hazelcast.operation.generic.thread.count: 50 hazelcast.heartbeat.failuredetector.type: phi-accrual hazelcast.heartbeat.interval.seconds: 2 hazelcast.max.no.heartbeat.seconds: 180 hazelcast.heartbeat.phiaccrual.failuredetector.threshold: 10 hazelcast.heartbeat.phiaccrual.failuredetector.sample.size: 200 hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis: 100参数含义简表参数作用默认建议hazelcast.invocation.max.retry.count调用最大重试次数20hazelcast.tcp.join.port.try.countTCP join 端口尝试次数30hazelcast.logging.type日志实现log4j2hazelcast.operation.generic.thread.count通用操作线程数50hazelcast.heartbeat.failuredetector.type心跳失效检测器phi-accrualhazelcast.heartbeat.interval.seconds心跳间隔2hazelcast.max.no.heartbeat.seconds最大无心跳秒数180hazelcast.heartbeat.phiaccrual.failuredetector.thresholdphi-accrual 判定阈值10hazelcast.heartbeat.phiaccrual.failuredetector.sample.size心跳采样窗口200hazelcast.heartbeat.phiaccrual.failuredetector.min.std.dev.millis最小标准差毫秒100这些值是基线而非万能参数上线前应根据 CPU 限制、网络延迟、Pod 驱逐行为、集群规模与作业并发度进行调优。分离模式Master 与 Worker 使用不同的 Hazelcast 配置在分离集群模式separated cluster mode下Master 与 Worker 应使用不同的 Hazelcast 配置Master配置 IMap MapStore 与偏保守的心跳设置对应 config/hazelcast-master.yaml。Worker配置member-attributes.ruleworker不携带 IMap MapStore对应 config/hazelcast-worker.yaml。seatunnel.yaml可以共享但部分设置只对某一角色生效。观察两个配置文件可以发现Master 与 Worker 的差异还体现在端口上Master 使用5801Worker 使用5802见 config/hazelcast-master.yaml 与 config/hazelcast-worker.yaml这是分离模式下集群内角色区分的直观体现。启动命令上Helm Chart 中 Master 通过/opt/seatunnel/bin/seatunnel-cluster.sh -r master启动见 deploy/kubernetes/seatunnel/templates/deployment-seatunnel-master.yamlWorker 侧则使用-r worker。Slot 配置Worker 调度资源的静态规划Worker 的 Slot 是集群的调度资源。生产环境推荐使用静态 Slotseatunnel: engine: slot-service: dynamic-slot: false slot-num: 8 job-schedule-strategy: WAIT规划slot-num时必须与 Worker 的 CPU、内存以及作业并行度统筹考虑当同时终止过多 Worker Pod 时可用 Slot 数量会快速下降正在运行的作业可能因拿不到 Slot 而失败或长时间排队。Worker 建议使用 StatefulSet 管理保证稳定的网络标识滚动更新或缩容前先确认 Slot 容量是否充足。注意与本地默认配置的差异config/seatunnel.yaml 中本地默认是dynamic-slot: true动态 Slot而生产 K8s 环境按上述示例改为静态 Slot 并显式指定slot-num: 8调度行为更可控。Checkpoint 存储多节点集群必须使用共享存储多节点集群必须使用共享存储或对象存储作为 Checkpoint 后端。常见选择包括HDFS、S3、OSS、COS、OBS、TOS 或 Kubernetes PersistentVolume。seatunnel: engine: checkpoint: interval: 180000 timeout: 30000 storage: type: hdfs max-retained: 3 plugin-config: storage.type: hdfs namespace: /seatunnel/checkpoint/ fs.defaultFS: hdfs://namenode:8020intervalCheckpoint 间隔毫秒示例为 1800003 分钟比本地默认的10000见 config/seatunnel.yaml更适用于生产环境的大吞吐作业。timeoutCheckpoint 超时时间毫秒。max-retained最多保留的 Checkpoint 份数。namespaceCheckpoint 数据在存储上的命名空间前缀。若使用对象存储每个 Master 和 Worker Pod 都必须具备网络连通性且拥有相同的读写权限。此外Checkpoint 存储与 IMap MapStore 可以共用同一个对象存储服务但应使用不同的namespace前缀例如/seatunnel/checkpoint/与/seatunnel/imap。IMap MapStore集群状态与检查点监控数据的持久化Master 节点负责 IMap 状态存储。生产环境应启用 MapStore并将数据写入共享存储或对象存储。在分离模式下只在hazelcast-master.yaml中配置 MapStoreWorker 不需要。MapStore 使用FileMapStoreFactory即 seatunnel-engine/seatunnel-engine-server/src/main/java/org/apache/seatunnel/engine/server/persistence/FileMapStoreFactory.javapublic class FileMapStoreFactory implements MapStoreFactoryObject, Object { Override public MapLoaderObject, Object newMapStore(String mapName, Properties properties) { properties.setProperty(businessName, mapName); return new FileMapStore(); } }从源码可以看到工厂会为每个 map 注入businessName即 map 名然后交给FileMapStore处理。配置中type: hdfs这一项是 IMap 文件存储工厂的标识符即使底层使用 S3 或 OSS 也必须保持type: hdfs不变真正的后端由storage.type决定目前支持hdfs、s3、oss三种。可选关闭 Checkpoint Monitor 的 MapStore 持久化如果不想持久化 checkpoint monitor 数据可以为engine_checkpoint_monitor显式添加覆盖配置hazelcast: map: engine_checkpoint_monitor: map-store: enabled: false注意该 IMap 存储的是 Checkpoint 概览与历史数据供 REST API 和 UI 可观测性使用不是权威的 Checkpoint 恢复状态。真正的 Checkpoint 恢复状态由seatunnel.engine.checkpoint.storage写入 HDFS、S3、OSS 或其他配置的 Checkpoint 存储后端。该覆盖是可选的当你想避免持久化纯可观测性数据、降低 MapStore/WAL 写放大时使用它如果希望 checkpoint monitor 的概览/历史与其它engine*IMap 使用相同的 MapStore 设置则可以省略。HDFS 后端hazelcast: map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /seatunnel/imap clusterName: seatunnel-cluster storage.type: hdfs fs.defaultFS: hdfs://namenode:8020engine*通配符会匹配所有以engine开头的 IMap。initial-mode: EAGER表示成员启动时即执行数据加载MapLoad。S3 或兼容对象存储S3 兼容存储使用 Hadoop S3A 配置。使用 AWS S3 时依赖 Hadoop S3A 的默认 endpoint 解析兼容服务如 MinIO、Ceph RGW通常需要配置各自的fs.s3a.endpoint和fs.s3a.path.style.access: true。如果最终 YAML 中提供静态凭据请使用固定的 Hadoop S3A keyfs.s3a.access.key与fs.s3a.secret.key。当显式配置SimpleAWSCredentialsProvider时两个 key 都必需。该模式下 Hadoop 直接使用 YAML 中的值不要写成${AWS_SECRET_ACCESS_KEY}或{AWS_SECRET_ACCESS_KEY}这类占位符hazelcast: map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /seatunnel/imap clusterName: seatunnel-cluster storage.type: s3 s3.bucket: s3a://seatunnel-bucket fs.s3a.access.key: YOUR_ACCESS_KEY fs.s3a.secret.key: YOUR_SECRET_KEY fs.s3a.aws.credentials.provider: org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider警告如果希望通过环境变量从 Kubernetes Secret 注入凭据不要把secretKeyRef放进 ConfigMap 内容里而应把 AWS SDK 环境变量注入 Pod并且不要把fs.s3a.aws.credentials.provider固定为SimpleAWSCredentialsProvider。当前使用的 Hadoop AWS 3.1.4 默认凭据链在未显式配置 provider 时会自动读取 AWS 环境变量。若希望只允许环境变量认证可将 S3A provider 设置为com.amazonaws.auth.EnvironmentVariableCredentialsProvider并通过 Secret 注入环境变量env: - name: AWS_ACCESS_KEY_ID valueFrom: secretKeyRef: name: seatunnel-s3-credentials key: access-key-id - name: AWS_SECRET_ACCESS_KEY valueFrom: secretKeyRef: name: seatunnel-s3-credentials key: secret-access-keyproperties: type: hdfs namespace: /seatunnel/imap clusterName: seatunnel-cluster storage.type: s3 s3.bucket: s3a://seatunnel-bucket fs.s3a.aws.credentials.provider: com.amazonaws.auth.EnvironmentVariableCredentialsProvider使用临时凭据时还需注入AWS_SESSION_TOKEN。AWS SDK 也接受AWS_ACCESS_KEY与AWS_SECRET_KEY但推荐使用AWS_ACCESS_KEY_ID与AWS_SECRET_ACCESS_KEY。如果使用 MinIO、Ceph RGW 或其他 S3 兼容服务需要把服务 endpoint 加入 S3 配置properties: fs.s3a.endpoint: https://s3-compatible-endpoint.example.com fs.s3a.path.style.access: trueOSS 后端阿里云阿里云 OSS 使用 Hadoop OSS 配置通过oss.bucket选择目标 bucket并设置fs.oss.endpoint为 bucket 所在 region、私有云或 OSS 兼容服务的实际 endpointhazelcast: map: engine*: map-store: enabled: true initial-mode: EAGER factory-class-name: org.apache.seatunnel.engine.server.persistence.FileMapStoreFactory properties: type: hdfs namespace: /seatunnel/imap clusterName: seatunnel-cluster storage.type: oss oss.bucket: oss://seatunnel-bucket fs.oss.endpoint: https://oss-region.aliyuncs.com fs.oss.accessKeyId: YOUR_ACCESS_KEY_ID fs.oss.accessKeySecret: YOUR_ACCESS_KEY_SECRETOSS 凭据相关要点默认的 Hadoop Aliyun OSS 凭据提供者读取fs.oss.accessKeyId与fs.oss.accessKeySecret临时凭据可额外设置fs.oss.securityToken。与 Hadoop S3A 不同OSS没有默认的环境变量凭据链因此从 Kubernetes Secret 以环境变量形式注入的凭据不会被自动使用。如果不想把 OSS 凭据渲染进最终的 ConfigMap可以使用 Hadoop credential provider 管理fs.oss.accessKeyId与fs.oss.accessKeySecret或将fs.oss.credentials.provider设置为自定义 provider。该自定义 provider 必须实现阿里云 OSS SDK 的com.aliyun.oss.common.auth.CredentialsProvider接口且必须存在于 SeaTunnel 镜像中。当使用backup-count: 1时至少需要 2 个 Master 副本才能存储 IMap 备份副本本地默认backup-count: 1见 config/seatunnel.yaml。警告凭据安全不要把真实的 access key / secret key 提交到 ConfigMap 或 Git 仓库。Kubernetes 不会解析 ConfigMap 文件内容中的secretKeyRefSeaTunnel 与 Hazelcast 必须读取到最终可用的 YAML 配置。生产环境应通过 Helm、Kustomize、External Secrets、CI/CD 或镜像构建流程生成最终 ConfigMap或使用底层文件系统真正支持的凭据机制Hadoop credential provider、AWS SDK 环境变量 provider、云厂商凭据链、挂载凭据文件。同时确保每个 Master Pod 对对象存储拥有相同的读写权限。当使用 S3 或 OSS 时SeaTunnel 镜像还必须包含对应的 Hadoop 文件系统实现与依赖例如 Hadoop AWS/AWS SDK 或 Hadoop Aliyun/OSS SDK。Checkpoint 存储与 IMap MapStore 可以共用同一对象存储但需使用不同的namespace前缀。插件加载Connector 与 Transform 的分目录装载基础 Master/Worker StatefulSet不包含自定义插件加载逻辑自定义插件属于额外的部署关注点应根据集群需求单独管理并确保 Master 与 Worker 使用相同的插件版本。运行时目录职责划分根据 jar 的加载方式使用 SeaTunnel 运行时目录目录用途不要用于${SEATUNNEL_HOME}/plugins自定义 Connector 插件 jar 或插件包Transform 插件 jar 或一般运行时 jar${SEATUNNEL_HOME}/libTransform 插件 jar、以及必须位于 SeaTunnel 进程 classpath 的少量运行时扩展 jarConnector 插件 jar注意SeaTunnel 对不同插件类型使用不同的加载路径。plugins/目录用于自定义 Connector而不是 Transform 插件或无关运行时 jar。若自定义 Connector 需要驱动或客户端库请将这些 jar 与放置于plugins/下的自定义 Connector 插件打包在一起。随 SeaTunnel 发布的 Transform 插件如seatunnel-transforms-v2.jar打包在lib/下并从运行时 classpath 发现。仅当某个 jar 是 Transform 插件或必须对 SeaTunnel 进程 classpath 可见的运行时扩展时才放入lib/。警告只把 Transform 插件 jar 放到plugins/下可能因不在运行时 classpath 上而导致加载失败也不要用lib/放置自定义 Connector 插件 jar。三种常见加载方式对比方式适用场景说明将自定义 Connector 插件与 Transform jar 构建进 SeaTunnel 镜像稳定的生产环境可重复性最高生产推荐用 initContainer overlay 注入自定义 Connector 插件Connector 集合频繁变更在 StatefulSet 上叠加 initContainer把插件从插件镜像拷贝到emptyDir并挂载从 PersistentVolume 或对象存储挂载大型 Connector 集合需要额外的版本一致性管理方式一自定义镜像对稳定的生产环境把自定义 Connector 插件 jar、Transform 插件 jar 以及所需运行时扩展 jar 构建进 SeaTunnel 镜像FROM seatunnel:3.0.0 # 可选自定义 Connector 插件 jar 或插件包。 COPY plugins/ /opt/seatunnel/plugins/ # 可选需要进程 classpath 的 Transform 插件 jar 或运行时扩展 jar。 COPY lib/ /opt/seatunnel/lib/自定义 Connector 插件 jar 放在/opt/seatunnel/plugins/下/opt/seatunnel/lib/仅用于 Transform 插件 jar 或必须位于 SeaTunnel 进程 classpath 的运行时扩展 jar。然后在 Master 与 Worker 两个 StatefulSet 中使用相同的镜像 tag。方式二initContainer overlay当自定义 Connector 插件需要独立于主镜像发布时在 Master 与 Worker 两个 StatefulSet 上叠加以下片段这不是基础部署清单的一部分。由于plugins的emptyDir挂载会在运行时替换镜像目录插件镜像必须包含提交作业所需的全部自定义 Connector 插件文件initContainers: - name: plugin-loader image: seatunnel-plugin:v1.0.0 command: - sh - -c - | cp -R /plugin/plugins/. /mnt/plugins/ volumeMounts: - name: plugin-dependencies mountPath: /mnt/plugins containers: - name: app volumeMounts: - name: plugin-dependencies mountPath: /opt/seatunnel/plugins volumes: - name: plugin-dependencies emptyDir: {}警告不要用emptyDir整体挂载/opt/seatunnel/lib目录除非它包含基础镜像中的全部运行时 jar单个 Transform 插件 jar 或运行时扩展 jar 应使用subPath挂载或直接构建进镜像。务必保证每个 Master 与 Worker Pod 获得相同的插件与依赖版本。如果还需要注入 Transform 插件 jar用subPath追加而不是替换整个lib目录。若已在使用上述 overlay可把runtime-lib挂载与拷贝命令合并进同一个 initContainer。独立的精简片段如下initContainers: - name: plugin-loader image: seatunnel-plugin:v1.0.0 volumeMounts: - name: runtime-lib mountPath: /mnt/lib command: - sh - -c - cp /plugin/lib/custom-transform.jar /mnt/lib/ containers: - name: app volumeMounts: - name: runtime-lib mountPath: /opt/seatunnel/lib/custom-transform.jar subPath: custom-transform.jar volumes: - name: runtime-lib emptyDir: {}日志控制台输出与滚动文件保持控制台日志输出以便 Kubernetes 日志收集器如 sidecar 或 DaemonSet 方式的 filebeat/fluentd能够收集。也可以使用log4j2.properties配置本地滚动日志若由 sidecar 或 DaemonSet 收集日志需确保日志路径、文件名与收集规则保持一致。SeaTunnel 默认日志路径通常为/opt/seatunnel/logs生产环境应限制日志保留时长与文件大小避免写满 Pod 本地磁盘。仓库中的日志模板可参考 config/log4j2.properties 及 Helm Chart 内的 deploy/kubernetes/seatunnel/conf/log4j2.properties。与官方 Helm Chart 的配合使用上述所有配置最终都要落到 Master/Worker 的 StatefulSet或 Deployment与 ConfigMap 中。仓库的 Helm Chart 提供了一条开箱即用的路径Chart 的values.yamldeploy/kubernetes/seatunnel/values.yaml可配置镜像 registry/tag、master.replicas默认2、worker.replicas默认2、滚动更新策略、liveness/readiness 探针默认 tcpSocket 探测 5801 端口以及 Prometheus 注解。conf/目录下的 8 个文件会被自动渲染为 ConfigMap 并通过subPath挂载见 deploy/kubernetes/seatunnel/templates/configmap.yaml 与 deploy/kubernetes/seatunnel/templates/deployment-seatunnel-master.yaml。注意 Chart 默认提供的是 Deploymentkind: Deployment而文档针对 Worker 场景建议使用 StatefulSet并在滚动更新/缩容前检查 Slot 容量。生产上线检查清单把以上要点汇总为一份可执行的上线检查清单配置注入ConfigMap 使用subPath逐个挂载绝不用空 ConfigMap 整体覆盖/opt/seatunnel/config。凭据安全敏感值一律走 SecretConfigMap 内容中不出现secretKeyRef与真实 keyS3 用环境变量注入时不要固定SimpleAWSCredentialsProvider。集群发现创建 Headless Service 并保持publishNotReadyAddresses: true选择 API 或 DNS 发现之一API 发现需预先创建 pods/services/endpoints 读权限的 RBAC并在 Pod 模板设置serviceAccountNamehazelcast-client.yaml的cluster-members与发现配置指向同一 namespace。分离模式Master 配 MapStore 与保守心跳Worker 配member-attributes.ruleworker且不配 MapStore。Slot 规划静态 Slotdynamic-slot: falseslot-num与 Worker 资源、作业并行度联动评估Worker 用 StatefulSet 管理。状态持久化多节点必须配置共享 Checkpoint 后端IMap MapStore 的type: hdfs保持不变按需选择storage.type: hdfs|s3|ossCheckpoint 与 IMap 使用不同namespace前缀backup-count: 1时 Master 至少 2 副本。插件装载Connector 插件放plugins/Transform 与运行时扩展 jar 放lib/生产优先构建进镜像动态变更用 initContainer overlay并保证 Master/Worker 版本一致。日志保留控制台输出限制滚动日志的保留时间与文件大小。【免费下载链接】seatunnelSeaTunnel is a multimodal, high-performance, distributed, massive data integration tool.项目地址: https://gitcode.com/GitHub_Trending/se/seatunnel创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考