This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

备份和还原 vSphere 上的管理和工作负载集群基础架构（技术预览版）

本主题介绍如何在 vSphere 上通过以下方法备份和还原具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 的集群基础架构：

  • 使用 Velero 备份和还原独立管理集群上的工作负载集群对象，以及
  • 从其配置文件重新创建独立管理集群
注意

  • VMware不支持使用 Velero 备份 TKG 独立管理集群。
  • 如果在部署独立管理集群后重新配置该集群，按照此处所述重新创建该集群可能不会恢复其所有资源。

要备份和还原具有独立管理集群的 Tanzu Kubernetes Grid (TKG) 工作负载集群上托管的工作负载和动态存储卷，请参见备份和还原集群工作负载。

要备份和还原 vSphere with Tanzu 集群（包括主管集群及其创建的工作负载集群），请参见 VMware vSphere 8.0 文档中的备份和还原 vSphere with Tanzu。

注意

  • 此功能处于不受支持的技术预览版状态；请参见 TKG 功能状态。

设置 Velero

您可以使用 Velero（开源社区标准工具）备份和还原 TKG 独立管理集群基础架构和工作负载。

Velero 支持各种存储提供程序以存储其备份。Velero 还支持：

  • 预挂接和后挂接备份和还原，以在备份和还原事件之前或之后运行自定义进程。
  • 排除不适合备份/还原的工作负载或集群状态的各个方面。

Tanzu Kubernetes Grid 订阅包括对 VMware 测试的、兼容的 Velero 发行版的支持，可从 Tanzu Kubernetes Grid 下载页面获取。

要备份和还原 TKG 集群，您需要：

完成上述必备条件后，还可以使用 Velero 在集群之间迁移工作负载。有关说明，请参见 Velero 文档中的集群迁移和资源筛选。

安装 Velero CLI

注意

如果已安装 Velero CLI v1.9.x 或更低版本（随早期版本的 TKG 一起分发），则需要升级到 v1.10.3。较旧的 Velero 版本不能与 v1.10 及更高版本中使用的 CRD 一起使用。有关信息，请参见下面的升级 Velero。

要安装 Velero CLI v1.10.3，请执行以下操作：

  1. 转到 Tanzu Kubernetes Grid 下载页面，然后使用您的 VMware Customer Connect 凭据登录。
  2. 在产品下载下，单击转到下载 (Go to Downloads)。
  3. 滚动到 Velero 条目，然后下载适用于您的工作站操作系统的 Velero CLI .gz 文件。其文件名以 velero-linux-、velero-mac- 或 velero-windows64- 开头。

  4. 使用 gunzip 命令或您选择的解压缩工具解压缩二进制文件：

    gzip -d <RELEASE-TARBALL-NAME>.gz

  5. 将适用于您的平台的 CLI 二进制文件重命名为 velero，确保它是可执行的，然后将其添加到 PATH。

    macOS 和 Linux
    1. 将二进制文件移入 /usr/local/bin 文件夹并将其重命名为 velero。
    2. 将文件指定为可执行文件：
    chmod +x /usr/local/bin/velero
    Windows
    1. 创建新的 Program Files\velero 文件夹并将二进制文件复制到其中。
    2. 将二进制文件重命名为 velero.exe。
    3. 右键单击 velero 文件夹，选择属性 (Properties) > 安全 (Security)，并确保您的用户帐户具有完全控制 (Full Control) 权限。
    4. 使用 Windows Search 搜索 env。
    5. 选择编辑系统环境变量 (Edit the system environment variables)，然后单击环境变量 (Environment Variables)按钮。
    6. 选择系统变量 (System variables)下的 Path，然后单击编辑 (Edit)。
    7. 单击新建 (New)以添加新行，然后输入 velero 二进制文件的路径。

升级 Velero

