七台虚机上的 cyxck8s-01

目录#

• 要解决什么
• 2025-04-10 下午（CST）
• 为什么是 7 台虚机、两台宿主机
• kubeasz 锁死的选择
• 网络：两个网段，没有 VIP
• MetalLB：从第一天就是 BGP
• Rook：三池当天就在，OSD 在 virtio 上
• 故障域其实只有两台物理机
• 到 08-21 还没变的
• 下一篇

要解决什么#

读者读完应能分清：

1. 哪天下午站住。 不是换底座那周才装 kubeasz。CA、MetalLB、Rook、三池的时间戳都在 2025-04-10。
2. 节点怎么拆。 3 master/etcd + 4 worker，跨两台 PVE；控制面多数票在 pve1。
3. 流量和存储怎么出虚机。 Calico IPIP Always；MetalLB BGP 宣告 10.1.10.0/24；块 / 文件 / 对象都在 Rook 上，OSD 是 QEMU virtio，不是后来的 960G。
4. 哪些是后话。 1.33、裸机、16T、槽 10、Harbor，以及 2026 年 6 月起那批 operator，都不在这天下午。

不要把这篇当成 kubeasz 安装教程。ezctl setup 的步骤网上有；现网后来证明，照文档的 setup network / setup cluster-addon / 整段 ezdown 会拆掉已有集群，那是 1.33 那篇的事。

2025-04-10 下午（CST）#

helm history 的时间戳和 kubectl creationTimestamp 对得上，按 UTC 存、这里换成 CST。CA 的 notBefore 也是当天。

StorageClass ceph-block（默认）、ceph-filesystem、ceph-bucket 从那天起就在，现网 AGE 和 04-10 对得上。

cluster chart 早期 revision 已被 helm 丢掉，所以 16:38 的四条 CR 才是「数据面当天就装上」的证据，不能靠 helm history rook-ceph-cluster 的第一号。operator 从 rev 1 起就是 1.16.6，到 08-22 才换成 1.17.9。

Traefik、监控的命名空间当天就有。Traefik 现网 history 最早只剩 2026-05-24（chart 35.0.0 / v3.3.5），更早的 revision 同样丢掉了。不要据此写成「Traefik 2026 年 5 月才进集群」。当天的 chart 小版本这篇不编。monitor 里后来是 kube-prometheus-stack（08-21 对照 chart 70.4.2），09-02 才换成 VictoriaMetrics；04-10 用的哪一档 chart 同样不编。

为什么是 7 台虚机、两台宿主机#

当时没有第三台可以当 K8s 节点的物理机。16.23 还不在这套集群里——它是另一套 PVE 裁下来的机器，08-30 之前才装成 Ubuntu，用来接走这 7 台。pve4 10.1.16.31 一直是 Proxmox，这次也不进 K8s。

角色在 1.33 和换底座两篇里对得上，起源就是这一组。inventory 以 08-22 升级前那份为准（hosts.bak.3.6.7-upstream 仍是这 7 个地址）：

1
[etcd]
2
10.1.4.100
3
10.1.4.101
4
10.1.5.100
5

6
[kube_master]
7
10.1.4.100
8
10.1.4.101
9
10.1.5.100
10

11
[kube_node]
12
10.1.4.103
13
10.1.4.102
14
10.1.5.101
15
10.1.5.102

[kube_node] 只有 4 个 worker。三台 master 不在这个组里。这是 kubeasz 的默认拆法，升 1.33 时 ezctl upgrade 会 cordon 不在组里的 master，不是那天新改的。[ex_lb]、[harbor] 空着：没有 kubeasz 自带的 apiserver VIP，也没有用 kubeasz 装 Harbor。

etcd 三票里 两票在 pve1。pve1 挂了，quorum 没了，apiserver 也没了。这是后来必须先有一台裸机接走控制面、再拆 16.21 的根：4.100 占着 4100，宿主机腾不空。

PVE 上还有另一类虚机：业务客机，不跑 K8s。它们在 VLAN 20 的 10.1.4.0/24（PVE vmbr1 tag=20），一部分在 10.1.5.0/24。嵌套 virt 只够试验，生产客机不能一直停在 QEMU 里套 KVM。客机怎么迁到 KubeVirt 是换底座篇。

节点规格（vCPU / 内存 / 系统盘大小）没有留下对照，这篇不编。

kubeasz 锁死的选择#

安装器是 kubeasz，控制端容器跑在 10.1.4.100：docker exec kubeasz ezctl …。08-21 对照是 3.6.6。CA 从 04-10 活到现在，中间没有重做集群；不能据此断言 04-10 当天的 kubeasz / Kubernetes 小版本就是 3.6.6 / 1.32.3，只知道动手升 1.33 之前已经是这一档，并且和 3.6.6 默认对齐。

08-22 改 K8S_VER 之前的 config.yml 还在：clusters/cyxck8s-01/config.yml.bak.K8S_VER-1.32.3。和 inventory 里 [all:vars] 对得上的是：

08-21 对照的小版本：Calico v3.28.3、CoreDNS 1.11.4、node-local-dns 1.23.1、etcd 3.5.20、containerd 2.0.4、runc 1.2.6、metrics-server v0.7.2、pause easzlab/pause:3.10。这些是 3.6.6 默认档，不是 1.33 那夜才定的。

Calico 现网备份里仍是：

1
etcd_endpoints: "https://10.1.4.100:2379,https://10.1.4.101:2379,https://10.1.5.100:2379"

