📚 课程目录第3章 K3s核心概念

3. K3s核心概念

K3s 是 Rancher 推出的轻量级 Kubernetes 发行版，专为资源受限、网络不稳定、运维人力有限的边缘与工业现场设计。它并不是“简化版玩具”，而是把标准 Kubernetes 的 API 语义、控制器模型和生态兼容性保留下来，同时通过裁剪非必要组件、合并进程、内置常用能力，把单节点资源占用压到约 512MB 内存、二进制体积控制在 100MB 以内。理解 K3s 的核心，关键在于看清它“保留了什么、替换了什么、放弃了什么”。

一、核心原理：单进程融合与轻量存储

标准 K8s 的控制平面由 kube-apiserver、kube-controller-manager、kube-scheduler、etcd 等多个独立进程组成，组件间通过证书和网络通信。K3s 则把这些控制平面组件编译进同一个 k3s server 进程，默认使用 SQLite 作为数据存储，也可切换为嵌入式 etcd 或外部 MySQL/PostgreSQL。节点侧，kubelet、kube-proxy、容器运行时被整合进 k3s agent 进程。这种“进程融合”显著降低了内存开销和进程间通信复杂度。

同时，K3s 内置了 Flannel 作为默认 CNI、CoreDNS、Traefik Ingress、ServiceLB、Local Path Provisioner 和 Metrics Server，开箱即用，无需逐项安装。对于工业边缘场景，这意味着现场部署时不必依赖外网拉取大量镜像，离线包即可完成集群初始化。

K3s 的设计哲学：保留 Kubernetes API 与控制器语义，裁剪非核心组件，合并进程，内置常用插件，使集群能在 1 核 1GB 的工控机或网关设备上稳定运行。

二、架构组件与数据流

下图展示 K3s 单节点与多节点混合架构中的关键组件及其关系。Server 节点承载控制平面与数据存储，Agent 节点运行工作负载；两者通过 6443 端口通信，Agent 使用 8472/UDP 进行 Flannel VXLAN 覆盖网络通信。

三、与标准 K8s 的关键差异

K3s 与标准 K8s 的差异不是“功能多少”的简单对比，而是面向边缘场景的取舍。下表从存储、运行时、网络、插件、高可用和资源占用六个维度进行对照。

对比维度	标准 Kubernetes	K3s
默认数据存储	etcd 独立集群	SQLite（单节点）/ 嵌入式 etcd（HA）
容器运行时	containerd 或 CRI-O 独立安装	内置 containerd，无需额外配置
网络插件	需手动安装 CNI	内置 Flannel VXLAN
Ingress / LB	需单独部署	内置 Traefik + ServiceLB
高可用模式	多 Master + etcd 集群	多 Server + 嵌入式 etcd 或外部 DB
资源占用	控制平面约 2GB+ 内存	单节点约 512MB 内存

需要特别注意的是，K3s 移除了部分 Alpha 特性和云厂商专属的 Cloud Provider 集成，默认也不包含 Helm、Dashboard 等上层工具。但 K3s 完全兼容标准 Kubernetes API，kubectl、Helm Chart、Operator 均可正常使用，这意味着应用迁移成本极低。

四、适用边界与限制

K3s 适合以下场景：工业网关、边缘计算盒子、零售门店服务器、IoT 汇聚节点、CI/CD 轻量测试集群、家庭实验室。这些场景的共同特征是节点数量少、资源有限、网络可能间歇、运维以远程为主。

但 K3s 也有明确的边界。第一，单节点 SQLite 模式不适合大规模高并发写入，节点数超过 5 个或 Pod 数超过数千时，建议切换嵌入式 etcd 或外部数据库。第二，K3s 默认不启用 Pod 安全策略和审计日志，生产环境需手动加固。第三，部分依赖云厂商 API 的存储类、负载均衡器无法直接使用，需要替换为 Local Path 或 NFS 方案。第四，K3s 的升级节奏跟随上游 K8s，但版本滞后约 1～2 个小版本，对最新特性有强依赖的项目需评估。

常见误区：认为 K3s 只能用于测试。实际上，通过多 Server + 嵌入式 etcd 高可用模式，K3s 完全可以承载生产级边缘业务，关键在于合理规划存储、网络和备份策略。

五、工业现场部署示例

以下命令展示在工业网关上以 Server 模式启动 K3s，并禁用 Traefik 以节省资源，同时指定 Flannel 使用指定网卡：

# 安装 K3s Server，禁用 Traefik，指定 Flannel 网卡
curl -sfL https://get.k3s.io | INSTALL_K3S_EXEC="server \
  --disable traefik \
  --flannel-iface eth0 \
  --write-kubeconfig-mode 644" sh -

# 查看节点状态
kubectl get nodes -o wide

# 查看 K3s 服务日志
journalctl -u k3s -f

在 Agent 节点加入集群时，只需指定 Server 地址和 Token：

# 在 Agent 节点执行
curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.10:6443 \
  K3S_TOKEN=<server-token> sh -

部署完成后，建议立即配置 etcd 快照或 SQLite 定期备份，并限制 API Server 的访问来源。对于工业现场，还应考虑看门狗、双机热备和断网续传策略，确保边缘集群在异常恢复后能自动重新加入。

复盘建议：在边缘项目中，先以单节点 K3s 验证业务容器和网络策略，再逐步扩展为多节点高可用。不要一开始就追求复杂架构，K3s 的价值恰恰在于“先跑起来，再优化”。

总结来说，K3s 是标准 Kubernetes 在边缘场景的工程化裁剪版本。它保留了 API 兼容性和控制器模型，通过进程融合、内置插件和轻量存储降低了资源门槛。理解它的架构组件、与 K8s 的差异以及适用边界，是后续在工业现场稳定部署和运维集群的基础。