用 200 美金废旧硬件搓出 K8s 裸金属集群的血泪实操记录

很多人学习云原生基础设施时，习惯了直接开通 AWS EKS 或阿里云 ACK 这种托管服务。但托管服务掩盖了太多底层细节，导致很多工程师在面对生产环境的诡异故障时，根本找不到排查方向。为了彻底搞清楚 K8s 的底层运行逻辑，我最近尝试用一些捡来的废旧硬件，硬生生地搭建了一个 4 节点的裸金属集群。

这次实验的硬件成本极低，总计约 215 美金。控制节点是一台免费捡来的 Dell OptiPlex（i5-6500 / 16GB / 256GB SSD），而三个工作节点则是从二手市场淘来的 Raspberry Pi 4（4GB RAM / 64GB SSD），单价约 60 美金，外加一个 35 美金的二手网管交换机。

在操作系统选择上，我没有使用传统的 Ubuntu Server，而是尝试了 Talos Linux。这是一款不可变（Immutable）操作系统，它没有 SSH，没有 Shell，所有的配置都通过 YAML 文件在 API 层级完成。这种设计虽然在初次部署时非常痛苦，但它强制你用声明式的方式管理集群，非常符合 K8s 的哲学。

这次架构的核心组合是：Talos Linux + Cilium (eBPF) + Longhorn。

最让我深刻的体感来自存储层。我在三个树莓派节点上部署了 Longhorn 来实现分布式存储。在实际运行中我发现，Longhorn 在 ARM 架构的树莓派上进行副本同步时，对 IO 的压力极大。如果你不预先设置严格的存储配额（Storage Quota），etcd 很容易因为磁盘空间被瞬间撑满而直接宕机，导致整个集群进入不可用状态。这种从磁盘满到 API Server 崩溃的连锁反应，是在云厂商的弹性磁盘环境下绝对体会不到的。

网络层我弃用了传统的 kube-proxy，直接上了基于 eBPF 的 Cilium。在理论上，Cilium 通过 eBPF 绕过了传统的 iptables 转发，能显著提升网络性能并降低延迟。但在实操中，这种“硬核”方案也带来了巨大的排查成本。由于 eBPF 策略是在内核层拦截流量，当某个 Pod 出现网络不通时，传统的 iptables -L 命令完全失效，你必须熟练使用 cilium monitor 等专用工具才能定位到流量被拦截的具体原因。

整个搭建过程中，我最惨痛的经历是烧掉了 3 张 SD 卡。由于 Talos Linux 的写入机制以及 Longhorn 频繁的同步操作，廉价 SD 卡的读写寿命在短时间内被迅速消耗，最终导致节点随机离线。这让我意识到，在裸金属环境下，硬件的可靠性直接决定了集群的稳定性。

这次实操让我意识到，考取 CKA 证书和真正维护一个裸金属集群完全是两回事。在模拟环境下，你只需要关注 API 的调用；但在真实环境下，你需要面对节点离线、存储同步失败、内核版本不兼容等各种底层问题。只有在这些崩溃的边缘，你才能真正理解 K8s 的自愈机制是如何在底层支撑起上层服务的。

对于想要在公司内部搭建 AI Agent 工作流或部署私有大模型的同学，我强烈建议先在自己的 Homelab 里把这些底层组件跑通。当你经历过手动修复 etcd 状态、排查 eBPF 网络丢包后，再去面对生产环境的部署，才会有真正的底气。