簡介面向需要在 Kubernetes 集群中落地定時任務(wù)調(diào)度的運(yùn)維與后端開發(fā)人群這份 XXL-JOB 容器化部署 YAML 可作為直接應(yīng)用的部署清單重點(diǎn)解決集群環(huán)境下任務(wù)調(diào)度組件編排與快速驗(yàn)證的問題。壓縮包內(nèi)僅含 1 個 YAML 文件類型為 yaml體積約 782B內(nèi)容緊湊便于按需修改鏡像、命名空間與資源配置后提交集群。已有 647 人學(xué)習(xí)下載說明其在實(shí)際部署場景中具備一定參考價值。讀者可直接獲得一份經(jīng)過驗(yàn)證的集群部署配置用于理解 XXL-JOB 在 K8S 中的服務(wù)、容器與調(diào)度組件組織方式并作為環(huán)境搭建、參數(shù)對照和部署排錯的起點(diǎn)適合具備基礎(chǔ) K8S 操作經(jīng)驗(yàn)、希望縮短驗(yàn)證路徑的讀者使用。1. 為什么先在 K8s 里跑通 XXL-JOB一個版本坑換來的教訓(xùn)上個月接手一個 XXL-JOB K8s 集群部署的爛攤子調(diào)度中心 Pod 反復(fù) CrashLoopBackOff執(zhí)行器在管理頁面里掛著一排“離線”業(yè)務(wù)方以為任務(wù)在跑實(shí)際三天沒觸發(fā)。排查兩小時根因是 YAML 里鏡像 tag 寫成了 latest節(jié)點(diǎn)上緩存的舊鏡像和新配置對不上。這類 xxljob 容器化部署的活兒最怕的就是“YAML 文件直接部署成功”這句話被當(dāng)成結(jié)論——apply 返回 created 不等于系統(tǒng)能跑。XXL-JOB 的結(jié)構(gòu)不復(fù)雜一個調(diào)度中心 admin、若干執(zhí)行器 executor、一個 MySQL。但搬到 K8s 之后注冊地址、時區(qū)、探針路徑、鏡像拉取策略每一項(xiàng)都能單獨(dú)翻車。這篇裝過的記錄適合正準(zhǔn)備把調(diào)度中心塞進(jìn)集群的人也適合已經(jīng) apply 完但頁面打不開、執(zhí)行器注冊不上的情況。2. 部署前把環(huán)境列清楚K8s 版本、鏡像 tag 和五個 YAML 的分工動手之前先把版本和資源對一遍這一步省掉后面所有報錯都會變成黑匣子。2.1 集群版本與命名空間的硬性檢查XXL-JOB 本身的 YAML 只用到 Deployment、Service、ConfigMap 這幾類基礎(chǔ)資源對集群版本不挑。真正會卡人的是 Ingress 和 RBAC 這兩塊K8s 1.22 之后extensions/v1beta1和networking.k8s.io/v1beta1的 Ingress 全部下線一份兩三年前下載的 YAML 直接 apply 會報no matches for kind Ingress1.25 之后 PodSecurityPolicy 被移除如果你的 YAML 里還掛著 PSP 引用整個 apply 會中斷。我一般先跑這四條確認(rèn)底子# 客戶端與服務(wù)端版本重點(diǎn)看 Minor 是否 22 kubectl version --short # 節(jié)點(diǎn)狀態(tài)和容器運(yùn)行時確認(rèn)沒有 NotReady 節(jié)點(diǎn) kubectl get nodes -o wide # 確認(rèn) Ingress API 用的是 v1 kubectl api-resources | grep ingress # 建獨(dú)立命名空間別和業(yè)務(wù)擠在 default kubectl create namespace xxl-job kubectl config set-context --current --namespacexxl-job參數(shù)上沒什么可調(diào)的重點(diǎn)是把--namespace固定下來。后面所有命令都默認(rèn)落在這個命名空間能避免“資源建到默認(rèn)命名空間去了”這種低級但高頻的問題。如果集群開了 NetworkPolicy 默認(rèn)拒絕還要提前放通 admin 的 8080 和執(zhí)行器的 9999否則注冊心跳會被靜默丟掉頁面上就是一直離線。資源配額也要看一眼。調(diào)度中心本身不重但我見過給 256Mi limit 的JVM 堆加元空間直接頂?shù)?OOMKilled重啟循環(huán)起來比配置錯誤更難查。2.2 鏡像 tag 的選擇別用 latest也別每次重啟都拉這是踩過最疼的一腳。latest配imagePullPolicy: Always意味著每次 Pod 重建都要去倉庫拉一次倉庫一抖動Pod 就ImagePullBackOff而滾動更新時因?yàn)?tag 沒變K8s 認(rèn)為鏡像沒變化新配置根本不會生效——現(xiàn)象是“我改了 YAML怎么還是老行為”。正確的做法是 tag 寫死到具體版本拉取策略用IfNotPresent私有倉庫提前把憑據(jù)建好# 私有倉庫憑據(jù)只需建一次 kubectl -n xxl-job create secret docker-registry registry-cred \ --docker-serverregistry.example.com \ --docker-usernamerobot_deploy \ --docker-password********spec: containers: - name: admin image: registry.example.com/middleware/xxl-job-admin:TAG # TAG 換成你實(shí)際驗(yàn)證過的版本 imagePullPolicy: IfNotPresent imagePullSecrets: - name: registry-credTAG這塊別照抄網(wǎng)上的看你下載的這套 YAML 里寫的是哪個版本就以哪個為準(zhǔn)。admin 有官方鏡像執(zhí)行器沒有——執(zhí)行器是你自己的業(yè)務(wù)鏡像這一點(diǎn)后面單獨(dú)講很多人卡在這兒以為執(zhí)行器也能拉一個現(xiàn)成的。2.3 YAML 清單拆解五個文件各管什么、按什么順序 apply一套能直接跑的部署文件通常拆成五份按依賴順序落地序號文件資源類型作用依賴0100-namespace.yamlNamespace隔離環(huán)境無0201-mysql-init.sqlSQL 腳本建庫建表MySQL 實(shí)例0302-configmap.yamlConfigMap數(shù)據(jù)源、token 等參數(shù)無0403-admin.yamlDeployment Service調(diào)度中心數(shù)據(jù)庫、ConfigMap0504-executor.yamlDeployment Service業(yè)務(wù)執(zhí)行器admin 的 Service順序錯了不會立刻報錯但會浪費(fèi)時間。比如先起 admin 再建庫Pod 會一直重啟你在日志里看到的是連接拒絕得從頭猜。我習(xí)慣先把 01 的 SQL 在數(shù)據(jù)庫里跑完再一次性apply -f .最后rollout status等就緒。2.4 數(shù)據(jù)庫這一層不能省版本、字符集和那張鎖表XXL-JOB 的元數(shù)據(jù)全在 MySQL 里表不多但一張都不能少。MySQL 5.7 和 8.0 都能跑差別在驅(qū)動類名和默認(rèn)排序規(guī)則5.7 用com.mysql.jdbc.Driver8.0 必須用com.mysql.cj.jdbc.Driver寫錯就是啟動時ClassNotFoundException。字符集統(tǒng)一到utf8mb4排序規(guī)則顯式指定utf8mb4_general_ci。8.0 默認(rèn)是utf8mb4_0900_ai_ci如果建庫時用了默認(rèn)值后面和 5.7 的環(huán)境做數(shù)據(jù)遷移會撞上Illegal mix of collations這個錯在跨環(huán)境同步任務(wù)配置時特別常見。還有一張容易被忽略的表xxl_job_lock。調(diào)度中心多副本部署時靠它做數(shù)據(jù)庫層面的分布式鎖保證同一個任務(wù)不會被兩個 admin 同時觸發(fā)。有人“清理冗余表”把它刪了結(jié)果就是任務(wù)重復(fù)執(zhí)行日志里還看不出異?！@張表是集群模式的后悔藥別動。3. 從 apply 到三個 Pod 起來XXL-JOB 的 YAML 按什么順序落地3.1 先建庫導(dǎo)表再談部署數(shù)據(jù)庫沒準(zhǔn)備好后面全是白搭。建庫語句顯式寫字符集和排序規(guī)則CREATE DATABASE IF NOT EXISTS xxl_job DEFAULT CHARACTER SET utf8mb4 DEFAULT COLLATE utf8mb4_general_ci; -- 建一個專用賬號別用 root 跑調(diào)度中心 CREATE USER xxl_job% IDENTIFIED BY ********; GRANT ALL PRIVILEGES ON xxl_job.* TO xxl_job%; FLUSH PRIVILEGES;然后導(dǎo)入隨包的tables_xxl_job.sql。如果 MySQL 跑在集群內(nèi)用一次性的 Job 或直接 exec 進(jìn)去導(dǎo)# 從本機(jī)把 SQL 灌進(jìn)集群里的 MySQL Pod kubectl -n middleware exec -i mysql-0 -- \ mysql -uxxl_job -p******** xxl_job tables_xxl_job.sql # 確認(rèn)關(guān)鍵表都在 kubectl -n middleware exec -i mysql-0 -- \ mysql -uxxl_job -p******** -e use xxl_job; show tables;期望看到xxl_job_info、xxl_job_log、xxl_job_group、xxl_job_registry、xxl_job_lock這些表。少一張admin 啟動時就會在初始化那一步拋異常日志里是一長串 MyBatis 的映射錯誤看著嚇人其實(shí)回去補(bǔ)表就行。3.2 admin 的 DeploymentPARAMS、探針和資源三處必須改調(diào)度中心的鏡像啟動腳本支持用PARAMS環(huán)境變量透傳 Spring Boot 參數(shù)這是最省事的做法不用自己打包 configmap 掛載。核心片段apiVersion: apps/v1 kind: Deployment metadata: name: xxl-job-admin namespace: xxl-job spec: replicas: 1 selector: matchLabels: app: xxl-job-admin template: metadata: labels: app: xxl-job-admin spec: containers: - name: admin image: registry.example.com/middleware/xxl-job-admin:TAG imagePullPolicy: IfNotPresent ports: - containerPort: 8080 env: - name: TZ value: Asia/Shanghai - name: PARAMS value: - --spring.datasource.urljdbc:mysql://mysql.middleware.svc.cluster.local:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltrue --spring.datasource.usernamexxl_job --spring.datasource.password******** --xxl.job.accessToken******** resources: requests: cpu: 500m memory: 512Mi limits: cpu: 1 memory: 1Gi readinessProbe: httpGet: path: /xxl-job-admin/toLogin port: 8080 initialDelaySeconds: 40 periodSeconds: 10 failureThreshold: 6 livenessProbe: tcpSocket: port: 8080 initialDelaySeconds: 90 periodSeconds: 20幾處細(xì)節(jié)值得說PARAMS里的連接串用-折疊寫法拼成一行注意在 YAML 里別裸寫在行首放在字符串中間沒問題但保險起見整段加引號或折疊塊。探針路徑必須是/xxl-job-admin/toLogin不是根路徑/。admin 是傳統(tǒng) Spring MVC 應(yīng)用根路徑返回 302 到登錄頁有些探針配置不跟隨跳轉(zhuǎn)就會判定失敗Pod 永遠(yuǎn)不 ReadyService 后面一個可用端點(diǎn)都沒有你以為是服務(wù)掛了其實(shí)是探針寫錯了。initialDelaySeconds給到 40 秒以上是因?yàn)槭状螁右跏蓟瘮?shù)據(jù)庫連接池和調(diào)度線程太快探活會把正常啟動判死。liveness 用 tcpSocket 而不是 httpGet是為了避免數(shù)據(jù)庫短時抖動導(dǎo)致探針失敗引發(fā)重啟——重啟解決不了數(shù)據(jù)庫問題只會讓啟動更慢。3.3 執(zhí)行器不是官方鏡像業(yè)務(wù)鏡像怎么接進(jìn) YAML這是新手最容易誤解的一環(huán)。執(zhí)行器沒有現(xiàn)成鏡像可拉它是你自己的 Spring Boot 應(yīng)用引入xxl-job-core依賴后打包再寫一個配置類把執(zhí)行器注冊上去Configuration public class XxlJobConfig { Value(${xxl.job.admin.addresses}) private String adminAddresses; Value(${xxl.job.accessToken}) private String accessToken; Value(${xxl.job.executor.appname}) private String appName; Value(${xxl.job.executor.port:9999}) private int port; Bean public XxlJobSpringExecutor xxlJobExecutor() { XxlJobSpringExecutor executor new XxlJobSpringExecutor(); executor.setAdminAddresses(adminAddresses); // 調(diào)度中心地址多個用逗號分隔 executor.setAppname(appName); // 執(zhí)行器名要和 admin 頁面里錄入的一致 executor.setPort(port); // 內(nèi)置 Netty 端口默認(rèn) 9999 executor.setAccessToken(accessToken); // 必須和 admin 完全一致 executor.setLogPath(/data/applogs/xxl-job/jobhandler); // 任務(wù)日志落盤路徑 executor.setLogRetentionDays(7); // 日志保留天數(shù)按磁盤容量調(diào) return executor; } }setAppname的值是執(zhí)行器和調(diào)度中心之間的約定鍵admin 頁面里“執(zhí)行器管理”新增的那條記錄AppName 必須和這里一字不差大小寫、橫線都算。setPort對應(yīng)的容器端口要一起暴露YAML 里containerPort: 9999加上 Service 的 9999 映射少一個注冊就上不去。setLogPath指向的目錄建議掛emptyDir或 PVC。容器重啟后日志丟失任務(wù)失敗時你連執(zhí)行輸出都看不到只剩一個失敗狀態(tài)排查全靠猜。執(zhí)行器的 Deployment 本體和 admin 差不多主要是PARAMS換成執(zhí)行器自己的參數(shù)env: - name: PARAMS value: - --xxl.job.admin.addresseshttp://xxl-job-admin:8080/xxl-job-admin --xxl.job.executor.appnamexxl-job-executor-demo --xxl.job.executor.port9999 --xxl.job.accessToken********地址里用的是 admin 的 Service 名xxl-job-admin同命名空間內(nèi)可直接解析不必寫完整域名?？缑臻g就補(bǔ)上.xxl-job.svc.cluster.local。3.4 對外暴露ClusterIP、NodePort、Ingress 三選一內(nèi)部使用只需要 ClusterIP業(yè)務(wù)方通過集群內(nèi)域名訪問。要從辦公網(wǎng)打開管理頁面再選 NodePort 或 Ingress。Ingress 的寫法在 1.22 之后必須是 v1apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: xxl-job-admin namespace: xxl-job spec: ingressClassName: nginx rules: - host: xxl-job.example.com http: paths: - path: /xxl-job-admin pathType: Prefix backend: service: name: xxl-job-admin port: number: 8080注意path要帶上應(yīng)用上下文/xxl-job-admin只寫/的話靜態(tài)資源和接口路徑會對不上頁面能打開但登錄請求 404。如果必須在根路徑訪問就得在 admin 啟動參數(shù)里改server.servlet.context-path但改了之后執(zhí)行器注冊地址也要跟著改牽一發(fā)動全身不如路徑帶前綴。4. 配置項(xiàng)逐個過數(shù)據(jù)源、accessToken、執(zhí)行器地址這三處最容易寫錯4.1 數(shù)據(jù)源URL 里四個參數(shù)不能少連接串看著簡單實(shí)際有四個參數(shù)直接影響能不能連上、連上之后行為對不對spring.datasource.urljdbc:mysql://mysql.middleware.svc.cluster.local:3306/xxl_job?useUnicodetruecharacterEncodingUTF-8serverTimezoneAsia/ShanghaiuseSSLfalseallowPublicKeyRetrievaltruerewriteBatchedStatementstrue spring.datasource.usernamexxl_job spring.datasource.password******** spring.datasource.driver-class-namecom.mysql.cj.jdbc.Driver spring.datasource.hikari.maximum-pool-size20 spring.datasource.hikari.minimum-idle5 spring.datasource.hikari.connection-timeout30000 spring.datasource.hikari.idle-timeout600000serverTimezone不寫MySQL 8.0 驅(qū)動會按 UTC 解釋時間任務(wù)的下次觸發(fā)時間整體偏 8 小時useSSLfalse在集群內(nèi)部通常直接關(guān)掉開著但沒配證書會建立連接失敗allowPublicKeyRetrievaltrue是 8.0 默認(rèn)加密方式下的必需項(xiàng)少了報Public Key Retrieval is not allowedrewriteBatchedStatementstrue對日志批量寫入有幫助調(diào)度中心的日志表增長很快這個參數(shù)能讓批量插入真正合并。連接池上限別拍腦袋寫大。調(diào)度中心是單實(shí)例長連接為主20 個連接足夠設(shè)成 100 反而可能把數(shù)據(jù)庫的max_connections吃滿影響同實(shí)例上的其他庫。4.2 accessToken兩端必須完全一致空值也不行1.9 之后版本默認(rèn)啟用通信校驗(yàn)admin 的xxl.job.accessToken和執(zhí)行器的setAccessToken必須是同一串字符。實(shí)踐里有三種寫法會導(dǎo)致注冊失敗admin 設(shè)了、執(zhí)行器沒設(shè)兩邊設(shè)了但一個有空格用了特殊字符在PARAMS透傳時被 shell 解釋。建議用純字母數(shù)字的 32 位串兩邊都從同一個配置源取。如果 admin 用 ConfigMap、執(zhí)行器用環(huán)境變量記得改的時候一起改。校驗(yàn)失敗的表現(xiàn)很隱蔽執(zhí)行器日志里是 401 或者“registry fail”admin 頁面上看不到機(jī)器任務(wù)調(diào)度時報“執(zhí)行器地址為空”。臨時排查可以先把兩邊都置空驗(yàn)證鏈路是否通確認(rèn)后再填回去。但生產(chǎn)環(huán)境不要長期空著等于把注冊接口完全敞開。4.3 執(zhí)行器注冊地址自動注冊在 K8s 里到底靠不靠譜執(zhí)行器默認(rèn)走自動注冊向 admin 上報自己的 IP 和端口admin 把這些地址存進(jìn)xxl_job_registry表調(diào)度時直接連。在 K8s 里這套邏輯能不能work取決于 admin 到執(zhí)行器的網(wǎng)絡(luò)路徑同集群同命名空間Pod IP 直接可達(dá)自動注冊沒問題。跨命名空間也通?？梢郧疤崾菦]有 NetworkPolicy 攔住 9999。但如果 admin 部署在集群外或者執(zhí)行器用了hostNetwork上報的地址就對不上了需要在執(zhí)行器側(cè)顯式指定xxl.job.executor.ip10.0.0.21 xxl.job.executor.addresshttp://10.0.0.21:9999/address優(yōu)先級高于ipport填了它就以它為準(zhǔn)。手工錄入模式也常用在 admin 頁面“執(zhí)行器管理”里把地址寫死成 Service 名或 NodePort代價是擴(kuò)縮容后要手動維護(hù)。自動注冊還有個副作用Pod 重建后 IP 變化舊地址會在注冊表里殘留約 90 秒靠心跳超時清理。這期間調(diào)度可能打到已經(jīng)銷毀的 IP 上任務(wù)日志顯示“連接超時”。滾動更新時如果流量敏感寧可先縮到 1 副本再更新。4.4 JVM 參數(shù)與時區(qū)任務(wù)慢 8 小時的那個坑時區(qū)要三處對齊容器TZ、JVM-Duser.timezone、數(shù)據(jù)庫連接串serverTimezone。缺一處cron 表達(dá)式就可能按 UTC 解析你配的0 0 2 * * ?實(shí)際在北京時間上午 10 點(diǎn)觸發(fā)。env: - name: TZ value: Asia/Shanghai - name: JAVA_OPTS value: - -Xms512m -Xmx512m -XX:UseG1GC -XX:MaxGCPauseMillis200 -Duser.timezoneAsia/Shanghai -Dfile.encodingUTF-8堆給 512m 起步調(diào)度中心的對象不多瓶頸在數(shù)據(jù)庫不在堆。-Dfile.encodingUTF-8是為了任務(wù)參數(shù)里有中文時不出現(xiàn)亂碼——這個錯很難定位因?yàn)槿蝿?wù)本身執(zhí)行成功了只是參數(shù)變了樣。執(zhí)行器側(cè)同樣要配尤其是日志文件里的中文輸出。5. 部署避坑五個卡住過我的現(xiàn)象和它們的解法5.1 Pod 一直 CrashLoopBackOff日志停在數(shù)據(jù)源初始化現(xiàn)象kubectl logs只看到 Spring Boot 啟動 banner 之后就沒了或者報Communications link failure。原因數(shù)據(jù)庫不可達(dá)或者賬號權(quán)限不足。常見于數(shù)據(jù)庫和 admin 不在同一命名空間但用了短域名DNS 解析失敗。解決先進(jìn) admin Pod 里用nc -zv mysql.middleware.svc.cluster.local 3306驗(yàn)證連通性再用同樣的賬號密碼從 Pod 內(nèi)跑一次mysql -h ... -u ... -p確認(rèn)權(quán)限。短域名不通就換成完整 FQDN。另外檢查數(shù)據(jù)庫的白名單有些云數(shù)據(jù)庫只允許特定網(wǎng)段。5.2 執(zhí)行器列表里顯示離線機(jī)器 registries 為空現(xiàn)象admin 頁面“執(zhí)行器管理”能看到執(zhí)行器記錄但“OnLine 機(jī)器地址”是空的。原因三種可能——accessToken 不一致、9999 端口不通、AppName 拼錯。解決先看執(zhí)行器日志里有沒有注冊成功的記錄再在 admin Pod 里curl http://執(zhí)行器IP:9999/試探端口最后逐字符比對 AppName。三條都排除后檢查 NetworkPolicy 和 Service 的 targetPort 是否指到了 9999 而不是 8080。5.3 任務(wù)到點(diǎn)沒觸發(fā)調(diào)度日志里一條記錄都沒有現(xiàn)象任務(wù)配置看起來正常cron 也到了但“調(diào)度日志”列表是空的。原因調(diào)度中心的時間不對或者任務(wù)狀態(tài)是“停止”而不是“運(yùn)行”。還有一種情況是 cron 表達(dá)式用了 Quartz 格式但寫錯了位數(shù)。解決先看 admin 容器內(nèi)的date和宿主機(jī)對一下再確認(rèn)任務(wù)狀態(tài)最后把 cron 換成0/30 * * * * ?這種 30 秒一次的做快速驗(yàn)證。如果日志里出現(xiàn)“調(diào)度成功但執(zhí)行失敗”那就是執(zhí)行器側(cè)的問題看handleCode。5.4 ImagePullBackOff節(jié)點(diǎn)上明明有鏡像現(xiàn)象kubectl describe pod顯示Failed to pull image但docker images在節(jié)點(diǎn)上能看到同名鏡像。原因imagePullPolicy: Always配合私有倉庫憑據(jù)失效或者 tag 是latest導(dǎo)致每次都拉。解決把策略改成IfNotPresenttag 寫死版本。憑據(jù)過期就重建 Secret注意 Secret 必須和 Pod 同命名空間。還有一個隱蔽情況節(jié)點(diǎn)打了污點(diǎn)或走了特定的鏡像加速配置實(shí)際拉取路徑和你以為的不一樣。5.5 滾動更新后任務(wù)重復(fù)執(zhí)行現(xiàn)象一次更新之后同一個任務(wù)在同一分鐘被觸發(fā)兩次。原因admin 起了兩個副本但沒配數(shù)據(jù)庫鎖相關(guān)參數(shù)或者xxl_job_lock表被刪了。解決確認(rèn)xxl_job_lock表存在且有數(shù)據(jù)多副本部署時確保所有副本連的是同一個庫。如果只是單副本需求replicas保持 1用strategy: Recreate避免新舊 Pod 并存期間重復(fù)調(diào)度。6. 裝完怎么驗(yàn)證跑通從 Pod 狀態(tài)到調(diào)度日志的四層自檢apply 完看到created不算數(shù)我固定按四層往下走每層不過就不往下看。第一層看 Pod 狀態(tài)和重啟次數(shù)kubectl -n xxl-job get pods -o wide kubectl -n xxl-job rollout status deploy/xxl-job-admin --timeout180sREADY 1/1、RESTARTS 0才算過。如果重啟次數(shù)是 1 但當(dāng)前 Running別放過去看上一次的日志多半是啟動初期探針太急。第二層看 HTTP 接口能不能返回 200繞過瀏覽器直接打kubectl -n xxl-job exec deploy/xxl-job-admin -- \ curl -s -o /dev/null -w %{http_code}\n http://127.0.0.1:8080/xxl-job-admin/toLogin返回200說明應(yīng)用上下文、端口、探針路徑三者一致。返回302一般是路徑少了前綴返回000是端口沒起。第三層登錄頁面確認(rèn)執(zhí)行器在線。默認(rèn)賬號admin密碼123456進(jìn)去第一件事是改密碼第二件事是看“執(zhí)行器管理”里的 OnLine 機(jī)器數(shù)是不是等于你起的副本數(shù)。第四層做一次端到端觸發(fā)這是唯一能證明“調(diào)度鏈路通”的驗(yàn)證檢查項(xiàng)操作期望結(jié)果執(zhí)行器在線執(zhí)行器管理頁OnLine 機(jī)器數(shù) ≥ 1任務(wù)可調(diào)度新建 GLUE(Shell) 任務(wù)內(nèi)容echo hello-xxl-job保存成功手動觸發(fā)點(diǎn)“執(zhí)行一次”調(diào)度日志出現(xiàn)一條記錄執(zhí)行回傳查看日志詳情handleCode200執(zhí)行備注含hello-xxl-job定時觸發(fā)cron 設(shè)0/30 * * * * ?等一分鐘連續(xù)出現(xiàn)兩條調(diào)度記錄四層全過這套 YAML 才算真的部署成功。任何一層卡住回到第 5 章對號入座基本都在那五條里。從那以后我每次部署完 XXL-JOB不管多急都強(qiáng)制把echo hello-xxl-job這個 GLUE 任務(wù)跑一遍——頁面能打開不代表調(diào)度能通只有日志里那條handleCode200才是真的。這套按順序編號的 YAML 和初始化 SQL 我整理在一起了把鏡像前綴和密碼換成自己的就能直接 apply希望你一次跑通不用在 CrashLoop 里耗一晚上。本文還有配套的精品資源點(diǎn)擊獲取