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