Velero v1.10.3 使用的 CRD 与 v1.9.x 不同。此外，Velero v1.10 采用 Kopia with Restic 作为上载程序，这导致组件和命令的命名以及 Velero 运行方式发生了一些更改。有关 v1.9.x 和 v1.10 之间的破坏性更改的详细信息，请参见 Velero v1.10 Changelog 中的重大更改。如果安装了具有先前版本的 TKG 的 Velero v1.9.x，则必须升级 Velero。

  1. 按照安装 Velero CLI 中的过程安装 Velero v1.10.3。

  2. 使用 Velero v1.10 二进制文件更新 CRD 定义。

    velero install --crds-only --dry-run -o yaml | kubectl apply -f -

  3. 更新 Velero 部署和守护进程集配置，以匹配在 Velero v1.10 中发生的组件重命名。

    在以下命令中，uploader_type 可以是 restic 或 kopia。

    kubectl get deploy -n velero -ojson \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"server\",#\"server\",\"--uploader-type=$uploader_type\",#g" \
| sed "s#default-volumes-to-restic#default-volumes-to-fs-backup#g" \
| sed "s#default-restic-prune-frequency#default-repo-maintain-frequency#g" \
| sed "s#restic-timeout#fs-backup-timeout#g" \
| kubectl apply -f -

  4. （可选）如果使用的是 restic 守护进程集，请重命名相应的组件。

    echo $(kubectl get ds -n velero restic -ojson) \
| sed "s#\"image\"\: \"velero\/velero\:v[0-9]*.[0-9]*.[0-9]\"#\"image\"\: \"velero\/velero\:v1.10.0\"#g" \
| sed "s#\"name\"\: \"restic\"#\"name\"\: \"node-agent\"#g" \
| sed "s#\[ \"restic\",#\[ \"node-agent\",#g" \
| kubectl apply -f -
kubectl delete ds -n velero restic --force --grace-period 0

有关详细信息，请参见 Velero 文档中的升级至 Velero 1.10。

设置存储提供程序

要备份 Tanzu Kubernetes Grid 工作负载集群内容，您需要以下存储位置：

  • 集群中 Kubernetes 元数据的集群对象存储备份
  • 集群使用的数据的卷快照

请参见 Velero 文档中的 备份存储位置和卷快照位置。Velero 支持各种存储提供程序，这些提供程序可以是：

  • 联机云存储提供程序。
  • 用于代理或气隙环境的内部部署对象存储服务，例如 MinIO。

VMware 建议将唯一的存储桶专用于每个集群。

要设置 MinIO，请执行以下操作：

  1. 使用 MinIO 凭据和存储位置运行 minio 容器映像，例如：

    $ docker run -d --name minio --rm -p 9000:9000 -e "MINIO_ACCESS_KEY=minio" -e "MINIO_SECRET_KEY=minio123" -e "MINIO_DEFAULT_BUCKETS=mgmt" gcr.io/velero-gcp/bitnami/minio:2021.6.17-debian-10-r7

  2. 将凭据保存到本地文件以传递到 velero install 的 --secret-file 选项，例如：

    [default]
aws_access_key_id=minio
aws_secret_access_key=minio123

vSphere 的存储

在 vSphere 上，集群对象存储备份和卷快照将保存到同一存储位置。此位置必须是 Amazon Web Services (AWS) 或 S3 提供程序（如 MinIO）上与 S3 兼容的外部存储。

要为 vSphere 上的 Velero 设置存储，请参见适用于 v1.5.1 插件的 Vanilla Kubernetes 集群中的 Velero Plugin for vSphere。

用于 AWS 的存储和 AWS 上的存储

要为 AWS 上的 Velero 设置存储，请按照适用于 AWS 存储库的 Velero 插件中的过程操作：

  1. 创建 S3 存储桶。

  2. 设置 Velero 的权限。

根据需要为每个插件设置 S3 存储。对象存储插件存储和检索集群对象备份，卷快照程序存储和检索数据卷。

用于 Azure 的存储和 Azure 上的存储

要为 Azure 上的 Velero 设置存储，请按照适用于 Azure 存储库的 Velero 插件中的过程操作：

  1. 创建 Azure 存储帐户和 blob 容器

  2. 获取包含虚拟机和磁盘的资源组

  3. 设置 Velero 的权限

根据需要为每个插件设置 S3 存储。对象存储插件存储和检索集群对象备份，卷快照程序存储和检索数据卷。

将 Velero 服务器部署到管理集群

要备份工作负载集群对象，请将 Velero v1.10.3 服务器安装到独立管理集群并验证安装。

