說真的,你們的服務不管哪種模式都太不穩定了啊,😭
說真的,你們的服務不管哪種模式都太不穩定了啊,😭
您好,抱歉讓您遇到這個問題。我剛剛進去您的 Aliyun Beijing 4C 8GB 伺服器查了一下,這不是隨機不穩定,而是一個非常具體的網路層問題,把原因跟您解釋清楚:
從 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 直連。
這形成連鎖反應:
fluent-bit 啟動時 log:Wait 30 secs until DNS starts up → 超時 CrashLoopvector-aggregator 啟動時 log:NATS Connect Error: DNS error: failed to lookup address information → CrashLoopzeabur-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 救急,但強烈建議之後盡快走 B。
簡直無言了!!!
A system component may be broken. Go to server settings to reinstall Zeabur services.
乾脆放棄中國大陸市場算了,真是的,搞什麼 zeabur.cn?放這麼多中國大陸的 providers 是要幹嘛?
既然都知道狀況,為什麼不願意在阿里雲 (Alibaba Cloud) registry 自建一下呢?不能保證你們自己的 Docker image 在阿里雲上能正常 pull 嗎?
既然都能跟阿里雲拿到合作價的伺服器了,難道 [XXXXX]
我真的已經遇過 Zeabur 這種情況至少 7 次了,這兩年多以來。
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 团队,附上完整证据和修复方向。
给您两个选项:
Bohan
This post has been inactive for a while. We will be closing it in 2 days if there is no new activity.
之前的叢集又是什麼情況呢?
[Zeabur] Pod/build-69f1c1347abecea3dc1878fa-2lqgd - FailedScheduling: 0/26 nodes are available: 1 node(s) had untolerated taint {node.kubernetes.io/unreachable: }, 2 node(s) had untolerated taint {k8s.zeabur.com/tcp-proxy: true}, 23 node(s) didn't match Pod's node affinity/selector. preemption: 0/26 nodes are available: 26 Preemption is not helpful for scheduling.
Jimmy 您好,
您贴的这条 FailedScheduling 跟之前那次又是另一个独立问题,先说结论再给您看技术细节:
这是我们共享集群的资源调度欠账,不是您服务的问题。
具体来说,sfo1 的 build pod 池长期只配了 1 台 SPOT 实例,AWS 今天把它回收 / kubelet 挂掉之后:
也就是说,从「builder 节点死掉」到「新 builder 起来」中间这段时间,所有 build 都没地方落 — 这就是您看到的 FailedScheduling。
这种「共享资源池没冗余」的设计问题,在您自己专属的伺服器或专属集群上不会出现 — 因为资源调度由您的实例独占决定,不会跟其他客户共用一个会被云厂商随时回收的资源池。
短期:刚刚 Platform 把死掉的节点替换掉了,您重试一次 build 应该就过了(我看到 build-69f1d74f7abecea3dc1884e6 已经在新 builder 上跑起来)。
长期:我会把这次 incident 记下来推 Platform 修 — 健康检查改成 kubelet-aware 的,不要等 1.5 小时。
再次抱歉让您踩到这个洞。这周已经从 NATS、builder 调度连续两个我们这边的架构问题了,说真的辛苦您了。
Bohan
deployment-69f1d7af7abecea3dc18852e 這個也沒成功,剛剛重試過了。
Jimmy 您好,针对您贴的 deployment 69f1d7af7abecea3dc18852e 跟 dashboard 上一堆显示「BUILDING」的纪录,更新一下:
发生什么事
您贴的这个跟之前 NATS 那个又是一个独立的问题。我们 sha2 region 的构建实际是跑在另一个共享的「构建机器池」上,今天下午这个池子里很多机器同时被云厂商回收 + 重建,您的 build 任务一个接一个在跑到一半时被踢掉,自动重试又撞到同样的状况,最后被超时杀掉。
更糟的是我们后端有个旧 bug:build 在底层被杀掉之后,dashboard 上的状态没办法正确翻成「失败」,所以您看到一长串 BUILDING 卡着,其实底层 build 任务早就结束了。这两个问题一起把您的体验放大成「我的 build 全部坏掉而且看起来一直在转」。
完整的调查证据 + 修复方向已经整理给 Platform 团队,已经 page 出去。
目前状况
刚刚再确认一次,构建机器池已经稳下来了。最近几分钟其他客户的构建都正常在跑,平均 1 分钟内完成。
您可以做的
69f1f4eb / 69f1f473)也有机会自己完成,按 dev.bibigpt.co 历史平均 ~22 分钟构建时间来看可以再等一下。非常抱歉这两次都让您撞到我们底层的洞,确实是我们的问题不是您的服务。
Bohan
Jimmy 您好,已經 6 天沒有收到您的回覆,先把這個串標記為已解決。如果之後又遇到這類構建池被回收的狀況,歡迎隨時回覆這個串或開新的串,我們會儘快協助。也再次感謝您一路以來對 Zeabur 的反饋。
resolved 的問題已停用新回覆。