本指南教你如何用 K3s 在一台或几台小机器上完成 Kubernetes 部署，解决传统 K8s 安装门槛高、资源占用大的痛点。很多团队想用 Kubernetes 但又怕官方发行版那套 etcd、controller、scheduler、kubelet 全套装下来动辄四五百兆内存，光是装完一个空集群就快把小机器吃满。K3s 是 Rancher 推出的精简发行版，把所有组件打包成单个二进制，默认存储用 SQLite，跑在 512MB 内存的小 VPS 上都不卡。本文会从单节点安装、高可用集群、持久化存储、Ingress 配置到生产上线的关注点逐步展开，帮助你用最小的运维成本拿到一套可用的容器编排平台。
K3s 与原生 K8s 的区别
K3s 不是 K8s 的功能子集，而是发行方式不同。理解这几点差异，再看后面所有的配置都会顺很多：
- 单二进制：把 kubelet、kube-proxy、容器运行时、网络插件全部打包，安装即用，没有零散的服务要拉起
- 默认存储：用 SQLite 替换 etcd，单节点足够轻；切换到高可用模式时再换成内嵌 etcd 或外部数据库
- 内置组件：自带 Traefik 作为入口、ServiceLB 提供 LoadBalancer 类型服务、本地路径作为默认存储
- 完全兼容：所有的 kubectl 命令、Helm 包、原生 YAML 都能直接用，社区资源完全复用
- 资源占用：主节点加工作节点跑在同一台机器上不到三百兆内存，比官方发行版省一半以上
简单说，K3s 让你用单台服务器就能学完整套 Kubernetes 概念，又不至于把机器跑爆，对个人项目和中小团队特别友好。
单节点最小安装
最快上手只要一条命令：
curl -sfL https://get.k3s.io | sh -
装完后 kubectl 直接可用，主节点的 kubeconfig 文件放在 /etc/rancher/k3s/k3s.yaml，权限默认 600。要让普通用户能用，把它复制到 ~/.kube/config 并改一下属主就行。国内服务器装的时候经常卡在拉镜像，可以在命令里加 INSTALL_K3S_MIRROR=cn 走国内镜像，速度会快很多。
加入工作节点
主节点装完后，记下它生成的 token，文件路径是 /var/lib/rancher/k3s/server/node-token。在工作节点上执行安装时带上主节点地址和这个 token，等几十秒就能加入集群：
curl -sfL https://get.k3s.io | K3S_URL=https://<master-ip>:6443 \
K3S_TOKEN=<token> sh -
回到主节点跑 kubectl get node 就能看到新节点状态变成 Ready。如果一直卡在 NotReady，多半是防火墙没放行 6443、10250、8472 这几个端口，先检查这一项。
高可用集群
单节点 K3s 死了集群就废了，生产环境至少三个主节点。第一台用 --cluster-init 启动并指定共享 token，后续节点用 --server 指向第一台。三个节点会自动形成内嵌的 etcd 集群，节点数要保持奇数（三个或五个），否则脑裂时无法选主。
前面挂一个 TCP 负载均衡指向 6443 端口，kubeconfig 里的 server 地址改成 VIP，单节点宕机不影响 API 访问。负载均衡器层的配置思路可以参考 Nginx 反向代理与负载均衡实战 中关于 TCP stream 模块的章节，直接把里面的健康检查模板搬过来用。
持久化存储
K3s 默认带的本地路径存储只在节点本地划目录，节点挂了数据就丢。生产环境建议换成下面几种之一：
- Longhorn：Rancher 出品，跨节点副本，安装最简单，运维门槛低
- NFS：用外部 NAS 通过子目录 provisioner 接入，适合已有存储设备的场景
- Ceph 或 Rook：规模上来后的选项，性能最好但运维成本最高
PVC 里写明 storageClass 就行，剩下的交给 provisioner。注意一点：默认存储类没设置时，部分 Helm 包装不上，要么显式声明 storageClass，要么把目标存储类设为默认。
Ingress 与证书
K3s 内置 Traefik 已经很够用，绝大多数场景写一份 IngressRoute 把域名指向 Service 就完事。证书部分用 cert-manager 自动申请 Let’s Encrypt 是最稳的方式，对内网集群推荐用 DNS 验证而不是 HTTP 验证，避免暴露 80 端口。
如果你前面还想再放一层 CDN（内容分发网络）做防 DDoS 和加速，可以看 Cloudflare CDN 中国加速 把回源 IP 与白名单一并配好，避免攻击者绕过 CDN 直击源站。
生产环境上线前的检查
部署完不等于上线，至少要过一遍这些项目，少一项都可能在凌晨叫你起床：
- 备份：etcd 快照自动保留多少代、存到哪台机器、能不能在测试环境恢复一遍
- 日志：每个节点的系统日志与 pod 日志聚合到 Loki 或 ELK，便于事后排查
- 监控：Prometheus 加 Grafana，至少看节点、pod、PVC 三层指标
- 安全：API 端口不暴露公网，节点 SSH 启用 Fail2ban 防爆破
- 升级：先升主节点再升工作节点，灰度推进，不要一把梭
跳板机的 SSH 加固建议参考 SSH 与 Fail2ban 加固 里的模板。如果集群里要跑 WordPress 站点，可以一并参考 WordPress 与 W3 Total Cache 调优 把容器化下的对象缓存配置对一遍。
常见踩坑
- 用了老内核的 cgroup v1，K3s 启动报错；升级内核或在 grub 加 cgroup v2 参数
- 防火墙没开 6443、10250、8472 这三个端口，工作节点加入失败
- token 漏写或带了换行符，节点加入卡 30 秒后超时报 unauthorized
- 高可用用了偶数主节点，etcd 选主异常导致集群不可写
- PVC 一直 Pending，往往是没设默认 storageClass 或 provisioner 没装好
总结
K3s 让 Kubernetes 从大公司专属技术变成单人也能跑的工具。建议先在一台开发机上跑通单节点，把 Deployment、Service、Ingress、PVC 这四种资源都摸一遍，再扩展到三节点高可用集群。如果你需要在生产环境替代 Docker Compose，K3s 是目前门槛最低的选择，资源占用也比官方发行版装出来的小一半以上。整体下来你会发现，过去那些关于 Kubernetes 太重的吐槽在 K3s 上基本不成立，它把八成的核心能力以两成的资源开销做了出来，对个人项目、小团队、自托管服务都非常合适。剩下的复杂度可以等业务真用上时再慢慢补，先把容器编排这件事跑起来，比纠结架构细节重要得多。