Velero 安装选项

要安装 Velero，请使用以下选项运行 velero install：

  • --provider $PROVIDER：例如，aws
  • --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1
  • --bucket $BUCKET：S3 存储桶的名称
  • --backup-location-config region=$REGION：存储桶所在的 AWS 地理区域
  • --snapshot-location-config region=$REGION：存储桶所在的 AWS 地理区域
  • （可选）--kubeconfig将 Velero 服务器安装到当前默认集群以外的集群。

  • （可选）--secret-file ./VELERO-CREDS 授予 Velero 访问 S3 存储桶的权限的一种方法是向该选项传递一个本地 VELERO-CREDS 文件，该文件如下所示：

    [default]
aws_access_key_id=<AWS_ACCESS_KEY_ID>
aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>

  • 有关其他选项，请参见安装和启动 Velero。

运行 velero install 命令以在集群上创建一个名为 velero 的命名空间，并在其中放置一个名为 velero 的部署。

需要以下设置：

  • 管理集群插件：需要以下插件。该选项会暂停集群并收集与正在备份的集群相关的资源。
    --plugins projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.0_vmware.1
    注意

    您可以添加多个以逗号分隔的选项。例如：

    --plugins projects.registry.vmware.com/tkg/velero/velero-plugin-for-aws:v1.6.2_vmware.1,projects.registry.vmware.com/tkg/velero/velero-mgmt-cluster-plugin:v0.2.0_vmware.1
  • 无快照位置：要备份集群基础架构，请勿设置 --snapshot-location-config

验证 Velero 安装

velero install 命令完成后，确认 Velero 已成功安装：

  1. 确认 Velero Pod 的状态为 Running：

    kubectl -n velero get pod
NAME                      READY   STATUS    RESTARTS   AGE
velero-78fdbcd446-v5cqr   1/1     Running   0          3h41m

  2. 验证备份位置是否处于 Available 阶段：

    velero backup-location get
NAME      PROVIDER   BUCKET/PREFIX   PHASE       LAST VALIDATED                  ACCESS MODE   DEFAULT
default   aws        mgmt            Available   2022-11-11 05:55:55 +0000 UTC   ReadWrite     true

备份工作负载集群对象

要备份由独立管理集群管理的所有工作负载集群对象，请运行：

velero backup create my-backup --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --wait
注意

  • --exclude-namespaces tkg-system 排除管理集群本身。

  • --include-resources cluster.cluster.x-k8s.io 包括工作负载集群对象

  • VMware 建议在进行任何结构更改（如纵向扩展或横向缩减）后立即备份工作负载集群。这可避免备份对象和物理基础架构之间出现不匹配问题，从而避免还原过程失败。

调度备份

在最近一次备份后更改集群对象时，还原后系统的状态与所需的最新状态不匹配。此问题称为“偏差”。有关如何从某些常见类型的偏差中检测和恢复的信息，请参见下面的处理偏差部分。

为了最大程度减少偏差，VMware 建议使用 Velero 安排频繁的定期备份。例如，要每天备份所有工作负载集群并将每个备份保留 14 天，请执行以下操作：

velero create schedule daily-bak --schedule="@every 24h"  --exclude-namespaces tkg-system --include-resources cluster.cluster.x-k8s.io --ttl 336h0m0s

有关更多 Velero 调度选项，请参见 Velero 文档中的调度备份。

还原后重新生成 kubeconfig 文件

使用 Velero 还原工作负载集群后，需要将其新的 kubeconfig 文件分发给使用该集群的任何人员：

  1. 重新生成 kubeconfig：

    tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

  2. 将上述命令的输出分发给使用集群的任何人员，以替换其旧的 kubeconfig 文件。

完成还原

