K3s 部署的难点，通常不在“能不能跑起来”，而在如何把第一次安装做成后续可扩展、可排查、可交接的基础环境。很多中小团队从 Docker Compose 进入 Kubernetes（容器编排平台）时，会被标准集群的组件数量、节点规划和网络策略吓住。本文教你用 K3s 完成一次从单节点验证到小型生产集群的上线流程，重点解决三个问题：服务器怎么选、节点怎么加入、部署后怎么验证。
与另一类“上线后的证书、备份、升级运维”不同，本文只聚焦首次部署阶段。我们会使用 1 个 Server 节点和 1 个 Worker 节点作为示例，先让应用跑通，再判断是否需要扩展到 3 个 Server 节点的控制面高可用。这样做的好处是投入更低、路径更短，也能避免一开始就把集群做得过重。对于 5 到 15 人的 Web 团队、测试平台、内部工具和小型业务服务，这条路线通常更容易落地。
先判断：K3s 是否适合这次上线
K3s 是轻量 Kubernetes（容器编排平台）发行版，安装包更小，默认组件更收敛，单 Server 节点最低可以在 1 核 512MB 内存上启动。但“能启动”不等于“适合生产”。如果要运行真实 Web 应用，我们建议 Server 节点至少 2 核 2GB 内存，Worker 节点至少 2 核 4GB 内存，并预留 20GB 以上磁盘空间给镜像、日志和临时数据。
你可以先用下面 4 个条件判断是否该用 K3s：
- 服务规模：当前服务数量在 3 到 20 个之间，例如 API、后台任务、前端站点和队列消费者
- 节点规模：初期节点少于 10 台，后续预计不会快速扩展到 50 台以上
- 运维人力：没有专职 SRE，但有人能维护 Linux、Docker 和基础网络
- 上线目标：希望获得滚动更新、自愈重启和资源限制，而不是复杂多租户平台
如果你的需求只是单个网站部署，Docker Compose 多服务编排仍然更轻。如果已经有多个服务、多个环境和固定发布节奏，K3s 才开始体现价值。基础服务器可以从 Hostease VPS（虚拟专用服务器） 起步，后续根据 CPU、内存和磁盘指标逐步扩容。
环境准备：把网络和系统先收紧
首次部署前，先把服务器环境统一。示例环境使用 Ubuntu 22.04 LTS，两台节点位于同一内网，Server 节点内网地址为 10.0.0.10，Worker 节点内网地址为 10.0.0.11。生产环境优先使用内网通信，不建议让 Worker 节点通过公网访问 Server 节点的 Kubernetes API。
每台节点都先执行基础检查：
free -h df -h uname -r ip addr
建议内核版本不低于 5.4，磁盘根分区剩余空间不少于 20GB。如果系统开启了 swap，需要先关闭，因为 kubelet 默认要求节点内存调度必须可控：
sudo swapoff -a sudo sed -i.bak '/ swap / s/^/#/' /etc/fstab
防火墙只开放必要端口：Server 节点至少放行 6443/tcp 给集群节点访问，所有节点之间放行 10250/tcp 和 8472/udp。8472/udp 是 Flannel VXLAN 的常用端口，如果它被拦截，Pod 可能创建成功但跨节点通信失败。与其凭经验放开大段端口，不如先按最小端口集部署，再通过 kubectl 事件定位缺口。更多服务器基础加固思路，可以参考服务器运维博客里的相关实践。
安装 Server 节点：明确绑定地址和默认组件
Server 节点是 K3s 集群的控制入口，首次安装时最容易遗漏两个参数：节点 IP 和 kubeconfig 权限。多网卡服务器如果不指定 --node-ip，K3s 可能选择错误网卡，导致 Worker 节点加入失败。示例安装命令如下：
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server --node-ip 10.0.0.10 --write-kubeconfig-mode 644" sh -
安装完成后，先看 systemd 服务状态，再查看节点：
sudo systemctl status k3s --no-pager kubectl get nodes -o wide
如果节点显示 Ready，说明控制面已经可用。此时不要急着部署业务应用，先记录加入令牌，后续 Worker 节点需要它完成注册：
sudo cat /var/lib/rancher/k3s/server/node-token
K3s 默认会安装 Traefik Ingress Controller 和 ServiceLB。对于首次上线，保留默认组件可以减少配置成本；如果团队已经有独立网关或负载均衡方案，再考虑禁用默认 Traefik。初期越少改默认参数，后续排查越容易。
加入 Worker 节点：先验证调度，再考虑扩容
Worker 节点负责承载业务 Pod。登录 Worker 节点后，用 Server 的内网地址和刚才读取的 token 执行安装：
curl -sfL https://get.k3s.io | K3S_URL=https://10.0.0.10:6443 K3S_TOKEN=K10xxxx::server:xxxx sh -
回到 Server 节点执行：
kubectl get nodes -o wide kubectl get pods -A
正常情况下，列表里会看到 1 个 Server 和 1 个 Worker。若 Worker 长时间是 NotReady，按顺序检查三件事：Server 的 6443/tcp 是否能从 Worker 访问，节点间 8472/udp 是否放行，Worker 的时间是否与 Server 相差过大。常用排查命令如下：
nc -vz 10.0.0.10 6443 sudo journalctl -u k3s-agent -n 80 --no-pager timedatectl status
如果你准备承载多个业务服务，建议至少保留 1 个 Worker 节点承载业务，把 Server 节点尽量留给控制面组件。小规模团队可以先用 2 到 3 台节点跑稳定，再决定是否引入更多 Worker。需要更强磁盘 I/O 的数据库、队列或日志组件，不建议和所有 Web 服务挤在同一台小规格节点上。
部署测试应用：用可观察结果验证集群
集群节点 Ready 只是第一层结果，还需要验证调度、Service 暴露和跨节点网络。下面用 Nginx 创建 2 个副本，并设置基础资源限制。资源请求不是装饰，它会直接影响调度器判断节点是否还能承载新 Pod。
kubectl create deployment web-demo --image=nginx:1.25 --replicas=2 kubectl set resources deployment web-demo --requests=cpu=50m,memory=64Mi --limits=cpu=100m,memory=128Mi kubectl expose deployment web-demo --type=NodePort --port=80 kubectl get pods -o wide kubectl get svc web-demo
观察 Pod 是否分布到不同节点，再从浏览器访问任一节点 IP 和 NodePort 端口。如果页面能打开，说明调度、容器运行时和 Service 暴露链路都正常。若只能在某个节点访问，重点检查节点安全组或本机防火墙；若 Pod 一直 Pending，则用 kubectl describe pod 查看调度事件。
测试完成后可以清理示例资源，避免占用端口和资源：
kubectl delete svc web-demo kubectl delete deployment web-demo
如果你的业务从脚本发布迁移到集群发布，可以先保留原有自动化流程，只把镜像构建和部署动作拆开。类似 Webhook 自动化部署实战 的流程，可以逐步改造成“代码提交后构建镜像，再由集群拉取新镜像”的模式，而不是一次性重构整条发布链路。
上线前检查：别把测试集群直接当生产
完成首次 K3s 部署后，还需要做一轮上线前检查。这里不展开证书轮换、备份恢复和版本升级的长期运维细节，但首次上线至少要把边界写清楚：谁能访问 kubeconfig，应用配置放在哪里，日志如何查看，节点资源达到什么阈值时扩容。
建议上线前完成下面 5 项检查：
- 访问控制：不要把
/etc/rancher/k3s/k3s.yaml直接发到群里，至少放到受控文档或密钥库中 - 命名空间：为业务创建独立 Namespace，例如
kubectl create namespace prod-web，避免所有资源混在 default - 资源限制：每个 Deployment 都设置 requests 和 limits，Web 服务可从 100m CPU、128Mi 内存起步压测
- 日志路径：确认团队会用
kubectl logs和kubectl describe定位失败，而不是只看应用页面 - 回滚动作：每次上线前记录镜像 tag，例如
web:2026-06-08-01，便于 5 分钟内回退
当业务开始稳定运行后，再补齐长期运维动作，例如每日备份、证书续期检查和升级窗口。对于页面响应变慢的应用，可以结合TTFB（首字节时间）优化方法定位服务器、网络和应用层瓶颈。这样 K3s 才不是一次安装命令，而是一套可持续维护的运行环境。
总结：从能跑到能上线，中间还差验证
K3s 部署的核心不是追求复杂架构，而是用最短路径得到一个可验证的小型集群：先准备 1 个 Server 和 1 个 Worker，明确节点 IP 与端口，部署测试应用确认调度和网络，再按上线检查清单补齐访问控制、资源限制和回滚策略。建议你先在测试环境完整跑一遍本文命令，把失败点记录下来，再迁移真实业务。
如果你需要为 K3s 准备基础服务器，可以考虑从 Hostease VPS（虚拟专用服务器） 起步；当业务对磁盘 I/O、隔离性或长期负载有更高要求时，再评估独立服务器。总结来看，K3s 适合让中小团队先拥有容器编排能力，但上线前的验证、资源边界和回滚方案，才决定它能否稳定承载业务。