IP_AUTODETECTION_METHOD 是 can-reach 第一台 master。探测地址是节点自己的口，不是后来裸机上的 bond。

每台 master 上还有 kubeasz 的 kube-lb：本机 nginx 听 127.0.0.1:6443，L4 反代到三台 apiserver。这不是集群 VIP。kubectl 打的就是当时那台控制端的 6443。MASTER_CERT_HOSTS 里 kubeasz 默认还写着 10.1.1.1 / k8s.easzlab.io，现网没有拿它们当入口。

网络：两个网段，没有 VIP#

K8s 节点本身就跨两个网段：pve1 上的 4.x 在 10.1.4.0/24，pve2 上的 5.x 在 10.1.5.0/24。业务客机当时在 VLAN 20；K8s 虚机跟客机挤在同一套 PVE 桥上，不是后来裸机那条 N9K access VLAN 40 / 10.1.16.0/24。

两个 L3 网段上的 overlay，kubeasz 默认就是 IPIP Always。08-21 仍是 Always。后来换成三台同网段裸机，这条隧道还在——那是换底座篇里 OSD TCP 校验和的背景，不是起源才挖出来的坑。

没有 apiserver VIP，没有 kubeasz [ex_lb]。控制面入口就是 4.100。私仓也在 4.100:5000，镜像路径 easzlab.io.local:5000/...。换底座之后模式没变，只是控制端和 :5000 跟节点一起迁到当时那台裸机。

MetalLB：从第一天就是 BGP#

15:43 装上，15:45 三条 CR 就位，一直用到现在（chart 仍是 0.14.9，08-21 对照也是这一档）：

1
# BGPPeer peer1
2
myASN: 65528
3
peerASN: 65533
4
peerAddress: 192.168.5.2   # N9K C92160YC-X
5

6
# IPAddressPool default
7
addresses:
8
  - 10.1.10.0/24
9

10
# BGPAdvertisement：按 /32 宣告

不是 L2 ARP。LoadBalancer 从 10.1.10.0/24 里拿地址，speaker 把 /32 发给 N9K。换底座之后 peer 从虚机地址改成 10.1.16.21/22/23，池和 ASN 没换。N9K 上后来要删掉 neighbor 10.1.4.100 / 10.1.4.101，是因为节点走了，不是起源配错。

Rook：三池当天就在，OSD 在 virtio 上#

16:38 四条 CR 一起出现。默认 StorageClass 是 ceph-block（RBD，reclaimPolicy: Delete，Immediate，可扩容）。另外两个是 ceph-filesystem、ceph-bucket。1.33 那夜默认 SC 也没改。

08-21 对照：Ceph Squid 19.2.1、3 mon / 6 OSD。不能断言 04-10 当天的 Ceph 小版本就是 19.2.1——只知道 operator 从那天起就是 1.16.6，数据面 minor 以 08-21 为准。

这 6 个 OSD 跟节点一起跑在 QEMU 里，设备名是 virtio（后来 helm values 里还留过 vdb / vdc / vdd），不是后舱那 6 块 Intel S4510 960G，values 里也还没有 WWN。08-27 单客户端打 ceph-block，路径仍是 PVE virtio + PM983 切片。960G 是换底座时才做成 ssd OSD 的。踢 5.x 之前，5.x 上还挂着 osd.2 / osd.4 / osd.8。

块、CephFS、RGW 都已经在这套 Rook 上。对象入口 2026-06-05 才接到 RGW（Ingress / 证书那天）。这篇只记：CephObjectStore ceph-objectstore 从 04-10 就在，不是换底座才装的。

现网对象正文在 ceph-objectstore.rgw.buckets.data（EC 2+1、deviceClass: hdd），块 / CephFS / RGW 索引钉 ssd、replica 3。那是 16T 进舱之后 的分盘。04-10 到 08-21 只有 6 块虚机盘，没有 hdd 故障域可切，不要把现在的 crush 倒回去写成起源。

16T 还在 TrueNAS，前舱空着。盘位和迁 NAS 是裸机之后的事。

故障域其实只有两台物理机#

Rook 池的 failureDomain: host 认的是 K8s 节点名。7 个虚机看起来像 7 个 host，底下只有 pve1 / pve2。三副本、EC、mon 分散，在 CRUSH 里都是「不同 host」，掉一台 Proxmox 等于一次掉一半节点。

这就是后来一定要换成三台裸机的原因之一：控制面 quorum、OSD host 域、业务客机的 /dev/kvm，都卡在「两台 hypervisor」上。起源这套能跑，是因为两台 PVE 当时还活着，不是因为故障域已经按物理机拆开。

到 08-21 还没变的#

用 08-23 凌晨升级前的对照还原。中间小版本若有过，helm 早期 revision 已经不在，不编。

也就是说：从装上到动手升 1.33，底座没有换成物理机，Rook 也没有跳到 1.17，MetalLB 池和 ASN 没有换。变的是后来往集群上堆的平台组件，那些各自成篇。

下一篇#

先把版本从 1.32.3 升到 1.33.1（Rook 到 1.17.9，Ceph 数据面当晚不动），见 七台虚机上把 Kubernetes 升到 1.33.1。再把 7 个节点从 PVE 换成三台 R730xd，见 把跑在 PVE 里的 Kubernetes 换成三台物理机。顺序不能反：4.100 占着 16.21，etcd 两票在 pve1，不先升完、不先有一台裸机接走控制面，宿主机腾不空。