Metal3 遇上 KubeVirtBMC：把 KubeVirt 虚拟机当作裸金属来部署

2026-09-02 46 预计阅读时间: 1 分钟
来源: cncf.io AI 摘要 Original link

Disclaimer: This article is an AI-assisted summary. Read it together with the original source when precision matters. The summary may omit context, version differences, or edge cases and is not official documentation.

预计阅读时间：10 分钟

上一篇内容介绍了 KubeVirtBMC：它为 KubeVirt 虚拟机提供虚拟 BMC 端点，并通过原始 IPMI 和 Redfish 命令验证了这些端点。真正有价值的地方在于，BMC 不必只服务于人工运维，也可以接入 Metal3，让 Metal3 按照管理裸金属服务器的方式管理 KubeVirt 虚拟机。

这意味着开发者可以在 Kubernetes 集群中创建一台 VM，同时让 Metal3 负责发现、开机、关机、设置启动介质以及执行操作系统部署。虚拟机仍然运行在 KubeVirt 上，但在 Metal3 看来，它拥有一个可访问的 BMC。

两个项目如何接在一起

Metal3 的裸金属工作流通常围绕 BareMetalHost 资源展开。资源中会声明 BMC 地址和凭据，Metal3 再通过 IPMI 或 Redfish 与目标主机交互，完成以下任务：

  • 检查主机是否可访问
  • 查询电源状态
  • 控制开机和关机
  • 配置启动设备
  • 将主机标记为可用或已占用
  • 配合镜像服务完成操作系统部署

KubeVirtBMC 位于 Metal3 和 KubeVirt VM 之间。它把面向 BMC 的请求转换成对虚拟机的操作：例如，将 Redfish 的电源开启请求转换为启动 KubeVirt VM，将虚拟介质或启动配置映射到虚拟机可以使用的启动设备。

因此，整体链路可以理解为：

Metal3 BareMetalHost
        |
        | IPMI / Redfish
        v
KubeVirtBMC 虚拟 BMC 端点
        |
        | Kubernetes API / KubeVirt API
        v
KubeVirt VirtualMachine

这里的关键不是把 VM 伪装成真实服务器，而是复用 Metal3 已经成熟的主机生命周期管理模型。对于测试环境、边缘场景和需要统一编排接口的基础设施平台，这种方式可以减少为虚拟机单独实现一套部署逻辑的工作量。

BareMetalHost 示例

下面是一个最小化的 BareMetalHost 示例。字段名称遵循 Metal3 常见的资源模型；实际使用时，需要根据集群中的 Metal3 版本、BMC 协议和 KubeVirtBMC 的部署方式调整地址格式。

假设条件如下：

  • KubeVirtBMC 已经运行在 Kubernetes 集群中
  • 它为目标 VM 暴露了一个 Redfish 端点
  • Metal3 相关控制器已经安装
  • Secret demo-vm-bmc 中保存了 BMC 用户名和密码
apiVersion: v1
kind: Secret
metadata:
  name: demo-vm-bmc
type: Opaque
stringData:
  username: admin
  password: change-me
---
apiVersion: metal3.io/v1alpha1
kind: BareMetalHost
metadata:
  name: demo-kubevirt-vm
  namespace: metal3
spec:
  online: true
  bootMACAddress: "52:54:00:12:34:56"
  bmc:
    address: redfish://kubevirtbmc.example.internal/redfish/v1/Systems/demo-vm
    credentialsName: demo-vm-bmc
    disableCertificateVerification: true
  bootMode: legacy
  automatedCleaningMode: disabled
  image:
    url: https://images.example.internal/ubuntu-24.04.qcow2
    checksum: https://images.example.internal/ubuntu-24.04.qcow2.sha256
    checksumType: sha256

应用前，至少需要替换以下内容：

  • metadata.namespace：改成 Metal3 控制器能够管理的命名空间
  • bmc.address：改成 KubeVirtBMC 实际暴露的 Redfish 或 IPMI 地址
  • credentialsName：改成实际的 BMC Secret
  • bootMACAddress：改成 VM 网卡的 MAC 地址
  • image.url 和校验和地址：改成集群能够访问的操作系统镜像
  • disableCertificateVerification：生产环境应优先使用可验证的 TLS 证书

如果当前集成使用 IPMI，可以将 BMC 地址调整为对应的 IPMI 形式，例如：

spec:
  bmc:
    address: ipmi://kubevirtbmc.example.internal:623
    credentialsName: demo-vm-bmc

这段地址只是可改造的配置示例。不同 KubeVirtBMC 部署可能使用不同的路径、端口和协议，应该以实际暴露的服务以及 Metal3 版本支持的 BMC 地址格式为准。

