服务器硬件规划

1.1 这台机器到底是什么配置

我现在这套机器配置不算新，但拿来做 homelab 其实挺顺手的：

CPU：双路 E5-2686v4，合计 36 核 72 线程
内存：128G
本地 SSD：512G x 2
外部存储：极空间 Q2C NAS，8T HDD

我看中的其实不是“参数多豪华”，而是它刚好有几个我需要的点：

核心数够多，拆 VM 不会太抠。
内存够我把数据库、监控、K8s 一起放上去。
有两块本地 SSD，起码能把系统盘和主要数据盘分开。
还有个 NAS，备份、归档、冷数据就有地方放。

对我这个项目来说，这台机器是够的。不是“想怎么装都行”的那种够，而是只要前面分配得别太乱，后面这套基础设施是能撑起来的。

1.2 我先想清楚的，不是装什么，而是边界

这一步其实挺重要。因为这套环境从一开始就不是拿来作为生产集群的。

它就是个家庭环境：

会按需开关机
不跑 7x24
不做跨地域容灾
也不打算为了“像企业”去硬上很重的高可用方案

所以我给自己定的目标也很明确：不是堆一堆组件证明“我也有”，而是把一条主干搭顺。机器开了以后，这套东西能跑；机器关了以后，再开起来也知道怎么恢复。

边界想清楚以后，硬件这章其实就剩三件事：

存储怎么分
网络怎么留
计算资源后面准备怎么拆

1.3 我心里先有一张图

我自己想这件事的时候，脑子里大概是下面这个结构：

我不是把这台机器当成一台“大 Docker 主机”在用，而是把它当成一台物理承载。上面会分出一层 VM，每个角色干自己的事。

最下面是物理机本身：CPU、内存、SSD、网卡。

往上一层是 PVE。

再往上一层才是 VM，大概会拆成这些角色：

infra：统一入口和控制面，后面会放 DNS、网关、跳板这些东西
monitor：监控和日志
db：数据库
redis：缓存
mq：消息队列
harbor：镜像仓库
storage：对象存储
k8s master：Kubernetes 控制面
k8s workers：真正跑工作负载的节点

这个想法一旦定下来，后面很多选择反而没那么纠结了。因为问题不再是“这个服务能不能装”，而是“它应该落在哪一层、吃多少资源、跟谁放一起合适”。

1.4 存储这块，我一开始就不想混着来

这套机器上，我的存储划分很早就定下来了：

SSD1
- 物理盘：nvme0n1
- PVE Storage：local + local-lvm
SSD2
- 物理盘：nvme1n1
- PVE Storage：data-disk
8T HDD
- 放在 NAS 上，不进 PVE 本地存储池

我这里的想法是这样的的：本地 SSD 负责运行中的东西，NAS 负责不那么热的数据。

说得更直白一点：

VM 的系统盘、主要运行盘，优先放本地 SSD
备份、归档、冷数据，往 NAS 放

这个项目里，NAS 从一开始就不是运行盘，也不参与启动链路。它在我这里更像后方仓储：冷备、归档、灾备包、冷数据，都可以放过去；真正在跑的 VM 磁盘，还是放本地 SSD。

所以 NAS 在我这里更像后勤，不是主战场。后面我准备用它来放这些东西：

SeaweedFS 的冷数据
数据库备份
日志归档
一些镜像缓存

这个分法我觉得该有的基本都有了，比较稳妥一点。

1.5 网络这块，我也没想偷懒

虽然只有一台物理机，但网络这块我还是想分层，不想全挤在一起。

我现在的预留是这样：

eno1 接 vmbr0，走 svc-net
eno2 接 vmbr1，走 cluster-net

这个分法背后的意思很简单：

svc-net 放中间件、监控、入口、管理面
cluster-net 留给 Kubernetes 内部通信

一开始我也想过，要不要简单一点，反正就一台机器，全都放一个网段里得了。后来还是觉得不值。现在省这点事，后面写 Terraform、配 Ansible、排入口链路、看 Kubernetes 流量，都会变麻烦。

所以我宁愿现在先把桥和网段想清楚。哪怕现在看起来有点“超前”，后面真开始搭，会轻松很多。

1.6 双路机器这件事，最不能偷懒的是 NUMA

