想象你经营着一家连锁咖啡品牌。旗舰店坐落在市中心，配备了中央厨房、全套咖啡机、收银系统和库存管理系统，光是设备间就占了一整层楼——这就是 Kubernetes（K8s），功能强大但体量庞大。现在，你决定把生意扩张到街角、工厂流水线旁，甚至野外音乐节，总不能在每处都盖一座中央厨房。于是你打造了一辆「移动咖啡车」：麻雀虽小五脏俱全，一台车就是一套完整门店，接上电源就能开张——这就是 K3s。 K3s 是 Kubernetes 的轻量化发行版，专为边缘计算和 IoT 场景设计。它把 K8s 的控制平面压缩进一个约 60MB 的单文件二进制里，用轻量的内嵌 SQLite 替代了重型的 etcd 作为默认存储，还内置了 Traefik 充当「取餐窗口」，为外部请求做路由分发。移动咖啡车虽小，依旧遵循餐饮行业的标准，顾客用同一个点单 App（kubectl）就能管理所有门店。 在这篇文章里，我会带你从零认识这辆「K3s 咖啡车」，理解它的裁剪哲学、存储方案、网络入口，最后把它开到真实的边缘和 IoT 场景中营业。读完你会明白：当 K8s 太重搬不动时，K3s 是如何让容器编排在最后一公里落地的。

岗位关联

理解 K3s 是迈入边缘计算与 IoT 容器化的重要一步，它能帮你把云原生的能力延伸到设备端，让你同时驾驭机房与现场的容器编排。

目录
  1. 可视化演示
  2. 一、裁剪架构：只带必用的厨具
  3. 二、SQLite存储：小车一本账
  4. 三、Traefik路由：取餐窗口
  5. 四、环境准备：找车位接电源
  6. 五、单节点部署：一辆车开张
  7. 六、多节点扩展：组车队出击
  8. 七、工具链兼容：统一点单App
  9. 八、生产实践：真正街头营业
  10. AI 应用场景
  11. Python 演示
  12. 常见误区
  13. 面试题

可视化演示

展示系统处理流水线、实时性能指标曲线及多方案对比分析，包含数据流转、吞吐延迟监控与方案评估。

本节配有交互动效（进入视口后自动加载，约 3KB）。

系统可视化 处理流程：输入→处理→模型→输出 性能监控：实时指标 P=L×T

一、裁剪架构：只带必用的厨具

中央厨房要搬家，你需要大卡车、搬家公司，甚至吊车。但如果是移动咖啡车，只需把咖啡机、制冰机、收银台全部折叠进车厢，开到哪都能立刻开张。K3s 做的正是这件事：把 Kubernetes 的各个组件「折叠」成一个单文件、约 60MB 的二进制程序，让你在边缘设备上一条命令就能拥有一套迷你但完整的集群。

传统 K8s 的安装像「拼积木」：kube-apiserver、kube-controller-manager、kube-scheduler、etcd、kubelet、容器运行时，每个都是独立进程，还得配置证书和服务发现。K3s 反其道而行，把这些组件统统塞进一个 k3s server 进程里，用轻量模式统一启动，大幅降低了安装与运维的心智负担。

光「打包」还不够，K3s 还做了减法。它移除了云厂商（AWS、Azure、GCP）的控制器代码，因为这些代码对边缘场景是累赘；还砍掉了部分非核心存储插件与 alpha 特性，把最常用的 Traefik、local-path-provisioner 等作为可选组件内置。经过这番裁剪，K3s 在树莓派上也能以低于 512MB 内存的代价运行。

所以，开咖啡车并不意味着咖啡缩水，只是把不必要的大件留在库房。K3s 通过「能折叠的折叠、能去掉的去掉」，让 Kubernetes 在边缘场景轻装上阵——这正是它作为「移动咖啡车」的存在意义。

