PVE 更换物理机后 K3s TLS 异常排查

Sat, 07 Nov 2026 18:35:00 +0800

背景

之前在 ArgoCD 落地 GitOps 中记录过这套 K3s 环境。最近将 PVE 从 Intel N150 物理机迁移到 AMD Ryzen 5 5600H 后，集群看起来还能正常工作，但日志持续出现 TLS 错误。

节点是 Ready，大部分时间 Pod 也全部就绪，普通 API 查询正常。问题主要出现在持续运行的资源监听连接上，偶尔还影响租约更新、身份认证和 webhook 调用。

最终有效的调整是：保留原磁盘和集群数据，将这台虚拟机的 CPU 类型从 x86-64-v2-AES 改为 host。截至本次排查结束，连续 15 分钟观察未再复发，随后复核也正常。

这个结果支持故障与虚拟 CPU 特性及其影响的执行路径有关，但还没有定位到具体的 Go、内核或 KVM 缺陷。下面记录判断过程，而不是把 host 当作所有 TLS 错误的通用修复。

环境

项目	配置
迁移前物理 CPU	Intel N150
迁移后物理 CPU	AMD Ryzen 5 5600H
PVE	8.4.1，内核 6.8.12-9-pve
QEMU 软件包	pve-qemu-kvm 9.2.0-5
虚拟机	2 核，14 GiB 内存，Ubuntu 24.04.2
guest 内核	6.8.0-147-generic
原虚拟 CPU 类型	x86-64-v2-AES
K3s	v1.33.6+k3s1，Go 1.24.9
Rancher	v2.13.0，Go 1.24.10
数据存储	SQLite 和 local-path 持久卷

故障现象

最常见的错误有三种：

local error: tls: bad record MAC
tls: unexpected message
http2: frame too large

11 月 7 日零点至 17:40 左右，K3s 累计记录约 1.28 万条相关日志，集中在 323 个秒级时间点。

这里不能把日志条数当作独立故障次数。HTTP/2 的一条连接承载多个资源监听，一次断连可能同时结束大量 watch，随后出现成批的 reflector 错误。

另外，bad record MAC 中的 MAC 是消息认证码，不是网卡 MAC 地址。它表示 TLS 记录校验失败，单凭这句话无法判断是证书、数据传输、端点处理还是运行环境的问题。

先拆开两个不同的问题

网络等待超时

系统启动时，systemd-networkd-wait-online 等待约两分钟后超时，系统状态为 degraded。网卡虽然已经拿到静态 IPv4 地址，却一直停留在 configuring。

检查发现，系统通过 sysctl 禁用了 IPv6，但 Netplan 没有设置 link-local，仍默认要求生成 IPv6 链路本地地址。

在原网卡配置下补充一行即可使两边配置一致：

network:
 version: 2
 ethernets:
 ens18:
 # 原有 addresses、nameservers、routes 保留
 accept-ra: false
 dhcp6: false
 link-local: []

这是原配置的局部示意，不能用它覆盖已有的静态地址和路由。修改前备份原文件，再执行：

sudo netplan generate
sudo networkctl reload
sudo networkctl reconfigure ens18
sudo systemctl restart systemd-networkd-wait-online
networkctl status ens18
systemctl is-system-running

修复后，网卡变为 configured，系统恢复为 running，并通过了后续重启验证。Netplan 官方说明明确规定，空的 link-local 列表会关闭链路本地地址配置。

但 TLS 错误仍然复发，说明这是两个不同的问题。

历史时间同步异常

迁移后确实发生过约 8 小时的时钟回拨，需要认真核对证书有效期和时间同步状态。不过，在宿主机和虚拟机均已同步、没有新增校时记录的时段，TLS 错误仍持续发生。

因此，历史时间异常值得修复，却不能解释当前全部故障。

从 Rancher 日志扩展到整个节点

最初 Rancher 的错误最显眼，聚合 API 的证书控制器还反复打印证书更新日志，很容易怀疑证书轮换。

核对 APIService 的 CA、Secret 内的证书和后端实际返回的证书后，证书链、域名和有效期均正常。结合 Rancher 源码，watch 失败后重启证书控制器、重新加载同一张证书，也会打印更新日志，不能将其直接理解为重新签发证书。

继续扩大日志检查范围，发现错误还出现在：

K3s 自身访问 127.0.0.1:6443 的 TokenReview 身份认证接口。
K3s 访问 127.0.0.1:6444 的资源监听。
metrics-server 的 HTTP/2 响应读取。
cert-manager 的领导者租约更新。
kube-state-metrics 等其他控制器的 watch。

这些证据说明故障并非只存在于 Rancher，更不能只靠 Rancher 日志数量判断责任端。

还有一个需要纠正的判断：日志中的 an error on the server 不一定是服务端主动返回的错误。Kubernetes 客户端的 StreamWatcher 会将本地解码失败包装为 Error 事件，再向上层传播。必须结合原始请求和底层错误判断，不能按字面归因。

验证网络和数据完整性

物理网卡更换后，桥接绑定和地址冲突仍需要检查：

# PVE 宿主机
qm config <VMID>
ip -br link
bridge link
bridge fdb show

# 虚拟机
ip -br address
ip route
ip neigh

本次虚拟机配置、guest 网卡、PVE 转发表，以及迁移前多个快照中的虚拟 MAC 一致，未发现其他虚拟机使用重复 MAC。物理网卡和虚拟网卡本来就有各自的 MAC，换物理机不等于虚拟 MAC 必须变化。

更关键的是，部分出错连接走本机回环，根本不经过物理网卡。这个事实降低了物理网卡绑定异常作为统一解释的可能性。