用命令检查整条链路

创建资源后，可以先观察 BareMetalHost 的状态：

kubectl apply -f demo-kubevirt-bmh.yaml

kubectl -n metal3 get baremetalhost demo-kubevirt-vm -o wide
kubectl -n metal3 describe baremetalhost demo-kubevirt-vm

重点检查这些状态信息：

  • BMC 是否通过认证
  • 主机是否被发现
  • 电源状态是否与 KubeVirt VM 一致
  • Metal3 是否等待网络、镜像或启动介质
  • 是否出现凭据错误、证书错误或连接超时

在确认 Metal3 端点可达之前，也可以直接调用 Redfish API。下面的命令需要将地址、用户名和密码替换为实际值：

export BMC_URL="https://kubevirtbmc.example.internal"
export BMC_USER="admin"
export BMC_PASSWORD="change-me"

curl --fail --silent --show-error \
  --insecure \
  -u "${BMC_USER}:${BMC_PASSWORD}" \
  "${BMC_URL}/redfish/v1/Systems" | jq .

如果返回系统列表，再查询目标系统的电源状态：

curl --fail --silent --show-error \
  --insecure \
  -u "${BMC_USER}:${BMC_PASSWORD}" \
  "${BMC_URL}/redfish/v1/Systems/demo-vm" \
  | jq '{Id, Name, PowerState, Boot}'

也可以从 KubeVirt 侧确认 VM 的状态：

kubectl -n workloads get vm demo-vm
kubectl -n workloads get vmi demo-vm

理想情况下，Metal3 通过 BMC 发出的开关机操作会反映到 VirtualMachine 或 VirtualMachineInstance 的状态变化中。若两边状态不一致，应沿着三段链路定位：Metal3 控制器日志、KubeVirtBMC 服务日志，以及 KubeVirt API 中的 VM 事件。

kubectl -n metal3 logs deploy/baremetal-controller -f
kubectl -n kubevirtbmc logs deploy/kubevirtbmc -f
kubectl -n workloads describe vm demo-vm

实际资源名称可能因安装方式不同而变化，可以先列出相关 Pod 和 Deployment：

kubectl get deployment,pod -A | rg 'metal3|bmc|kubevirt'

这种组合适合什么场景

这套组合最适合需要统一主机生命周期接口的环境。

在 CI 测试中，可以为每个测试任务创建独立的 KubeVirt VM，再通过 Metal3 的主机状态和部署流程验证操作系统镜像、网络配置以及节点注册。测试结束后，Metal3 可以执行清理，KubeVirt 则负责回收虚拟资源。

在边缘或实验室环境中，平台团队也可以把真实裸金属和虚拟主机放进同一套资源模型。上层自动化只需要处理 BareMetalHost，无需为不同底层设备分别编写电源控制逻辑。

不过，虚拟 BMC 并不会自动提供真实 BMC 的全部语义。以下边界需要明确：

  • 虚拟电源操作最终受 Kubernetes 调度和 KubeVirt 控制器影响，时延可能不同于物理服务器
  • 虚拟介质、启动顺序和硬件传感器的支持范围取决于 KubeVirtBMC 的实现
  • disableCertificateVerification: true 会降低连接安全性，不应作为生产默认配置
  • BMC 凭据需要使用最小权限，并通过 Kubernetes Secret 或外部 Secret 管理系统保护
  • Metal3、KubeVirt 和 KubeVirtBMC 的资源版本必须兼容
  • 镜像下载地址、网络连通性和 VM 网卡配置仍然是部署成功的前提

落地时的检查清单

可以按下面的顺序验证集成：

  1. 确认 KubeVirt VM 可以独立启动和停止。
  2. 确认 KubeVirtBMC 的 Redfish 或 IPMI 端点能够访问。
  3. 使用 curl 或 ipmitool 验证认证和电源状态。
  4. 创建 BMC Secret，并确认 Metal3 控制器可以读取它。
  5. 创建 BareMetalHost，观察 BMC 连接和电源状态条件。
  6. 再接入镜像部署、网络配置和自动清理流程。
  7. 为超时、证书错误、VM 删除和控制器重启补充测试。

Metal3 与 KubeVirtBMC 的组合把“虚拟机”纳入了“主机供应”视野。它的价值不在于让虚拟机看起来更像服务器，而在于让既有的裸金属自动化流程能够延伸到 KubeVirt。采用时应从 BMC 连通性和电源控制开始，逐步加入镜像部署与回收，并把协议支持范围和安全边界写进平台文档。

# CNCF # 云原生

相关推荐