要还原独立管理集群及其管理的工作负载集群对象，请从其配置文件重新创建管理集群，使用 Velero 还原其工作负载集群，并将新的 kubeconfig 文件分发给使用这些文件的人员：

  1. 如果怀疑工作负载集群对象的最新备份与其当前运行状态之间存在偏差，请使用偏差检测器工具生成修复报告，如使用偏差检测器中所述。

  2. 确保最初部署管理集群后对管理集群所做的任何配置更改都反映在其配置文件或环境变量中。否则，它不会还原到其最新状态。

  3. 从配置文件 mgmt-cluster-config.yaml 重新创建管理集群，如从配置文件部署管理集群中所述。

    • 如果已将管理集群或其工作负载集群部署到 vSphere 上的多个可用区，如跨多个可用区运行集群中所述，还包含具有 VSphereFailureDomain 和 VSphereDeploymentZone 对象定义的文件，例如，通过在 --az-file vsphere-zones.yaml 命令中包含 tanzu mc create。

  4. 创建管理集群后，应只有一个 TKR：

    tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.26.8---vmware.2-tkg.1  v1.26.8+vmware.1-tkg.1  True        True

  5. 等待几分钟，直到备份的工作负载集群使用的所有 TKR 变得可用：

    tanzu kubernetes-release get
NAME                       VERSION                  COMPATIBLE  ACTIVE  UPDATES AVAILABLE
v1.24.17---vmware.2-tkg.2  v1.24.17+vmware.2-tkg.2  True        True
v1.25.13---vmware.1-tkg.1  v1.25.13+vmware.1-tkg.1  True        True
v1.26.8---vmware.2-tkg.1   v1.26.8+vmware.1-tkg.1   True        True

  6. 按照上述将 Velero 服务器部署到集群说明在管理集群上安装 Velero。确保凭据和备份位置配置设置具有与执行备份时相同的值。

  7. Velero 安装后，运行 velero backup get 直到备份同步且命令列出要使用的备份：

    velero backup get
NAME                 STATUS      ERRORS   WARNINGS   CREATED                         EXPIRES   STORAGE LOCATION   SELECTOR
my-backup            Completed   0        0          2022-12-07 17:10:42 +0000 UTC   24d       default            <none>

  8. 运行 velero restore create 以还原工作负载集群资源。VMware 建议使用最新的备份：

    velero restore create my-restore --from-backup my-backup --wait

    还原完成后，集群将处于 createdStalled 状态：

    tanzu cluster list
NAME                NAMESPACE  STATUS          CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    createdStalled  0/3           0/3      v1.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

  9. 修补集群对象以将其 paused 属性设置为 false。这是必需的，因为在新的管理集群上以 paused 状态重新创建了集群对象，以防止其控制器尝试协调：

    • 要在还原集群后对其取消暂停，请运行：

      kubectl -n my-namespace patch cluster CLUSTER-NAME --type merge -p '{"spec":{"paused":false}}'

    • 要取消暂停多个命名空间中的所有集群，请运行以下脚本：

      #!/bin/bash

for ns in $(kubectl get ns -o custom-columns=":metadata.name" | grep -v "tkg-system");
do
      clusters=$(kubectl -n $ns get cluster -o name)
      if [[ -n $clusters ]];then
              kubectl -n $ns patch $clusters --type merge -p '{"spec":{"paused":false}}'
      fi
done

  10. 确认所有工作负载集群都处于 running 状态，例如：

    tanzu cluster list
NAME                NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES         ROLES   PLAN  TKR
tkg-vc-antrea       default    running  3/3           3/3      v1.26.8+vmware.1   <none>  prod  v1.26.8---vmware.2-tkg.1

  11. 对于每个工作负载集群，运行 tanzu cluster get CLUSTER-NAME 以检查所有组件是否都处于 running 状态，例如：

    tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  3/3           3/3      v1.26.8+vmware.1 <none>  v1.26.8---vmware.2-tkg.1

Details:

NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
/tkg-vc-antrea                                                True                     4h14m
├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-s6kl5  True                     4h36m
├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-ch5hn      True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-8gfvt                         True                     4h14m
│ ├─Machine/tkg-vc-antrea-ch5hn-vdcrp                         True                     4h23m
│ └─Machine/tkg-vc-antrea-ch5hn-x7nmm                         True                     4h32m
└─Workers
  ├─MachineDeployment/tkg-vc-antrea-md-0-8b8zn                True                     4h23m
  │ └─Machine/tkg-vc-antrea-md-0-8b8zn-798d5b8897-bnxn9       True                     4h24m
  ├─MachineDeployment/tkg-vc-antrea-md-1-m6dvh                True                     4h24m
  │ └─Machine/tkg-vc-antrea-md-1-m6dvh-79fb858b96-p9667       True                     4h28m
  └─MachineDeployment/tkg-vc-antrea-md-2-brm2m                True                     4h21m
    └─Machine/tkg-vc-antrea-md-2-brm2m-6478cffc5f-tq5cn       True                     4h23m

    所有工作负载集群都运行后，可以使用 Tanzu CLI 管理工作负载集群。

  12. 如果在重新创建管理集群之前运行偏差检测器，请手动修复或调查偏差检测器报告中标记的任何对象，如修复偏差中所述。

  13. 为管理集群及其工作负载集群重新生成并分发新的 kubeconfig 文件：

    1. 重新生成管理集群 kubeconfig：

      tanzu management-cluster kubeconfig get

    2. 对于每个工作负载集群，重新生成其 kubeconfig：

      tanzu cluster kubeconfig get CLUSTER-NAME --namespace NAMESPACE

    3. 将上述命令的输出分发给使用集群的任何人员，以替换其旧的 kubeconfig 文件。

处理偏差

在最近一次备份后更改集群对象时出现偏差，因此还原后系统的状态与所需的最新状态不匹配。

为了最大程度减少偏差，VMware 建议安排频繁的定期备份。

为了帮助检测和修复偏差，可以使用以下各节中所述的偏差检测器工具。

使用偏差检测器

偏差检测器是一个命令行工具，该工具可以：

  • 将 TKG 备份的内容与 TKG 集群对象基础架构的当前状态进行比较，
  • 生成报告，其中列出潜在问题和修复偏差的步骤
重要

偏差检测器处于不受支持的实验状态。偏差很复杂，偏移检测器可能无法检测所有偏差实例。它仅应用作参考，而不应用作常规备份的替代项。

有关如何安装和使用偏差检测器的信息，请参见 VMware 知识库网站上的适用于 Tanzu Kubernetes Grid 管理集群的偏差检测器。整个过程如下：

  1. 从备份还原 TKG 之前，运行 drift-detector 命令以生成报告。

  2. 从最近的备份下载和还原 TKG。

  3. 参阅偏差检测器报告，按照 修复偏差中的指导对还原状态的 TKG 执行修复操作。

修复偏差

偏差情况可能很复杂，但如果您具有偏差检测器报告或以其他方式检测到上次备份后集群对象状态中的某些偏差，则可以按以下方式修复一些常见模式：

  • 失效的工作节点：

    • 额外的未使用节点
    • 如果在备份后减少工作线程节点计数，则可能会出现此情况
    • 缓解通常没有必要。还原后，计算机运行状况检查会删除失效的计算机对象，并创建一个新节点以满足所需的计算机计数。

  • Ghost 工作节点基础架构：

    • 多余的非受管节点基础架构
    • 如果在备份后扩展了工作线程节点计数，则可能会出现此情况

    • 缓解：

      1. 获取工作负载集群 kubeconfig 并将其设置为 kubectl 上下文。

      2. 比较以下 kubectl 和 tanzu 命令的输出：

        # Get the actual worker nodes of the workload cluster
$ kubectl --context tkg-vc-antrea-admin@tkg-vc-antrea get node
NAME                                        STATUS   ROLES           AGE    VERSION
tkg-vc-antrea-md-0-p9vn5-645498f59f-42qh9   Ready    <none>          44m    v1.26.8+vmware.1
tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt   Ready    <none>          114m   v1.26.8+vmware.1
tkg-vc-antrea-wdsfx-2hkxp                   Ready    control-plane   116m   v1.26.8+vmware.1

