K3s是Rancher Labs推出的轻量级Kubernetes发行版，它将Kubelet、Kubernetes API Server、Controller Manager、Scheduler以及容器运行时等核心组件全部打包进一个不到100MB的二进制文件中，同时对内存的占用也降到了512MB以内。这使得它非常适合运行在边缘设备、工控机、ARM开发板甚至NAS等资源受限的环境中。本文将从架构原理、部署实操、组件对比和高可用方案几个方面，完整讲解K3s集群的搭建过程。
一、K3s的架构设计与核心优势
K3s的核心思路是做减法。标准Kubernetes发行版依赖etcd作为存储后端，而K3s默认使用SQLite作为嵌入式数据库，大幅降低了部署复杂度。网络层面，K3s内置了Flannel作为默认的CNI插件，Service层则使用轻量的klipper-lb替代传统的云负载均衡器，Ingress默认由Traefik承担。这些内置组件开箱即用，省去了大量手动配置工作。
在集群角色划分上，K3s分为server节点和agent节点。server节点承担控制面职责，负责运行API Server和数据库；agent节点则只运行工作负载。这种分离设计让边缘场景可以采用一主多从的最小拓扑，甚至可以在单台设备上以server模式跑一个单节点集群用于开发测试。另外，K3s默认启用了containerd作为容器运行时，同时保留了切换到Docker的能力，兼容性表现出色。
值得注意的是，K3s删除了Kubernetes中一些在边缘场景用不到的功能，比如云厂商专属的存储插件和旧版本的alpha特性API，但保留了全部稳定的核心API。这意味着编写好的YAML清单文件可以直接从标准K8s迁移到K3s上运行，几乎不需要任何修改。
二、K3s集群的完整部署流程
部署K3s最简单的方式是使用官方提供的安装脚本。在server节点上执行一条命令即可完成安装：
# 在server节点执行安装，国内环境可加镜像加速参数 curl -sfL https://get.k3s.io | sh -s - server \ --write-kubeconfig-mode 644 \ --system-default-registry registry.cn-hangzhou.aliyuncs.com # 安装完成后查看节点状态 kubectl get nodes # 查看server节点的接入令牌 cat /var/lib/rancher/k3s/server/node-token
安装脚本会自动下载二进制文件、注册systemd服务并启动集群。执行完成后，kubectl命令已经自动配置好上下文，可以直接使用。node-token文件中保存的令牌是agent节点加入集群的凭证，需要妥善保管，避免泄露。
接下来在每一台agent节点上执行加入操作：
# 在agent节点执行，指向server节点的地址 curl -sfL https://get.k3s.io | K3S_URL=https://192.168.1.10:6443 \ K3S_TOKEN=上面获取到的令牌 sh -
这里的K3S_URL指向server节点的API地址，默认端口是6443。agent加入成功后，在server节点上再次执行kubectl get nodes就能看到新节点处于Ready状态。如果边缘环境没有外网连接，可以采用离线安装方式：提前在有网环境下载K3s二进制文件和离线镜像包，将镜像tar包放置到/var/lib/rancher/k3s/agent/images/目录下，再执行安装即可跳过在线下载环节。
对于网络拓扑比较特殊的场景，比如server节点处于NAT内网、agent无法直连其6443端口时，可以使用--node-external-ip参数声明外部地址，或者通过NODE_TOKEN配合代理中转的方式建立连接。此外，如果默认的Pod网络网段与现场网络冲突，可以通过--cluster-cidr参数自定义，避免路由异常。
三、内置组件与标准Kubernetes的差异对比
K3s与标准K8s在功能层面兼容，但组件实现上有多处不同，理解这些差异有助于排查问题和性能调优。下表列出了主要区别：
| 组件 | 标准Kubernetes | K3s |
|---|---|---|
| 存储后端 | etcd | SQLite（可选etcd、MySQL、PostgreSQL） |
| CNI插件 | 需手动安装 | 内置Flannel |
| Ingress控制器 | 需手动安装 | 内置Traefik |
| 负载均衡 | 依赖云厂商 | 内置klipper-lb（Service LB） |
| 容器运行时 | containerd | containerd（可切换Docker） |
内置Traefik虽然方便，但如果现场已有统一的网关层，很多运维人员会选择关闭它，改用自有的Ingress Controller。关闭方式很简单，在server启动参数中追加--disable=traefik即可。同理，如果需要替换网络插件，可以用--flannel-backend=none关闭Flannel，再自行安装Calico等插件，实现更细粒度的网络策略控制。
另一个常见差异是helm控制器。K3s原生支持通过HelmChart自定义资源部署应用，只需要编写一个声明式的YAML文件，K3s就会自动拉取Chart并完成部署，这对于没有安装helm命令行的边缘设备来说非常实用。
apiVersion: helm.cattle.io/v1 kind: HelmChart metadata: name: nginx-ingress namespace: kube-system spec: repo: https://kubernetes.github.io/ingress-nginx chart: ingress-nginx targetNamespace: ingress-nginx
四、高可用架构与常见问题排查
单server节点存在单点故障风险，生产环境建议搭建高可用集群。K3s提供了两种方案：一种是外置数据库方案，即多个server节点共同连接一个MySQL或PostgreSQL集群；另一种是从版本起支持的嵌入式etcd方案，通过--cluster-init参数初始化，再用--server参数追加节点。嵌入式etcd方案部署更简单，推荐在大多数场景中使用：
# 第一台server节点初始化etcd集群 curl -sfL https://get.k3s.io | sh -s - server --cluster-init # 后续server节点加入控制面 curl -sfL https://get.k3s.io | sh -s - server \ --server https://192.168.1.10:6443 \ --token <令牌>
高可用集群前面还建议挂载一个负载均衡器分发6443端口的流量，可以使用HAProxy或者keepalived配合虚拟IP实现，确保某个server节点故障时API访问不受影响。
在日常运维中，K3s的常见问题主要集中在网络和镜像两方面。如果agent节点一直处于NotReady状态，首先检查journalctl -u k3s-agent -f的日志输出，多数情况是令牌错误或时钟不同步导致TLS校验失败，边缘设备没有NTP服务时尤其常见。如果Pod镜像拉取失败，可以通过k3s ctr images import命令手动导入离线镜像，或者在/etc/rancher/k3s/registries.yaml中配置私有镜像仓库地址和加速端点。
日志排查方面，K3s自身的日志可以通过journalctl -u k3s查看，容器的日志路径为/var/log/pods/。卸载K3s时执行/usr/local/bin/k3s-uninstall.sh（server）或/usr/local/bin/k3s-agent-uninstall.sh（agent）即可完全清理环境。掌握这些运维入口之后，在边缘场景中管理K3s集群就会得心应手，既能享受Kubernetes完整的生态能力，又不必为资源开销发愁。
K3s部署边缘计算Kubernetes轻量集群修改时间：2026-09-01 12:09:03