搜"K3s 和 K8s 的区别"，多数答案会给你一张功能对照表。先等一下------这两个东西根本不是并列关系。
K3s 不是"另一个 Kubernetes"，也不是"阉割版 Kubernetes"。它和你部署的标准 K8s 从同一段上游代码构建，API 完全一致，你为 K8s 写的 YAML 拿到 K3s 上原样能跑。打个后端同学熟悉的比方：K8s 之于 K3s，有点像 Spring 之于 Spring Boot------不是两套东西，是"自己装配"和"约定装配"两种形态。
所以"区别"这个说法容易带偏人：你比较的不是两个产品的功能清单，而是同一系统的两种交付方式。K3s 的全部取舍可以归到三个发行决策上------进程怎么打包、存储选什么、默认值给不给。本文就按这个讲：先把定位钉死，再拆三个决策，然后把那张著名的资源对比表还原成决策的后果，最后说怎么选。
不预设你读过 K8s 架构文档，组件用到哪个讲到哪个。
一、先把定位钉死：发行版，不是竞品
"发行版"这个词在这里是有具体含义的，不是修辞：
- 同源码：K3s 直接从 Kubernetes 上游源码构建，不是分叉重写。跟着上游版本走，一般慢一两个小版本。
- 同 API：这不是宣传口径。K3s 通过了 CNCF 的 Kubernetes 一致性认证------同一套 kubectl、同一份 YAML、同一批 GitOps 工具，行为一致。
- 不同交付：把"怎么把它装到机器上"这件事，做成了完全不同的产品形态。
这就是为什么标题说"差的不是功能"。API 层没有差的东西；差的全部在 API 层之下------怎么打包进程、用什么存数据、默认配哪些组件。三个决策，一个一个看。
二、K3s 做的三个发行决策
决策一：把控制平面打进一个二进制
标准 K8s 里，API Server、Scheduler、Controller Manager 各自是独立进程，各自一套证书、日志、systemd 单元。隔离性好，代价是每个进程一份运行时开销，进程间还要互相通信。
K3s 的做法：同一批组件（还包括 kubelet 和 kube-proxy 的功能），连同进程编排逻辑，编译进一个 Go 二进制文件，小于 100MB。一条命令拉起整个控制平面：
curl -sfL https://get.k3s.io | sh -（官方安装脚本的形态。它做的事：下载二进制、注册 systemd 服务、拉起集群------"一条命令，不到 1 分钟"的出处就在这。）
内存优势直接来自这里：进程少了，常驻开销和进程间通信就少了。Go 交叉编译还让它天然出了 ARM 版本------树莓派、工控机、边缘盒子都能跑，这是它霸占边缘场景的技术原因。
决策二：把 etcd 换成 SQLite
标准 K8s 强制依赖 etcd------不是"推荐"，是上游 API Server 只支持 etcd。
K3s 单机模式默认用 SQLite：单文件、零运维。为什么敢换？看一眼集群里的通信结构就明白了：
kubectl / CI 流水线 / ArgoCD / Helm ......
↓ 只有一条路：调 API
┌────────────┐
│ API Server │ ← 全集群唯一会碰存储的组件
└─────┬──────┘
↓ 这一层换掉，上面全部无感
etcd（标准 K8s）
SQLite（K3s 单机默认）
嵌入式 etcd / 外接数据库（K3s HA 模式）Scheduler、Controller Manager、kubelet......所有组件都只跟 API Server 说话，没有人直接碰 etcd。存储是 API Server 的私有实现细节，换掉它，上层一行代码不用改------和 DAO 层换个数据库、上层接口纹丝不动是同一个道理。
单机为什么敢用 SQLite，还有一层：SQLite 不做分布式共识，但单机模式只有一个 API Server 实例、单点写入，本来就不需要共识。等到要高可用------上多个控制平面节点------K3s 也会切到嵌入式 etcd 或外接数据库。换句话说，K3s 不是"砍掉了 etcd"，是把"单机场景用不上共识"这件事说了实话。
决策三：把默认值填上
标准 K8s 是故意"裸"的：CNI（容器网络）、CSI（存储）、Ingress、DNS，上游都只定义接口契约，具体实现留给你自己选。自由，但代价是装完一个"能用"的集群要做一堆决策和接线。
K3s 替你做了默认选择，开箱即用：containerd（容器运行时）、Flannel（CNI）、Traefik（Ingress）、CoreDNS。这就是"约定优于配置"------和 Spring Boot 替你定好内嵌容器、日志、数据源默认值是同一套思路。
两个边界要说清：一是默认不等于锁死，Traefik 可以换成别的 Ingress，Flannel 也可以换；二是别把"内置"读成"标准 K8s 没有"------标准 K8s 这边如今主流运行时同样是 containerd，区别只在 K3s 把它打进包里、配好、替你负责版本组合。
三、那张对比表：数字不是新区别，是三个决策的后果
| 对比维度 | K3s | 标准 K8s |
|---|---|---|
| 最低内存需求 | 约 512 MB | 至少 2 GB（仅控制平面） |
| 安装部署 | 一条命令，不到 1 分钟 | 步骤繁琐，通常 10-30 分钟或更久 |
| 适用规模 | 边缘、小集群（官方建议 HA 下约 1200 节点） | 大规模集群，可支撑数千节点 |
逐行还原一下，每个数字都能挂回前面的决策：
- 512 MB vs 2 GB：决策一（进程少）+ 决策二（SQLite 没有 etcd 多副本共识的开销）+ 决策三（内置的都是轻量组件）。
- 一条命令 vs 半小时：决策一（单文件）+ 决策三（不用装完集群再挑 CNI、DNS、Ingress）。标准 K8s 那 10-30 分钟的大头不是下载二进制，是"把裸集群补成能用"的决策和接线。
- 1200 节点 vs 数千节点 ：单一进程的控制平面 + 存储吞吐的天花板。注意这是控制平面的上限，不是 API 的上限------真到了那个规模，要换的是底座，你的 YAML 一行不用改。
四、怎么选：一个问题定方向
别拿两张场景清单打勾，先回答一个问题：你要的是"一套 Kubernetes"，还是"一台机器上的 Kubernetes"？
选 K3s 的场景------共同点是资源受限、要快、要省心：
- 边缘计算、IoT 设备（ARM 架构是 K3s 的主场）
- 开发测试环境：本机、GitLab / Jenkins 流水线里起一个迷你集群跑集成测试，用完销毁
- 中小团队的生产环境：想要功能完备的 K8s，但不想养专职运维
选标准 K8s 的场景------共同点是要组件级隔离、要极致控制：
- 大型数据中心、数千节点的规模
- 多租户、复杂网络策略、深度定制
- 强合规与审计要求，需要每个组件独立升级、独立追责
- 重度绑定云厂商的托管扩展和专有方案
还有一条常被忽略：选 K3s 的代价很低。因为 API 一致，你的 YAML、Helm Chart、kubectl 脚本、ArgoCD 这套 GitOps 流水线原样可用------哪天规模顶到 K3s 的天花板，要迁移的是底座，不是你的工作负载定义。这是"发行版"这个定位送的红利。
顺带一提：K3s 出自 Rancher Labs（SUSE），和做 K8s 管理平台的 Rancher 是同一家------如果你在用 Rancher 管集群，K3s 在它那边是一等公民。
收尾感受
写完最大的感受："X 和 Y 有什么区别"这类问题，先问定位，再谈区别。K3s 和 K8s 看起来是并列的竞品，实际是同一系统的两种发行形态。定位摆正之后，对照表里的每一行才有了归属：进程打包、存储选型、默认值------全是发行决策，不是能力差异。把区别讲成能力差异，就会有人问出"K3s 能不能跑 StatefulSet"这种问题；讲成发行决策，问题的正确形态变成"你的场景需要哪一种交付"。
第二个感受：K3s 是"诚实面对场景"的工程范本。单机用不上分布式共识，就不让你付共识的钱；边缘机器小，就把进程收进一个二进制。它省掉的不是功能，是不必要的开销。
最后是官方起名时就把定位说透了的细节：Kubernetes 十个字母缩写成 K8s；官方想要一个"一半大小"的东西，五个字母------K3s。名字本身就是答案。