在裸金属上创建集群
本文介绍如何使用裸金属 provider 在物理服务器上创建 Kubernetes 集群。整个工作流仅使用 YAML——目前没有适用于裸金属集群的 Fleet Essentials UI。
目录
先决条件1. 安装所需插件2. 导入 OS 镜像并填充镜像目录3. 网络连接4. 主机时间同步5. TPM 决策6. 业务集群镜像 Registry7. 主机磁盘和启动准备8. 节点标签和污点集群创建工作流解析占位符值步骤 1:构建 SeedImage 并注册主机首次安装前调整 COS_STATE 大小可选:准备托管数据磁盘步骤 2:创建MachineInventoryPool 资源步骤 3:创建控制平面集群资源步骤 4:部署工作节点确认 worker pool 容量配置 worker BaremetalMachineTemplate配置 bootstrap template配置 MachineDeployment集群验证使用 kubectl验证控制平面端点预期结果常见故障模式后续步骤附录完整的 KubeadmControlPlane 配置先决条件
创建集群之前,请确保满足以下所有先决条件。
1. 安装所需插件
在裸金属上创建第一个业务集群之前,请在 global 集群上上传并安装以下插件。无论 global 集群本身运行在哪种 IaaS 平台上,都适用:
- Alauda Container Platform Cluster Bootstrap Provider
- Alauda Container Platform Infrastructure Provider for Bare Metal(umbrella chart,会同时安装裸金属 manager 和
elemental-operator)
操作步骤请参阅安装 Provider。如果 global 集群安装在裸金属上,还需完成将 global 集群准备为管理集群。
2. 导入 OS 镜像并填充镜像目录
创建任何集群资源之前,请将两种裸金属 OS 镜像都导入目标平台 registry,然后将目标 Kubernetes 版本添加到 elemental-image-catalog。这两个步骤都不会自动完成:provider 软件包不包含 OS 镜像,provider chart 创建的镜像目录也没有任何条目。
只导入一种镜像是不够的。添加镜像目录条目或 SeedImage 引用,并不会导入对应的镜像。
导入镜像。 适用于你的 ACP 版本的 Bare Metal OS 下载文件是一个归档,其中包含一个 OCI 镜像布局,两个镜像使用同一个 tag;请参阅各 Provider 的镜像格式。在安装了 containerd 且能够访问平台 registry 的主机上以 root 身份运行导入操作,例如 global 控制平面节点;Alauda OS 自带 ctr,但不包含 skopeo。/var/lib/containerd 需要至少与归档大小相等的可用空间。将归档导入专用的 containerd namespace,并列出创建的镜像名称:
输出会列出 baremetal-base-image:<os-image-tag> 和 baremetal-base-image-iso:<os-image-tag>。推送这两个镜像,并确认 registry 中各自都列出了该 tag。--skip-verify 需要 --local:
最后一条命令会在两个镜像均成功推送后删除本地副本。对于 global 集群的 registry,admin 密码存储在 cpaas-system/registry-admin Secret 中。在灾难恢复对中,请将镜像导入两个 global 集群的 registry;请参阅将 global 集群准备为管理集群。
导入后,<base-image> 为 <registry-address>/tkestack/baremetal-base-image:<os-image-tag>,而 <base-image-iso> 为 <registry-address>/tkestack/baremetal-base-image-iso:<os-image-tag>。两个镜像必须来自同一个归档。不要将集群资源指向构建用 registry,不要混用来自不同归档的镜像,也不要替换为独立构建的镜像。
填充镜像目录。 cpaas-system 中的 elemental-image-catalog ConfigMap 将 Machine.spec.version 映射到用于(重新)配置节点的 elemental upgrade 镜像。provider chart 创建的该 ConfigMap 不包含任何条目,因此在添加目标版本之前,无法配置任何节点。请 patch 该 ConfigMap,而不是替换它,以保留现有条目,然后检查结果:
控制平面和 worker MachineDeployment 资源中使用的每个 Machine.spec.version 值,都必须作为键出现在此 ConfigMap 中,并保留开头的 v,且解析到已导入的 base-image。provider 会在重新配置时,通过将条目中的 registry 部分替换为平台 registry 地址来解析镜像。如果缺少目标版本,则不会写入 reprovision plan,BaremetalMachine 最终会进入 Failed / Reason=ImageCatalogMiss。之后再添加条目也不会清除此状态;请删除受影响的 Machine,使其 owner 重新创建该对象。
3. 网络连接
裸金属主机的注册、安装和加入集群都完全通过网络进行,因此在首台主机启动 SeedImage ISO 之前,必须开放下表中的所有网络路径。
Alauda OS 节点上的主机防火墙已预先配置并由平台维护——你无需管理它,而且下表也不是节点防火墙规则集。请参阅管理防火墙端口。你需要规划的是主机与其访问端点之间的网络:主机子网、平台和 registry 之间的站点防火墙、安全组及路由器 ACL。
仅开放 443 不足以满足业务主机的要求
elemental-register 和 elemental-system-agent 都通过平台访问地址访问平台,因此注册和轮询 plan 只需要开放平台 HTTPS 端口。但这并非全部要求。同一主机仍需通过 DNS 解析名称、从 11443 上的 registry 拉取操作系统和平台镜像、通过控制平面端点端口加入 API server,并与其他节点交换集群流量。仅允许 443 的防火墙审批,会导致主机成功注册,却在安装或加入集群时失败,而且届时更难查明原因。
表格范围。 这些路径适用于业务集群主机,也就是本文创建的主机。另外两种相邻场景在其他文档中说明,未包含在上表中:
- Bootstrap。 在
global本身仍在安装期间,其主机会向临时 bootstrap 端点注册,适用的端口也不同——请参阅Bootstrap 节点网络。 - 移交后的
global主机。global主机的系统智能体使用 Global 控制平面端点,而不是平台入口路径;在 DR 对中,它会直接使用6443上的本地控制平面 VIP。请参阅端点与身份。
在 bootstrap 阶段创建的 SeedImage 指向 bootstrap 端点,移交后不得重复使用;请在活动的 global 集群上创建新的 MachineRegistration 和 SeedImage 对象。在 global 集群上创建的业务 SeedImage 在移交后仍然有效,因为其注册 URL 指向平台域名,而不是 bootstrap 地址。
控制平面端点。
- 对于
InternalSelf-built VIP,该 VIP 必须与控制平面节点 IP 位于同一个二层广播域中。vrid在该域中必须唯一,网络必须允许 VRRP 和 gratuitous ARP 更新,并且节点镜像必须公开 IPVS,且允许 Alive 设置net.ipv4.conf.all.arp_accept=1和net.ipv4.vs.conntrack=1。 - 对于
ExternalLoadBalancer,请在创建集群之前配置 listener 和控制平面后端。请遵循规划控制平面端点。
首次启动时的寻址。
如果目标 VM 或物理主机启动进入 live ISO 后未从 DHCP 获取地址,请先在主机控制台手动配置网络,然后再等待注册。先检查 NetworkManager 连接名称,再应用站点专用的地址、网关和 DNS 值:
4. 主机时间同步
每台将成为集群节点的主机——无论是控制平面节点还是 worker 节点——在启动 SeedImage ISO 时都必须已经具有正确的时间。平台对跨节点的要求是:每个集群节点使用统一的时区,且节点之间的时间同步误差不超过 10 秒;请参阅节点检查。该要求描述的是集群节点,因此同样适用于此处,但此路径不会替你验证这一点:该页面中的快速配置脚本和节点检查面向的是平台通过 SSH 加入的非 Alauda OS 机器,不会在通过 elemental-operator 安装的 Alauda OS 主机上运行。
将时间同步作为步骤 1之前的必要条件:
- 确保主机子网可以访问站点 NTP 服务器,并按照网络连接中的说明开放 UDP
123。生产集群不应依赖公共 NTP。 - 从固件设置时间,而不是从操作系统设置。此时安装磁盘已按照主机磁盘和启动准备中的说明被擦除,因此主机上没有可用于运行命令的操作系统。请在 BIOS/UEFI 设置中或通过 BMC 校正时间,并将硬件时钟保持为 UTC,以便安装 Alauda OS 后统一应用时区。
- 相互比较各主机,而不仅仅是与某个参考时间比较。对于所有计划加入同一集群的主机,在其中任何主机启动 ISO 之前,时间差都必须保持在 10 秒要求以内。
- 节点达到
Ready后,在每个节点上使用timedatectl确认结果——该命令会同时报告时区以及时钟是否已同步——并使用chronyc tracking查看时间源和当前偏移量。
整个集群 PKI 都继承运行 kubeadm init 的主机时钟。kubeadm 根据该主机的当前时间设置证书颁发机构的 NotBefore,每个叶证书都会继承该 NotBefore,并据此计算每个证书的 NotAfter。因此,时钟超前的主机会生成一套 PKI,其他节点和任何客户端都会将其视为尚未生效,直到自身时钟追上;而时钟落后的主机会生成一套比配置的有效期所暗示的时间更早过期的 PKI。硬件时钟从未同步过的服务器通常会相差数分钟或数小时,而不是几秒,因此后果是控制平面完全无法启动——而且问题会在控制平面启动阶段才暴露,此时距离引入错误时钟的注册步骤已经很久。
Day-2 chrony MachineConfig 无法替代此要求
配置 Chrony 时间服务会将 /etc/chrony.conf 写入已经运行并加入集群的节点。这是使集群在持续运行期间使用站点 NTP 服务器的正确方式,但它与此处的要求不同:它无法校正仍在安装 Alauda OS 或运行 kubeadm 的主机时钟。将时间同步推迟到该步骤,会使安装和加入集群的时间窗口得不到保护。
5. TPM 决策
根据主机是否提供真实硬件 TPM(/dev/tpm0)设置 MachineRegistration.spec.config.elemental.registration.emulate-tpm,而不是根据主机是物理机还是虚拟机来设置:
emulate-tpm: false(或省略该字段)——仅适用于具有可用硬件 TPM 的主机,以便elemental-register使用它执行auth: tpm。emulate-tpm: true和emulated-tpm-seed: -1——适用于任何没有硬件 TPM 的主机。这既包括虚拟机,也包括出厂时未配备 TPM 模块的物理服务器(例如 Dell R620)。在此类主机上,auth: tpm与emulate-tpm: false结合使用会使elemental-register的 TPM 证明失败,并且永远不会发送注册请求,因此elemental-operator会记录 0 次注册 POST。
6. 业务集群镜像 Registry
启动集群不需要 Registry 凭证。裸金属主机仅使用平台 Registry 地址安装操作系统并加入集群,因此无需配置凭证即可访问一个所有节点均为 Ready 的集群。
下一步——在新集群上安装平台组件——才需要凭证。这些组件会从 Registry 拉取镜像,而要求身份验证的 Registry 需要集群可使用的凭证。
默认情况下,集群使用 global 集群的 Registry;当该 Registry 需要身份验证时,其凭证由 public-registry-credential Secret 提供。如果希望从专用 Registry 拉取平台组件镜像,请遵循为业务集群选择镜像 Registry。
凭证可以稍后配置,但 Registry 的选择不能推迟。集群创建时即会绑定其 Registry,现有集群无法迁移到其他 Registry。请在应用以下 manifest 之前完成决定,即使你要到之后才安装平台组件。
上述两种选择都不会影响前文所述的操作系统镜像。主机会在 elemental install 期间以及每次重新置备时,从平台 Registry 拉取 base-image 和 base-image-iso,此时尚不存在任何集群级绑定。
7. 主机磁盘和启动准备
在启动 SeedImage ISO 之前,先对每台主机上的所有磁盘和虚拟磁盘(VD)进行分类。记录哪个设备是 OS 安装目标,以及哪些设备(如有)必须保留应用数据:
- 擦除选定的 OS 安装磁盘和其他已废弃的启动磁盘,确保不再保留可启动的旧操作系统。主机必须启动 ISO,而不是磁盘上旧的操作系统。将
MachineRegistration.spec.config.elemental.install.device设置为准确的 OS 磁盘。 - 如果计划使用
Adopt策略管理数据磁盘,不要擦除该磁盘。请独立备份它,记录其稳定 ID 和文件系统 UUID,并确保不会将其选为安装设备。 - 用于
InitializeIfBlank的磁盘必须可丢弃且确实为空。格式化仍需在主机注册后单独获得初始化批准;注册 manifest 不会授权执行该操作。 - 从所有磁盘中移除残留的 Elemental 分区标签——
COS_STATE、COS_PERSISTENT、COS_OEM、COS_RECOVERY,而不仅是目标安装磁盘。Elemental 会根据标签(blkid -L COS_STATE)解析分区;第二块磁盘上的残留标签(例如来自之前的安装或遗留的 multipath 成员)会导致它解析到错误的设备,从而使重新置备 snapshotter 失败。 - 对于同一磁盘可能通过多个路径显示的主机(multipath),请确保这些路径中没有任何路径暴露仍带有
COS_*标签的磁盘;任一路径上的残留标签都可能先于目标安装磁盘被解析。请清理磁盘,而不是禁用 multipath——该镜像会保持 multipath 启用,以支持网络连接存储启动。 - 对于具有多个磁盘的主机,不要将
install.device留空,也不要将/dev/sda用作持久身份标识。请遵循在多磁盘裸金属主机上选择固定系统磁盘,以便重复使用同一个 ISO,同时通过 WWN 选择每台主机的系统磁盘。 - 设置启动顺序,使主机优先启动虚拟 CD / ISO。
只能使用已注册清单报告的稳定存储身份。/dev/sdX、/dev/vdX、/dev/nvmeXnY 和 /dev/mapper/mpathX 等 Linux 路径属于运行时路径,不得放入 MachineInventory.spec.storage。
8. 节点标签和污点
如果要为池中的节点设置专属角色标签和污点——例如为监控、日志记录或 ingress 预留专用池——请按照基础设施节点中的说明,在池的资源上声明这些配置。请在创建池之前完成规划。
集群创建工作流
使用 YAML 时,先导入配套的 OS 镜像,然后执行五个必需的资源步骤;在将节点加入池之前,还可选择执行存储准备步骤。每个 Kubernetes 资源都必须应用到 cpaas-system 命名空间中。
重要的命名空间要求
所有裸金属资源都必须应用到 cpaas-system 命名空间中。provider 和 elemental-operator 只会协调该命名空间中的对象。
业务集群命名
业务 cluster-name 不得命名为 global。该名称保留给 global 集群;重复使用会导致业务集群的资源与 cpaas-system 中 global 集群的资源发生冲突。按照惯例,CAPI Cluster 和 BaremetalCluster 应保持名称恰好为 <cluster-name>,而依赖资源(KubeadmControlPlane、KubeadmConfigTemplate、MachineDeployment、machine 模板、池、注册资源)则应以 <cluster-name>- 为前缀。
解析占位符值
以下示例清单使用 <placeholder> 语法表示特定环境的值:
步骤 1:构建 SeedImage 并注册主机
创建一个描述注册 URL 和首次安装 cloud-config 的 MachineRegistration,以及一个将 elemental-operator 指向匹配 ISO 基础镜像的 SeedImage。
将 SeedImage.spec.baseImage 设置为导入的 base-image-iso 的最终目标平台 registry 引用。它必须与 image catalog 用于后续重新置备的导入 base-image 配对:两个镜像都必须来自同一个 OS 归档文件,绝不能来自不同的归档文件。
首次安装前调整 COS_STATE 大小
state 分区用于存放运行中的系统以及所有保留的快照。Elemental 默认的 8192 MiB 不够用:一个镜像的快照会共享 extent,但升级到不同镜像时,必须同时容纳两个大小约为 3.5 GiB 且互不相关的系统,并会在中途因 no space left on device 失败,导致每次重试都在其上留下一个不完整的快照。每次集群升级都会经过 elemental upgrade,而分区大小在安装时固定,因此该问题只会在之后才暴露——此时集群已经投入生产,若不重新安装就无法再重新分区。
在安装时将其大小设置为至少 20480 MiB(20 GiB)。
该片段必须位于 stages.boot 下的 SeedImage.spec.cloud-config 中。将其放入 MachineRegistration.spec.config.cloud-config 或任何其他阶段都会留下 8 GiB 分区,并且不会报告错误。
在向其余主机群推出之前,先在第一台已安装的主机上验证结果:
不要将 /etc/resolv.conf 添加到 SeedImage.spec.cloud-config。保持 ISO 通用;仅当首次启动注册路径需要时,才在 MachineRegistration.spec.config.cloud-config 中配置站点特定的 resolver。在经过测试的 Global 部署流程中,ISO 不包含 resolver 文件;节点 DNS 随后由 kubeadm bootstrap 数据进行配置。
install.device、install.eject-cd 和 install.reboot 是有意设置的。如果省略目标磁盘,elemental install 可能会选择非预期设备。在多磁盘物理主机上,请使用固定系统磁盘操作流程,而不是使用会变化的 /dev/sdX 名称。如果 eject-cd 或 reboot 为 false,主机可能会在首次安装后仍停留在 live 环境中,永远无法成为 Cluster API 可用的 inventory。
应用 manifest,并等待 SeedImage 构建完成:
不要将 status.state 用作成功判定条件;当前 controller 不会填充该字段。只有当 SeedImageReady=True 的 reason 为 SeedImageBuildSuccess,且 status.downloadURL 和 status.checksumURL 均非空时,才能继续操作。下载生命周期已过期的 SeedImage 仍可能报告 SeedImageReady=True,但其 reason 会发生变化,且其 URL 会被清除。
从此 ISO 启动每台目标主机。elemental-register 首先运行(创建 MachineInventory 并上传 observedNetwork),随后 elemental install 将 OS 写入磁盘。安装完成后,主机仍可用于执行 plan。如果 live ISO 环境没有 DHCP 地址,请按照网络连接中的说明,在主机控制台上手动配置 NetworkManager,然后再等待 MachineInventory。
确认注册状态:
每个计划使用的 inventory 都必须:
- 显示
Ready=True。 - 具有非空的
status.plan.secretRef.name。 - 具有与主机预期 NIC 匹配的
spec.observedNetwork(仅当希望安装时 IP 在重新置备期间保持不变时才需要)。 - 当需要托管数据磁盘时,运行支持 observer 的 OS image,报告新的
status.observedStorage,并在分配到 pool 之前达到status.storage.phase=Prepared。
记录确切的 MachineInventory 名称——下一步会按名称引用它们。
可选:准备托管数据磁盘
托管存储属于长期存在的 MachineInventory,而不属于 CAPI Machine 或 BaremetalMachineTemplate。请在 inventory 尚未分配、且尚未将其添加到生产 pool 之前进行配置。
按照管理裸金属主机上的数据磁盘中的说明:
- 验证
elemental-storage-observer.service并检查status.observedStorage。 - 使用稳定 ID 选择每个设备,并选择
Adopt或InitializeIfBlank。 - 使用匹配的
storagectlbinary 进行验证,并以原子方式修补声明;在需要时,同时修补其初始化批准。 - 等待
StoragePrepared=True/AllRequiredVolumesPrepared和status.storage.phase=Prepared。
如果不应管理任何磁盘,请省略 spec.storage,或将其设置为 volumes: []。存储 controller 会将该 inventory 收敛到 Unmanaged,并设置 StoragePrepared=True/NoManagedVolumes,且不会执行任何磁盘操作。
步骤 2:创建 MachineInventoryPool 资源
每个角色创建一个 pool。pool reconciler 会验证每个成员是否存在,计算容量计数器,并将 baremetal.alauda.io/pool=<pool-name> annotation 写入 inventory。
关键参数:
应用并验证:
健康的 pool 会报告 Ready=True、total = len(spec.machineInventories) 和 available = total - allocated - preparing - reprovisioning - unavailable。spec.machineInventories 中列出的 inventory 如果未通过验证(缺失、plan secret 缺失、Ready=False 或存储未准备好),会增加 pool 的 unavailable 计数器,并显示在 MembersValid condition 中。非空的存储声明是分配门槛:只有在基于最新 observation 成功完成 Prepare 后,该 inventory 才会对 CAPI 处于 Available 状态。
将 control-plane pool 的大小设置为至少 KubeadmControlPlane.spec.replicas。将 worker pool 的大小设置为至少 MachineDeployment.spec.replicas。对于滚动升级,pool 必须容纳完整的 replica 数量——provider 会在同一个 pool 中采用先删除后添加的语义,绝不会同时执行两者。
步骤 3:创建控制平面集群资源
创建 BaremetalCluster(声明所选的控制平面 endpoint 模式)、控制平面 BaremetalMachineTemplate(指向控制平面 pool)、KubeadmControlPlane(replicas + kubeadm 配置)以及 CAPI Cluster。
Bare Metal API 在同一操作流程中支持两种 endpoint 模式:
Internal:provider 部署 Alive,并协调 VIP 和控制平面后端成员。External:provider 跳过 Alive;负载均衡器所有者维护 listener、健康检查和后端成员。
在下面的 manifest 中使用 <control-plane-load-balancer-type> 选择模式。
使用 OS image 中内置的 Kubernetes image
受支持的裸金属 OS image 会在 cloud.alauda.io/alauda 下预加载 kubeadm 控制平面、CoreDNS 和 etcd image。在 KCP 配置中保留该 repository,并使用 OS Support Matrix 中的组件 tag。不要将其替换为 <registry-address>/tkestack:这会生成与 OS 中预加载的 image 不匹配的 image 引用。OS 会通过 containerd 配置其内置的 pause image;不要将 pod-infra-container-image 添加到 KCP kubelet 参数中。
完整配置参考
下面的示例使用最小化的 KubeadmControlPlane。如需生产环境推荐的完整加固配置文件——包括 admission、audit、kubelet 补丁和 encryption provider——请参阅附录中的完整 KubeadmControlPlane 配置。
集群 annotation。 裸金属 provider 在 reconcile 期间依赖一组 Cluster annotation。operator 必须设置的权威 annotation 如下:
BaremetalCluster 参数:
应用并观察:
每个新的控制平面 BaremetalMachine 都会推进 Pending → Allocated → Reprovisioning → Running。观察:
BaremetalMachine.status.machineInventoryRef.name—— 被选中的 inventory。BaremetalMachine.status.planSecretRef.name—— 正在驱动的 plan secret。该 secret 携带 annotationbaremetal.alauda.io/plan.type=reprovision。MachineInventory.status.plan.state—— 主机完成cloud-init clean、elemental upgrade、重启以及kubeadm init/join后变为Applied。BaremetalCluster.status.conditions[EndpointReady]—— 配置的控制平面 endpoint 可访问后变为 true。
裸金属 provider 不支持单节点控制平面。至少置备三个控制平面 replica(KubeadmControlPlane.spec.replicas: 3),以确保 etcd 保持仲裁。在 Internal 模式下,相同节点还会参与 Alive VIP 仲裁。
步骤 4:部署工作节点
控制平面 Ready 后,创建 worker BaremetalMachineTemplate、worker KubeadmConfigTemplate 和 MachineDeployment。
确认 worker pool 容量
status.available 必须至少等于目标 replica 数量。如果需要额外容量,请注册更多主机(在这些主机上启动 SeedImage ISO——参见步骤 1),在每个 inventory 仍未分配时准备任何托管存储,然后将其名称添加到 spec.machineInventories。
以此方式添加的主机会经历与原始节点相同的首次启动流程,因此必须满足相同的先决条件:网络连接中所述的网络路径,以及主机时间同步中的时钟门槛。请为新主机确认这两项,不要假定交付时获得的批准涵盖其子网和硬件时钟。
配置 worker BaremetalMachineTemplate
关键参数:
配置 bootstrap template
imagePullCredentialsVerificationPolicy: NeverVerify 仅从 Kubernetes 1.35 开始需要。使用 Kubernetes 1.34 或更早版本创建 worker 时,请省略此参数。
provider 会在将 bootstrap user-data 写入 reprovision plan 之前进行最小化规范化,因此请将以下字段从 template 中省略:
- Hostname / FQDN —— 自动根据
MachineInventoryPool.spec.machineInventories[].hostname设置(省略时使用 inventory 名称)。 kubeletExtraArgs.provider-id—— 自动设置为baremetal:///<inventory-name>。nodeRegistration.criSocket—— 未设置时自动设置为unix:///var/run/containerd/containerd.sock。
规范化后的 user-data 也会写回 bootstrap secret 中的 data["resolved-value"],以便调试;原始 data["value"] 保持不变。
配置 MachineDeployment
关键参数:
应用并观察:
集群验证
使用 kubectl
验证控制平面端点
确认配置的模式和端点:
对于 Internal,验证 Alive 状态和节点前置条件:
在每个控制平面节点上运行以下命令,而不是在管理集群上运行:
对于 External,根据External LoadBalancer contract 验证负载均衡器前端和每个后端。确认负载均衡器所有者已注册当前所有控制平面节点,并确认每个后端的 HTTPS /healthz 返回 HTTP 200。
预期结果
成功创建的集群应显示:
Cluster.status.conditions[Ready]=True。KubeadmControlPlane个副本全部为Ready。- 每个
BaremetalMachine.status.phase=Running和status.ready=true。 - 每个使用的
MachineInventory.status.plan.state=Applied都在其 plan secret 上带有注解baremetal.alauda.io/plan.type=reprovision(这是注解而不是标签——-o jsonpath='{.metadata.annotations}')。 - 每个使用的、
spec.storage.volumes[]非空的 inventory 都报告status.storage.phase=Active、StoragePrepared=True和StorageActive=True;对应的BaremetalMachine报告StorageReady=True/AllVolumesReady。 MachineInventoryPool.status满足available + allocated + preparing + reprovisioning + unavailable = total。- Kubernetes Nodes 均为 Ready。
- 对于
Internal,Alive Pods 均为 Ready,并且可以通过自建 VIP 访问 API。 - 对于
External,负载均衡器前端可访问,并且其后端列表与当前控制平面节点匹配。
常见故障模式
有关完整的 operator 侧状态机参考(每个 condition reason 和恢复操作),请参阅 Provider Overview → clean / reprovision plans。
后续步骤
创建集群后:
附录
完整的 KubeadmControlPlane 配置
生产环境裸金属集群推荐使用的加固配置——包括准入控制、审计策略、kubelet 补丁、加密 provider 和 IPv6 绑定地址。请替换解析占位符值表中的占位符。
仅从 Kubernetes 1.35 开始才需要 imagePullCredentialsVerificationPolicy: NeverVerify。使用 Kubernetes 1.34 或更早版本创建集群时,请省略此参数。
Worker bootstrap 采用对称配置——有关 worker KubeadmConfigTemplate,请参阅配置 Bootstrap 模板。