論壇

您好，抱歉讓您遇到這個問題。我剛剛進去您的 Aliyun Beijing 4C 8GB 伺服器查了一下，這不是隨機不穩定，而是一個非常具體的網路層問題，把原因跟您解釋清楚：

根本原因：Aliyun 北京節點無法從 Docker Hub 拉取映像

從 K8s events 看到，kube-system 的 3 個關鍵系統 Pod（coredns、local-path-provisioner、metrics-server）都卡在 ImagePullBackOff，錯誤訊息：

Failed to pull image "rancher/mirrored-coredns-coredns:1.12.1"
dial tcp 67.228.235.91:443: i/o timeout
dial tcp 199.59.148.222:443: i/o timeout
dial tcp 168.143.171.93:443: i/o timeout

這些 IP 全部是 Facebook/Meta 的 IP — 這是典型的大陸 DNS 被污染後，registry-1.docker.io 被解析到無法連通的 IP。換句話說，就是 GFW / 大陸網路環境封鎖了 Docker Hub 直連。

為什麼會「系統組件全面異常」

這形成連鎖反應：

1. CoreDNS 拉不下來 → K8s 內部 DNS 整個不能用
2. fluent-bit 啟動時 log：Wait 30 secs until DNS starts up → 超時 CrashLoop
3. vector-aggregator 啟動時 log：NATS Connect Error: DNS error: failed to lookup address information → CrashLoop
4. zeabur-kube-watch 也一樣 → CrashLoop

所以您看到的「Zeabur system components unhealthy」不是 Zeabur 服務本身有 bug，而是上游 docker.io 在大陸被封導致 K3s 一旦發生 Pod 重排就起不來。您的伺服器今天凌晨 13:29 跟 14:35 都 rebooted 過，reboot 後系統 Pod 重新拉 image，就直接卡住了。

解決方案

A. 短期：手動幫您 pull 缺失的 image 並匯入

如果您希望繼續使用北京節點，我可以 SSH 上去幫您從 Aliyun 自家的 container mirror（registry.cn-hangzhou.aliyuncs.com）手動把這 3 個 image 拉下來 import 進 containerd。這能立即解決當下的 ImagePullBackOff，但每次伺服器重啟或 Pod 被重排時仍可能再次發生，每次都會需要重新介入處理。

B. 長期：遷移到非大陸節點（最穩，強烈建議）

說實在話，大陸境內的 K3s 部署要長期穩定運行，一直是個硬仗 — 不是 Zeabur 服務不穩，是大陸網路環境對公共 container registry 本來就不友善。如果您沒有硬性的「必須在大陸境內」需求（例如 ICP 備案、國內使用者低延遲），強烈建議改用 Zeabur 香港 / 東京 / 新加坡 區的節點，這類問題就會完全消失，之後都不會再觸發「Zeabur system components unhealthy」這類告警。

請您告訴我您希望怎麼處理

請回覆一下您的偏好：

• 選 A：我立即 SSH 上去手動幫您 pull image 救急（約 5–10 分鐘內恢復）— 適合暫時救急，但不是長久之計
• 選 B：您想遷移到非大陸節點（最推薦），我可以協助評估遷移方案、資料搬移流程與規格建議

如果您比較急，可以先選 A 救急，但強烈建議之後盡快走 B。

Jimmy 您好，我是 Bohan。之前两次回复我对问题的判断都是错的，想直接说清楚。

今天在您机器上查到底：您的 k3s、pods、网络、节点资源都是健康的，过去 3.5 天没有任何一个 pod 重启。真正在闹的是我们后端 NATS——您机器上的 zeabur-kube-watch 发布事件时一直被 NATS 拒绝（503 insufficient resources，光这一条 error 在您机器上就有 849 次）。每次被拒 watcher 就关闭重连，中间的 gap 里 dashboard 收不到心跳，就把组件标成 Unknown，重连上又翻回 Running——这就是您看到的 flapping。

