简介一份面向Kubernetes运维与开发人员的XXL-JOB容器化部署配置基于实际集群环境验证通过适用于需要快速上线xxl-job调度中心或调整既有部署方案的场景。资源包整体极为精简仅含1个yaml文件压缩包大小782B该文件将xxl-job在K8s中运行所需的资源定义集中在一起直接应用即可完成基础部署省去从零编写配置的时间同时避免因版本或环境差异导致的常见坑点。目前已有645人学习下载适合中高级K8s使用者作为参考也适合团队内部搭建任务调度平台时作为起始模板。对于刚接触xxl-job容器化的读者这份配置能帮助理解核心资源结构对于有经验的读者则可作为快速验证与对照排错的便捷工具。无论是微服务架构中的定时任务场景还是独立部署的任务调度中心这套YAML都能提供清晰可复用的落地样板。1. XXL-JOB 上 K8s为什么说这套部署验证版 YAML 比你自己写的少踩一半坑先说结论XXL-JOB 容器化部署卡住你的往往不是 YAML 语法而是调度中心和执行器之间「怎么互相找到对方」。这套部署验证版的 YAML 把调度中心、执行器、数据库连接、路由暴露全部整理成了可以直接 apply 的形态解决的是 Java 定时任务从单体迁移到 K8s 集群后怎么保留分片广播、失败重试和完整调度日志的问题。适合正在把 Spring Boot 任务逐个迁进 K8s、又被 CronJob 单副本限制坑过的后端开发和运维同学。CronJob 只能按 Cron 触发单个 Pod做不到分片广播也没有失败重试和调度报表所以不少团队最终都会回到 XXL-JOB 这类专业调度平台上。2. 先搞懂两个角色调度中心与执行器的镜像和连接逻辑2.1 调度中心一个会自动建表的 Spring Boot 服务XXL-JOB 的调度中心admin本质是一个 Spring Boot 应用官方镜像xuxueli/xxl-job-admin:2.4.0把整个 Web 控制台、调度触发器、任务管理都打包好了。它启动时会自动执行内置的建表 SQL把xxl_job_info、xxl_job_log、xxl_job_registry这些核心表建出来。换句话说你只需要提前建好数据库表结构不用手动导入这是很多人第一次部署时没想到的。admin 能多副本跑是因为任务调度靠数据库行锁做抢占同一时刻只有一个副本能拿到触发权。所以集群里跑两个 admin Pod 是安全的不会出现同一个任务被两个调度中心重复触发。但这个前提是多个副本连的是同一个 MySQL并且xxl.job.accessToken完全一致。只要这两个条件满足调度中心就可以像无状态服务一样水平扩展。调度中心的启动参数是通过PARAMS环境变量传入的官方镜像的启动脚本会把PARAMS的内容拼到 Java 命令后面。常见的配置包括数据源地址、账号密码、accessToken、时区、国际化语言。这部分参数直接影响 admin 能不能连上数据库以及执行器能不能握手成功部署前最好先把这一层逻辑理清。2.2 执行器真正跑任务的 Pod端口和注册方式才是关键执行器是嵌入在你业务应用里的一个 SDK 组件xxl-job-core它会在应用内部起一个 Netty HTTP 服务监听xxl.job.executor.port指定的端口默认 9999等待调度中心把任务命令推过来。在这个体系里真正干活的是执行器 Pod调度中心只负责按 Cron 表达式、分片参数等规则把任务发给对应的执行器。执行器启动后会向调度中心注册自己的地址。自动注册模式下它上报的是 Pod 的 IP 和端口。这意味着调度中心必须能在集群网络里直接访问到执行器 Pod 的 9999 端口两者在同一 namespace 下是最稳妥的。很多人在这里翻车是因为把执行器端口配成了 NodePort 或者宿主机端口又或者在配置里写死了执行器 IP结果 Pod 重建后地址漂移调度中心再也连不上。还有一个值得注意的设计执行器不需要对外暴露 Service。调度是 admin 主动回调执行器端口而不是执行器主动连 admin 的 Service。所以执行器的 YAML 里只需要声明 containerPort不需要配 Service。理解了这个单向调用关系后面排查网络问题时思路会清晰很多。3. 直接可用的 YAML从建库到调度中心、执行器一起上线3.1 先准备数据库只需要建库表结构由 admin 自动完成我这里假设你的 K8s 集群里已经有一个可用的 MySQL 实例或者公司有现成的 MySQL 服务可以连。如果没有建议先在集群里用 StatefulSet 部署一个 MySQL 8.x注意给它配持久化存储不然重启一次数据就没了。在连接串指向的 MySQL 实例上先执行这条 SQL 把库建出来CREATE DATABASE IF NOT EXISTS xxl_job DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;建库这一步是必须的。admin 镜像启动时只会建表不会建库如果库不存在数据源初始化会直接报错。字符集这里用 utf8mb4 是为了兼容任务参数里可能出现的表情符号或中文特殊字符。表结构不需要手动导入admin 第一次启动时会自动完成。如果你用的是已有的 MySQL建议对账号做最小权限授权只给xxl_job库的 DML 权限就够了。admin 启动后会自动创建表所以账号至少要有建表权限也就是 CREATE、ALTER、INDEX、INSERT、UPDATE、DELETE、SELECT 这些。生产环境建议单独建账号别直接用 root。3.2 调度中心 YAML多副本 探针 外部访问下面这份 YAML 是调度中心的完整部署清单包含了 Deployment 和 Service 两部分。replicas 设置为 2让调度中心具备基本的 HA 能力NodePort 暴露给外部访问控制台方便查看任务情况和调度日志。apiVersion: apps/v1 kind: Deployment metadata: name: xxl-job-admin labels: app: xxl-job-admin spec: replicas: 2 selector: matchLabels: app: xxl-job-admin template: metadata: labels: app: xxl-job-admin spec: containers: - name: admin image: xuxueli/xxl-job-admin:2.4.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 name: http env: - name: PARAMS value: - --spring.datasource.urljdbc:mysql://mysql:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue --spring.datasource.usernamexxljob --spring.datasource.passwordYourPassword --xxl.job.accessTokenmy-token-2024 --xxl.job.i18nzh_CN - name: TZ value: Asia/Shanghai resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi readinessProbe: httpGet: path: /xxl-job-admin/toLogin port: 8080 initialDelaySeconds: 60 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: xxl-job-admin labels: app: xxl-job-admin spec: type: NodePort selector: app: xxl-job-admin ports: - name: http port: 8080 targetPort: 8080 nodePort: 30080PARAMS 是官方镜像约定的启动参数入口Spring Boot 的配置项都可以通过它传入。数据源连接串里必须带serverTimezoneAsia/ShanghaiMySQL 8 的驱动还需要allowPublicKeyRetrievaltrue否则会报认证插件相关的错误。xxl.job.accessToken是调度中心和执行器之间的握手凭证所有组件必须用同一个值。readinessProbe 探测/xxl-job-admin/toLogin如果返回 HTTP 200 说明 admin 已经能处理请求了。这个探针的意义在于多副本滚动更新时新 Pod 起不来就不会被 Service 纳入旧 Pod 可以继续扛流量。注意initialDelaySeconds给了 60 秒因为 admin 首次启动要做建表和数据源初始化探测太早只会看到连接失败。Service 这里用的是 NodePort端口 30080。内部执行器访问 admin 时走的是 Service 的 8080 端口也就是http://xxl-job-admin:8080/xxl-job-admin这个地址要写进执行器的配置。NodePort 只是给你自己在浏览器里打开控制台用的和内部调度链路没有关系。3.3 执行器 YAMLsample 镜像直接验证注意环境变量绑定规则为了方便你直接验证整条链路这里用官方 sample 执行器镜像xuxueli/xxl-job-executor-sample-springboot:2.4.0作为示例。这个镜像里内置了 demo 任务部署起来就能在控制台看到执行器注册上线。apiVersion: apps/v1 kind: Deployment metadata: name: xxl-job-executor labels: app: xxl-job-executor spec: replicas: 2 selector: matchLabels: app: xxl-job-executor template: metadata: labels: app: xxl-job-executor spec: containers: - name: executor image: xuxueli/xxl-job-executor-sample-springboot:2.4.0 imagePullPolicy: IfNotPresent ports: - containerPort: 9999 name: executor env: - name: XXL_JOB_ADMIN_ADDRESSES value: http://xxl-job-admin:8080/xxl-job-admin - name: XXL_JOB_ACCESS_TOKEN value: my-token-2024 - name: XXL_JOB_EXECUTOR_APPNAME value: xxl-job-executor-sample - name: XXL_JOB_EXECUTOR_PORT value: 9999 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 1 memory: 512Mi这串环境变量之所以能覆盖配置文件里的xxl.job.admin.addresses等属性靠的是 Spring Boot 的宽松绑定规则XXL_JOB_ADMIN_ADDRESSES可以映射到xxl.job.admin.addressesXXL_JOB_ACCESS_TOKEN映射到xxl.job.accessToken。不过这一点依赖 sample 工程是否开启了环境变量配置源如果你用的是自己打包的执行器镜像最稳妥的做法是直接在application.properties里写死这些配置项不要赌环境变量能被正确读取。执行器这里没有配 Service因为调度中心是通过 admin 的xxl-job-admin:8080主动回调执行器 Pod 的 9999 端口。两个副本会自动注册到调度中心在控制台的执行器管理页面里应该能看到两台在线机器。等到这一步整个闭环就通了调度中心发任务到执行器执行器跑完再回调 admin 上报结果。4. 避坑部署与调度最常见的五个翻车点4.1 执行器一直显示不在线现象调度中心控制台里执行器管理页面显示「不在线」手动调度任务时直接报「执行器地址为空」或者连接超时。原因最常见的是 accessToken 不一致执行器注册请求被调度中心直接拒绝。其次是把执行器 IP 写死成了宿主机 IP 或者 NodePort 地址Pod 重建后这个地址无法访问。还有一个隐蔽情况是执行器容器里xxl.job.executor.port配置的和实际监听端口不一致。解决先看执行器 Pod 日志里有没有xxl-job registry success这行字如果没有说明注册环节就失败了。确认所有组件的 accessToken 完全一致然后把xxl.job.executor.ip这项配置删掉让执行器自动探测容器 IP。最后在 admin Pod 里手动curl http://执行器PodIP:9999/验证网络可达性这个命令能直接区分是网络问题还是端口问题。4.2 admin 起不来反复 MySQL 连接失败现象admin Pod 启动后一直 CrashLoopBackOff日志里出现Communications link failure或者Access denied for user。原因MySQL 8 默认使用caching_sha2_password认证老版本的 MySQL 驱动不带上allowPublicKeyRetrievaltrue就会认证失败。另一个常见原因是连接串没写时区参数驱动报错后 admin 启动失败。还有不少人忘了先建库admin 连的库不存在数据源初始化直接异常。解决连接串统一带上serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueuseSSLfalse这几个参数。启动前先确认CREATE DATABASE IF NOT EXISTS xxl_job真的执行成功了。如果你想在集群内快速验证 MySQL 连通性可以起一个临时 Podkubectl run mysql-client --imagemysql:8.0 --rm -it -- bash进去后用mysql -h mysql -u xxljob -p实测一下账号和网络。4.3 任务跑完了调度日志却提示结果丢失现象业务代码明显执行了数据也写了但调度中心日志里显示「执行结果丢失」或者回调超时。原因执行器跑完任务后要回调 admin 的地址上报结果。如果执行器里xxl.job.admin.addresses配置的是 NodePort 地址比如http://节点IP:30080/xxl-job-admin而集群网络到 NodePort 的链路不通回调就会失败。另一个原因是执行器 Pod 没有声明 9999 端口虽然不声明也能监听但部分网络策略或者 Service Mesh 环境会把这个端口挡掉。解决把执行器里的 admin 地址改成集群内 Service 域名http://xxl-job-admin:8080/xxl-job-admin不要走 NodePort。检查集群里有没有 NetworkPolicy 限制了 Pod 间的端口访问。最后看执行器日志里有没有回调异常栈有的话把完整报错拉到群里对一下十有八九是地址配置问题。4.4 多副本部署后担心任务重复执行现象admin 起了两个副本感觉任务会不会同时被触发两次或者某个任务在同一时刻被调度了两次。原因XXL-JOB 用数据库行锁保证多副本互斥理论上不会重复调度。但如果你把各个副本的 accessToken 配得不一样又不影响调度互斥却会影响执行器握手。真正会导致重复调度的是集群节点时钟不同步两个副本的时间偏差超过一定范围后抢占锁的判断就会出现混乱。解决所有 admin 副本的 accessToken 保持一致这个参数在 2.4.0 版本里必须统一否则执行器会拒绝调度命令。给每个节点的/etc/chrony.conf配上统一的时间源确保 node 间时间差在 100ms 以内。然后随便找一个任务把调度频率调到每 10 秒一次观察一段时间确认调度日志里没有同一时刻的重复触发记录基本就能放心了。4.5 容器被 OOMKilled执行器无限重启现象Pod 状态反复 CrashLoopBackOffkubectl describe pod里显示Last State: OOMKilled任务频繁丢失。原因官方镜像默认给 JVM 分配了较大的堆内存比如-Xmx1g甚至更高而容器 limits 只给了 256Mi 或 512MiJVM 还没起来就被 cgroup 杀掉了。很多人只调了 YAML 里的 resources没有改镜像里的 JVM 参数所以问题一直复现。解决先用kubectl describe pod确认是不是 OOMKilled。如果是优先把 limits.memory 调到 1Gi 以上给 JVM 留足堆和元空间。想精细控制的话在执行器自己的 Dockerfile 里通过JAVA_OPTS环境变量覆盖启动参数比如-Xmx512m -Xms256m。admin 也一样别把 limits.memory 压到 512Mi 以下它要加载一堆类内存紧张时会出现各种莫名其妙的启动超时。5. 部署完怎么确认真的成了三查两验 滚动发布技巧5.1 三查Pod 状态、在线机器数、启动日志部署完成后的第一件事不是急着建任务而是先看三层状态。第一层是 Pod 本身kubectl get pods -o wide确认 admin 和 executor 都处于 Running 状态并且能看到它们各自的 Pod IP。第二层是调度中心控制台打开http://节点IP:30080/xxl-job-admin用默认账号 admin/123456 登录到执行器管理页面确认两台执行器显示在线。第三层是日志kubectl logs -f deployment/xxl-job-executor --tail50里应该能看到执行器启动完成和注册成功的记录。这三层都过了说明镜像没问题、数据库没问题、网络链路没问题。如果卡在第二层回去看 4.1 的排查路径如果卡在第三层大概率是环境变量没生效去核对 Spring Boot 的宽松绑定规则。5.2 两验手动触发一次任务再跑一个五秒循环任务控制台里找到 sample 执行器自带的 demo 任务点一次「执行一次」。跑完之后看调度日志应该有两条记录一条是调度中心的触发记录一条是执行器的执行结果。再看执行器 Pod 日志能对上同一批日志输出说明调用链路完整。第二验是新建一个 Cron 表达式为0/5 * * * * ?的简单任务执行器选刚注册的 sample观察十分钟。重点看执行日志里每次触发的执行机器是不是在两个 Pod 之间轮换如果是说明多副本注册和调度分配都正常。这里能直观感受到 XXL-JOB 的调度能力也是后续做分片广播任务的基础。5.3 滚动发布时别让任务断档执行器升级镜像时直接用kubectl rollout restart deployment/xxl-job-executor触发滚动更新。但因为每个 Pod 重启都会有一段时间从 admin 下线正在执行中的任务会被打断。我一般会在 Deployment 里加一个minReadySeconds: 30让新 Pod 起来后先运行 30 秒确认稳定再继续滚下一个。kubectl set env deployment/xxl-job-executor XXL_JOB_EXECUTOR_APPNAMExxl-job-executor-sample kubectl rollout status deployment/xxl-job-executor滚动发布过程中盯着调度中心执行器管理页你会发现在线数会短暂从 2 降到 1再恢复到 2。这是正常现象只要不是同时降到 0 就不用慌。从那以后我每到一个新集群都会强制走一遍「三查两验」的流程再去接业务任务宁可多花五分钟验证链路也不愿意等业务方报障说任务没跑。希望帮到你。本文还有配套的精品资源点击获取
简介一份面向Kubernetes运维与开发人员的XXL-JOB容器化部署配置基于实际集群环境验证通过适用于需要快速上线xxl-job调度中心或调整既有部署方案的场景。资源包整体极为精简仅含1个yaml文件压缩包大小782B该文件将xxl-job在K8s中运行所需的资源定义集中在一起直接应用即可完成基础部署省去从零编写配置的时间同时避免因版本或环境差异导致的常见坑点。目前已有645人学习下载适合中高级K8s使用者作为参考也适合团队内部搭建任务调度平台时作为起始模板。对于刚接触xxl-job容器化的读者这份配置能帮助理解核心资源结构对于有经验的读者则可作为快速验证与对照排错的便捷工具。无论是微服务架构中的定时任务场景还是独立部署的任务调度中心这套YAML都能提供清晰可复用的落地样板。1. XXL-JOB 上 K8s为什么说这套部署验证版 YAML 比你自己写的少踩一半坑先说结论XXL-JOB 容器化部署卡住你的往往不是 YAML 语法而是调度中心和执行器之间「怎么互相找到对方」。这套部署验证版的 YAML 把调度中心、执行器、数据库连接、路由暴露全部整理成了可以直接 apply 的形态解决的是 Java 定时任务从单体迁移到 K8s 集群后怎么保留分片广播、失败重试和完整调度日志的问题。适合正在把 Spring Boot 任务逐个迁进 K8s、又被 CronJob 单副本限制坑过的后端开发和运维同学。CronJob 只能按 Cron 触发单个 Pod做不到分片广播也没有失败重试和调度报表所以不少团队最终都会回到 XXL-JOB 这类专业调度平台上。2. 先搞懂两个角色调度中心与执行器的镜像和连接逻辑2.1 调度中心一个会自动建表的 Spring Boot 服务XXL-JOB 的调度中心admin本质是一个 Spring Boot 应用官方镜像xuxueli/xxl-job-admin:2.4.0把整个 Web 控制台、调度触发器、任务管理都打包好了。它启动时会自动执行内置的建表 SQL把xxl_job_info、xxl_job_log、xxl_job_registry这些核心表建出来。换句话说你只需要提前建好数据库表结构不用手动导入这是很多人第一次部署时没想到的。admin 能多副本跑是因为任务调度靠数据库行锁做抢占同一时刻只有一个副本能拿到触发权。所以集群里跑两个 admin Pod 是安全的不会出现同一个任务被两个调度中心重复触发。但这个前提是多个副本连的是同一个 MySQL并且xxl.job.accessToken完全一致。只要这两个条件满足调度中心就可以像无状态服务一样水平扩展。调度中心的启动参数是通过PARAMS环境变量传入的官方镜像的启动脚本会把PARAMS的内容拼到 Java 命令后面。常见的配置包括数据源地址、账号密码、accessToken、时区、国际化语言。这部分参数直接影响 admin 能不能连上数据库以及执行器能不能握手成功部署前最好先把这一层逻辑理清。2.2 执行器真正跑任务的 Pod端口和注册方式才是关键执行器是嵌入在你业务应用里的一个 SDK 组件xxl-job-core它会在应用内部起一个 Netty HTTP 服务监听xxl.job.executor.port指定的端口默认 9999等待调度中心把任务命令推过来。在这个体系里真正干活的是执行器 Pod调度中心只负责按 Cron 表达式、分片参数等规则把任务发给对应的执行器。执行器启动后会向调度中心注册自己的地址。自动注册模式下它上报的是 Pod 的 IP 和端口。这意味着调度中心必须能在集群网络里直接访问到执行器 Pod 的 9999 端口两者在同一 namespace 下是最稳妥的。很多人在这里翻车是因为把执行器端口配成了 NodePort 或者宿主机端口又或者在配置里写死了执行器 IP结果 Pod 重建后地址漂移调度中心再也连不上。还有一个值得注意的设计执行器不需要对外暴露 Service。调度是 admin 主动回调执行器端口而不是执行器主动连 admin 的 Service。所以执行器的 YAML 里只需要声明 containerPort不需要配 Service。理解了这个单向调用关系后面排查网络问题时思路会清晰很多。3. 直接可用的 YAML从建库到调度中心、执行器一起上线3.1 先准备数据库只需要建库表结构由 admin 自动完成我这里假设你的 K8s 集群里已经有一个可用的 MySQL 实例或者公司有现成的 MySQL 服务可以连。如果没有建议先在集群里用 StatefulSet 部署一个 MySQL 8.x注意给它配持久化存储不然重启一次数据就没了。在连接串指向的 MySQL 实例上先执行这条 SQL 把库建出来CREATE DATABASE IF NOT EXISTS xxl_job DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;建库这一步是必须的。admin 镜像启动时只会建表不会建库如果库不存在数据源初始化会直接报错。字符集这里用 utf8mb4 是为了兼容任务参数里可能出现的表情符号或中文特殊字符。表结构不需要手动导入admin 第一次启动时会自动完成。如果你用的是已有的 MySQL建议对账号做最小权限授权只给xxl_job库的 DML 权限就够了。admin 启动后会自动创建表所以账号至少要有建表权限也就是 CREATE、ALTER、INDEX、INSERT、UPDATE、DELETE、SELECT 这些。生产环境建议单独建账号别直接用 root。3.2 调度中心 YAML多副本 探针 外部访问下面这份 YAML 是调度中心的完整部署清单包含了 Deployment 和 Service 两部分。replicas 设置为 2让调度中心具备基本的 HA 能力NodePort 暴露给外部访问控制台方便查看任务情况和调度日志。apiVersion: apps/v1 kind: Deployment metadata: name: xxl-job-admin labels: app: xxl-job-admin spec: replicas: 2 selector: matchLabels: app: xxl-job-admin template: metadata: labels: app: xxl-job-admin spec: containers: - name: admin image: xuxueli/xxl-job-admin:2.4.0 imagePullPolicy: IfNotPresent ports: - containerPort: 8080 name: http env: - name: PARAMS value: - --spring.datasource.urljdbc:mysql://mysql:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue --spring.datasource.usernamexxljob --spring.datasource.passwordYourPassword --xxl.job.accessTokenmy-token-2024 --xxl.job.i18nzh_CN - name: TZ value: Asia/Shanghai resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi readinessProbe: httpGet: path: /xxl-job-admin/toLogin port: 8080 initialDelaySeconds: 60 periodSeconds: 10 --- apiVersion: v1 kind: Service metadata: name: xxl-job-admin labels: app: xxl-job-admin spec: type: NodePort selector: app: xxl-job-admin ports: - name: http port: 8080 targetPort: 8080 nodePort: 30080PARAMS 是官方镜像约定的启动参数入口Spring Boot 的配置项都可以通过它传入。数据源连接串里必须带serverTimezoneAsia/ShanghaiMySQL 8 的驱动还需要allowPublicKeyRetrievaltrue否则会报认证插件相关的错误。xxl.job.accessToken是调度中心和执行器之间的握手凭证所有组件必须用同一个值。readinessProbe 探测/xxl-job-admin/toLogin如果返回 HTTP 200 说明 admin 已经能处理请求了。这个探针的意义在于多副本滚动更新时新 Pod 起不来就不会被 Service 纳入旧 Pod 可以继续扛流量。注意initialDelaySeconds给了 60 秒因为 admin 首次启动要做建表和数据源初始化探测太早只会看到连接失败。Service 这里用的是 NodePort端口 30080。内部执行器访问 admin 时走的是 Service 的 8080 端口也就是http://xxl-job-admin:8080/xxl-job-admin这个地址要写进执行器的配置。NodePort 只是给你自己在浏览器里打开控制台用的和内部调度链路没有关系。3.3 执行器 YAMLsample 镜像直接验证注意环境变量绑定规则为了方便你直接验证整条链路这里用官方 sample 执行器镜像xuxueli/xxl-job-executor-sample-springboot:2.4.0作为示例。这个镜像里内置了 demo 任务部署起来就能在控制台看到执行器注册上线。apiVersion: apps/v1 kind: Deployment metadata: name: xxl-job-executor labels: app: xxl-job-executor spec: replicas: 2 selector: matchLabels: app: xxl-job-executor template: metadata: labels: app: xxl-job-executor spec: containers: - name: executor image: xuxueli/xxl-job-executor-sample-springboot:2.4.0 imagePullPolicy: IfNotPresent ports: - containerPort: 9999 name: executor env: - name: XXL_JOB_ADMIN_ADDRESSES value: http://xxl-job-admin:8080/xxl-job-admin - name: XXL_JOB_ACCESS_TOKEN value: my-token-2024 - name: XXL_JOB_EXECUTOR_APPNAME value: xxl-job-executor-sample - name: XXL_JOB_EXECUTOR_PORT value: 9999 resources: requests: cpu: 200m memory: 256Mi limits: cpu: 1 memory: 512Mi这串环境变量之所以能覆盖配置文件里的xxl.job.admin.addresses等属性靠的是 Spring Boot 的宽松绑定规则XXL_JOB_ADMIN_ADDRESSES可以映射到xxl.job.admin.addressesXXL_JOB_ACCESS_TOKEN映射到xxl.job.accessToken。不过这一点依赖 sample 工程是否开启了环境变量配置源如果你用的是自己打包的执行器镜像最稳妥的做法是直接在application.properties里写死这些配置项不要赌环境变量能被正确读取。执行器这里没有配 Service因为调度中心是通过 admin 的xxl-job-admin:8080主动回调执行器 Pod 的 9999 端口。两个副本会自动注册到调度中心在控制台的执行器管理页面里应该能看到两台在线机器。等到这一步整个闭环就通了调度中心发任务到执行器执行器跑完再回调 admin 上报结果。4. 避坑部署与调度最常见的五个翻车点4.1 执行器一直显示不在线现象调度中心控制台里执行器管理页面显示「不在线」手动调度任务时直接报「执行器地址为空」或者连接超时。原因最常见的是 accessToken 不一致执行器注册请求被调度中心直接拒绝。其次是把执行器 IP 写死成了宿主机 IP 或者 NodePort 地址Pod 重建后这个地址无法访问。还有一个隐蔽情况是执行器容器里xxl.job.executor.port配置的和实际监听端口不一致。解决先看执行器 Pod 日志里有没有xxl-job registry success这行字如果没有说明注册环节就失败了。确认所有组件的 accessToken 完全一致然后把xxl.job.executor.ip这项配置删掉让执行器自动探测容器 IP。最后在 admin Pod 里手动curl http://执行器PodIP:9999/验证网络可达性这个命令能直接区分是网络问题还是端口问题。4.2 admin 起不来反复 MySQL 连接失败现象admin Pod 启动后一直 CrashLoopBackOff日志里出现Communications link failure或者Access denied for user。原因MySQL 8 默认使用caching_sha2_password认证老版本的 MySQL 驱动不带上allowPublicKeyRetrievaltrue就会认证失败。另一个常见原因是连接串没写时区参数驱动报错后 admin 启动失败。还有不少人忘了先建库admin 连的库不存在数据源初始化直接异常。解决连接串统一带上serverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrueuseSSLfalse这几个参数。启动前先确认CREATE DATABASE IF NOT EXISTS xxl_job真的执行成功了。如果你想在集群内快速验证 MySQL 连通性可以起一个临时 Podkubectl run mysql-client --imagemysql:8.0 --rm -it -- bash进去后用mysql -h mysql -u xxljob -p实测一下账号和网络。4.3 任务跑完了调度日志却提示结果丢失现象业务代码明显执行了数据也写了但调度中心日志里显示「执行结果丢失」或者回调超时。原因执行器跑完任务后要回调 admin 的地址上报结果。如果执行器里xxl.job.admin.addresses配置的是 NodePort 地址比如http://节点IP:30080/xxl-job-admin而集群网络到 NodePort 的链路不通回调就会失败。另一个原因是执行器 Pod 没有声明 9999 端口虽然不声明也能监听但部分网络策略或者 Service Mesh 环境会把这个端口挡掉。解决把执行器里的 admin 地址改成集群内 Service 域名http://xxl-job-admin:8080/xxl-job-admin不要走 NodePort。检查集群里有没有 NetworkPolicy 限制了 Pod 间的端口访问。最后看执行器日志里有没有回调异常栈有的话把完整报错拉到群里对一下十有八九是地址配置问题。4.4 多副本部署后担心任务重复执行现象admin 起了两个副本感觉任务会不会同时被触发两次或者某个任务在同一时刻被调度了两次。原因XXL-JOB 用数据库行锁保证多副本互斥理论上不会重复调度。但如果你把各个副本的 accessToken 配得不一样又不影响调度互斥却会影响执行器握手。真正会导致重复调度的是集群节点时钟不同步两个副本的时间偏差超过一定范围后抢占锁的判断就会出现混乱。解决所有 admin 副本的 accessToken 保持一致这个参数在 2.4.0 版本里必须统一否则执行器会拒绝调度命令。给每个节点的/etc/chrony.conf配上统一的时间源确保 node 间时间差在 100ms 以内。然后随便找一个任务把调度频率调到每 10 秒一次观察一段时间确认调度日志里没有同一时刻的重复触发记录基本就能放心了。4.5 容器被 OOMKilled执行器无限重启现象Pod 状态反复 CrashLoopBackOffkubectl describe pod里显示Last State: OOMKilled任务频繁丢失。原因官方镜像默认给 JVM 分配了较大的堆内存比如-Xmx1g甚至更高而容器 limits 只给了 256Mi 或 512MiJVM 还没起来就被 cgroup 杀掉了。很多人只调了 YAML 里的 resources没有改镜像里的 JVM 参数所以问题一直复现。解决先用kubectl describe pod确认是不是 OOMKilled。如果是优先把 limits.memory 调到 1Gi 以上给 JVM 留足堆和元空间。想精细控制的话在执行器自己的 Dockerfile 里通过JAVA_OPTS环境变量覆盖启动参数比如-Xmx512m -Xms256m。admin 也一样别把 limits.memory 压到 512Mi 以下它要加载一堆类内存紧张时会出现各种莫名其妙的启动超时。5. 部署完怎么确认真的成了三查两验 滚动发布技巧5.1 三查Pod 状态、在线机器数、启动日志部署完成后的第一件事不是急着建任务而是先看三层状态。第一层是 Pod 本身kubectl get pods -o wide确认 admin 和 executor 都处于 Running 状态并且能看到它们各自的 Pod IP。第二层是调度中心控制台打开http://节点IP:30080/xxl-job-admin用默认账号 admin/123456 登录到执行器管理页面确认两台执行器显示在线。第三层是日志kubectl logs -f deployment/xxl-job-executor --tail50里应该能看到执行器启动完成和注册成功的记录。这三层都过了说明镜像没问题、数据库没问题、网络链路没问题。如果卡在第二层回去看 4.1 的排查路径如果卡在第三层大概率是环境变量没生效去核对 Spring Boot 的宽松绑定规则。5.2 两验手动触发一次任务再跑一个五秒循环任务控制台里找到 sample 执行器自带的 demo 任务点一次「执行一次」。跑完之后看调度日志应该有两条记录一条是调度中心的触发记录一条是执行器的执行结果。再看执行器 Pod 日志能对上同一批日志输出说明调用链路完整。第二验是新建一个 Cron 表达式为0/5 * * * * ?的简单任务执行器选刚注册的 sample观察十分钟。重点看执行日志里每次触发的执行机器是不是在两个 Pod 之间轮换如果是说明多副本注册和调度分配都正常。这里能直观感受到 XXL-JOB 的调度能力也是后续做分片广播任务的基础。5.3 滚动发布时别让任务断档执行器升级镜像时直接用kubectl rollout restart deployment/xxl-job-executor触发滚动更新。但因为每个 Pod 重启都会有一段时间从 admin 下线正在执行中的任务会被打断。我一般会在 Deployment 里加一个minReadySeconds: 30让新 Pod 起来后先运行 30 秒确认稳定再继续滚下一个。kubectl set env deployment/xxl-job-executor XXL_JOB_EXECUTOR_APPNAMExxl-job-executor-sample kubectl rollout status deployment/xxl-job-executor滚动发布过程中盯着调度中心执行器管理页你会发现在线数会短暂从 2 降到 1再恢复到 2。这是正常现象只要不是同时降到 0 就不用慌。从那以后我每到一个新集群都会强制走一遍「三查两验」的流程再去接业务任务宁可多花五分钟验证链路也不愿意等业务方报障说任务没跑。希望帮到你。本文还有配套的精品资源点击获取
