K3s 集群搭建起来只需要一条命令，但真正考验团队的是上线之后的日常运维。证书过期导致 API 不可达、节点磁盘写满引发 Pod 驱逐、升级后组件不兼容——这些故障在中小团队中反复出现，而大多数团队并没有专职运维来兜底。本文将教你如何解决 K3s 集群上线后的四大核心运维问题：证书轮换、节点管理、数据备份和故障排查，帮助你建立可复查、可恢复、可升级的运维流程，在没有专职运维的情况下也能让集群长期稳定运行。
K3s 集群运维的核心任务
K3s 虽然比标准 K8s（容器编排平台）轻量，但运维工作并没有消失，只是换了一种更简洁的方式。证书续期窗口、备份范围和升级影响都有明确官方口径，不能继续沿用旧经验。以下四个任务覆盖了中小团队大多数日常需求：
- 证书管理：K3s 会在启动时自动续期已过期或 120 天内到期的客户端和服务器证书；如果系统时间异常或组件仍报证书错误，再按官方顺序停服、轮换、启动
- 节点管理：添加 Worker 节点、移除故障节点、查看节点资源水位，这些操作直接影响集群的调度能力
- 备份与恢复：单 Server 节点默认使用 SQLite（轻量嵌入式数据库）存储集群状态，可靠备份必须覆盖整个
/var/lib/rancher/k3s/server/db/目录，并单独保存/var/lib/rancher/k3s/server/token - 版本升级：K3s 的升级脚本设计得相当简洁，但升级前需要确认兼容性和数据备份
与标准 K8s 不同，单 Server 的 K3s 默认不需要你管理 etcd（分布式键值存储，K8s 的核心数据层）集群，也不需要手动配置网络插件 CNI（容器网络接口，负责 Pod 间通信）。如果要使用内置 etcd 做控制面高可用，官方要求至少 3 个 Server 节点；外部数据库方案才适合从 2 个 Server 节点起步。运维负担大幅降低，但核心的证书、备份、升级这三件事仍然不能忽视。
证书管理：最常见的故障来源
K3s 默认使用自签名证书；当前受支持版本会在 K3s 启动时检查证书，并自动续期已经过期或 120 天内到期的客户端证书和服务器证书。这里要区分：90 天窗口是 2025 年 5 月前旧版本规则，长时间离线后重新启动也不代表会跳过自动续期。真正需要人工介入的场景通常是系统时间异常、证书链被手动改动，或轮换后组件没有重新加载证书。
- 系统时间被手动改动：时间跳跃会导致证书校验失败，kubectl 命令返回
certificate has expired or is not yet valid错误 - 节点重新加入集群：旧节点上的证书与 Server 端不匹配，需要清理后重新加入
手动触发证书轮换时，顺序不能省略。官方推荐先停止 K3s 服务，再执行轮换命令，最后重新启动服务：
sudo systemctl stop k3s sudo k3s certificate rotate sudo systemctl start k3s
执行后等待 30 秒左右，用 kubectl get nodes 确认节点状态恢复为 Ready。如果仍然报证书错误，检查服务器时间是否准确：
date sudo timedatectl set-ntp true
时间同步后再次按“停止、轮换、启动”的顺序执行。对于多节点集群，每个 Worker 节点也需要重启 K3s agent 服务来加载新证书；如果是内置 etcd 高可用集群，应逐台处理 Server 节点。
节点管理：添加与移除 Worker
单节点集群能跑测试环境，但生产环境要先区分两类目标：如果只是提升业务 Pod 的调度余量，可以在 1 个 Server 后增加 Worker 节点；如果目标是控制面高可用，内置 etcd 至少需要 3 个 Server 节点，不能把“1 个 Server + 1 个 Worker”理解成控制面高可用。添加 Worker 节点的流程比标准 K8s 简单得多。
获取加入令牌
在 Server 节点上查看节点令牌：
sudo cat /var/lib/rancher/k3s/server/node-token
输出是一串长 token，复制它。然后在 Worker 节点上执行：
curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 K3S_TOKEN=*** sh -
将 SERVER_IP 替换为 Server 节点的内网或公网 IP，YOUR_TOKEN 替换为上面获取的 token。安装完成后在 Server 节点上验证：
kubectl get nodes
如果新节点显示 NotReady，最常见的原因是防火墙未放行 8472/UDP 端口（Flannel VXLAN 隧道端口）。检查 Worker 节点的防火墙规则：
sudo ufw allow 8472/udp
移除节点时，先在 Server 端驱逐并删除节点：
kubectl drain NODE_NAME --ignore-daemonsets --delete-emptydir-data kubectl delete node NODE_NAME
然后在 Worker 节点上停止并清理 K3s agent：
sudo systemctl stop k3s-agent sudo /usr/local/bin/k3s-agent-uninstall.sh
对于需要同时管理多个节点的团队，K3s 配合 Hostease VPS（虚拟专用服务器） 可以快速搭建多节点集群，每个节点独立计费，按需扩展。如果工作负载对磁盘 I/O 要求较高，独立服务器 的 NVMe SSD（非易失性存储高速接口固态硬盘）方案能显著提升 etcd 或 SQLite 的写入性能。
备份与恢复：防止数据丢失
K3s 默认使用嵌入式 SQLite 数据库存储集群状态，包括 Namespace、Deployment、Service、ConfigMap 的元数据。旧教程常说只复制 state.db，但这不能构成完整备份。更稳妥的做法是备份整个 /var/lib/rancher/k3s/server/db/ 目录，并保存 /var/lib/rancher/k3s/server/token；这个 token 会影响节点重新加入和恢复后的集群身份校验。
推荐使用 cron 任务每天执行一次备份：
sudo crontab -e 0 3 * * * tar -czf /backup/k3s-$(date +\%Y\%m\%d).tgz /var/lib/rancher/k3s/server/db /var/lib/rancher/k3s/server/token
恢复时，先停止 K3s 服务，解压备份目录并确认文件属主权限，再启动服务：
sudo systemctl stop k3s sudo tar -xzf /backup/k3s-20260709.tgz -C / sudo systemctl start k3s
恢复完成后，用 kubectl get pods --all-namespaces 确认工作负载状态。SQLite 相关备份只恢复集群元数据和集群 token，不包含容器镜像和持久卷数据。如果使用了 local-path 存储，持久卷数据需要单独备份；生产环境建议把元数据备份和 PV（持久卷）备份分成两条任务。
版本升级：安全操作步骤
K3s 的升级方式比标准 K8s 简单，但升级前仍要做好准备。升级脚本会替换 K3s 二进制文件并重启服务，因此 API Server 会短暂不可用，节点组件也会重新连接；不能无条件承诺对已有 Pod 和配置没有影响。稳妥做法是在业务低峰期执行，先备份，再逐台升级并观察事件。
升级前先确认当前版本和目标版本：
k3s --version
单节点集群的升级命令：
curl -sfL https://get.k3s.io | sh -s - --write-kubeconfig-mode 644
这个命令会检测已安装的 K3s 版本，自动下载并替换为最新稳定版。升级过程中 K3s 服务会短暂重启，API 可能有几十秒不可用；多数已运行 Pod 会继续由容器运行时维持，但依赖 API 调度或控制器变更的工作负载可能受到影响，所以仍应提前设置维护窗口。
多节点集群建议先逐台处理 Worker 节点，再处理 Server 节点；如果是多 Server 控制面，应一次只升级一个 Server，每次升级后确认 kubectl get nodes 和核心系统 Pod 状态正常。Worker 节点的升级命令：
curl -sfL https://get.k3s.io | K3S_URL=https://SERVER_IP:6443 K3S_TOKEN=*** sh -
升级后检查各节点版本是否一致：
kubectl get nodes -o wide
如果某个节点版本落后，重新在该节点执行升级命令即可。K3s 的升级脚本通常会沿用已有配置，但升级前仍建议备份 /etc/rancher/k3s/ 和 systemd service 文件。
常见故障排查清单
以下是 K3s 集群运维中最高频的故障场景和对应的排查步骤：
- kubectl 连接超时：先检查 K3s 服务是否在运行
sudo systemctl status k3s，然后确认 6443 端口是否监听ss -tlnp | grep 6443。如果服务正常但端口未监听，检查磁盘空间df -h——SQLite 在磁盘写满时会拒绝写入，导致 API 不可用 - Pod 一直处于 Pending 状态：运行
kubectl describe pod POD_NAME查看事件。最常见的原因是节点资源不足（CPU 或内存不够），用kubectl top nodes查看各节点资源水位 - 节点磁盘使用率持续增长：K3s 默认不会清理未使用的容器镜像，运行
sudo k3s crictl rmi --prune可以清理不再被任何 Pod 引用的镜像。建议在 cron 中每周执行一次 - Flannel 网络不通：检查 8472/UDP 端口是否放行，以及
/etc/cni/net.d/目录下是否存在 10-flannel.conflist 文件。如果文件缺失，重新安装 K3s 网络组件
这些排查步骤覆盖了 K3s 集群 80% 以上的日常故障。如果遇到更复杂的问题，可以参考 K3s 官方文档的 Troubleshooting 章节，或者在 服务器运维博客 中找到更多实战经验。对于需要同时管理多个网站的场景，WordPress 托管方案 提供了容器化部署的参考架构。如果排查过程中发现应用响应延迟问题，TTFB（首字节时间）优化方法 可以帮助你进一步定位服务器与应用之间的性能瓶颈。
运维建议与总结
K3s 集群的运维并不复杂，但需要建立几个基本习惯。建议你在集群上线后立即做三件事：配置每日 server/db/ 目录与 server/token 备份、在 cron 中设置每周镜像清理、记录 Server 节点的 node-token 到安全位置。这三件事加起来只需要 10 分钟，但能在关键时刻节省数小时的恢复时间。
如果你正在寻找服务器来运行 K3s 集群，Hostease VPS（虚拟专用服务器）方案 提供多种配置，支持按需升级，适合从开发测试到小型生产环境逐步扩展。总结来看，K3s 的运维核心是证书、备份、升级三件事，把这三件事管好，集群就能长期稳定运行。