如果这台机器是单路，很多事会简单不少。双路机器麻烦一点的地方，不在于“核心多”，而在于很容易以为核心多就能随便分。

我在这块踩刹车踩得最早。因为 CPU pinning 这种东西，一旦先按想象写进 Terraform，后面发现 NUMA 对不上，就很难受。

所以我先去把拓扑核了一遍：

lscpu -e
如果环境里有，再看 numactl —hardware

当前核出来的结果是：

NODE 0：0-17，36-53
NODE 1：18-35，54-71

这一步看着很细，但很有必要。至少现在已经知道后面哪些核能放一起，哪些核不该想当然地混着绑。

我现在首批最小集里，先这样留：

infra：64
k8s-master：10-11
monitor：12-17

这几个我已经对过拓扑，至少先起这批的时候心里有底。

我现在对这件事的态度很简单：

不先核拓扑，就不写 pinning
不假设编号连续就是一组
给宿主机自己留点余地，别把核全分光

这不是讲究，是后面少返工。

1.7 后面这些资源，到底准备拿来跑什么

如果只是装几个容器，其实硬件规划没这么复杂。可我后面不是只想跑几个容器。

我准备放上去的东西，核心这批大概是：

vm-infra：统一入口和控制面
vm-monitor：监控、日志、告警
vm-storage：对象存储
vm-harbor：镜像仓库
vm-db1 / vm-db2：数据库主从
vm-redis1 / vm-redis2 / vm-redis3：Redis 集群
vm-mq：消息队列
vm-k8s-master：Kubernetes 控制面
vm-k8s-worker1 / vm-k8s-worker2：Kubernetes 工作节点
vm-loadtest：压测节点

看到这里，机器在我眼里其实就已经不是“一台主机”了，而是一块地。上面要盖多少房子、每个房子多大、谁挨着谁，前面都得大概有谱。

1.8 资源我现在大概是这么切的

按现在的想法，后面资源预算差不多是这样：

vm-db1：4C / 6G / 120G
vm-db2：3C / 4G / 120G
vm-redis1/2/3：每台 1C / 2G / 20G
vm-k8s-master：2C / 6G / 60G
vm-monitor：6C / 8G / 100G
vm-harbor：2C / 4G / 80G
vm-storage：3C / 4G / 100G
vm-k8s-worker1/2：每台 9C / 16G / 80G
vm-loadtest：6C / 8G / 50G
vm-mq：4C / 6G / 80G
vm-infra：1C / 1G / 20G

这里写的是规划值，不是说所有组件在任何时候都会把资源同时吃满。

这个预算表里，我自己最在意的是几个点：

infra 资源不大，但优先级很高。因为 DNS、网关、跳板都在它上面。
monitor 不能给太小，不然后面看板、日志、告警会很快卡住。
worker 才是真正吃算力的大头。
数据库和中间件不用上来就配得很豪华，但也不能抠到一碰就碎。

按现在这套分法，资源我觉得是够的。前提还是那个老问题：别想着一步到位把所有能力同时拉满，得分阶段来。

1.9 我最后接受的几个取舍

写到这里，其实我自己接受了几件事。

第一，这就是单机。我不打算拿它去硬整一套企业生产架构，所以有些事情我愿意妥协：

不做跨机高可用
不做超大规模弹性
一些组件首期先单实例

第二，本地盘和 NAS 的角色我不想混。本地盘就是跑核心运行盘的，NAS 就是做冷数据、备份和归档的。

第三，infra、monitor、k8s-master 这几个角色得先稳住。后面很多事情能不能继续推进，其实看这几个点稳不稳。

第四，双路机器就老老实实先看 NUMA。这里偷的懒，后面基本都会加倍补回来。

1.10 这一步里我最怕的几个坑

双路机器别想当然地分核，先核拓扑
单机不代表什么都往一起塞
资源预算别只按“平时能跑”来算，开关机和恢复也得留余量

1.11 最后总结一下

对我来说，这套 homelab 真正的第一步，不是装 PVE，也不是先起 Kubernetes，而是先把硬件边界和资源分法想清楚。

我最后落下来的判断是这些：

双 SSD 承担本地核心运行盘
NAS 承担冷数据、备份和归档
网络先按两层留出来
NUMA 先核，再谈 pinning
资源预算先做出来，后面再往上搭

前面这一步慢一点，后面其实会顺很多。