#安装 VMware vSphere Provider

本文介绍如何安装 Virtualization Platform 的 Infrastructure Provider 和 Cluster Bootstrap Provider，以及如何验证所需的 Cluster API 组件在 global 集群上可用。

#适用场景

在安装 global 集群后、在 VMware vSphere 上创建第一个业务集群之前完成此页面中的操作。无论 global 集群自身运行在哪种 IaaS 平台上，都必须执行此操作。在灾难恢复 (DR) 对中，请在两个 global 集群上完成此操作，以便备用集群在故障转移后能够协调相同的业务集群。将软件包上传到每个 global 集群。

这是一项独立于安装 global 集群中 provider 操作的任务。后者会将 provider 软件包上传到临时引导集群，以创建 global 集群本身。

#先决条件

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

• 你可以访问 global 集群。
• 你可以访问 Customer Portal 以下载 provider 软件包。
• 集群将通过 VSphereCluster.spec.identityRef 引用的 vCenter 账户可以列出、创建和设置 VM 自定义属性。授予 Global → Manage custom attributes 和 Global → Set custom attribute 权限。每当 VSphereCluster 或其 CAPI Cluster 携带任何 vsphere.cluster.x-k8s.io/* annotation 时，provider 都需要这些权限；如果缺少权限，VM reconciliation 会失败，而不是跳过元数据写入。
• 要创建或升级业务集群，请针对 active management cluster 操作，而不是灾难恢复备用集群。请参阅备用管理集群。

#步骤

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 是一个 Aligned 扩展，会随 global 集群的 Distribution Version 升级一同升级。按照升级前准备中的说明，使用 violet 发布目标版本的 provider 软件包；随后，CVO 会在集群升级过程中升级已安装的集群插件。请参阅升级 global 集群的 Distribution Version。

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

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

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

• 在较早版本的 provider 上创建的集群会保留其外部 LoadBalancer，且无法采用 Self-built VIP。端点是在部署时确定的：集群运行期间无法调整，升级也不是更改端点的时机——在运行中的集群上填写 spec.controlPlaneLoadBalancer 会被拒绝。请参阅控制平面端点模式。
• pool 会保留创建时使用的磁盘列表。spec.configs[].ephemeralDisks[] 是 provider v1.0.17 中新增的，但升级不会将任何现有磁盘移入其中：在较早版本的 provider 上创建的集群会继续将 /var/cpaas、/var/lib/containerd 和 /var/lib/etcd 作为持久磁盘。新集群所记录的持久磁盘与临时磁盘拆分布局是在创建时确定的。请参阅标准数据磁盘。
• 通过 guestinfo user data 传递的来宾系统端更改（例如 pod 日志重定位）只有在节点被替换时才会应用。请参阅重定位 pod 日志目录。

请使用验证安装中的检查确认结果，然后读取一个 pool：

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

升级前已预配的每个磁盘都会显示其阶段，并且 status.configStatuses[].reclaimStatus 已被清除。尚无任何 Machine 分配过的 slot 上的磁盘还没有 VMDK，因此不会有记录；这是预期情况，并不表示迁移未完成。

#Standby Management Clusters

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

• 仍会协调由保留的 global 集群拥有的对象。
• 每隔 30 秒跳过并重新排队其他所有对象。
• 如果无法确定对象所属的集群名称，也会跳过该对象。

请勿在备用管理集群上创建或升级业务集群。 协调器会静默地不执行任何操作——不会更改条件，也不会在资源上显示错误，因此工作流看起来像是停滞，而不是被阻止。

开始前请检查：

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

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

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

#后续步骤

安装 provider 后，请继续：

• VMware vSphere Infrastructure Preparation
• 在 VMware vSphere 上创建集群
• 在 VMware vSphere 上升级 Kubernetes
• VMware vSphere Provider