对照另一台刚上线 1 天的机器（不同客户）：这种 error 0 条。问题是我们后端的 stream retention / 配额策略对长期用户有设计缺陷，跑得越久越容易撞到。所以您 2 年里反复撞到这个问题，不是您的机器、服务、或网络的问题，是我们工程上的欠账。

已经开了内部工单给 Platform 团队，附上完整证据和修复方向。

给您两个选项：

• 继续用：您实际业务是健康的，dashboard flap 扎眼但不影响运行。平台修完就好。
• 迁移到香港/东京/新加坡：flap 会明显稀疏。迁移流程我可以协助评估。

Bohan

This post has been inactive for a while. We will be closing it in 2 days if there is no new activity.

Jimmy 您好，

您贴的这条 FailedScheduling 跟之前那次又是另一个独立问题，先说结论再给您看技术细节：

这是我们共享集群的资源调度欠账，不是您服务的问题。

具体来说，sfo1 的 build pod 池长期只配了 1 台 SPOT 实例，AWS 今天把它回收 / kubelet 挂掉之后：

• ASG 健康检查只看 EC2 层，不看 kubelet 是否正常 → 没触发自动替换
• 上层 EKS managed nodegroup 才在约 1.5 小时后把节点重建出来
• 您这次 build 的 30 分钟 deadline 早就过了，所以直接被标 FailureTarget

也就是说，从「builder 节点死掉」到「新 builder 起来」中间这段时间，所有 build 都没地方落 — 这就是您看到的 FailedScheduling。

这种「共享资源池没冗余」的设计问题，在您自己专属的伺服器或专属集群上不会出现 — 因为资源调度由您的实例独占决定，不会跟其他客户共用一个会被云厂商随时回收的资源池。

短期：刚刚 Platform 把死掉的节点替换掉了，您重试一次 build 应该就过了（我看到 build-69f1d74f7abecea3dc1884e6 已经在新 builder 上跑起来）。

长期：我会把这次 incident 记下来推 Platform 修 — 健康检查改成 kubelet-aware 的，不要等 1.5 小时。

再次抱歉让您踩到这个洞。这周已经从 NATS、builder 调度连续两个我们这边的架构问题了，说真的辛苦您了。

Bohan

Jimmy 您好，针对您贴的 deployment 69f1d7af7abecea3dc18852e 跟 dashboard 上一堆显示「BUILDING」的纪录，更新一下：

发生什么事

您贴的这个跟之前 NATS 那个又是一个独立的问题。我们 sha2 region 的构建实际是跑在另一个共享的「构建机器池」上，今天下午这个池子里很多机器同时被云厂商回收 + 重建，您的 build 任务一个接一个在跑到一半时被踢掉，自动重试又撞到同样的状况，最后被超时杀掉。

更糟的是我们后端有个旧 bug：build 在底层被杀掉之后，dashboard 上的状态没办法正确翻成「失败」，所以您看到一长串 BUILDING 卡着，其实底层 build 任务早就结束了。这两个问题一起把您的体验放大成「我的 build 全部坏掉而且看起来一直在转」。

完整的调查证据 + 修复方向已经整理给 Platform 团队，已经 page 出去。

目前状况

刚刚再确认一次，构建机器池已经稳下来了。最近几分钟其他客户的构建都正常在跑，平均 1 分钟内完成。

您可以做的

1. 直接重新 push / 重新部署一次，应该就会过。
2. 您 12:34 起还在跑的两个 build（69f1f4eb / 69f1f473）也有机会自己完成，按 dev.bibigpt.co 历史平均 ~22 分钟构建时间来看可以再等一下。
3. dashboard 上那些旧的「BUILDING」纪录请暂时忽略 — 那些已经是底层早就死掉的幽灵纪录，等我们修完上面的 bug 会一起清掉，不影响您重试新的 build。

非常抱歉这两次都让您撞到我们底层的洞，确实是我们的问题不是您的服务。

Bohan