抓包也提供了更直接的证据。对一次真实 Rancher 故障连接，在 Pod 网卡与节点 veth 两侧重组双向 TCP 数据，约 164 KB 的载荷逐字节一致，没有缺口或冲突。这次样本没有显示数据在两个抓包点之间被改写，但不能据此排除所有内核和端点内存问题。

其他检查结果如下：

检查	结果	能说明什么
SQLite 只读 quick_check	ok	未发现本次检查覆盖的数据库结构损坏
K3s 二进制 SHA-256	与官方发布一致	安装文件未发现变化
普通 TCP 回环传输	512 MiB 校验通过	本轮普通传输数据一致
独立 OpenSSL 回环传输	AES-GCM、ChaCha20 合计 512 MiB 通过	不能认为所有加密运算都不正常
独立 Go HTTP/2 watch	16 路、128 路测试均通过	简化客户端未复现生产故障

其中一次独立 Go 客户端通过测试时，真实 Rancher 连接在同一时间窗口报错。因此，“短请求正常”“独立测试通过”都不能证明间歇性故障不存在。

取证链路本身也要校验。期间一次 SSH 上传的压缩数据校验失败，另一次长测试的 SSH 回传中断，这两次都没有作为有效测试结果。后续执行诊断程序前，分别校验压缩包和可执行文件的 SHA-256；传输复测三次通过，但那次异常的原因没有确证，也不能用来证明物理 CPU 损坏。

用重启和 CPU 类型做对照

证书、数据库和网卡配置检查没有给出直接修复依据后，先尝试保留原数据的重启，再改变一个配置项。

以下时间均为 2026 年 11 月 7 日北京时间：

操作	结果
18:00 左右原版本滚动重启 Rancher	kube-state-metrics 在 18:00:38 仍报 TLS 错误
18:04:55 K3s 重启恢复	18:08:00 再次出现 TLS 错误
保持原 CPU 类型，正常关闭再启动虚拟机，18:09:55 K3s 恢复	本次启动日志在 18:10:03 已出现同类错误
仅将 CPU 类型改为 host，再正常启动，18:16:54 K3s 恢复	连续 15 分钟观察无新增错误，18:34:24 复核仍为零

每一步都保留原磁盘、证书和持久卷，不卸载 K3s，也不重新安装 Rancher。最后一次配置差异只有：

-cpu: x86-64-v2-AES
+cpu: host

操作步骤如下，<VMID> 需要替换为目标虚拟机编号：

qm config <VMID>
qm shutdown <VMID> --timeout 180
qm status <VMID>
# 确认 status: stopped 后再继续；正常关机超时不要直接强制断电
qm set <VMID> --cpu host
qm start <VMID>

若没有改善，可以按同样的正常关机流程，将 CPU 类型恢复为记录下来的原值。本次因为观察结果改善，保留了 host。

为什么 CPU 类型会影响 TLS

虚拟 CPU 类型决定 guest 能看到哪些指令特性，并不只是修改一个显示名称。Proxmox 文档说明，host 会将宿主机 CPU 特性暴露给虚拟机；跨不同 CPU 的在线迁移则需要考虑兼容性。

原来的 x86-64-v2-AES 配置暴露了 AES，但没有暴露 PCLMULQDQ。在 Go 1.24.10 的 TLS 实现中，amd64 的 AES-GCM 加速判断需要同时满足多个条件：

hasGCMAsmAMD64 = cpu.X86.HasAES && cpu.X86.HasPCLMULQDQ && cpu.X86.HasSSE41 && cpu.X86.HasSSSE3

改为 host 后，guest 获得了 PCLMULQDQ、AVX2 等更多特性。同一个 Go 1.24.10 诊断程序的实际协商结果随之改变：

CPU 类型	诊断连接的 TLS 加密套件
x86-64-v2-AES	TLS_CHACHA20_POLY1305_SHA256
host	TLS_AES_128_GCM_SHA256

在 host 环境中，128 路 watch 全部正常结束，10,758 条 TLS 记录通过独立解密校验，没有异常 HTTP/2 帧或采集缺口。实际组件日志也停止出现原来的错误。

这形成了一条有实际对照支持的解释：CPU 特性变化改变了加密和相关代码的执行路径，新的路径避开了本次故障的触发条件。

但它还不能证明 ChaCha20 算法本身有问题，也不能证明某条物理 CPU 指令损坏。host 同时改变了多个 CPU 特性；原类型下的独立 ChaCha20 测试也曾通过。具体是某条优化路径、虚拟化状态处理，还是受执行时序影响的其他缺陷，仍需要更小的复现程序和更长时间的验证。

恢复验证和重建判断

修改后检查了 37 个运行中 Pod 的日志，未检出上述三类错误。持续观察覆盖 K3s、Rancher、metrics-server、kube-state-metrics 和 cert-manager，结束后再次核对：

所有常驻 Pod 就绪，API /readyz 返回 ok。
Rancher 聚合 API 为 Available=True。
4 个 PV/PVC 的 UID 和绑定关系与重启前一致。
10 个 Argo CD 应用均为 Synced / Healthy。
节点心跳和资源指标持续更新，系统状态为 running。

这些检查支持保留当前配置继续运行，没有必要因为日志中出现 TLS 错误就清空数据库、重新签发证书或重建集群。

如果最终确实需要重建，也应先保留数据库、server token 和业务卷数据。K3s 的备份恢复文档特别要求同时保存 server token；GitOps 仓库可以重建资源定义，但不会自动恢复本地持久卷内容。

这次排查中最有价值的做法，是将每个判断绑定到可验证的证据：区分日志条数和故障次数，区分客户端包装错误和服务端原始错误，验证取证数据本身，再通过保留数据、逐项变更的对照决定下一步。最终获得了有效的运行配置，而没有用重装掩盖尚未弄清的原因。

K3s on F嘉阳