现在搜"K3s"，先撞见的是一大片 Kimi K3。真正的 K3s——那套被叫作"减半版 K8s"的轻量 Kubernetes——讨论量不大，但一直没停。而且这两个月，它的社区出现了一个值得留意的转向：安装教程在退场，"扩容踩坑实录"在进场。
从 6 月初到 8 月初，光知乎上就出现了至少四五篇完整的折腾记录：有人把阿里云、AWS、Oracle Cloud 的机器整合成一个跨云集群。知乎专栏有人把腾讯云 VPS、OCI 的免费 ARM 机和家里局域网的 NUC 混编在一起跑 Kong 网关。知乎专栏还有人用 GitOps 把 Pod 从云端零停机漂移回本地。知乎专栏这些人有个共同点：单机 K3s 早就跑稳了，想用最低成本把集群做大——然后无一例外，全栽在了"加第二台机器"这件事上。
我把这批实录翻完，又对着 K3s 官方文档核了一遍机制，整理出 4 个出现频率最高的坑。如果你正处在"单机跑得好好的，想加机器"的阶段，这篇文章能帮你省掉几个通宵的抓包。
这篇写给谁，不写给谁
先划边界。如果你还没装过 K3s，这篇可以不看：安装教程已经饱和了，年初的"保姆级"系列从主机名、防火墙、时间同步写到离线安装，跟着抄作业足够。
这篇服务的是已经有第一台机器的人：想加节点、想把云主机或家里的旧机器接进来、想把服务暴露到外网。这个阶段的坑有个共同特征——只在"跨网络"时出现，所以单机玩家永远不会遇到，安装教程作者也就永远不会写。
坑一：节点全 Ready，Pod 通信却是黑洞
最反直觉的一个坑，也是跨云玩家必踩的一个。
有位玩家把手头散落在阿里云、AWS 和 Oracle Cloud 的四台机器拿出来组集群，思路简单直接：大家都有公网 IP，master 用 --tls-san 挂公网地址，worker 用 --node-external-ip 注册公网地址，公网互联。节点加入异常顺利，kubectl get nodes 一看，全部 Ready。
然后部署应用，全挂。
这里藏着一个很容易骗过直觉的不对称性：kubectl get nodes 能通，是因为 kubelet 主动向 API Server 发起连接，是单向请求；而 kubectl exec、kubectl logs 是 master 主动连 node，Pod 跨节点通信更是双向路由。云厂商的公网 IP 并不真正绑在机器网卡上——你去 AWS 或 OCI 的机器上敲 ip a，看到的都是 172.x、10.x 这样的内网地址，公网 IP 是外层网关做的 1:1 NAT。知乎专栏K3s 默认的 Flannel 走 VXLAN 封装，封装包头的地址根本穿不透这层 NAT，于是所有需要"主动找到对方"的流量全部掉进黑洞。
判断信号很明确：节点状态正常，但 exec/logs 卡住、跨节点 Pod 互访超时，基本就是这个坑。
这批实录给出的解法高度一致：别和云厂商的 NAT 硬刚，拉一层 overlay 网络。几乎所有记录都用了 Tailscale，在每台机器上装好后会多出一张 tailscale0 虚拟网卡（100.x.x.x 网段），让 K3s 的节点间流量全部走这张卡——复杂的公网拓扑被压平成一个"虚拟局域网"，NAT 问题直接消失。知乎专栏
坑二：新节点加入时，flannel 会悄悄选错网卡
这个坑是坑一的"续集"，也是 8 月初一篇踩坑实录的主角，排查过程相当曲折，值得多看两眼。
场景是腾讯云控制面 + 家用 NUC + OCI 免费 ARM 机的混合集群。NUC 一直很稳，但新加的 OCI 节点上，网关入口全部 502。排查时发现两个叠加的问题：
第一个，flannel 的 VXLAN 隧道端点绑在了 OCI 的内网 IP 上。知乎专栏flannel 选接口的规则很简单：你显式指定 --flannel-iface 就用它；不指定，它就选"默认路由出口"那张网卡——它不区分这个 IP 是公网、内网还是 Tailscale，只看默认路由。单云环境里所有节点的默认路由出口互相可达，自动探测没问题；跨云时每台机器的默认路由出口是各家的内网 IP，互相根本不可达。NUC 之前没事，是因为加入时显式指定了 --flannel-iface tailscale0；OCI 这台漏了这一步，flannel 就自作主张了。
第二个，MTU 静默丢包。flannel.1 的 MTU 是启动时按"物理网卡 MTU 减 50"（VXLAN 封装头开销）自动算出来的。OCI 的物理网卡支持巨型帧，MTU 9000，于是 flannel.1 被算成 8950；而集群其他节点走 Tailscale，MTU 是 1280 − 50 = 1230。知乎专栏结果 OCI 节点按 8950 发大包，对端按 1230 收不了，包在物理层被静默丢弃——TCP 连接表现为一直挂起、curl 返回 000，日志里却什么错误都没有，非常折磨人。而且实测发现，K3s 内置的 flannel 并不读取配置文件里手写的 MTU，改文件没用。
一条很值钱的检查命令：在所有节点上跑 ip link show flannel.1，对比 MTU。全集群必须一致，不一致就是隐患。
避坑动作就一条：只要你的节点不在同一个二层网络（跨云、跨家庭网络、走 Tailscale/ZeroTier 组网），加节点时一律显式带上 --flannel-iface，指定那张所有节点互相可达的网卡。
坑三：svclb 早就占了你的 80/443 端口
单机阶段感觉不到它的存在，扩容或换网关时它就会跳出来。
K3s 为了"开箱即用"，内置了一个叫 servicelb（svclb）的负载均衡实现，本质是一个 DaemonSet：每个节点上跑一个 pod，直接监听宿主机的 80/443，把流量转给 Traefik。注意，K3s 默认不给控制面打 taint，所以 control-plane 节点上也会跑这个 pod。知乎专栏
这带来两个后果。一是端口占用：你想自己装 Kong、nginx-ingress 或者任何监听 80/443 的入口，会发现自己和 svclb 打架。二是流量模型和标准 K8s 不一样：外部流量从任意节点的 80 进去，先过 svclb 再进 Traefik，排查 502 的时候如果不知道这一层，很容易怀疑错方向——前面那个 OCI 502 的案例里，排查的第一步就是确认三个节点上的 svclb pod 都在正常跑。
处理方式很简单：不需要内置 LB 的，安装时加 --disable=servicelb。需要保留的，记住"每台节点都在监听 80/443"这件事，别把问题想复杂。
坑四：扩容之前，先想清楚数据放在哪
这是四个坑里损失上限最高的一个，但很少有人提前想到。
K3s 默认用内置 SQLite 存集群状态。数据落在 /var/lib/rancher/k3s 下，默认存储 local-path 也是把 PVC 的数据写进宿主机目录。知乎专栏单机场景下这等于集群和数据绑定了同一块硬盘、同一台机器——机器一坏，集群配置、应用数据一起走。扩容的时机，恰好是把这个风险拆掉的时机：
先把 /var/lib/rancher/k3s/server/db 纳入备份，这是集群的命根子；想更稳的，了解 --cluster-init 切到内置 etcd 的方案，K3s 为此提供了内嵌的基于 etcd 的高可用数据源。
local-path 是节点本地盘，数据不跨节点。Pod 漂移到别的节点后访问不到原来的数据，所以在 K3s 上跑数据库、跑任何有状态服务之前，先想好数据方案（NFS、对象存储或者固定 nodeSelector），别等漂移完了才想起来。
一张速查表
症状 | 先查什么 |
|---|---|
节点 Ready，但 exec/logs 卡住、跨节点 Pod 不通 | 云 NAT + Flannel VXLAN，考虑 overlay 组网（坑一） |
新节点加入后部分流量超时，curl 返回 000 | ip link show flannel.1 对比各节点 MTU，查隧道端点绑了哪张网卡（坑二） |
自建网关起不来 / 入口 502 | 确认 svclb 是否存在、是否占着 80/443（坑三） |
担心机器挂了数据没了 | 备份 server/db，评估 local-path 的节点绑定属性（坑四） |
值不值得继续折腾
说句实在话：K3s 扩容的坑，没有一个是"装不上"级别的，全是"装上了但不通、不丢但吓人"级别的。好处也一样实在——免费层 VPS + 家里吃灰的旧机器就能拼出一套完整 K8s 环境，这两个月的实录里有人已经跑到跨云 GitOps、Pod 零停机漂移的程度。知乎专栏投入的也就是几个晚上。
给两个继续观察的信号：一是 K3s 版本跟上游 Kubernetes 的节奏走，升级前先看 changelog 里 flannel 和网络相关的改动；二是"跨云 + homelab 混合"这套玩法还在快速演进，最近两个月几乎每周都有新实录出现，这个兴趣值得保持关注。
如果你也在折腾 K3s 扩容，欢迎评论区聊聊你踩的是哪个坑——尤其是那些日志里什么都不写、就是不通的。
