为什么中小团队应该关注 K3s
很多中小团队在业务增长到一定阶段后，都会面临同一个问题：单台服务器已经跑不下所有服务，但上完整的 Kubernetes（K8s）集群又太重了。标准 K8s 的 control plane 至少需要 2 核 4G 内存的机器，etcd、API Server、Scheduler、Controller Manager 四个组件缺一不可，光安装配置就要花大半天。对于 5-15 人的技术团队来说，这笔运维成本并不划算。
K3s 就是为了解决这个场景而生的。它是 Rancher 开源的轻量级 Kubernetes 发行版，把整个 control plane 压缩成一个二进制文件，内存占用只需 512MB 就能启动。2024 年 CNCF 的调查数据显示，K3s 已经成为边缘计算和中小规模部署中使用率最高的 K8s 发行版之一。如果你正在找一种”够用、好装、好维护”的容器编排方案，K3s 值得认真考虑。
本文将从零开始，带你完成 K3s 集群的搭建、验证和第一个应用部署。整个过程大约需要 30-60 分钟，前提是你有 2 台及以上可以互通的 Linux（Ubuntu/Debian/CentOS）服务器（VPS（虚拟专用服务器）或云服务器（基于云计算的虚拟化服务器，可按需弹性扩展））。
环境准备：硬件与系统要求
K3s 对硬件的要求比标准 K8s 低很多，但也不是”随便一台机器就行”。以下是我们实测后总结的最低配置和推荐配置：
- Server 节点（控制平面）：最低 1 核 512MB 内存，推荐 2 核 2GB 内存。如果你打算用内置的 SQLite 作为数据存储，磁盘 I/O 建议用 SSD。
- Agent 节点（工作节点）：最低 1 核 512MB 内存，推荐 2 核 4GB 内存。实际配置取决于你要跑的业务容器数量和资源需求。
- 操作系统：Ubuntu 20.04/22.04 LTS、Debian 11/12、CentOS 7/8/Stream、Rocky Linux 8/9 均已验证可用。内核版本建议 ≥ 5.4。
- 网络：所有节点之间必须能互通，Server 节点需要开放 6443 端口（Kubernetes API）和 10250 端口（kubelet）。
如果你还没有合适的服务器，可以考虑从 Hostease VPS 主机 选择一台 2 核 2G 的机器作为 Server 节点。对于测试环境，1 核 1G 的入门款也能跑起来，但不建议用于生产。
准备工作还包括两件容易被忽略的事：关闭 swap 和配置防火墙。K3s 和标准 K8s 一样，要求 swap 必须关闭，否则 kubelet 启动会报错。执行以下命令：
sudo swapoff -a
sudo sed -i '/ swap / s/^/#/' /etc/fstab
防火墙方面，如果使用 ufw（Ubuntu 默认），需要放行相关端口：
sudo ufw allow 6443/tcp
sudo ufw allow 10250/tcp
sudo ufw allow 8472/udp # Flannel VXLAN
sudo ufw allow 51820/udp # WireGuard（如果用后端加密）
安装 K3s：Server 节点与 Agent 节点
K3s 的安装过程是它最大的卖点之一——一条命令搞定。Server 节点的安装命令如下：
curl -sfL https://get.k3s.io | sh -
执行完成后，K3s 会自动以 systemd 服务的方式运行。验证安装是否成功：
sudo systemctl status k3s
sudo kubectl get nodes
如果看到节点状态为 Ready，说明 Server 节点已经就绪。接下来获取 Agent 节点加入集群所需的 token：
sudo cat /var/lib/rancher/k3s/server/node-token
这串 token 类似集群的”入场券”，Agent 节点需要用它来向 Server 注册。在 Agent 节点上执行：
curl -sfL https://get.k3s.io | K3S_URL=https://<SERVER_IP>:6443 K3S_TOKEN=*** sh -
把 <SERVER_IP> 替换成 Server 节点的内网或公网 IP，<TOKEN> 替换成上一步获取的 token。大约 30 秒后，回到 Server 节点执行 kubectl get nodes，应该能看到新加入的 Agent 节点。
一个常见的坑是：如果 Server 节点有多个网卡（比如同时有内网和公网 IP），K3s 默认可能绑定到错误的接口。这时需要在安装时指定 --node-ip 参数：
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="--node-ip=<内网IP>" sh -
如果你正在搭建多节点集群，内网互通和 IP 绑定的问题尤其需要注意。可以参考 Webhook 自动化部署实战 中关于服务器网络配置的部分，提前规划好节点间的通信方案。
部署第一个应用：验证集群是否正常工作
集群搭好了，但”能连上”和”能正常跑应用”是两回事。我们用一个 Nginx 部署来验证整个集群的调度、网络和存储链路是否通畅。
创建一个 Deployment 和对应的 Service：
# nginx-test.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-test
spec:
replicas: 2
selector:
matchLabels:
app: nginx-test
template:
metadata:
labels:
app: nginx-test
spec:
containers:
- name: nginx
image: nginx:1.25-alpine
ports:
- containerPort: 80
resources:
requests:
memory: "64Mi"
cpu: "50m"
limits:
memory: "128Mi"
cpu: "100m"
---
apiVersion: v1
kind: Service
metadata:
name: nginx-test
spec:
type: NodePort
selector:
app: nginx-test
ports:
- port: 80
targetPort: 80
nodePort: 30080
应用这个配置：
kubectl apply -f nginx-test.yaml
等待几十秒后，检查 Pod 状态和节点分布：
kubectl get pods -o wide
kubectl get svc nginx-test
如果 2 个 Pod 分别运行在不同节点上，说明集群的调度逻辑工作正常。用浏览器访问 http://<任意节点IP>:30080，看到 Nginx 欢迎页面就表示整个链路通了。
这里有一个容易被忽略的细节：K3s 默认使用 Traefik 作为 Ingress Controller（标准 K8s 默认没有预装 Ingress Controller）。如果你的业务需要通过域名（DNS（域名系统））路由流量到不同服务，Traefik 开箱即用，不需要额外安装。访问 http://<节点IP>:8080 可以看到 Traefik 的 Dashboard。
对于需要 HTTPS（安全传输协议）的场景，K3s 的 Traefik 集成了 cert-manager 的能力，可以快速实现自动化证书签发。如果你之前有使用 Docker Compose 多服务编排 的经验，迁移到 K3s 会非常自然——两者的编排思路是一致的，只是 K3s 提供了更强的自愈和调度能力。
生产环境注意事项与 K3s vs 标准 K8s 选型
K3s 虽然轻量，但用于生产环境时仍有一些必须关注的点。以下是我们团队在实际项目中踩过的坑和总结出的最佳实践。
数据备份：K3s 默认使用 SQLite 存储集群状态，这在单 Server 节点场景下够用，但如果 Server 节点磁盘故障，数据就没了。生产环境建议切换到 etcd 或外部 MySQL/PostgreSQL，并定期备份 /var/lib/rancher/k3s/server/db/ 目录。备份频率建议每天一次，保留最近 7 天。
升级策略：K3s 的升级非常方便，只需重新执行安装脚本并指定新版本号即可。但要注意：升级 Server 节点时，所有 Agent 节点上的 Pod 会有短暂不可用。建议在业务低峰期操作，并提前做好滚动更新的准备。升级命令示例：
curl -sfL https://get.k3s.io | INSTALL_K3S_VERSION="v1.29.4+k3s1" sh -
资源监控：K3s 本身不带完整的监控栈。如果你需要 Prometheus + Grafana 的监控能力，可以通过 Helm 安装 kube-prometheus-stack，但这会额外占用约 1GB 内存。对于资源紧张的场景，可以用轻量的 metrics-server 配合 kubectl top 做基础监控。
那么，什么时候该用 K3s，什么时候该用标准 K8s？这里给出一个简单的决策框架：
- 选 K3s：团队 ≤ 10 人、节点 ≤ 20 个、业务以微服务和 Web 应用为主、运维人力有限、需要快速搭建和迭代。
- 选标准 K8s：节点超过 50 个、需要复杂的 RBAC（基于角色的访问控制）和网络策略、有专职 SRE 团队、对高可用有严格要求（如金融、医疗行业）。
- 折中方案：先用 K3s 跑起来，等团队规模和业务复杂度增长后，再迁移到标准 K8s。K3s 和标准 K8s 的 API 完全兼容，迁移成本比从裸机迁移低得多。
如果你的业务目前以传统托管为主，随着流量增长考虑迁移到容器化架构，K3s 是一个很好的过渡选择——它的学习曲线比标准 K8s 平滑得多，而且可以直接复用现有的 Docker 镜像。迁移前建议先阅读 VPS 安全加固与性能优化指南，确保基础设施层面已经准备就绪。
总结与下一步行动
K3s 的核心价值在于降低了容器编排的门槛。它不是”阉割版 K8s”，而是针对中小规模场景的优化版本。通过本文的步骤，你已经完成了从环境准备到应用部署的完整流程。整个过程大约需要 30-60 分钟，相比标准 K8s 的半天到一天，效率提升明显。
建议你接下来做这几件事：
- 在测试环境跑通后，规划生产环境的网络和存储方案。不要直接把测试环境的单节点架构搬到生产。
- 配置自动化备份。至少备份 K3s 的数据目录和关键的 Kubernetes 资源 YAML 文件。
- 学习 Helm 包管理器。K3s 生态中的大多数组件（如 cert-manager、Prometheus）都通过 Helm Chart 安装，掌握 Helm 能大幅提高部署效率。
- 关注 K3s 的版本更新节奏。K3s 跟随上游 Kubernetes 的发布周期，每个小版本都会修复安全漏洞和性能问题，建议每季度评估一次升级。
如果你在搭建过程中遇到问题，K3s 的官方文档和 GitHub Issues 是最直接的排查资源。对于需要更高可用性或多区域部署的场景，建议参考我们的 免备案 VPS 选购指南，选择合适的基础设施来支撑你的 K3s 集群。