K3s：装进口袋的 Kubernetes

项目地址：https://github.com/k3s-io/k3s 定位：轻量级 Kubernetes 发行版——单二进制、低资源、为边缘/物联网/CI/开发环境而生，Rancher（现 SUSE）出品，CNCF 沙箱项目。

元信息	说明
语言	Go（打包成单二进制 ~70MB）
星标	28k+ ⭐
协议	Apache 2.0
资源需求	最低 512MB 内存即可跑起控制面（生产建议 1GB+）
内核兼容	去掉云厂商与遗留驱动依赖，支持老内核与 ARM

1、背景：K8s 太重的困境

标准 K8s（kubelet + apiserver + etcd + controller-manager + scheduler + CNI/CSI 生态）的部署门槛与资源占用，让它在三个场景水土不服：

边缘节点（工厂/门店/车机）：1C1G 的盒子跑不动完整控制面
ARM/嵌入式：官方发行版对非 x86 与老内核支持不佳
CI/开发：minikube 太重，Kind 真实度不足，开发机内存有限

K3s 的答案：一个二进制 + SQLite（替代 etcd）+ 内置打包的轻量组件，牺牲"完整集群的部分默认能力"，换取"在 512MB 内存的树莓派上 30 秒起一个真 K8s"。

2、轻量化的五个裁剪决策

① 存储：默认 SQLite 替代 etcd（--datastore-endpoint 可切回 etcd/MySQL/PostgreSQL）
② 运行时：内置 containerd（无 docker 依赖）
③ 网络：内置 flannel + service.lb 简化实现 + Traefik ingress（开箱即用）
④ 驱动：剔除云厂商/第三方存储驱动，合入 local-path-provisioner
⑤ 打包：全部组件打进一个二进制，systemd/容器 两种启动方式

关键认知：K3s 是认证的 Kubernetes（CNCF 一致性认证通过）——裁剪的是默认组件与安装形态，不是 API。你的 Deployment/Service/CRD/Helm 在 K3s 上与在 GKE 上语义一致。这就是"轻量但不残废"的底气。

2.1、高可用与嵌入式 etcd

单机 SQLite 只适合边缘/实验；生产多节点：

# 控制面 HA：3 台 master + 外部数据源
# 选项 A：回到 etcd（嵌入式，3 master 组成 etcd 集群）
curl -sfL https://get.k3s.io | sh -s - server \
  --cluster-init                    # 初始化嵌入式 etcd
# 其余 master：
curl -sfL https://get.k3s.io | sh -s - server --server https://master1:6443

# 选项 B：复用现有 MySQL/PostgreSQL（运维体系已有 DB 团队时友好）
--datastore-endpoint="mysql://user:pass@tcp(db:3306)/k3s"

3、快速上手

# 30 秒起集群（Linux）
curl -sfL https://get.k3s.io | sh -
# kubeconfig、kubectl（自动符号链接 /usr/local/bin/kubectl → k3s kubectl）全部就绪
sudo k3s kubectl get nodes        # ready！

# 加入 worker（NODE_TOKEN 在 /var/lib/rancher/k3s/server/node-token）
curl -sfL https://get.k3s.io | K3S_URL=https://<server-ip>:6443 \
  K3S_TOKEN=<token> sh -

# macOS/Windows 开发：用 multipass/lima 起一台 VM 再装 k3s；
# 或直接用 Rancher Desktop（内置 k3s）

# 验证"真 K8s"体验
kubectl apply -f https://k8s.io/examples/application/deployment.yaml
kubectl get pods -w        # Traefik ingress 已内置，local-path PV 可用

uninstall 干净利落：/usr/local/bin/k3s-uninstall.sh（agent：k3s-agent-uninstall.sh）——CI 场景反复起停无残留。

4、典型场景与方案地图

