边缘与轻量 Kubernetes：K3s、KubeEdge 与资源受限环境

在机房、零售门店、工地或车载设备上，不可能跑一套完整的 K8s：内存只有 2GB、带宽时有时无、节点上不了云、还要单机就能干活。于是轻量发行版 K3s 与云边协同框架 KubeEdge 应运而生。本指南先讲边缘场景到底约束在哪，再深入 K3s 的架构与裁剪（一个二进制跑起整个集群）、单节点与嵌入式部署、KubeEdge 的云边协同模型，最后讲资源受限环境的调度、离线弱网应对与安全的升级策略。

目录

• 1. 边缘场景的约束与选型
• 2. K3s 架构与组件裁剪
• 3. K3s 单节点与嵌入式部署
• 4. KubeEdge 云边协同
• 5. 资源受限环境的调度
• 6. 离线与弱网环境
• 7. 边缘存储与网络
• 8. 边缘集群升级与更新策略
• 9. 生产最佳实践

1. 边缘场景的约束与选型

1.1 边缘到底难在哪

边缘节点典型画像：硬件弱（14 核 CPU、18GB 内存、无独显）、网络差（公网弱网/间歇断连、NAT 后、多跳）、无人值守（断电重启、磁盘故障、无本地运维）、规模化（成千上万个分散站点，逐个升级不现实）。对 K8s 的挑战：控制面太重（etcd/多个 controller）吃不下；依赖云上 API Server，断网即失控；运维模型按"一个集群"想，边缘是"成千上万个集群"。

1.2 选型：K3s vs KubeEdge

简单判断：一个边缘站点需要"完整 K8s 能力、独立自治"选 K3s；上千个边缘设备要"云端统一管理、弱网优化"选 KubeEdge。很多场景是 K3s（站点）+ 上层统一 GitOps 管控。

2. K3s 架构与组件裁剪

2.1 一个二进制里有什么

K3s 把标准 K8s 的控制面压进一个约 60MB 的二进制：kube-apiserver、kube-scheduler、kube-controller-manager、etcd（单节点可切换 SQLite），还内嵌 traefik（Ingress）、flannel + kube-proxy、CoreDNS、local-path。K3s 是"把标准组件收进一个进程 + 默认选型更轻"，API 兼容标准 K8s，kubectl 用法完全一样。

2.2 安装时裁剪组件

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh \
  INSTALL_K3S_MIRROR=cn sh -s - \
  --disable traefik \
  --disable servicelb \
  --disable metrics-server \
  --disable coredns \
  --node-taint node-role.kubernetes.io/control-plane=true:NoSchedule

嵌入式场景建议：关掉 traefik（边缘常不用 Ingress，直接用 hostPort/NodePort）、关掉 metrics-server（省内存）、用 local-path 做本地卷。存储选型：单节点默认 SQLite（零依赖、轻）；高可用才用 etcd（至少 3 台 server）。

3. K3s 单节点与嵌入式部署

3.1 一条命令装好

curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh \
  INSTALL_K3S_MIRROR=cn \
  INSTALL_K3S_SKIP_ENABLE_SYSTEMD=false \
  sh -s - --write-kubeconfig-mode 644

kubectl get nodes
kubectl get pods -A
export KUBECONFIG=/etc/rancher/k3s/k3s.yaml

3.2 资源预算与嵌入式

精简后（关掉 traefik/servicelb/metrics-server）控制面 + 系统约占 300~500MB 内存，把余量留给业务。单节点用 SQLite 需要注意：它只适合单 server，别在 SQLite 上做 HA；备份用 k3s etcd-snapshot save 或直接备份 SQLite 文件。

ℹ️ 心智模型：K3s 不是"另一套系统"，而是"把标准 K8s 塞进一个进程"。API 兼容、kubectl 全兼容，只是默认组件选型更轻。

4. KubeEdge 云边协同

4.1 架构

┌──────────── 云侧 ────────────┐
│  CloudCore：与 K8s API Server │
│  对接，管理所有边缘节点       │
└──────────────┬───────────────┘
  云边通道（WebSocket/Quic）
┌──────────────▼───────────────┐
│  EdgeCore（边侧）            │
│  EdgeHub：云边通信/离线缓存  │
│  EdgeMesh：边边通信/服务发现 │
│  Edged：轻量 Kubelet         │
│  DeviceTwin：设备孪生        │
└──────────────────────────────┘

4.2 断网自治与设备孪生

云边断连时，EdgeHub 会缓存云下发的对象（Pod/ConfigMap），边侧照常调度、Pod 继续运行，网络恢复后双向同步增量数据。**DeviceTwin（设备孪生）**把传感器/设备状态同步一份到云侧，云侧下发期望状态、边侧执行并回报——适合 IoT 的 PLC 点位、温湿度、开关状态。加入边缘节点：边侧执行 edgecore --config edgecore.yaml start，云侧 kubectl get nodes 看到节点 Ready。

ℹ️ KubeEdge 的关键词是"协同"而非"独立集群"：它假设你有一个中心集群，边节点是"被纳管的远程 Kubelet"，这与 K3s 的"每站一个完整集群"是两种管理哲学。

