k3s在边缘设备上启动更快、内存更低，因其将etcd、kube-proxy、coredns等组件合并为单二进制，用containerd替代docker，默认禁用云控制器等非必需模块，实测树莓派4b常驻内存约380mb；默认sqlite存储免去etcd开销，自动启用flannel和local-path-provisioner，且支持证书自动轮换与kubeconfig自动生成。
K3s 和 k0s 是目前边缘计算场景下最实用的两个轻量 Kubernetes 发行版，其中 K3s 更成熟、文档更全、生态适配更好；k0s 更“干净”，组件可裁剪性更强，但默认不带内置存储和网络插件，需要手动补全。
为什么 K3s 在边缘设备上启动更快、内存更低
K3s 把 etcd、kube-proxy、coredns 等组件合并进单个二进制，用 containerd 替代 Docker，并默认禁用云控制器、服务网格等非必需模块。实测在树莓派 4B（4GB RAM）上，K3s 启动后常驻内存约 380MB，而标准 kubeadm 集群通常超 1.2GB。
- 默认使用 SQLite 作为后端存储，避免 etcd 的资源开销和 TLS 配置复杂度
- 自动启用
flannelCNI，无需额外安装网络插件 -
local-path-provisioner默认启用，能直接挂载主机目录为 PVC，省去 NFS 或 Longhorn 的部署步骤 - 证书自动轮换、配置文件自动生成（
/etc/rancher/k3s/k3s.yaml），不用手动处理kubeconfig
k0s 安装后必须手动补哪些关键组件
k0s 虽然也单二进制，但默认只提供控制平面核心功能，不包含任何 CNI 或存储驱动。首次运行 k0s server 后，kubectl get nodes 可能显示 NotReady，常见原因就是网络不通或存储不可用。
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 必须显式指定 CNI：用
--cni calico或--cni custom+ 自定义配置文件，否则 Pod 无法分配 IP - 存储需手动部署：
k0s kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml - 若要支持
LoadBalancer类型 Service，得额外部署metallb或klipper-lb，k0s 不内置 -
k0s status显示组件状态，但不反映 CNI/Storage 是否就绪，需单独验证：k0s kubectl get pods -A | grep -E "(calico|local-path)"
Ubuntu 22.04 上部署 K3s 时最容易被忽略的三件事
系统层面的细节没调好，K3s 往往跑着跑着就卡住或报错，尤其在 ARM 设备或低配 x86 边缘盒子上。
- 必须关闭 swap：
sudo swapoff -a并注释/etc/fstab中 swap 行，否则 kubelet 直接拒绝启动 - 内核参数需提前加载：
net.bridge.bridge-nf-call-iptables=1和vm.overcommit_memory=1缺一不可，否则 Flannel 启动失败或 Pod 分配内存失败 - 时间同步必须稳定：边缘设备若离线时间长，证书会因时间漂移失效；推荐用
chrony而非 systemd-timesyncd，后者在弱网下容易失步
边缘节点一旦部署完成，别急着堆应用——先确认 k3s kubectl get nodes -o wide 输出的 INTERNAL-IP 是你期望的网卡地址，而不是 docker0 或 lo。很多网络不通的问题，根源只是 K3s 绑错了监听接口。