场景	方案要点
边缘计算（门店/工厂）	K3s + GitOps（Fleet/ArgoCD）管理百级节点；Agent 通道可选 airgap 离线安装
IoT 设备集群	ARM64 树莓派组集群；SQLite 单机 + 定期备份
CI/CD 流水线	每个测试任务起独立 K3s（VM/容器内），跑完即删——比 Kind 更接近"真集群"（真实 kubelet/containerd）
开发环境	Rancher Desktop / k3d（容器里跑 K3s，秒级多集群）
小型生产集群	3 master 嵌入式 etcd + 若干 agent + 备份（见下）
K8s 学习实验	与第 24 篇 minikube 二选一：资源紧张的机器选 K3s

5、生产实践清单

备份就是一切：SQLite/etcd 数据目录 /var/lib/rancher/k3s/server + token；官方 k3s etcd-snapshot save/restore 内置（嵌入式 etcd 模式）；SQLite 模式直接停服拷贝文件。边缘节点没备份=数据裸奔；
网络默认值检查：flannel VXLAN 默认可用；需要 BGP/网络策略强表达时换 Cilium/Calico（--flannel-backend=none --disable-network-policy 后自装）；节点网络段冲突用 --cluster-cidr/--service-cidr 规避；
替换内置组件：Traefik 不要就 --disable traefik；metrics-server、local-storage 同理可关——默认全家桶是甜点也是约束，按需裁剪；
离线安装：airgap 模式（镜像 tar 包 + 二进制离线拷贝）是边缘刚需，提前把离线包纳入制品管理；
版本策略：K3s 跟随上游 K8s 小版本（v1.30.x+k3s1），升级=换二进制重启（逐节点滚动）；别把它当"阉割版"长期落后上游；
与 RKE2 的边界：Rancher 系里 K3s 面向轻量/边缘，RKE2 面向"安全合规优先的企业级"（默认更硬化的 CIS 基线）。生产合规要求高时评估 RKE2 而不是给 K3s 硬堆配置。

6、横向对比：轻量级 K8s 生态

方案	形态	启动速度	真实度	适合
K3s	单二进制（VM/裸机）	~30s	高（真 kubelet）	边缘/生产小集群/ARM
k3d	容器内跑 K3s	~5s	中高	开发多集群模拟
minikube（第 24 篇）	VM/容器	1-3min	高	学习/单机实验（功能面板全）
Kind	容器节点	~10s	中（控制面容器化）	CI 跑 K8s API 测试
MicroK8s	snap 单机发行	~1min	高	Ubuntu 系快速体验

决策速判：生产边缘 → K3s；开发机模拟多节点 → k3d；跑 helm/CRD 集成测试 → Kind；系统学习 K8s 功能全貌 → minikube。

7、面试/实践高频问答

Q：K3s 和 K8s 的 API 有区别吗？ A：没有。K3s 通过 CNCF 一致性认证，标准工作负载语义一致；差异在默认组件（SQLite/flannel/Traefik/local-path）与安装形态。面试答"发行版差异"而非"功能阉割"更准确。
Q：SQLite 存集群状态，靠谱吗？ A：定位决定。边缘单节点/实验完全够用（且备份就是拷文件）；但 SQLite 是单写者，多 master 必须切嵌入式 etcd/外部 DB——K3s 的数据源是可插拔的，不要把"默认"当"上限"。
Q：为什么边缘场景不用 Docker Compose？ A：节点数=1 且永远是 1，Compose 够了；一旦多节点、要声明式扩缩、要统一下发应用（GitOps），K8s 的控制循环（第 5 篇）价值就出现了。K3s 把这个决策的门槛降到"512MB 内存"。
Q：k3d 和 Kind 有什么区别？ A：k3d=容器里跑 K3s（完整的轻量发行版，含网络/PV 默认可用）；Kind=把标准 K8s 控制面跑成容器（更"官方"，但节点本身是容器，某些运行时行为不真实）。测 operator/CRD 两者都行，测 CNI/存储行为 k3d 更接近真机。

8、总结

K3s 用工程手段回答了"K8s 能不能轻"：单二进制打包、SQLite 数据源、内置全家桶、认证一致性。它让 Kubernetes 走出数据中心——走进门店、工厂、树莓派和你的 CI 流水线。与系列前文呼应：第 5 篇理解控制循环，第 11 篇手搓过黑盒，第 24 篇 minikube 做实验——K3s 则是你把它们带到"真实小规模生产"的那张船票。