RK3s=14RK8s,SK3s≈125SK8sR_{\text{K3s}} = \frac{1}{4}R_{\text{K8s}},\quad S_{\text{K3s}} \approx \frac{1}{25}S_{\text{K8s}}
R 表示内存需求，S 表示安装体积。K3s 用 1/4 的内存、1/25 的体积，换来边缘环境可运行的 Kubernetes。
  1. 内存比值K3s 官方最低内存需求约 512MB，传统 K8s 控制平面建议 2GB 起步，比值约 1/4，为资源紧张的边缘设备留出了余量。
    RK3s/RK8s=512 MB/2 GB=1/4R_{\text{K3s}} / R_{\text{K8s}} = 512\,\text{MB} / 2\,\text{GB} = 1/4
  2. 安装体积比值K3s 单个二进制约 60MB；K8s 各组件加工具链体积可达 1.5GB 左右，比值约 1/25，下载和离线分发都更快。
    SK3s/SK8s≈60 MB/1.5 GB≈1/25S_{\text{K3s}} / S_{\text{K8s}} \approx 60\,\text{MB} / 1.5\,\text{GB} \approx 1/25

二、SQLite存储：小车一本账

中央厨房用一套 ERP 系统管理库存、订单和人员，信息量大、并发高；而移动咖啡车一天不过几百单，随身带一个小记账本就够了。K8s 默认用 etcd 这个分布式数据库保存集群状态，虽然强一致，但至少三台机器才能撑起高可用，在边缘显然太重。K3s 因此选择内嵌 SQLite 作为默认存储——一个小账本，随手能翻。

为什么敢用这么「轻」的数据库？关键在于 K3s 的写入模式。集群的状态变更由唯一的 Server 节点写入，Agent 节点只是通过 kubelet 读取状态来执行任务，是典型的「单写多读」。SQLite 天然擅长单写多读，且没有网络开销，读写延迟反而低于走 Raft 协议的 etcd。

当然，小账本也有天花板。如果业务增长到需要多台 Server 组成高可用控制面，内嵌 SQLite 就不再适用。此时 K3s 支持把数据放到外部 PostgreSQL、MySQL 或 etcd 上，实现「先小账本跑通，再按需换大系统」。

小账本虽简单，却精准匹配了移动咖啡车的小本生意；等生意做大，账本也能无缝升级成「总部系统」。这正是 SQLite 在 K3s 里「小事不费力、大事有后路」的设计智慧。

