Forum

Hello, I have investigated the issue from the server side:

Root Cause: The metrics-server pod was previously stuck in ImagePullBackOff — it was trying to pull images from docker.io. However, your server is located in Volcengine Guangzhou, and docker.io is generally unreachable from mainland China, which is why it couldn't pull the image. This is the reason why the "k3s service" appeared red on the dashboard.

Current Status: It has been resolved. I just SSH'd into the server and checked: K3s is active, the Node is Ready, and all pods are Running. The "Reinstall Zeabur System Components" action you triggered at 22:34 actually finished at 22:35:43. The reinstallation process switched the system component image source to the Huawei Cloud SWR China mirror (swr.cn-east-3.myhuaweicloud.com/zeabur/...), allowing the metrics-server to pull the image successfully using the new source. Therefore, the "reinstallation also reported an error" you saw was likely a transient error during the process, and it was ultimately successful. Refreshing the dashboard should show that all services are back online.

If you captured any specific error messages (screenshots or text) during the reinstallation, please feel free to post them, and I will check if there are any other issues.

The issue persists, mainly with the following phenomena:

1. When starting the service, k3s still shows an offline status; as shown in the image.
2. Is the domain resolution error related to the offline status?

Due to k3s being offline, I reinstalled the Zeabur service, but I encountered an error: Invalid input

Hello, we SSH'd in and took a look:

The host is deadlocked due to "Disk 90% full + CPU/RAM maxed out" ── this is not a Zeabur platform issue, but a typical case of a 2C/2GB instance being overwhelmed by k3s + user services.

Status:

• Disk 34 GB / 40 GB (90%) ── As soon as kubelet hits the disk-pressure threshold, it triggers eviction + image GC + log rotation, and these actions consume CPU.
• Load average 49 / 50 / 52 on a 2-core machine ── Severely overloaded.
• RAM 1.7Gi / 1.9Gi used, 232 Mi remaining.
• k3s service shows as active, but all kubectl / systemctl commands time out, and our secondary SSH attempts were refused ── the host is too frozen to respond.

Therefore, the phenomena you are seeing are downstream symptoms:

• Dashboard "K3s Offline" red dot ← K3s API cannot respond to platform probes due to host overload.
• Domain resolution errors ← CoreDNS pod cannot get enough CPU.
• Reinstall reports "Invalid input" ← Platform handshake with the frozen host timed out.

Recommendation: Upgrade your specifications

2C/2GB is too tight for running k3s + user services; every time the disk/memory fills up, today's situation will repeat. Upgrading directly to 2C/4GB (or higher) on the server page in the Dashboard is the most direct and permanent solution ── the new spec will provide more disk and memory, giving k3s room to operate normally. The upgrade process will also restart the machine, clearing the current frozen state.

If the upgrade process is not smooth or you have any questions, please let us know.

After the upgrade, it can start, but now I'm facing an access issue (it was working before). Based on the prompt, it seems my domain needs to be re-registered (ICP filing) with Volcano Engine. This is severely affecting the system's usability. Could you please help me migrate the project from this server to your Alibaba Cloud server? I will renew the subscription directly with Alibaba. Note: The domain is already registered with Alibaba and is in normal use.

I have purchased a new Alibaba Cloud server, server-69fe894341759f9bfacd8bc5. Could you please help me with the migration? I tried copying and transferring it myself, but it keeps getting stuck at 76%.

Hello, we have completed the migration process on the backend. The data volumes for Redis and the dev/prod PostgreSQL have been successfully replicated to the new Alibaba Cloud instance, and all related services have been deployed. Please test if the new project is working correctly and feel free to reply if you encounter any issues.

Adding a note about the expiration period so you don't have to worry while testing new projects: The official process for BytePlus annual/monthly instances is that they will only be shut down 12 hours after expiration (during this period, the VM is still running, and services on the old machine remain available).

Take your time testing your new project, and feel free to reply if you have any questions. We will assist you as soon as possible.