#VMware vSphere Provider 安装

本文介绍如何安装 VMware vSphere Infrastructure Provider，并验证所需的 Cluster API 组件在 global 集群上可用。本页中的 provider 版本、CRD 集合和 admission webhooks 已针对 VMware vSphere Provider v1.0.17 完成验证。

#前提条件

安装 provider 前，请确保满足以下条件：

• 您可以访问 global 集群。
• 您可以访问 Customer Portal 以下载 provider 软件包。
• 您知道计划安装的平台版本和 provider 软件包版本。本页针对 v1.0.17。
• 集群将通过 VSphereCluster.spec.identityRef 引用的 vCenter 账户可以列出、创建和设置 VM 自定义属性。请授予 Global → Manage custom attributes 和 Global → Set custom attribute 权限。每当 VSphereCluster 或其 CAPI Cluster 携带任何 vsphere.cluster.x-k8s.io/* 注释时，provider 都需要这些权限；如果缺少权限，VM reconciliation 将失败，而不是跳过元数据写入。
• global 集群是活动管理集群，而不是灾难恢复备用集群。请参阅 Standby Management Clusters。

#操作步骤

kubectl get minfo -l cpaas.io/module-name=cluster-api-provider-vsphere
kubectl get minfo -l cpaas.io/module-name=cluster-api-provider-kubeadm

kubectl get crd | grep -E '^vsphere[a-z]+\.infrastructure\.cluster\.x-k8s\.io\b'

kubectl get validatingwebhookconfiguration \
  -o jsonpath='{range .items[*]}{range .webhooks[*]}{.name}{"\n"}{end}{end}' \
  | grep -E 'vsphere|capv'

#升级 Provider

按照安装 Provider 的相同方式进行升级：上传更新后的软件包，并更新 global 集群上的集群插件。

升级还会更新 Provider CRD。某些字段会在不同版本之间移动，但现有资源会自动迁移：不要手动编辑 VSphereMachineConfigPool 或任何其他 Provider 对象以匹配新 schema，也不要删除并重新创建对象。升级后的首次协调过程中，控制器会将每个对象更新为当前布局：

• 不会触碰控制平面端点。现有集群会保持 spec.controlPlaneLoadBalancer 未设置，这正是外部 LoadBalancer 的状态，并且会一直保持不变：API server 地址不会更改，也不会向业务集群部署任何内容。
• 以前记录在 spec.configs[].persistentDisks[].volumePath 和 .diskUUID 上的每个磁盘状态，以及 status.configStatuses[].reclaimStatus 下每个 slot 的回收状态，都会合并到 status.persistentDiskStatuses[] 中。正在进行的回收会保留其阶段和任务引用并继续执行，随后清除 reclaimStatus，使状态只有一个真实来源。
• 已弃用的 spec 字段会保留在对象中。请将其视为历史记录，并改为读取 status.persistentDiskStatuses[]。
• 迁移不会覆盖已设置的值，因此可以安全地重复执行。磁盘部分仅记录状态，并且会在联系 vCenter 之前运行，因此即使 vCenter 无法访问也能完成。
• 迁移仅涵盖 Provider 自身的资源。准入 webhook 要求在 Cluster API 对象上设置的发布值——maxSurge、replicas、maxUnavailable——会经过验证，但绝不会被重写，因此现有的不包含这些值的 KubeadmControlPlane 或 MachineDeployment 仍必须手动修正。请参阅根据准入规则检查 manifest。

业务集群中的任何内容都不会被触碰，也不会替换任何 VM。在升级前，需要了解以下三个影响：

• 在早期 Provider 上创建的集群会保留其外部 LoadBalancer，无法采用 Self-built VIP。端点是在部署时选择的：集群运行期间无法调整，升级也不是更改端点的时机——在运行中的集群上填入 spec.controlPlaneLoadBalancer 会被拒绝。请参阅控制平面端点模式。
• 一个池会保留其创建时使用的磁盘列表。spec.configs[].ephemeralDisks[] 是此版本新增的，但升级不会将现有磁盘移入其中：在早期 Provider 上创建的集群会继续将 /var/cpaas、/var/lib/containerd 和 /var/lib/etcd 作为持久磁盘，而处于 InUse 或 Released 状态的 slot 会拒绝删除或重塑任一列表中的磁盘。新集群文档中介绍的持久磁盘与临时磁盘拆分属于创建时布局。请参阅标准数据磁盘。
• 通过 guestinfo 用户数据交付的来宾侧更改（例如 pod 日志迁移）只有在节点被替换时才会应用到节点。请参阅迁移 pod 日志目录。

按照验证安装中的检查确认结果，然后读取一个池：

kubectl -n <namespace> get vspheremachineconfigpool <pool_name> \
  -o jsonpath='{range .status.persistentDiskStatuses[*]}{.hostname}{" "}{.name}{" "}{.phase}{"\n"}{end}'

升级前已完成配置的每个磁盘都会显示一个阶段，并且 status.configStatuses[].reclaimStatus 已消失。从未被任何 Machine 分配过的 slot 上的磁盘尚无 VMDK，因此不会有记录；这是预期行为，并不表示迁移不完整。

#Standby 管理集群

只要 etcd-sync ConfigMap 存在于 kube-public 命名空间中，Provider 就会将管理集群视为灾难恢复备用集群：

• 由保留的 global 集群拥有的对象仍会进行调谐。
• 所有其他对象都会被跳过，并每 30 秒重新入队。
• 无法确定集群名称的对象也会被跳过。

请勿针对灾难恢复备用管理集群创建或升级业务集群。 调谐器会静默地执行 no-op——资源上的 condition 不会发生变化，也不会显示任何错误，因此该工作流看起来像是停滞了，而不是被阻止。

开始前请检查：

kubectl -n kube-public get configmap etcd-sync -o name 2>/dev/null || echo "not standby"

一个常见错误是检查 kube-system。ConfigMap 位于 kube-public 中。

有关灾难恢复工作流本身，请参阅Global Cluster 灾难恢复。

#后续步骤

安装 Provider 后，继续执行以下操作：

• VMware vSphere 基础设施准备
• 在 VMware vSphere 上创建集群
• 在 VMware vSphere 上升级集群
• VMware vSphere Provider
• Release Notes