# Get the worker nodes managed by the TKG
$ tanzu cluster get tkg-vc-antrea
  NAME           NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
  tkg-vc-antrea  default    running  1/1           1/1      v1.26.8+vmware.1  <none>  v1.26.8---vmware.2-tkg.1-zshippable

  Details:

  NAME                                                          READY  SEVERITY  REASON  SINCE  MESSAGE
  /tkg-vc-antrea                                                True                     13m
  ├─ClusterInfrastructure - VSphereCluster/tkg-vc-antrea-b7fr9  True                     13m
  ├─ControlPlane - KubeadmControlPlane/tkg-vc-antrea-wdsfx      True                     13m
  │ └─Machine/tkg-vc-antrea-wdsfx-2hkxp                         True                     13m
  └─Workers
    └─MachineDeployment/tkg-vc-antrea-md-0-p9vn5                True                     13m
      └─Machine/tkg-vc-antrea-md-0-p9vn5-645498f59f-shrpt       True                     13m

      3. 对于 kubectl 列出的每个没有来自 tanzu cluster get 的 Workers > Machine 列表的工作节点：

        1. 将工作节点纵向扩展到预期值，例如：

          tanzu cluster scale ${cluster_name} --worker-machine-count 2
        2. 使用集群 kubeconfig 引流 ghost 节点，ghost 节点会将其工作负载移至 TKG 管理的节点：
          kubectl drain ${node_name} --delete-emptydir-data --ignore-daemonsets

        3. 从集群中移除 ghost 节点：

          kubectl delete node ${node_name}

        4. 登录到 vSphere 或其他基础架构，然后手动移除虚拟机。

  • 控制平面上的失效节点和 ghost 基础架构

    • 控制平面的未使用节点和多余的节点基础架构
    • 如果在备份后替换控制平面节点，可能会出现此情况

    • 缓解：

      1. 获取工作负载集群 kubeconfig 并将其设置为 kubectl 上下文。

      2. 比较以下 kubectl 和 tanzu 命令的输出：

        # Get the actual control plane nodes of the workload cluster
$ kubectl --context wc-admin@wc get node
NAME                             STATUS   ROLES           AGE    VERSION
wc-2cjn4-4xbf8                   Ready    control-plane   107s   v1.26.8+vmware.1
wc-2cjn4-4zljs                   Ready    control-plane   26h    v1.26.8+vmware.1
wc-2cjn4-59v95                   Ready    control-plane   26h    v1.26.8+vmware.1
wc-2cjn4-ncgxb                   Ready    control-plane   25h    v1.26.8+vmware.1
wc-md-0-nl928-5df8b9bfbd-nww2w   Ready    <none>          26h    v1.26.8+vmware.1
wc-md-1-j4m55-589cfcd9d6-jxmvc   Ready    <none>          26h    v1.26.8+vmware.1
wc-md-2-sd4ww-7b7db5dcbb-crwdv   Ready    <none>          26h    v1.26.8+vmware.1

# Get the control plane nodes managed by the TKG
$ tanzu cluster get wc
NAME  NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES        ROLES   TKR
wc    default    updating 4/3           3/3      v1.26.8+vmware.1 <none>  v1.26.8---vmware.2-tkg.1-zshippable

Details:

NAME                                               READY  SEVERITY  REASON  SINCE  MESSAGE
/wc                                                True                     24m
├─ClusterInfrastructure - VSphereCluster/wc-9nq7v  True                     26m
├─ControlPlane - KubeadmControlPlane/wc-2cjn4      True                     24m
│ ├─Machine/wc-2cjn4-4xbf8                         True                     24m
│ ├─Machine/wc-2cjn4-4zljs                         True                     26m
│ └─Machine/wc-2cjn4-59v95                         True                     26m
└─Workers
  ├─MachineDeployment/wc-md-0-nl928                True                     26m
  │ └─Machine/wc-md-0-nl928-5df8b9bfbd-nww2w       True                     26m
  ├─MachineDeployment/wc-md-1-j4m55                True                     26m
  │ └─Machine/wc-md-1-j4m55-589cfcd9d6-jxmvc       True                     26m
  └─MachineDeployment/wc-md-2-sd4ww                True                     26m
    └─Machine/wc-md-2-sd4ww-7b7db5dcbb-crwdv       True                     26m

      3. 对于 kubectl 列出的不具有 tanzu cluster get 中的 ControlPlane > Machine 列表的每个 control-plane 节点：

        1. 删除节点：

          kubectl delete node ${node_name}
        2. 登录到 vSphere 或其他基础架构，然后手动移除虚拟机。
check-circle-line exclamation-circle-line close-line
Scroll to top icon