存储模式={SQLite单Server（默认）PostgreSQL / MySQL / etcd多Server高可用\text{存储模式} =\begin{cases}\text{SQLite} & \text{单Server（默认）}\\[6pt]\text{PostgreSQL / MySQL / etcd} & \text{多Server高可用}\end{cases}
K3s 的存储策略是分级的：单节点用内嵌 SQLite 零依赖起步；要高可用时再切换到外部一致数据库。
  1. 单Server模式一台 Server 默认使用内嵌 SQLite，零额外依赖，数据备份只需复制单个文件。
    1 Server⇒SQLite 单文件存储\text{1 Server} \Rightarrow \text{SQLite 单文件存储}
  2. 多Server模式多台 Server 需要共享同一集群状态，K3s 支持切换到外部一致数据库。
    N Server（N≥2）⇒外部数据库\text{N Server（N} \ge 2\text{）} \Rightarrow \text{外部数据库}

三、Traefik路由：取餐窗口

顾客不会绕到后厨翻冰箱，他们只认准取餐窗口。在 K3s 集群里，Traefik 就是这个窗口。K3s 默认自带 Traefik 作为 Ingress 控制器——所有外部请求先来到 Traefik，再由它按规则递给对应的服务（Service），最终送到具体的 Pod 手上。

在传统 K8s 里，安装 Ingress 控制器往往要自己下载 Nginx 或 HAProxy、配置 ConfigMap、管理证书，步骤又碎又重。K3s 把 Traefik 打进默认安装，你只需创建一个 Ingress 资源，声明「哪个域名对应哪个服务」，Traefik 就会自动监听并实时更新路由规则，无需重启。

Traefik 还自带 ACME 协议支持，可以自动向 Let's Encrypt 申请和续期 TLS 证书。在边缘部署一个 HTTPS 服务，只需在 Ingress 中标注证书注解，证书的申请、安装、续期就全部交给 Traefik，安全又省心。

移动咖啡车最大的亮点在取餐窗口：顾客不用关心后厨有几个咖啡师、豆子从哪来，只要报上订单号，咖啡就到手。Traefik 让 K3s 的流量入口体验同样干净利落。

请求→Host匹配Ingress规则Service→Selector匹配Pod\text{请求} \xrightarrow[\text{Host匹配}]{\text{Ingress规则}} \text{Service} \xrightarrow[\text{Selector匹配}]{} \text{Pod}
请求从客户到 Pod 要穿过两道门：第一道由 Traefik 根据域名找服务，第二道由 Service 靠标签选 Pod。
  1. Ingress规则匹配Traefik 按 Host 或 Path 匹配 Ingress 中的规则，找到对应的 Service。
    app.example.com⇒Service: myapp:80\text{app.example.com} \Rightarrow \text{Service: myapp:80}
  2. Service转发Service 通过 Label Selector 选中后端 Pod，完成最终的负载均衡。
    Service: myapp⇒Pod: 10.42.0.5\text{Service: myapp} \Rightarrow \text{Pod: 10.42.0.5}

四、环境准备：找车位接电源

移动咖啡车开张前，总得先看看停车位有没有电源、水龙头和足够的空间；部署 K3s 也一样，得先确认设备能满足最小要求。好消息是，K3s 的门槛低得惊人——官方要求内存不低于 512MB、CPU 不低于 1 核、存储不低于 2GB，树莓派这样的卡片电脑都能胜任。

K3s 支持 x86_64、armhf、arm64 以及 s390x 等多架构。你可以在树莓派、Jetson、NUC、老旧的 x86 工控机上安装。操作系统方面，主流 Linux 发行版（Ubuntu、Debian、Raspberry Pi OS 等）都行，macOS 和 Windows 上也有面向开发的单机二进制。

网络层面主要准备三个端口。K3s Server 要开放 6443（Kubernetes API）、8472（Flannel VXLAN）、10250（kubelet 指标）。如果集群跨子网，还要确认 UDP 8472 能在节点间畅通。准备工作越细致，后续出车越顺。

确认了车位和电源，咖啡车才敢开过去。同样，在 IoT 设备上安装 K3s 前，花十分钟核对资源、架构、端口，能让后续部署少踩很多坑。

最小配置=[CPU≥1 核, 内存≥512 MB, 存储≥2 GB]\text{最小配置}=\left[\text{CPU}\ge 1\,\text{核},\ \text{内存}\ge 512\,\text{MB},\ \text{存储}\ge 2\,\text{GB}\right]
这是一套能跑起控制平面的最低配置；真正承载业务 Pod 时建议内存翻倍及以上。
  1. CPU下限1 核是最低要求，生产建议 2 核以上。
    CPUmin⁡=1 核\text{CPU}_{\min} = 1\,\text{核}
  2. 内存下限512MB 可启动控制平面，但只够跑少量业务负载。
    内存min⁡=512 MB\text{内存}_{\min} = 512\,\text{MB}
  3. 存储下限2GB 用于系统、容器镜像和 SQLite 数据文件。
    存储min⁡=2 GB\text{存储}_{\min} = 2\,\text{GB}

五、单节点部署：一辆车开张

一辆咖啡车选好闹市区位置，接上电源，摇下取餐窗，立刻就能营业。K3s 的单节点部署也快得让人意外：一条 curl ... | sh - 命令，几十秒钟就能拥有一个带控制平面的集群。

在 K3s 中，安装脚本会自动下载二进制、生成启动配置、注册 systemd 服务并启动 k3s server。整个过程把 apiserver、controller-manager、scheduler、kubelet、containerd 全部折叠进一个进程，意味着一台设备既是大脑又是双手，既能管理资源也能运行 Pod。

安装完成后，K3s 会自动生成 kubeconfig 文件（默认在 /etc/rancher/k3s/k3s.yaml）。你把它拷到本地，或用 k3s kubectl get nodes 查看节点状态。看到 STATUS 为 Ready，说明单节点集群已经健康运行，可以开始部署第一个应用了。

从拉下卷帘门到端出第一杯咖啡，只需要几分钟。K3s 的单节点部署让边缘设备瞬间变成「迷你数据中心」，用最少的动作开启了云原生之旅。

install.sh→下载+注册k3s server⇒控制平面+kubelet\text{install.sh} \xrightarrow{\text{下载+注册}} \text{k3s server} \Rightarrow \text{控制平面} + \text{kubelet}
一条安装命令同时完成「下载、注册、启动」三步，最终得到单节点的完整集群。
  1. 安装脚本install.sh 负责下载二进制并注册 systemd 服务。
    curl -sfL 0 | sh -\text{curl -sfL 0 | sh -}
  2. k3s server一个进程同时启动 API、调度、控制器等控制面组件。
    k3s server⇒apiserver+scheduler+controller\text{k3s server} \Rightarrow \text{apiserver} + \text{scheduler} + \text{controller}
  3. 运行负载同一节点上的 kubelet 和 containerd 负责启动业务 Pod。
    kubelet+containerd⇒业务 Pod 运行\text{kubelet} + \text{containerd} \Rightarrow \text{业务 Pod 运行}

六、多节点扩展：组车队出击

一辆咖啡车忙不过来怎么办？再派几辆车过去，组成一个车队，由调度中心统一派单。K3s 的多节点扩展正是这个思路：一个 Server 负责调度和 API，多个 Agent 负责跑容器，整体像一支灵活的移动车队。

加节点的操作异常简单。登录 Server，读取 /var/lib/rancher/k3s/server/node-token 文件拿到 Token；然后在目标设备上执行带环境变量的安装命令，指明 Server 地址和 Token 即可。安装完成后，这台设备上的 k3s agent 会自动连接 Server 并汇报状态。

Agent 节点只包含 kubelet、containerd 和 Flannel，不跑控制平面，因此内存占用可以压到 200MB 左右。集群中所有资源请求仍然由 Server 统一调度，如果 Agent 不够用，随时再执行一次安装命令加一台——这就是 K3s「横向扩容」的便利。

车队规模随订单量灵活调整，这正是移动咖啡车商业模式的魅力。K3s 用 Token 把新「车辆」一键接入车队，让边缘集群从单机到多机只花一条命令的时间。

集群容量=资源Server+∑i=1n资源Agenti\text{集群容量} = \text{资源}_{\text{Server}} + \sum_{i=1}^{n}\text{资源}_{\text{Agent}_i}
集群整体容量等于 Server 管理开销加上所有 Agent 的计算资源之和，n 越大容量越大。
  1. Server资源控制平面占用的资源，不用于业务 Pod。
    资源Server=管理开销\text{资源}_{\text{Server}} = \text{管理开销}
  2. Agent求和n 个 Agent 的 CPU、内存、存储累加，就是可调度资源。
    ∑i=1n资源Agenti∝n\sum_{i=1}^{n}\text{资源}_{\text{Agent}_i} \propto n
  3. 弹性扩展n 可以随时增大，集群容量随之线性增长。
    n→n+1⇒集群容量增加n \rightarrow n+1 \Rightarrow \text{集群容量增加}

七、工具链兼容：统一点单App

顾客在旗舰店用手机 App 点单，在移动咖啡车也用同一个 App，因为品牌标准是统一的。K3s 与 K8s 生态之间也是如此：不管是 K3s 还是 K8s，kubectl、Helm、CRD 等工具都能直接使用——菜谱一样，做法一样，只是厨房设在不同的地方。

K3s 中已内置 kubectl 二进制（k3s kubectl），同时也兼容标准 kubeconfig。你可以把 k3s.yaml 拷贝到 ~/.kube/config，之后使用任意版本的 kubectl 访问集群。Helm 方面，安装 Charts 只需给 Helm 指定 K3s 的 kubeconfig 即可，无需任何额外插件。

K3s 也完整支持 CustomResourceDefinition（CRD）和 controller-runtime，因此各种 K8s 生态组件（如 Prometheus、Argo CD、Knative）都可以跑在 K3s 上。由于兼容 CRI（Container Runtime Interface）标准，它默认用 containerd，也允许通过参数切换其他运行时。

标准化的点单 App 让顾客走到任何一家门店都宾至如归。K3s 对齐 K8s 工具链，也让运维人员从云端到边缘使用同一套兵器——学一次 K8s，处处都能用。

工具链={kubectl, Helm, CRD, CRI}⊂K3s生态\text{工具链} = \{\text{kubectl},\ \text{Helm},\ \text{CRD},\ \text{CRI}\} \subset \text{K3s生态}
这行公式读作：kubectl、Helm、CRD、CRI 都是 K3s 生态的子集，标准工具链在 K3s 里完整可用。
  1. kubectl使用标准 kubeconfig 直连 K3s API Server。
    kubectl↔K3s API Server\text{kubectl} \leftrightarrow \text{K3s API Server}
  2. Helm兼容 Helm 3，Charts 可直接安装到 K3s。
    helm install→K3s 集群\text{helm install} \rightarrow \text{K3s 集群}
  3. CRD与CRI标准扩展模型和运行时接口都保持兼容。
    CRD+CRI⊂K3s生态\text{CRD} + \text{CRI} \subset \text{K3s生态}

八、生产实践：真正街头营业

咖啡车最终要开到真实的街头去赚钱。K3s 在边缘生产中最常见的场景，是把 AI 推理服务部署到靠近数据源的地方：工厂车间里对着传送带跑质检模型，门店里处理客流视频，农田里分析传感器数据——这些地方网络不好、也没有标准机房，恰恰是 K3s 的主场。

在工业 IoT 场景中，一台 K3s Server 可以同时管理几十台边缘设备，每台设备以 Agent 加入，用 Deployment 统一部署采集容器，用 Ingress 暴露数据接口。相比过去逐台 SSH 登录部署的「人肉运维」，K3s 让整个边缘集群像云上一样可控。

运维上需要特别注意：定期备份 SQLite 数据库文件（或外部数据库）、用 Prometheus + Grafana 监控节点与 Pod 指标、通过 k3s etcd-snapshot（若用外部 etcd）做快照，还要控制 Agent 上的镜像数量，避免占满存储。把这些做好，边缘集群就能长期稳定运行。

把咖啡车开进生活，才有商业价值；把 K3s 部署到真实边缘场景，才有工程价值。当你能像管理云集群一样管理一台台 IoT 设备时，K3s 就从「玩具」变成了真正的生产力。

可用性=T可用T总×100%≥99%\text{可用性} = \frac{T_{\text{可用}}}{T_{\text{总}}} \times 100\% \ge 99\%
可用性是衡量边缘服务稳定性的核心指标：99% 可用意味着每年停机不超过 3.65 天。
  1. 可用时间统计周期内服务正常响应的时间。
    T可用=T总−T故障T_{\text{可用}} = T_{\text{总}} - T_{\text{故障}}
  2. 总时间观察窗口的总时长，如一年 365 天。
    T总=365 天T_{\text{总}} = 365\,\text{天}
  3. 目标边缘生产环境至少保证 99% 以上可用。
    ≥99%⇒年停机≤3.65 天\ge 99\% \Rightarrow \text{年停机} \le 3.65\,\text{天}

AI 应用场景

智能工厂边缘质检

阶段：模型部署与推理服务

解决的问题：传统工厂质检依赖云端推理，带宽占用大、延迟高、断网即停摆。K3s 把模型容器部署到车间边缘节点，数据在本地处理，只有统计信息回传云端，解决了「最后一公里」的延迟和可靠性问题。

具体案例：某汽车零部件厂用一台 K3s Server + 5 台 Agent 管理 8 条产线的摄像头推理容器，通过 Traefik 暴露质检 API，AI 推理延迟从云端往返 2 秒降到本地 50ms，产线节拍完全不受影响。

连锁门店本地推理

阶段：边缘推理与数据汇聚

解决的问题：门店网络不稳定，客流分析模型依赖云端体验差。K3s 把模型放到门店本地设备上，同时支持模型的滚动更新，网络断了也不影响门店核心业务。

具体案例：连锁咖啡品牌在每家门店放一台 Jetson 设备，跑 K3s 单节点集群，部署客流统计和库存预测容器，每天定时把聚合指标同步到总部。总部统一用 kubectl 管理全国各地门店的 K3s，运维效率大幅提升。

智慧农业远程站点

阶段：数据采集与轻量推理

解决的问题：大棚、农场设备分散、环境恶劣，无法派人逐个维护。K3s 把采集、推理、告警容器统一编排到多个树莓派上，形成一个可远程管理的边缘集群。

具体案例：智慧番茄基地在 5 个大棚各放一台树莓派组成 K3s 集群，统一部署温湿度采集、病虫害图像识别容器。识别到异常立即在边缘触发告警并上报云端，大大节省了巡田人力。

Python 演示

python67 行
"""K3s集群模拟器: 演示边缘Agent加入Server并调度Pod."""  class K3sNode:    """模拟K3s中的一个节点(Server或Agent)."""    def __init__(self, name, role, memory_mb, cpu_cores=2):        self.name = name        self.role = role        self.memory_mb = memory_mb        self.cpu_cores = cpu_cores        self._mem_used = 0        self.pods = []        self._status = "Pending"     def join_cluster(self, server_name):        self._status = "Ready"        print("[{}] token校验通过, 角色={}, 已加入Server[{}]".format(            self.name, self.role, server_name))     def schedule(self, pod_name, mem_mb):        left = self.memory_mb - self._mem_used        if left >= mem_mb:            self._mem_used += mem_mb            self.pods.append(pod_name)            print("[{}] 调度成功: {}, 剩余内存 {}MB".format(                self.name, pod_name, self.memory_mb - self._mem_used))            return True        print("[{}] 内存不足, 拒绝调度: {}".format(self.name, pod_name))        return False  class K3sCluster:    """模拟K3s集群: 一个Server管理多个Agent."""    def __init__(self, server_name="edge-server"):        self.server = K3sNode(server_name, "server", 2048, 4)     def add_agent(self, name, memory_mb):        node = K3sNode(name, "agent", memory_mb)        node.join_cluster(self.server.name)        return node     def deploy_pod(self, agents, pod_name, mem_mb):        for node in agents:            if node.schedule(pod_name, mem_mb):                return node.name        raise RuntimeError("集群中没有足够内存调度 {}".format(pod_name))  def main():    cluster = K3sCluster("edge-server")    agents = [        cluster.add_agent("raspberry-pi", 1024),        cluster.add_agent("edge-gateway", 512),    ]    cluster.deploy_pod(agents, "ai-inference", 256)    cluster.deploy_pod(agents, "log-collector", 128)    cluster.deploy_pod(agents, "stream-analytics", 300)    try:        cluster.deploy_pod(agents, "heavy-job", 1000)    except RuntimeError as e:        print("调度被拒绝:", e)    print("活跃Agent:", [n.name for n in agents])    print("各节点Pod数:", {n.name: n.pods for n in agents})  if __name__ == "__main__":    main()
目的：这是一个简化版 K3s 调度模拟器，演示边缘设备如何以 Agent 身份加入 Server，以及调度器如何在内存不足时拒绝 Pod。
  1. def deploy_pod(self, agents, pod_name, mem_mb):模拟 K3s 调度器遍历 Agent 列表，找一个内存足够的节点。
  2. left = self.memory_mb - self._mem_used计算节点剩余可分配内存，类似 kubectl describe node 里看到的可分配资源。
  3. if left >= mem_mb:判断当前节点是否满足 Pod 的内存请求，对应真实 K3s 调度器的资源匹配逻辑。
  4. node.join_cluster(self.server.name)模拟 Agent 携带 Token 与 Server 握手并加入集群的过程。
  5. raise RuntimeError("集群中没有足够内存调度 {}".format(pod_name))所有 Agent 都不满足时抛出异常，对应真实集群中 Pod 一直 Pending 的调度失败场景。

常见误区

误区我一直以为 K3s 只是技术 demo 级别的玩具，API 功能被大削，生产环境用会有兼容性问题，不太敢把重要服务放在上面。

正解K3s 并没有阉割 K8s 的标准 API。它移除的只是与边缘场景关系不大的「外设」：云厂商存储控制器、部分 alpha 特性、部分非核心组件。K8s 标准 API、kubectl、Helm、CRD 都是兼容的。就像移动咖啡车少了中央厨房的炒锅，但出品的拿铁配方和旗舰店一模一样。

为何常见：名字里带「轻量」，宣传又强调「精简」，容易让人第一个联想到功能缩水。

误区SQLite 只是一个单文件小库，etcd 才是分布式高可用的。K3s 用 SQLite 不就是为了省资源？数据丢一次就全完蛋了吧。

正解SQLite 在「单写多读」场景下非常稳定，而 K3s 的 Server 天然是集群状态的唯一写入者，Agent 只读状态，所以 SQLite 完全够用。K3s 还支持把数据放到外部 PostgreSQL、MySQL 或 etcd 上，高可用生产模式依然有出路。

为何常见：人们习惯把 etcd 和 K8s 强绑定，见到替代品第一反应就是「降级」。

误区听说 K3s 是给树莓派用的，所以它只能跑在非常小的设备上，性能肯定不行，不适合正经业务。

正解K3s 是为资源受限场景设计，但它支持的硬件范围很广——从 256MB 内存的树莓派到 128GB 内存的服务器都可以跑。工业现场常用的边缘 AI 推理服务器也常部署 K3s 来管理 GPU 推理任务。

为何常见：宣传物料里常见树莓派、智能路由器的图片，容易留下「玩具」印象。

误区K3s 默认自带 Traefik 之后，不就用不了 Nginx Ingress 了吗？这就好比手机预装了一堆应用还不能卸载。

正解K3s 启动时可以通过 --disable=traefik 参数关闭默认 Traefik，之后按需部署 Nginx Ingress。默认集成只是降低上手门槛，不等于锁死生态。

为何常见：把「默认自带」理解成了「强制绑定」。

误区K3s 既然是 Kubernetes 的「轻量发行版」，那命令、资源文件、API 肯定都不一样吧？学 K3s 是不是等于重新学一遍？

正解K3s 兼容 K8s 的标准 API 和命令行工具。你在 K3s 上写的 Deployment、Service、Ingress YAML，放到 K8s 集群上照样跑。区别主要在「安装方式」和「发行策略」，使用层是同一套体系。

为何常见：名字一字之差，又总被放在一起对比，容易以为是一个平行体系。

面试题

Q1. K3s默认使用什么来替代etcd存储集群状态？

单选题 · easy

  • A.Redis存储
  • B.SQLite存储← 正确答案
  • C.MySQL存储
  • D.Hadoop存储

答案：B。K3s 为了降低资源占用，默认使用内嵌 SQLite 单文件数据库存储集群状态，避免了 etcd 需要多节点部署的开销。Redis、MySQL、Hadoop 都不是 K3s 默认内置的存储方案。

Q2. K3s默认内置的Ingress控制器是？

单选题 · mid

  • A.Traefik代理← 正确答案
  • B.Nginx服务
  • C.HAProxy代理
  • D.Envoy网关

答案：A。K3s 默认集成 Traefik 作为 Ingress 控制器，安装即可用。Nginx 需要手动部署，HAProxy 和 Envoy 需要额外控制面配置，都不是开箱即用。

Q3. K3s中Agent节点不需要运行哪个组件？

单选题 · mid

  • A.集群调度器组件← 正确答案
  • B.节点代理运行端
  • C.容器运行引擎
  • D.虚拟网络插件

答案：A。Agent 只负责执行任务，运行 kubelet、CRI 容器引擎和 Flannel 网络插件即可。调度器（scheduler）属于控制面组件，只运行在 Server 节点上。就像分店不需要配总部的排班经理。

Q4. K3s安装包的典型特征是什么？

单选题 · easy

  • A.单文件二进制← 正确答案
  • B.多服务分离
  • C.需要源码编译
  • D.依赖编译环境

答案：A。K3s 把所有组件打成一个约 60MB 的单文件二进制，这是它轻量化的核心。多服务分离恰好是传统 K8s 的方式；源码编译和编译环境描述的是从源码构建，不是安装包特征。

Q5. K3s生产环境实现多Server高可用，应使用什么数据存储？

单选题 · hard

  • A.外部独立数据库← 正确答案
  • B.内嵌单文件库
  • C.本地临时缓存
  • D.多机同步存储

答案：A。多 Server 需要共享同一集群状态，必须使用外部一致存储（PostgreSQL、MySQL 或 etcd）。内嵌 SQLite 是单文件，多个 Server 同时读写会不一致；本地临时缓存和多机同步存储都不满足 K8s 对状态存储的一致性要求。

Q6. K3s裁剪架构中移除了哪些内容？（多选）

多选题 · mid

  • A.云商存储插件← 正确答案
  • B.核心调度器
  • C.云控制器代码← 正确答案
  • D.API服务网关

答案：AC。K3s 裁剪的重点是云厂商相关的控制器和存储插件，这些在边缘场景用不到。核心调度器和 API 服务网关是 K8s 的骨架，K3s 完整保留，因此 B、D 不能选。

Q7. K3s支持哪些外置数据存储选项？（多选）

多选题 · mid

  • A.关系型数据库← 正确答案
  • B.文档型数据库
  • C.键值型数据库← 正确答案
  • D.图模型数据库

答案：AC。K3s 支持把集群状态存储到 PostgreSQL、MySQL（关系型数据库）以及 etcd（键值型数据库）。文档型（如 MongoDB）和图模型（如 Neo4j）不在官方支持列表中。

Q8. 关于K3s与K8s生态兼容性，以下说法正确的是？

单选题 · hard

  • A.API接口完全兼容← 正确答案
  • B.kubectl不可使用
  • C.Helm工具不能安装
  • D.调度插件完全不可用

答案：A。K3s 是 CNCF 认证的 Kubernetes 发行版，API 与 K8s 标准完全兼容，kubectl、Helm、CRD 都能正常使用。B、C、D 描述的「不可用」都与事实相反。

Q9. K3s内置的Traefik提供哪些能力？（多选）

多选题 · easy

  • A.路由请求分发← 正确答案
  • B.TLS证书管理← 正确答案
  • C.集群自动扩缩容
  • D.后端负载均衡← 正确答案

答案：ABD。Traefik 作为 Ingress 控制器，能按 Host/Path 路由请求（A）、为多个后端 Pod 做负载均衡（D），并支持自动签发和续期 TLS 证书（B）。集群自动扩缩容属于 HPA 控制器，不是 Traefik 的职责。

Q10. 新Agent节点加入K3s集群需要提供什么信息？

单选题 · mid

  • A.集群地址与密钥← 正确答案
  • B.数据库账号密码
  • C.节点SSH密钥
  • D.镜像仓库凭证

答案：A。加入 K3s 需要 Server 的 URL（如 https://server:6443）和 node-token（存在 Server 节点的文件中）。这个 Token 就是「集群的钥匙」，不需要数据库密码、SSH 密钥或镜像仓库凭证。