论坛

您好，抱歉让您遇到这个问题。我刚刚进去您的 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 您好，

您贴的这条 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