如何用最少的资源搭建一套能跑生产环境的 Kubernetes 集群？这是很多中小团队在业务增长到多服务阶段后面临的第一个技术决策。标准 Kubernetes 的 control plane 需要至少 2 核 4GB 内存，etcd、API Server、Scheduler、Controller Manager 四个组件缺一不可，光安装配置就要半天。对于 5 到 15 人的技术团队来说，这笔运维成本并不划算。
K3s 是 Rancher 开源的轻量级 Kubernetes 发行版，将整个 control plane 压缩为单个二进制文件，512MB 内存即可启动。CNCF 2024 年调查数据显示，K3s 已成为边缘计算和中小规模部署中使用率最高的 K8s 发行版之一。本文将从零开始，带你完成 K3s 集群的安装、验证和第一个应用部署，整个过程约 30 到 60 分钟。
环境准备：硬件要求与系统配置
K3s 对硬件的要求比标准 K8s 低很多，但仍需满足基本条件。Server 节点（控制平面）最低 1 核 512MB 内存，推荐 2 核 2GB 内存；Agent 节点（工作节点）最低 1 核 512MB，推荐 2 核 4GB 内存。操作系统方面，Ubuntu 20.04/22.04 LTS、Debian 11/12、CentOS 7/8/Stream 均已验证可用，内核版本建议 5.4 以上。
网络方面，所有节点之间必须能互通，Server 节点需要开放 6443 端口（Kubernetes API）和 10250 端口（kubelet）。如果你还没有合适的服务器，可以考虑从 Hostease VPS 主机 选择一台 2 核 2G 的机器作为 Server 节点。
安装前还需要完成两项容易被忽略的配置。第一，关闭 swap——K3s 和标准 K8s 一样要求 swap 必须关闭，否则 kubelet 启动会报错。第二，配置防火墙放行 6443/tcp、10250/tcp、8472/udp（Flannel VXLAN）等端口。具体操作可以参考 VPS 防火墙配置指南 中的详细步骤。
安装 K3s：一条命令完成集群初始化
K3s 的安装过程是它最大的卖点之一。Server 节点只需执行官方安装脚本，K3s 会自动以 systemd 服务方式运行。安装完成后用 kubectl get nodes 命令验证，看到节点状态为 Ready 即表示 Server 节点就绪。
接下来获取 Agent 节点加入集群所需的 token，这串 token 类似集群的”入场券”。在 Agent 节点上执行安装脚本时，通过环境变量指定 Server 节点的 IP 地址和 token，大约 30 秒后 Agent 节点就会自动注册到集群中。
一个常见的坑是：如果 Server 节点有多个网卡（同时有内网和公网 IP），K3s 默认可能绑定到错误的接口。这时需要在安装时通过 INSTALL_K3S_EXEC 参数指定 node-ip。如果你正在搭建多节点集群，内网互通和 IP 绑定的问题尤其需要注意。可以参考 Webhook 自动化部署实战 中关于服务器网络配置的部分，提前规划好节点间的通信方案。
部署第一个应用：验证集群是否正常工作
集群搭好了，但”能连上”和”能正常跑应用”是两回事。建议用一个 Nginx Deployment 配合 NodePort Service 来验证整个集群的调度、网络和存储链路是否通畅。创建 2 个副本的 Nginx 部署，设置合理的资源请求和限制（requests: 64Mi 内存/50m CPU，limits: 128Mi 内存/100m CPU），然后通过 NodePort 暴露服务。
如果 2 个 Pod 分别运行在不同节点上，说明集群的调度逻辑工作正常。用浏览器访问任意节点 IP 的对应端口，看到 Nginx 欢迎页面就表示整个链路通了。
K3s 默认使用 Traefik 作为 Ingress Controller，标准 K8s 默认没有预装。如果你的业务需要通过域名路由流量到不同服务，Traefik 开箱即用，不需要额外安装。对于需要 HTTPS 的场景，K3s 的 Traefik 集成了 cert-manager 的能力，可以快速实现自动化证书签发。如果你之前有使用 Docker Compose 多服务编排 的经验，迁移到 K3s 会非常自然——两者的编排思路一致，只是 K3s 提供了更强的自愈和调度能力。
生产环境注意事项与 K3s 选型建议
K3s 虽然轻量，但用于生产环境时仍有一些必须关注的点。数据备份方面，K3s 默认使用 SQLite 存储集群状态，单 Server 节点场景下够用，但如果磁盘故障数据就没了。生产环境建议切换到 etcd 或外部 MySQL/PostgreSQL，并定期备份数据目录，备份频率建议每天一次。
升级策略方面，K3s 的升级非常方便，只需重新执行安装脚本并指定新版本号即可。但要注意升级 Server 节点时所有 Agent 节点上的 Pod 会有短暂不可用，建议在业务低峰期操作。资源监控方面，K3s 本身不带完整的监控栈，可以通过 Helm 安装 Prometheus + Grafana，但这会额外占用约 1GB 内存。资源紧张的场景可以用轻量的 metrics-server 配合 kubectl top 做基础监控。
那么什么时候该用 K3s，什么时候该用标准 K8s？简单来说：团队 10 人以内、节点 20 个以下、以微服务和 Web 应用为主、运维人力有限的场景，选 K3s 准没错。节点超过 50 个、需要复杂 RBAC 和网络策略、有专职 SRE 团队的场景，建议直接上标准 K8s。也可以先用 K3s 跑起来，等规模增长后再迁移到标准 K8s——两者的 API 完全兼容，迁移成本比从裸机迁移低得多。更多关于服务器基础设施的选型建议，可以参考 VPS 部署优化指南。
总结
K3s 的核心价值在于降低了容器编排的门槛。它不是”阉割版 K8s”，而是针对中小规模场景的优化版本。通过本文的步骤，你已经可以完成从环境准备到应用部署的完整流程。建议你在测试环境跑通后，规划好生产环境的网络和存储方案，配置自动化备份，逐步学习 Helm 包管理器来提高部署效率。如果你需要更高可用性或多区域部署的基础设施支撑，Hostease VPS 提供多种配置方案，可以根据你的 K3s 集群规模灵活选择。