5. 资源受限环境的调度

5.1 声明精确的资源

apiVersion: apps/v1
kind: Deployment
metadata:
  name: edge-app
  namespace: edge-apps
spec:
  replicas: 1
  selector:
    matchLabels: { app: edge-app }
  template:
    metadata:
      labels: { app: edge-app }
    spec:
      nodeSelector:
        role: edge-gateway
      containers:
        - name: app
          image: my-edge-app:1.2
          resources:
            requests: { cpu: 200m, memory: 256Mi }
            limits:   { cpu: 500m, memory: 512Mi }

资源受限调度要点：每个容器必须声明 resources（否则边缘 OOM 是常态）；用 nodeSelector/nodeAffinity 把重服务引到强节点；用 requests 而非 limits 做调度依据；边缘应用普遍单副本。

5.2 Taint 隔离

给边缘节点打污点 kubectl taint nodes edge-node-01 gpu=none:NoSchedule，普通负载就不会上去；只有带对应 tolerations 的边缘应用才能调度过来，形成"重负载与边缘负载互不干扰"的隔离。

6. 离线与弱网环境

6.1 镜像分发的难题

边缘断网时 Pod 需要镜像却拉不到 → 部署失败。对策分三层：预拉取（节点部署时把镜像打好）、本地镜像仓库（边侧起 registry 或从 USB/离线包导入）、弱网重试调优。K3s 相关命令：k3s ctr images import xxx.tar 离线导入镜像。

6.2 弱网优化与断点续传

弱网表现：带宽几十 KB、抖动大、频繁断连。应对：镜像共享基础层只拉变更层；控制面通信注意 keepalive；KubeEdge 的云边通道默认 Quic/WebSocket，专为弱网设计；日志与遥测本地缓冲 + 批量上报，别实时长连。离线自治兜底：即使完全断网，已调度的 Pod 与已缓存镜像应能持续运行——这也是 K3s 单节点自治 / KubeEdge 缓存机制的核心价值。

7. 边缘存储与网络

7.1 本地存储

边缘没有云盘，常见选择：local-path（K3s 内置的本地卷 provisioner，路径映射到宿主机）、宿主机目录 hostPath（慎用）、边缘文件系统（Ceph 太重，边缘通常不碰）。用 local-path 声明 PVC：storageClassName: local-path，accessModes 用 ReadWriteOnce。

7.2 网络：EdgeMesh 与多站点

K3s 默认 flannel 保证单站点内 Pod 互通。跨站点服务发现要用 EdgeMesh——它提供跨节点的服务发现与通信，无需 kube-proxy；站点间通道用 WireGuard/OpenVPN 组网或云边 VPN。

ℹ️ 边缘网络别照搬数据中心：数据中心能开任意端口、有稳定 DNS；边缘 NAT 后可能连"主动连回"都难。设计时默认"节点无法被外部直连，由它主动上报"。

8. 边缘集群升级与更新策略

8.1 升级的风险

边缘升级难点：站点多（逐个手工升级不现实）、升级中断 = 业务中断（无人现场盯）、回滚难（跨版本不可逆）。原则：小步升级（一次一个小版本）、分片灰度（先升 5% 站点再全量）、可回滚（升级前 etcd 快照/镜像回滚点）。

8.2 自动化升级

export INSTALL_K3S_VERSION=v1.28.8+k3s1
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | sh -s -

# 升级前快照
k3s etcd-snapshot save --etcd-snapshot-dir=/var/lib/rancher/k3s/snapshots

把节点版本当作"声明状态"写进 Git/ConfigMap，由定时任务或专门的升级 Daemon 检查差异并触发重装。回滚预案：保留上一版本二进制、定义明确回滚流程、升级窗口避开业务高峰、先 worker 后 server、关键站点升级前演练。

9. 生产最佳实践

9.1 Checklist

□ 明确选型：单站自治用 K3s，海量设备纳管用 KubeEdge
□ 精简安装：按需 --disable 内建组件，控内存
□ 单节点用 SQLite，高可用才上 etcd（至少 3 server）
□ 每个容器声明 resources，防边缘 OOM
□ 离线预置：镜像预拉取/离线导入，弱网调优重试
□ 本地存储走 local-path，别指望云盘
□ 升级小步 + 分片灰度 + 可回滚（升级前快照）
□ 无人值守保障：systemd 自启 + 磁盘/健康监控

9.2 常见坑与对策

小结

边缘 K8s 的核心是"轻、自治、可管“三件事：轻靠 K3s 这类发行版把控制面压进一个二进制并裁剪组件；自治靠单节点完整控制面（SQLite + 缓存镜像）或 KubeEdge 的断网降级；可管靠 GitOps/上层平台把成千上万个站点当"声明状态"统一升级。生产落地记住五件事：先选对型（K3s 单站 vs KubeEdge 大规模）、精简安装控内存、离线预置镜像、升级小步灰度可回滚、网络按"节点主动上报"设计。